On Tue, Dec 20, 2016 at 12:18 PM, Vittorio Giovara <[email protected]> wrote: > On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes <[email protected]> wrote: >> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara >> <[email protected]> wrote: >>> On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes <[email protected]> >>> wrote: >>>> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara >>>> <[email protected]> wrote: >>>>> This is the assumption that is made everywhere in the codebase >>>>> and in several specifications too. The added benefit is that any >>>>> variable referencing range can now be simply considered a boolean. >>>>> >>>>> Signed-off-by: Vittorio Giovara <[email protected]> >>>> >>>> >>>> I don't like this. You can assume this in the code if you want to, but >>>> it should be possible to export the difference between unsignaled and >>>> specifically limited from a file. >>> >>> Unsignaled is the default way of notifying limited range, such as h264 >>> or hevc. Also there is not a single codec where this distinction is >>> useful. For all intents and purpose this kind of data is intrinsically >>> a boolean. >> >> And yet there is a difference in the h264/hevc bitstream between the >> element not being in there at all, or it being set to limited. > > umh, no the element not being present simply means that the color > information is missing, so the application is free to do whatever it > wants for the selection of color space and range.
Exactly, and you want to take away the option to tell the application this. > >> 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. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
