On Tue, Dec 20, 2016 at 12:22 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Tue, Dec 20, 2016 at 12:18 PM, Vittorio Giovara > <vittorio.giov...@gmail.com> wrote: >> On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes <h.lepp...@gmail.com> >> wrote: >>> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara >>> <vittorio.giov...@gmail.com> wrote: >>>> On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes <h.lepp...@gmail.com> >>>> wrote: >>>>> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara >>>>> <vittorio.giov...@gmail.com> 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 <vittorio.giov...@gmail.com> >>>>> >>>>> >>>>> 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.
mm would you be okay with moving unspecified to 2 so that at least the most common usecase can be mapped to a bool? >>> 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. -- Vittorio _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
