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. > In mpv, we actually have a function to determines "missing" colorspace > related fields if they're set to unspecified. This way we avoid > ambiguous interpretation of such unspecified flags before they are used > by whatever code is using them. It's especially necessary for the > colorspace, which is usually guessed from the video resolution. You > could invent such a function for AVFrames too. This is probably a good idea, although for the range field there is no reliable analysis or heuristic. In fact even in mpv you implicitly 'guess' an unspecified range is limited for anything except V_LOG which isn't supported here -- Vittorio _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
