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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
