[FFmpeg-devel] [PATCH] avcodec/libx265: Support full range videos

[Michael Niedermayer]

On Sat, May 25, 2019 at 06:31:14PM -0300, James Almer wrote:
> On 5/25/2019 6:03 PM, James Almer wrote:
> > On 5/25/2019 12:50 PM, Derek Buitenhuis wrote:
> >> On 25/05/2019 04:25, James Almer wrote:
> >>>> +
> >>>
> >>> Unnecessary empty line.
> >>
> >> Fixed.
> >>
> >>> Could we not? The idea is to eventually kill these, so we should at
> >>> least try to not make them even more widespread...
> >>
> >> As far as I know, they can't be removed, as there isn't a simple replacement
> >> for some of their functionality. Has this changed?
> > 
> > Paul tried to remove them, but as usual a billion obscure use cases and
> > command lines started to behave differently and he gave up. I don't
> > recall if the issue was in swscale or lavfi, but one of those seems to
> > have some code deeply tied to these pseudo formats and no easy solution
> > for it.
> > 
> >>
> >> Either we finally act on their """deprecation""", or we at least have
> >> consistent behavior. e.g. libx264.c has almost this exact bit of code, and
> >> users would expect libx265.c to behave the same.
> > 
> > libx264 is a very old encoder. New encoders, including this one, vpx and
> > aom, accept only yuv4xxp + color_range value. Is this change really
> > necessary? Why did nobody request it before?
> 
> Ah hell, whatever, just push it. Jeeb pointed out the reason you wrote
> this patch. Reverting this patch in the future should be trivial anyway.
> 

> Anyone wants to write libavscale and solve this mess?

how would rewriting, i presume a libswscale solve a problem 
between libavfiter and its negotiation of pixel formats when they are
split into multiple components instead of an enum?

If i remember correctly, the problem was something like that the
negotiation system for pixel formats in libafilter is designed for a single
value as in an enum. It could be changed to a struct and still treat that
as a single value and that might work (with some issues). But when its a 
series of values which are treated more independantly while they are not 
actually independant then corner cases start falling appart.
I dont even think this is so much an issue with how things are designed
but more a fundamental issue of negotiation
A list of enums or structs can fully capture what some component supports.
2 seperate lists one of pixel formats and one of color ranges which are
independant no longer achieves this

Now i may be misremembering parts of this, after all i was IIRC not closely
involved in this ...
But i think the first step to solve it is to understand what the problem is

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190527/3aa68101/attachment.sig>