On Tue, Dec 20, 2016 at 5:48 PM, Vittorio Giovara <[email protected]> wrote: > On Tue, Dec 20, 2016 at 5:14 PM, Hendrik Leppkes <[email protected]> wrote: >> On Tue, Dec 20, 2016 at 4:59 PM, Vittorio Giovara >> <[email protected]> wrote: >>> On Tue, Dec 20, 2016 at 4:10 PM, wm4 <[email protected]> wrote: >>>> On Tue, 20 Dec 2016 12:29:20 +0100 >>>> Vittorio Giovara <[email protected]> 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.
Seems equally pointless. And using an enum straight as a boolean is the actual error prone thing, since you brought that up. I don't see the advantage in using "if (range)" over "if (range == AVCOL_RANGE_JPEG)", if anything the second is much clearer to what it means. Personally I would introduce aliases for those names tho, mpeg/jpeg seems a bit uncommon to me. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
