[FFmpeg-devel] [PATCH 0/3] Pass colour range from source to sink v2

[wm4]

On Wed, 21 Feb 2018 14:25:35 -0800
Philip Langdale <philipl at overt.org> wrote:

> This change turns out to be a subset of a much bigger change that Paul
> put together back in December and which didn't get enough review
> coverage for him to comfortably push. I didn't know about that, so I
> redid a bunch of stuff, but the end result is what I think is a logical
> subset of the complete YUVJ purge which can be reviewed and pushed on
> its own.
> 
> Unlike Paul's complete set of changes, this does not include any
> replacement of YUVJ code with color_range code and doesn't include
> any range negotiation. It is strictly just passing the range from one
> end to the other, assuming a range value is set by some means. This
> is more useful than you may think as many demuxers and decoders set
> the range, and many encoders and muxers respect the range.
> 
> Today, we have a colour range property on decoders and encoders. The
> decoder sets the property on itself to reflect what it is decoding,
> and the user sets it on the encoder to reflect what is being encoded.
> 
> However, we don't support a way to pass it through filter chains and
> 'ffmpeg' does not make any attempt to set it on the encoder.
> 
> This set of changes introduces a way to do this, by defining a new
> filter link property, and allowing it to be set on a buffersrc and
> read back from a buffersink.
> 
> We then extend the various relevant filters to set the property
> when they manipulate the colour range, and finally, we get 'ffmpeg'
> to get and set the range appropriately.
> 
> After this change, it is now possible to correctly pass the colour
> range through a pipeline so that it it influences encoder behaviour,
> and is recorded in the container, where relevant.

To be honest, I think we _could_ initialize the encoder AVCodecContext
color_range field from the first AVFrame. AFAIK we wait with encoder
initialization anyway until the first frame is filtered.

Do encoders (which support jpeg range) currently do the right thing if
you only set the "normal" pixfmt and the wanted color_range? The mjpeg
encoder and a bunch of other things work only with the J formats
anyway. What's the plan to deal with that?