Support per-frame QP configuration by VideoEncoder #270

daijh · 2021-06-07T04:02:36Z

Customize BRCs by applications, in addition to CBR/VBR provided by VideoEncoder.

Some applications prefer to implement its own BRC according to per-frame QP, to better response to network bandwidth estimation. One such per-frame QP BRC implement can be found:
https://github.com/intel/libmebo/blob/master/explainer.md

dictionary VideoEncoderEncodeOptions {
  boolean keyFrame = false;

  // proposal
  unsigned long QP;
};

The text was updated successfully, but these errors were encountered:

daijh · 2021-06-07T04:03:36Z

#56 Refine encoder configuration of bitrate and/or quantization

chcunningham · 2021-06-11T19:13:19Z

Thanks for filing @daijh. Can you say more on why per-frame is important vs making this part of the config (affecting N frames). I'm surprised we would want to adjust it with every frame (e.g. 30 times a second).

daijh · 2021-06-15T04:15:53Z

@chcunningham
The BRC is something intrinsic of the video encoder, and it usually cannot be much changed after platform shipped.
Some developers would like to use their own BRC cross all platforms, instead of platform intrinsic BRC.
Per-frame QP enables the developer to implement customized BRC, by set QP of every frame according to previous encoded frames size and bitrate budget, as mentioned in #56

Djuffin · 2022-06-28T03:29:36Z

As I see it we’ll need to make at least 3 following changes in the API. I'm curious to know what the community thinks

New bitrate mode.

We’ll introduce a new value to BitrateMode enum : ‘qp’

QP range discovery. Either

A new optional field to VideoEncoderConfig dictionary : ULongRange qpRange
This range is populated by VideoEncoder.isConfiguSupported() when an input config has bitrateMode=’qp’. It gives API users a range of expected QP values. VideoEncoder.configure() expects that config.qpRange value will be the same as the one returned by VideoEncoder.isConfiguSupported(). This works as an extra check that API users are aware of the expected QP range.
QP range is always assumed to be between 1 and 100, and it is up to the implementation to scale it to values expected by underlying encoders.

Setting a QP value. Either

A new optional field in VideoEncoderEncodeOptions dictionary : unsigned long qp. API users can set a new QP value while submitting a new frame to VideoEncoder.encode().
If a new QP value is not given, it’s assumed to be the same as the previous frame.
A new optional field in VideoEncoderConfig dictionary unsigned long qp. API users will need to reconfigure a video encoder by calling VideoEncoder.configure() each time they want to change the QP value.

It also might be a good idea to replace QP by a more generic term.

aboba · 2022-06-29T21:05:27Z

Some thoughts:

For setting the QP value, it seems like option 1 (using encode()) is easier than option 2 (configure()).
For the QP range, I have a mild preference for handling it on a per-codec basis (option 1).

chcunningham · 2022-07-27T16:42:19Z

Editors Call discussion w/ @aboba

Thanks @Djuffin for moving this along!

For bitrate mode: Could we just use "VBR" here? I like reasoning about both cases as "variable".

Related questions:

should we define the behavior where setting per-frame QP comes to override any previously configured config.bitrate? (do underlying libraries support combining these things? My hunch is it's probably either-or).

For range discovery:

I also like 1 better. I wonder if we need to return a supported range, or if we can instead get by with a static codec specific range defined in each codec registration?
If range-support is impl specific, would you support throwing an error (rather than silent failure) for unsupported values.
Do you know the semantic meaning of QP across codecs. For ex, is it always as simple as a single value? I've heard AV1 may have different quantizer knobs for y, u, and v (a matrix)? I expect that most codecs have a common notion, but if we find codec-specific the details have enough variance, we may prefer to have codec specific knob (e.g. config.avc.qp vs config.av1.qp[Y_PLANE]) as a way to cleanly define the semantics.

For setting a QP value, I also prefer option 1. This is a per-frame config, so doing it per-frame feels right.

chcunningham · 2022-08-02T21:05:10Z

Chrome folks met just now. Notes:

For bitrate mode: Could we just use "VBR" here? I like reasoning about both cases as "variable".

Simplicity of just doing VBR is clear, but also this is modeled on AVCodec (Mac), which has a distinct "mode" for setting QP. No super strong opinions though.

should we define the behavior where setting per-frame QP comes to override any previously configured config.bitrate? (do underlying libraries support combining these things? My hunch is it's probably either-or).

@Djuffin assumed they would be exclusive. Combining is an error.

I also like 1 better. I wonder if we need to return a supported range, or if we can instead get by with a static codec specific range defined in each codec registration?

Some preference for codec-specific route w/ ranges in registry.

If range-support is impl specific, would you support throwing an error (rather than silent failure) for unsupported values.

Throw an unsupported error.

Do you know the semantic meaning of QP across codecs....

Seems like another good reason to consider codec specific route (w/ codec specific names if appropriate).

dalecurtis · 2022-08-02T21:12:32Z

I spoke with James Zern from the encoding team today:

He indicated that QP based configuration is uncommon, but necessary in the long tail of support. I.e., lets ensure we have engaged partners before undertaking this.
He indicated there will be more than just QP parameters needed in the long tail, so codec specific dictionaries sounded good. Especially for real time tuning.
Offloading the standardization of the parameters to the respective codec standards and codec registrations sounded good.
He indicated most folks will probably just want a simple quality selector or some concept of presets. E.g., we could define a set of low, medium, high, ultra presets in each codec registration.

Djuffin · 2023-02-01T01:43:04Z

API proposal: #633

This is PR introduces codec specific quantizer fields in VideoEncoderEncodeOptions dictionary.

dictionary VideoEncoderEncodeOptions {
  boolean keyFrame;
  VideoEncoderEncodeOptionsForVp9 vp9;
  VideoEncoderEncodeOptionsForAv1 av1;
};

dictionary VideoEncoderEncodeOptionsForVp9 {
 unsigned short? quantizer;
}

Djuffin · 2023-02-28T07:41:05Z

Alternative API #642

This is PR introduces a generic quantizer field in VideoEncoderEncodeOptions dictionary.

dictionary VideoEncoderEncodeOptions {
  boolean keyFrame;
  double? quantizer;
};

Djuffin · 2023-03-07T22:54:11Z

On March 7th w3c media working group decided that codec specific quantizer fields are preferred.
API proposal: #633

Rationale:

There might be codecs in the future that don't have the concept of QP
Having qp values for different codecs in different places will prevent websites from accidentally using qp value from one codec for another codec.

aboba · 2023-03-16T16:15:03Z

@dalecurtis Can we close this issue?

dalecurtis · 2023-03-16T16:43:39Z

Now landed.

This value is used by VideoEncoder.encode() if VideoEncoder is configured with "quantizer" bitrate mode. Followup for: #270

@padenot

* Make VideoFrame.timestamp non-nullable. Current spec always defines a timestamp for user constructed VideoFrames. Setting a real timestamp is especially important for frames that sent to VideoEncoder, as the timestamp is used for rate control. With no way for users to generate a null timestamp, it makes sense to make the type non-nullable. This also aligns with AudioData.timestamp. This patch also addresses the one lingering opporutnity for null timestamps: ImageDecoder used null as a default for output VideoFrames. This patch updates that default to be zero. While it could be argued that null is technically more correct (we don't often present images on timeline), this is outweighed by the practical impact of using zero which allows us to define a clear contract: VideoFrame always has a timestamp. * Add AudioDecoder 'dequeue' event * Add notes clarifying VideoFrame timestamp * [WebCodecs] Fix markup for notes within lists A `<div>` cannot appear within a `<dl>`. Bikeshed used to automatically tie notes with the previous `<dd>` in a list but no longer does that, and generated HTML is now invalid. * [Webcodecs] Fix markdown typos for definition lists Trailing `</dt>` has nothing to do here and now makes Bikeshed generate invalid HTML markup. * Describe that WG consensus is needed to add registry entries * fix getAvccBox * Revise processing model, begin transitioning AudioDecoder * Use coded size in mp4-decode sample Fixes w3c#495 * Fix typo in processing loop * Explicitly define codec saturation * Remove ImageTrack.onchange event. We decided not to do this, but forgot to remove it from the spec. The fact that decode() calls stall until the next frame is available and the availability of the `completed` promise make it largely unnecessary. Clients which don't want to wait for for `completed` can instead handle a RangeError exception during decode() if no more frames remain. While not ideal it's inefficient to implement something like onchange since common formats like GIF would require us to attempt decode in order to update the frame count. * Add HEVC registration * Fix H.264 biblio title * Apply suggestions from code review Co-authored-by: Chris Needham <chrisn@users.noreply.github.com> * Finish transitioning AudioDecoder to new model * update HTTP RFC * Add missing AudoiDecoder slot init * Transition VideoDecoder to new model * Transition AudioEncoder to new model * Transition VideoEncoder to new model * Transition VideoFrame to new model * Transition ImageDecoder to new model * line wrap fix * Schedule the dequeue event to coalesce events and avoid spam * Add dequeue event to VideoDecoder * Add dequeue event to VideoEncoder * Add dequeue event to AudioEncoder * Fix missing removal from ImageTrack change event. Overlooked in initial PR. * Add missing biblio entry to HEVC registration * Revert "Fix the problem that getAvccBox cannot get the value when the first track of the video is not AVC" * Revert "Revert "Fix the problem that getAvccBox cannot get the value when the first track of the video is not AVC"" * Add audio-video-player sample Authored in collaboration w/ padenot@ Originally hosted here: https://github.com/chcunningham/wc-talk This is mostly a copy/paste of that, but I've moved demuxing and decoding to a dedicated "media worker" and tried to clean things up a bit. * Cleanup for audio_video_player sample * Rearrange audio_video_player.html * Add audio_video_player.html to samples index * Move/rename mp4-decode sample * Rewview feedback * Update index links for player sample to use netlify * Update hevc_codec_registration.src.html * Remove unused property from example code * Move Netlify _headers to top level * Move Netlify _headers back to samples folder Since we're only interested in publishing samples to Netlify, let's only publish the `samples` folder with Netlify instead of the contents of the `gh-pages` branch. * Codec registry: escape "*" in codec strings As the spec uses Markdown, some of the `*` characters were interpreted by Bikeshed as a request to turn the string in italics, whereas we actually want to render the asterisk characters. For instance, `hev1.*, hvc1.*` was rendered as `hev1. <em>, hvc1.<em>`. This update escapes the asterisk character in codec strings. * Refactor * Address PR comments. * Support decoding of hevc. Added the parser part. Actual hevc content is not uploaded unless this is neccessary. * Fix link to the registry in the README. This fixes w3c#540. * Move common samples files to library/ Preparing to reuse these files in a new sample. * Fix visible rect comparison to use strict equality to allow for visible rect of the same size as coded size This fixes w3c#515. * Add HEVC registry entry generated output to .gitignore * Split the privacy and security considerations sections in the registry entries and the registry document This fixes w3c#544. * Add new pull demuxer interface. Inject demuxers. Rather than have the renderer create a specific demuxer, let's inject a demuxer that uses a common interface. This allows us to re-use the same renderer with the a variety of demuxers (including the forthcoming FFmpeg based demuxer). * Add Acknowledgements - long overdue! * Add frameDuration attribute to OpusEncoderConfig * [Publication job] Add HEVC WebCodecs registration Add HEVC (H.265) WebCodecs Registration to the auto-publish script so that the specs gets published to the `gh-pages` branch (and to /TR later on when a first draft note will have been published) * fix a typo in 8.2.1 * change type of frameDuration in OpusEncoderConfig to unsigned long long, and meaning of it to microseconds as well * Introduce VideoFrame metadata * Copy metadata from HTMLVideoElement if init metadata is absent. Fix some additional nits. * Additional nit * Remove ImageDecoderInit.premultiplyAlpha Fixes w3c#508 * Fix build error and rename getMetadata to metadata * Throw when calling metadata() in case VideoFrame is closed * Address review comments on ImageDecoder spec change. Fixes issues addressed in review. * Fix indent for paragraphs. Fixes preview build error. * Fix reference to mime type RFC. Fixes build error. * change the type of frameDuration in OpusEncoderConfig to unsigned long; add validation checking steps to it * Fixup nullability. * Remove escape. * Remove unrelated change. * Introduce metadata registry * fix wrong reference of RFC7587 in opus_codec_registration * wrap ptime with backticks in opus_codec_registration.src.html * Add WCG color spaces. * Add spec text for serializable encoded chunks. Chromium launched with this support, but apparently the spec text was never updated. Sorry about that! Fixes: w3c#289 * Change library to lib * Fix typos * Remove EnforceRange to framrate definition since EnforceRange is only for integer types * Address some of Chris's feedback * Update video_frame_metadata_registry.src.html * Add policy for changes to existing registry entries This attempts to formalize the policy for changes proposed in: w3c#571 (comment) * Update .github/workflows/auto-publish.yml Co-authored-by: François Daoust <fd@tidoust.net> * merge fix * Add AllowShared to EncodedVideoChunkInit data * Address Chris comments * Make VideoDecoderConfig.description AllowShared * Link to netlify-powered URL for samples (w3c#585) * Move note on meaningful timestamp to VideoFrame constructor it really is about the timestamp in VideoFrameInit, not the attribute of VideoFrame * When serializing some WebCodecs objects with forStorage=true, throw DataCloneError instead of TypeError This applies to EncodedVideoChunk, EncodedAudioChunk, AudioData and VideoFrame, and fixes issue w3c#589. * Add null defaults to VideoColorSpaceInit members No need to do in prose what Web IDL can achieve. * Add VideoFrame Metadata Registry to local biblio The entry is needed until the registry gets published and can be added to official databases of specs. * Add OpusEncoderConfig parameters * Add defaults to booleans * Move VideoFrameMetadata dfn to WebCodecs A registry cannot contain normative IDL, so the base definition of the `VideoFrameMetadata` dictionary should remain in WebCodecs. Also note that while the registry will be published as a "W3C Draft Registry", the document in the repo remains an "Editor's Draft". Updating the status accordingly. * Add more defaults, notes * Remove text description of defaults * Change frameDuration to microseconds * Linkify to Opus RFC 6716 * Expand acronyms * Address minor comment * Change type to long long * Introduce VideoFrame metadata * Copy metadata from HTMLVideoElement if init metadata is absent. Fix some additional nits. * Additional nit * Fix build error and rename getMetadata to metadata * Throw when calling metadata() in case VideoFrame is closed * Introduce metadata registry * Address some of Chris's feedback * Update video_frame_metadata_registry.src.html * Update .github/workflows/auto-publish.yml Co-authored-by: François Daoust <fd@tidoust.net> * Address Chris comments * Add VideoFrame Metadata Registry to local biblio The entry is needed until the registry gets published and can be added to official databases of specs. * Add null defaults to VideoColorSpaceInit members No need to do in prose what Web IDL can achieve. * Move note on meaningful timestamp to VideoFrame constructor it really is about the timestamp in VideoFrameInit, not the attribute of VideoFrame * Move VideoFrameMetadata dfn to WebCodecs A registry cannot contain normative IDL, so the base definition of the `VideoFrameMetadata` dictionary should remain in WebCodecs. Also note that while the registry will be published as a "W3C Draft Registry", the document in the repo remains an "Editor's Draft". Updating the status accordingly. * When serializing some WebCodecs objects with forStorage=true, throw DataCloneError instead of TypeError This applies to EncodedVideoChunk, EncodedAudioChunk, AudioData and VideoFrame, and fixes issue w3c#589. * Add OpusEncoderConfig parameters * Add defaults to booleans * Add more defaults, notes * Remove text description of defaults * Linkify to Opus RFC 6716 * Expand acronyms * Address minor comment * Add requirements to metadata registry definition Covers adding, changing, and deprecating registry entries * Clarify metadata entry requirements * Clarify metadata entry requirements * Mark Chris as a former editor of WebCodecs specs. * Update WGSL of renderer_webgpu.js This `textureSampleLevel()` overload was moved to a new `textureSampleBaseClampToEdge()` builtin * Add a way of specifying blockSize and compressLevel to FLAC encoder * This fixes w3c#595. Add a way of specifying frame duration to FLAC encoder config * Fix memory layout of NV12 image example According to the text: - The coded width and coded height must be even. So image cannot be 16x9. This update makes it 16x10 - There should be one Y byte per pixel, so 16x10 Y bytes (example only had 14 bytes per row) - The U and V components are sub-sampled horizontally and vertically by a factor of 2, and interleaved, so there should 16x10/4 = 40 UV blocks (example only sub-sampled horizontally). This update also fixes occurrences of "horizontaly". * Drop local custom definitions where possible Bikeshed now contains cross-reference anchors from Webref, which means it now knows about a number of "new" specifications, including WebCodecs, Media Capture specs, the Infra standard, etc. See announcement at: https://lists.w3.org/Archives/Public/spec-prod/2023JanMar/0004.html In turn, this means that WebCodecs specs no longer need to list and maintain a local database of cross-references, except in rare cases (such as when a term is not exported by the referenced spec). This update drops local definitions where ever possible, adjusting references in the prose as needed. A few definitions remain here and there to list external terms that are not exported, along with a couple of linking defaults in the WebCodecs spec. One temporary hiccup: the markup definitions of `CanvasImageSource` and `drawImage()` are slightly incorrect. Hence the need to re-define them locally. To be removed once the HTML spec is fixed. In codec registration specs, note that the form `{{VideoDecoderConfig/description|VideoDecoderConfig.description}}` is used to output `VideoDecoderConfig.description` (with the right link to the WebCodecs spec) when merely having `description` would be ambiguous. * Drop local definition of now fixed HTML anchors Definitions fixed upstream so local definitions are no longer needed: whatwg/html#8736 * Add VideoFrame Metadata Registry to the Readme * Editorial: fix typos, add missing links * fix several typoes * restore 3 wrong fixes according to the comments of @padenot * Add WebCodecs in Worker sample This is a sample demonstrating WebCodecs Encode and Decode in a worker. A live demo is here: https://webrtc.internaut.com/wc/wcWorker/ * Cleanup debug messages * Add more granular error messages * Add CSS, update codec configuration * Fix HEVC codec string * Fix HEVC codec string * Remove remaining "var" usage * Renove hard coded HEVC error * Update encode/decode and queue depth statistics * Remove encoder and decoder metrics * Restore queue size metrics, change default bitrate and GoP size * Fix cfg.svc bug * Add bitrate mode selection * Adjust default bitrate * Add WebCodecs in Worker link on samples page Add a link to the WebCodecs in Worker sample, once merged. Related: w3c#583 * Add nixxquality's fixes See: w3c#332 (comment) * Fix close algorithm for non-null VideoFrame timestamps. Timestamp shouldn't be null anymore, so remove language around setting it to null. * Fix a link URL Fix the link to the "WebCodecs in Worker" sample * Annotate encoder/decoders with EventTarget on ondequeue events. Seems to be an oversight from when ondequeue events were added. Allows the idlharness.js test to start passing. * Fix usage of {Audio/Video}Decoder.isConfigSupported() in example * Introducing a new 'quantizer' mode for VideoEncoder A codec specific quantizer is specified for each video frame for constant quality or fine tuned external rate control. * Use is not origin-clean concept in VideoFrame constructor * support specify audio encode bitrateMode interface * Move the attribute of bitrateMode from to OpusEncoderConfigAudioEncoderConfig * Per frame quantizer option for Av1. This value is used by VideoEncoder.encode() if VideoEncoder is configured with "quantizer" bitrate mode. * Enable configuration of AV1 screen content coding tools Fixes w3c#646 Rebase of w3c#652 * Add screen content coding tools as an encoder configuration option * Update the abstract * fix 2 grammatical errors * Add per-frame QP support to AVC This value is used by VideoEncoder.encode() if VideoEncoder is configured with "quantizer" bitrate mode. Followup for: w3c#270 * Av1 -> Avc * Clone configuration should perform a deep copy This fixes w3c#485. * Address review comment. * Define videoSource before videoSelect.onchange to avoid ReferenceError. * Add VideoFrameBufferInit.transfer * Editorial: account for SharedArrayBuffer change in Web IDL See whatwg/webidl#1311 for context. * Fix usage of RFC2119 words in privacy and security section This fixes w3c#644. * Add AudioDataInit.transfer * Remaining normative language issues Fixes w3c#689 * Replace RFC2119 wording in Security Connsiderations * Add to codec registry requirements Changes: - Adds a requirement for a public specification that is stable - The WG may consult external expertise as part of its review - Fixes the numbering in the source document * Fix HEVC registration text * Add ImageDecoderInit.transfer * Fix typo multiply -> mutliply Also trigger spec publishing * Add H.265/VP8/VP9/AV1 samples to video decoding page. This should be helpful for developer to test the browser implement or compare the performance of different codecs on different platforms. Note that the previous version of mp4box is not able to parse AV1 video codec string correctly, so to support AV1, we also need to upgrade mp4box to version 0.5.2. Safari doesn't support `gl.createShader` so change the default renderer to `2d`. All sample videos are encoded from `bbb-1920x1080-cfg06.mp4` using ffmpeg and shaka packager. * Remove stable from codec registry requirements * Revert unwanted change * Add Eugene Zemtsov to the list of editors --------- Co-authored-by: Chris Cunningham <chcunningham@chromium.org> Co-authored-by: Francois Daoust <fd@tidoust.net> Co-authored-by: Chris Needham <chris.needham@bbc.co.uk> Co-authored-by: Vinlic <vinlic@vinlic.com> Co-authored-by: Dan Sanders <sandersd@google.com> Co-authored-by: Dale Curtis <dalecurtis@chromium.org> Co-authored-by: Chris Needham <chrisn@users.noreply.github.com> Co-authored-by: Christoph Guttandin <chrisguttandin@media-codings.com> Co-authored-by: Dan Sanders <sandersd@chromium.org> Co-authored-by: Qiu Jianlin <jianlin.qiu@intel.com> Co-authored-by: Paul Adenot <paul@paul.cx> Co-authored-by: bdrtc <webrtc@bytedance.com> Co-authored-by: Youenn Fablet <youennf@gmail.com> Co-authored-by: 何超 <hechao.0520@bytedance.com> Co-authored-by: youennf <youennf@users.noreply.github.com> Co-authored-by: Thomas Guilbert <52718142+tguilbert-google@users.noreply.github.com> Co-authored-by: Dominique Hazael-Massieux <dom@w3.org> Co-authored-by: Thomas Guilbert <tguilbert@chromium.org> Co-authored-by: Bernard Aboba <bernard.aboba@gmail.com> Co-authored-by: mark a. foltz <mfoltz@chromium.org> Co-authored-by: Ben Clayton <bclayton@google.com> Co-authored-by: josephrocca <1167575+josephrocca@users.noreply.github.com> Co-authored-by: Chris James <etcet@users.noreply.github.com> Co-authored-by: Eugene Zemtsov <eugene@chromium.org> Co-authored-by: Chunbo Hua <chunbo.hua@intel.com> Co-authored-by: Anne van Kesteren <annevk@annevk.nl> Co-authored-by: Sida Zhu <zhusida@bytedance.com> Co-authored-by: Eugene Zemtsov <e.zemtsov@gmail.com> Co-authored-by: StaZhu <zhusidayoyo@hotmail.com>

chcunningham added the extension Interface changes that extend without breaking. label Jun 11, 2021

aboba mentioned this issue Sep 30, 2021

Pluggable Congestion Control w3c/webtransport#365

Closed

chcunningham added the TPAC 2022 Issues to discuss in upcoming TPAC meeting label Jul 27, 2022

sandersdan mentioned this issue Oct 12, 2022

Will calling VideoEncoder.configure trigger the next frame to be generated as a key frame? #580

Closed

aboba mentioned this issue Oct 13, 2022

Transport: Encoder Rate Control and congestion control state w3c/media-pipeline-arch#6

Open

aboba mentioned this issue Dec 28, 2022

Processing pipeline: Guidelines on handling backpressure w3c/media-pipeline-arch#8

Open

Djuffin mentioned this issue Feb 1, 2023

Introducing a codec specific 'quantizer' mode for VideoEncoder #633

Merged

Djuffin mentioned this issue Feb 28, 2023

2023-02-28 Add an agenda item for webcodecs w3c/media-wg#39

Merged

dalecurtis closed this as completed Mar 16, 2023

Djuffin mentioned this issue Apr 1, 2023

Per frame quantizer option for Av1. #659

Merged

aboba added a commit that referenced this issue Apr 19, 2023

Add per-frame QP support to AVC

baf8e2f

This value is used by VideoEncoder.encode() if VideoEncoder is configured with "quantizer" bitrate mode. Followup for: #270

aboba mentioned this issue Apr 19, 2023

Add per-frame QP support to AVC #667

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support per-frame QP configuration by VideoEncoder #270

Support per-frame QP configuration by VideoEncoder #270

daijh commented Jun 7, 2021

daijh commented Jun 7, 2021 •

edited

chcunningham commented Jun 11, 2021

daijh commented Jun 15, 2021 •

edited

Djuffin commented Jun 28, 2022

aboba commented Jun 29, 2022

chcunningham commented Jul 27, 2022 •

edited

chcunningham commented Aug 2, 2022

dalecurtis commented Aug 2, 2022

Djuffin commented Feb 1, 2023 •

edited

Djuffin commented Feb 28, 2023 •

edited

Djuffin commented Mar 7, 2023

aboba commented Mar 16, 2023

dalecurtis commented Mar 16, 2023

Support per-frame QP configuration by VideoEncoder #270

Support per-frame QP configuration by VideoEncoder #270

Comments

daijh commented Jun 7, 2021

daijh commented Jun 7, 2021 • edited

chcunningham commented Jun 11, 2021

daijh commented Jun 15, 2021 • edited

Djuffin commented Jun 28, 2022

New bitrate mode.

QP range discovery. Either

Setting a QP value. Either

aboba commented Jun 29, 2022

chcunningham commented Jul 27, 2022 • edited

chcunningham commented Aug 2, 2022

dalecurtis commented Aug 2, 2022

Djuffin commented Feb 1, 2023 • edited

Djuffin commented Feb 28, 2023 • edited

Djuffin commented Mar 7, 2023

aboba commented Mar 16, 2023

dalecurtis commented Mar 16, 2023

daijh commented Jun 7, 2021 •

edited

daijh commented Jun 15, 2021 •

edited

chcunningham commented Jul 27, 2022 •

edited

Djuffin commented Feb 1, 2023 •

edited

Djuffin commented Feb 28, 2023 •

edited