On Tue, Dec 20, 2016 at 3:09 PM, Anton Khirnov <an...@khirnov.net> wrote: > Quoting Vittorio Giovara (2016-12-20 12:29:20) >> mm would you be okay with moving unspecified to 2 so that at least the >> most common usecase can be mapped to a bool? > > I think the API should be designed in such a way that it is hard to use > it incorrectly. Specifically in this case, I think it's better to force > the user to acknowledge that he is making a non-trivial choice (of > treating undefined as some specific value).
I do think this adds unnecessary complexity for literally no gain. Overall moving the "unspecified" value to the last position is a good compromise in my opinion. >> 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. > > This is simply not true. When there is no information about the range, > it is undefined. We should simply make this fact clear to the caller and > leave him to deal with it. We should not invent arbitrary assumptions > and force them upon the caller. No you always have to assume it's either limited or full range, there is no analysis or heuristic that could be use to determine it beforehand, unless it's tagged. And as I said, BT.709 and others explicitly mandate limited color range everywhere. -- Vittorio _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
