This provides experimental support to play again all available video
resolutions, by combining audio and video "adaptive" elementary streams
using an input slave. Not in use by default; use at your own risks.
Again, by allowing to select resolutions lower than 360p, this also
provides mitigation against the throttling issue.
Ref #10237, #27227
This extends the old &fmt=[itag] URL syntax that we still supported all
along to force format selection, and allows choosing from "adaptive"
elementary streams without knowledge of itag specifics and in accordance
with normal resolution preferences.
This also allows playing only the audio part of music videos and
skipping the download of the video part entirely, greatly reducing
bitrate and providing mitigation against the throttling issue.
Ref #10237, #27227
Formats listed under that label are audio-only or video-only elementary
streams, but offer choice encompassing the full array of supported
resolutions, qualities and codecs; whereas classic multiplexed formats
have long been dwindling down to only two formats now, 720p and 360p, or
even 360p only for some content.
For now, these "adaptive" formats are only used if explicitly requested
by itag number.
Ref #10237
The encoder is able to process CVPixelBuffer (chroma CVP*) as input.
Note that this encoder will asynchronously signal its codec extradata at
the first i-frame encoded.
It currently disable B-frame generation since VideotoolBox requires
reordering to happen in the output too, moving the enabling to another
merge request.
Fixes#25152
If the core requests to change the vout format (because it added filters
having a different format), recreate the interop and the filters to
accept the new format without an additional converter.
The core is not ready to support size changes via the "update format"
mechanism.
Attempt to update the vout format only when the only difference between
the old and new format is the chroma.
Refs #1021
The vout is created first, based on the input format. Then filters
(filter_t) could be added, possibly producing pictures in a different
format.
input ---> filters ---> MISMATCH [I420] vout
I420 RGBA
To avoid a mismatch between the output of the last filter and the
expected format of the vout input, a converter was added when necessary
to compensate:
input ---> filters ---> converter ---> [I420] vout
I420 RGBA I420
But this was often a waste, and it caused problems for opaque formats.
Instead, request the vout to adapt itself to the actual format produced
by the last filter. If it can, we can avoid an additional converter.
input ---> filters ---> MISMATCH [I420] vout
I420 RGBA
input ---> filters ------------------> [RGBA] vout
I420 RGBA
If the vout does not support the new format (or does not accept to
update its format), a converter is still added like before.
Co-authored-by: Alexandre Janniaux <ajanni@videolabs.io>
Previous changes were transforming the error path as early return,
leaving a potential indentation level for each commit that could be
removed. This commit is removing them.
No functional changes.
Split the normal path and error path and move the release behind the
error label to remove the handling of the `b_ok` state in the normal
path.
Since returning an error only makes the processing forward to the next
extension to be run, and doesn't fail completely, the label is named
"discard" to signal it will only discard the current extension.
Previous changes were transforming the error path as early return,
leaving a potential indentation level to be removed. This commit is
removing it.
No functional changes.
Previous changes were transforming the error path as early return,
leaving a potential indentation level for each commit that could be
removed. This commit is removing them.
No functional changes.
Pierre Ynard