On Tue, Dec 20, 2016 at 5:14 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Tue, Dec 20, 2016 at 4:59 PM, Vittorio Giovara > <vittorio.giov...@gmail.com> wrote: >> On Tue, Dec 20, 2016 at 4:10 PM, wm4 <nfx...@googlemail.com> wrote: >>> On Tue, 20 Dec 2016 12:29:20 +0100 >>> Vittorio Giovara <vittorio.giov...@gmail.com> wrote: >>> >>>> >>> Also h264/hevc are not the only video codecs on the planet. Implicit >>>> >>> defaults in the data type is the wrong way to go about this, it takes >>>> >>> away any kind of flexibility for no real gain. >>>> >> >>>> >> What kind of flexibility is there now? I cannot think of a case where >>>> >> the current state is nothing more than added complexity. The gain, >>>> >> besides simpler handling of the range, i sthat the data type correctly >>>> >> reflects the only two states in which the range can be found. >>>> > >>>> > Undefined is a perfectly valid state in my book. >>>> >>>> The problem is that the range is never undefined, or when undefined it >>>> is assumed to be limited. This is true in several BT specifications >>>> for example. >>> >>> You're free to assume that unspecified means limited in whatever code >>> consumes the range flag. But the decoder should output what the >>> bitstream contains whenever possible. >> >> Yes I agree, but in this case there are literally two states the pixel >> can be represented, I am having a hard time seeing the advantage of >> moving this complexity to the app. >> > > Its not complexity, if all you care about is if the pixel is full > range or not, you just do (range == AVCOL_RANGE_JPEG), and all is > done, implicit default and everything.
Yes and you have to do this every time you try to access a yuv surface. It's very redundant in my opinion, and error prone. > All your change does is change that condition slightly, it has no real > advantage but does remove the ability to actually specify undefined - > even if apps don't do much with it (but thats irrelevant). No, as I said I can compromise in simply moving "undefined" state to value 2, so that if there is a remote case where this is useful it can be still achieved. If that would be ok I'll send another patch. -- Vittorio _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
