Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Vittorio Giovara]

On Tue, Dec 20, 2016 at 5:54 PM, Hendrik Leppkes  wrote:
> On Tue, Dec 20, 2016 at 5:48 PM, Vittorio Giovara
>>
>> No, as I said I can compromise in simply moving "undefined" state to
>> value 2, so that if there is a remote case where this is useful it can
>> be still achieved. If that would be ok I'll send another patch.
>
> Seems equally pointless. And using an enum straight as a boolean is
> the actual error prone thing, since you brought that up.
> I don't see the advantage in using "if (range)" over "if (range ==
> AVCOL_RANGE_JPEG)", if anything the second is much clearer to what it
> means.

I really disagree but since I'm clearly in the minority I'll withdraw
this patch.

> Personally I would introduce aliases for those names tho,
> mpeg/jpeg seems a bit uncommon to me.

I would be ok with it, will you send a patch? :)
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Hendrik Leppkes]

On Tue, Dec 20, 2016 at 5:48 PM, Vittorio Giovara
 wrote:
> On Tue, Dec 20, 2016 at 5:14 PM, Hendrik Leppkes  wrote:
>> On Tue, Dec 20, 2016 at 4:59 PM, Vittorio Giovara
>>  wrote:
>>> On Tue, Dec 20, 2016 at 4:10 PM, wm4  wrote:
 On Tue, 20 Dec 2016 12:29:20 +0100
 Vittorio Giovara  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.
>
> Yes and you have to do this every time you try to access a yuv
> surface. It's very redundant in my opinion, and error prone.
>
>> 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).
>
> No, as I said I can compromise in simply moving "undefined" state to
> value 2, so that if there is a remote case where this is useful it can
> be still achieved. If that would be ok I'll send another patch.

Seems equally pointless. And using an enum straight as a boolean is
the actual error prone thing, since you brought that up.
I don't see the advantage in using "if (range)" over "if (range ==
AVCOL_RANGE_JPEG)", if anything the second is much clearer to what it
means. Personally I would introduce aliases for those names tho,
mpeg/jpeg seems a bit uncommon to me.

- Hendrik
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Vittorio Giovara]

On Tue, Dec 20, 2016 at 5:14 PM, Hendrik Leppkes  wrote:
> On Tue, Dec 20, 2016 at 4:59 PM, Vittorio Giovara
>  wrote:
>> On Tue, Dec 20, 2016 at 4:10 PM, wm4  wrote:
>>> On Tue, 20 Dec 2016 12:29:20 +0100
>>> Vittorio Giovara  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.

Yes and you have to do this every time you try to access a yuv
surface. It's very redundant in my opinion, and error prone.

> 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).

No, as I said I can compromise in simply moving "undefined" state to
value 2, so that if there is a remote case where this is useful it can
be still achieved. If that would be ok I'll send another patch.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Hendrik Leppkes]

On Tue, Dec 20, 2016 at 4:59 PM, Vittorio Giovara
 wrote:
> On Tue, Dec 20, 2016 at 4:10 PM, wm4  wrote:
>> On Tue, 20 Dec 2016 12:29:20 +0100
>> Vittorio Giovara  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
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Vittorio Giovara]

On Tue, Dec 20, 2016 at 4:10 PM, wm4  wrote:
> On Tue, 20 Dec 2016 12:29:20 +0100
> Vittorio Giovara  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

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Vittorio Giovara]

On Tue, Dec 20, 2016 at 3:09 PM, Anton Khirnov  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

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[wm4]

On Tue, 20 Dec 2016 12:29:20 +0100
Vittorio Giovara  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.

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.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Anton Khirnov]

Quoting Vittorio Giovara (2016-12-20 12:29:20)
> On Tue, Dec 20, 2016 at 12:22 PM, Hendrik Leppkes  wrote:
> > On Tue, Dec 20, 2016 at 12:18 PM, Vittorio Giovara
> >  wrote:
> >> On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes  
> >> wrote:
> >>> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
> >>>  wrote:
>  On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes  
>  wrote:
> > On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
> >  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 
> >
> >
> > 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?

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).

> 
> >>> 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.

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.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Vittorio Giovara]

On Tue, Dec 20, 2016 at 12:22 PM, Hendrik Leppkes  wrote:
> On Tue, Dec 20, 2016 at 12:18 PM, Vittorio Giovara
>  wrote:
>> On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes  
>> wrote:
>>> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
>>>  wrote:
 On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes  
 wrote:
> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
>  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 
>
>
> 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

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Hendrik Leppkes]

On Tue, Dec 20, 2016 at 12:18 PM, Vittorio Giovara
 wrote:
> On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes  wrote:
>> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
>>  wrote:
>>> On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes  
>>> wrote:
 On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
  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 


 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
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Vittorio Giovara]

On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes  wrote:
> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
>  wrote:
>> On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes  
>> wrote:
>>> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
>>>  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 
>>>
>>>
>>> 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.

> 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.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Hendrik Leppkes]

On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
 wrote:
> On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes  wrote:
>> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
>>  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 
>>
>>
>> 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.
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.

- Hendrik
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Vittorio Giovara]

On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes  wrote:
> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
>  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 
>
>
> 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.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Anton Khirnov]

Quoting Hendrik Leppkes (2016-12-20 10:40:41)
> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
>  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 
> 
> 
> 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.

+1

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Hendrik Leppkes]

On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
 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 


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.

- Hendrik
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] [post-bump] pixfmt: Always assume unspecified range as limited

[Vittorio Giovara]

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 
---
This is the first patch I had in mind for the transition period after
the bump, when ABI in not exactly stable.

Unrelated to this patch, is there anything else baking for this time?
Cheers,
Vittorio

 libavutil/pixfmt.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 41498cc..80a0651 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -389,9 +389,9 @@ enum AVColorSpace {
  * MPEG vs JPEG YUV range.
  */
 enum AVColorRange {
-AVCOL_RANGE_UNSPECIFIED = 0,
-AVCOL_RANGE_MPEG= 1, ///< the normal 219*2^(n-8) "MPEG" YUV ranges
-AVCOL_RANGE_JPEG= 2, ///< the normal 2^n-1   "JPEG" YUV ranges
+AVCOL_RANGE_MPEG= 0, ///< the normal 219*2^(n-8) "MPEG" YUV ranges
+AVCOL_RANGE_UNSPECIFIED = AVCOL_RANGE_MPEG,
+AVCOL_RANGE_JPEG= 1, ///< the normal 2^n-1   "JPEG" YUV ranges
 AVCOL_RANGE_NB,  ///< Not part of ABI
 };
 
-- 
2.10.0

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel