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. 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). - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
