Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Paul B Mahol]

On 12/11/17, Hendrik Leppkes  wrote:
> On Mon, Dec 11, 2017 at 3:36 PM, James Almer  wrote:
>> On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
>>> On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol  wrote:
 On 12/11/17, Hendrik Leppkes  wrote:
> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol 
> wrote:
>>>
>>> Fine, but it's inevitable that the encoder supports the J formats
>>> still
>>> for a while.
>>
>>
>> Why are you all dismissive about this?
>
>
> Because we have an established way to remove things like this, and
> that doesn't happen over night.
> Its not ok for stuff to stop working without a replacement in place
> for a sufficient time before that, so people can migrate.
>
> First, implement replacement and add visible deprecation messages -
> and then wait the established deprecation period before actually
> removing it.

 Bullshit, J formats are deprecated for ages.
>>>
>>>
>>> A deprecation is only meaningful if there is actually a replacement
>>> you can use - which did not exist yet.
>>>
>>> Want to encode jpeg right now? Have to use J format. No way around
>>> that. And many more of such cases.
>>> As such, you can't just make the J format non-functional over night.
>>> Thats not going to fly.
>>
>> And how will we get users to migrate? We have printed a "deprecated,
>> don't use" message that has been ignored by absolutely everyone for a
>> whole decade. What could we do or add now that will actually get people
>> to read and pay attention to a "for real now guise" warning?
>>
>> The current warning gives instructions about the supposed replacement,
>> yet it doesn't work. Even if it suddenly starts to work, who the hell is
>> going to try it again after it failed time and time again for like
>> twenty different releases?
>
> Thats no excuse for blindly breaking it without even giving users a
> chance to migrate. Migration period has to be observed. If users still
> don't react, there is nothing we can do about that - but we can do our
> best to give them a chance.
>
> The message currently is being generated by swscale as far as I can
> tell, unless I missed it somewhere else. Moving it to a more prominent
> position (perhaps encoder/filter init) and rewording it would be a
> good start.
>
>>
>>>
>>> Either do it properly, or don't do it at all.
>>
>> Someone finally started to work on getting rid of one the oldest, most
>> annoying hacks in the codebase. Help or suggestions in how to implement
>> said compatibility layer and deprecation period would be much better
>> than this.
>
> We tried suggesting, so we get responses like "this is bullshit".
> Rules apply even to the people that do the work.
>
> Supporting both J and non-J formats in an encoder doesn't require
> help, its as simple as keeping both as supported input formats for the
> encoders and filters, for the time being.
> Or if you want something more elaborate, just re-mapping of the J
> format to non-J + color_range in the generic code somewhere, still
> easy.

I do not plan to ditch J formats immediately from encoders.

I just want there exist both paths one without J and another one with J.

Do you want it in little small steps so everybody can understand problem?

Do you want adding new item(s) to AVCodec? I see no other reason how to proceed.

I would like to make anyone happy, but looks like nobody gives a shit about my
work and instead just want current status.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Paul B Mahol]

On 12/11/17, Paul B Mahol  wrote:
> On 12/11/17, Hendrik Leppkes  wrote:
>> On Mon, Dec 11, 2017 at 3:36 PM, James Almer  wrote:
>>> On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
 On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol  wrote:
> On 12/11/17, Hendrik Leppkes  wrote:
>> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol 
>> wrote:

 Fine, but it's inevitable that the encoder supports the J formats
 still
 for a while.
>>>
>>>
>>> Why are you all dismissive about this?
>>
>>
>> Because we have an established way to remove things like this, and
>> that doesn't happen over night.
>> Its not ok for stuff to stop working without a replacement in place
>> for a sufficient time before that, so people can migrate.
>>
>> First, implement replacement and add visible deprecation messages -
>> and then wait the established deprecation period before actually
>> removing it.
>
> Bullshit, J formats are deprecated for ages.


 A deprecation is only meaningful if there is actually a replacement
 you can use - which did not exist yet.

 Want to encode jpeg right now? Have to use J format. No way around
 that. And many more of such cases.
 As such, you can't just make the J format non-functional over night.
 Thats not going to fly.
>>>
>>> And how will we get users to migrate? We have printed a "deprecated,
>>> don't use" message that has been ignored by absolutely everyone for a
>>> whole decade. What could we do or add now that will actually get people
>>> to read and pay attention to a "for real now guise" warning?
>>>
>>> The current warning gives instructions about the supposed replacement,
>>> yet it doesn't work. Even if it suddenly starts to work, who the hell is
>>> going to try it again after it failed time and time again for like
>>> twenty different releases?
>>
>> Thats no excuse for blindly breaking it without even giving users a
>> chance to migrate. Migration period has to be observed. If users still
>> don't react, there is nothing we can do about that - but we can do our
>> best to give them a chance.
>>
>> The message currently is being generated by swscale as far as I can
>> tell, unless I missed it somewhere else. Moving it to a more prominent
>> position (perhaps encoder/filter init) and rewording it would be a
>> good start.
>>
>>>

 Either do it properly, or don't do it at all.
>>>
>>> Someone finally started to work on getting rid of one the oldest, most
>>> annoying hacks in the codebase. Help or suggestions in how to implement
>>> said compatibility layer and deprecation period would be much better
>>> than this.
>>
>> We tried suggesting, so we get responses like "this is bullshit".
>> Rules apply even to the people that do the work.
>>
>> Supporting both J and non-J formats in an encoder doesn't require
>> help, its as simple as keeping both as supported input formats for the
>> encoders and filters, for the time being.
>> Or if you want something more elaborate, just re-mapping of the J
>> format to non-J + color_range in the generic code somewhere, still
>> easy.
>
> So, do you want color_range as array or as int?
>

Looks nobody have valid opinion. So will aply this as is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Vittorio Giovara]

>* On Sat, Dec 9, 2017 at 10:37 AM, Paul B Mahol > wrote:*
> Endless bikeshed...
Being dismissive to valid points is not good for project health.

> I hate how people can be so ignorant these days.

Can you tone it down a notch maybe? I can't envision a scenario in which
saying this would help
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Paul B Mahol]

On 12/11/17, Hendrik Leppkes  wrote:
> On Mon, Dec 11, 2017 at 3:36 PM, James Almer  wrote:
>> On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
>>> On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol  wrote:
 On 12/11/17, Hendrik Leppkes  wrote:
> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol 
> wrote:
>>>
>>> Fine, but it's inevitable that the encoder supports the J formats
>>> still
>>> for a while.
>>
>>
>> Why are you all dismissive about this?
>
>
> Because we have an established way to remove things like this, and
> that doesn't happen over night.
> Its not ok for stuff to stop working without a replacement in place
> for a sufficient time before that, so people can migrate.
>
> First, implement replacement and add visible deprecation messages -
> and then wait the established deprecation period before actually
> removing it.

 Bullshit, J formats are deprecated for ages.
>>>
>>>
>>> A deprecation is only meaningful if there is actually a replacement
>>> you can use - which did not exist yet.
>>>
>>> Want to encode jpeg right now? Have to use J format. No way around
>>> that. And many more of such cases.
>>> As such, you can't just make the J format non-functional over night.
>>> Thats not going to fly.
>>
>> And how will we get users to migrate? We have printed a "deprecated,
>> don't use" message that has been ignored by absolutely everyone for a
>> whole decade. What could we do or add now that will actually get people
>> to read and pay attention to a "for real now guise" warning?
>>
>> The current warning gives instructions about the supposed replacement,
>> yet it doesn't work. Even if it suddenly starts to work, who the hell is
>> going to try it again after it failed time and time again for like
>> twenty different releases?
>
> Thats no excuse for blindly breaking it without even giving users a
> chance to migrate. Migration period has to be observed. If users still
> don't react, there is nothing we can do about that - but we can do our
> best to give them a chance.
>
> The message currently is being generated by swscale as far as I can
> tell, unless I missed it somewhere else. Moving it to a more prominent
> position (perhaps encoder/filter init) and rewording it would be a
> good start.
>
>>
>>>
>>> Either do it properly, or don't do it at all.
>>
>> Someone finally started to work on getting rid of one the oldest, most
>> annoying hacks in the codebase. Help or suggestions in how to implement
>> said compatibility layer and deprecation period would be much better
>> than this.
>
> We tried suggesting, so we get responses like "this is bullshit".
> Rules apply even to the people that do the work.
>
> Supporting both J and non-J formats in an encoder doesn't require
> help, its as simple as keeping both as supported input formats for the
> encoders and filters, for the time being.
> Or if you want something more elaborate, just re-mapping of the J
> format to non-J + color_range in the generic code somewhere, still
> easy.

So, do you want color_range as array or as int?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Hendrik Leppkes]

On Mon, Dec 11, 2017 at 3:36 PM, James Almer  wrote:
> On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
>> On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol  wrote:
>>> On 12/11/17, Hendrik Leppkes  wrote:
 On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:
>>
>> Fine, but it's inevitable that the encoder supports the J formats still
>> for a while.
>
>
> Why are you all dismissive about this?


 Because we have an established way to remove things like this, and
 that doesn't happen over night.
 Its not ok for stuff to stop working without a replacement in place
 for a sufficient time before that, so people can migrate.

 First, implement replacement and add visible deprecation messages -
 and then wait the established deprecation period before actually
 removing it.
>>>
>>> Bullshit, J formats are deprecated for ages.
>>
>>
>> A deprecation is only meaningful if there is actually a replacement
>> you can use - which did not exist yet.
>>
>> Want to encode jpeg right now? Have to use J format. No way around
>> that. And many more of such cases.
>> As such, you can't just make the J format non-functional over night.
>> Thats not going to fly.
>
> And how will we get users to migrate? We have printed a "deprecated,
> don't use" message that has been ignored by absolutely everyone for a
> whole decade. What could we do or add now that will actually get people
> to read and pay attention to a "for real now guise" warning?
>
> The current warning gives instructions about the supposed replacement,
> yet it doesn't work. Even if it suddenly starts to work, who the hell is
> going to try it again after it failed time and time again for like
> twenty different releases?

Thats no excuse for blindly breaking it without even giving users a
chance to migrate. Migration period has to be observed. If users still
don't react, there is nothing we can do about that - but we can do our
best to give them a chance.

The message currently is being generated by swscale as far as I can
tell, unless I missed it somewhere else. Moving it to a more prominent
position (perhaps encoder/filter init) and rewording it would be a
good start.

>
>>
>> Either do it properly, or don't do it at all.
>
> Someone finally started to work on getting rid of one the oldest, most
> annoying hacks in the codebase. Help or suggestions in how to implement
> said compatibility layer and deprecation period would be much better
> than this.

We tried suggesting, so we get responses like "this is bullshit".
Rules apply even to the people that do the work.

Supporting both J and non-J formats in an encoder doesn't require
help, its as simple as keeping both as supported input formats for the
encoders and filters, for the time being.
Or if you want something more elaborate, just re-mapping of the J
format to non-J + color_range in the generic code somewhere, still
easy.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[wm4]

On Mon, 11 Dec 2017 11:36:52 -0300
James Almer  wrote:

> On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
> > On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol  wrote:  
> >> On 12/11/17, Hendrik Leppkes  wrote:  
> >>> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:  
> >
> > Fine, but it's inevitable that the encoder supports the J formats still
> > for a while.  
> 
> 
>  Why are you all dismissive about this?  
> >>>
> >>>
> >>> Because we have an established way to remove things like this, and
> >>> that doesn't happen over night.
> >>> Its not ok for stuff to stop working without a replacement in place
> >>> for a sufficient time before that, so people can migrate.
> >>>
> >>> First, implement replacement and add visible deprecation messages -
> >>> and then wait the established deprecation period before actually
> >>> removing it.  
> >>
> >> Bullshit, J formats are deprecated for ages.  
> > 
> > 
> > A deprecation is only meaningful if there is actually a replacement
> > you can use - which did not exist yet.
> > 
> > Want to encode jpeg right now? Have to use J format. No way around
> > that. And many more of such cases.
> > As such, you can't just make the J format non-functional over night.
> > Thats not going to fly.  
> 
> And how will we get users to migrate? We have printed a "deprecated,
> don't use" message that has been ignored by absolutely everyone for a
> whole decade. What could we do or add now that will actually get people
> to read and pay attention to a "for real now guise" warning?
> 
> The current warning gives instructions about the supposed replacement,
> yet it doesn't work. Even if it suddenly starts to work, who the hell is
> going to try it again after it failed time and time again for like
> twenty different releases?

Well, whatever we do, the first step is adding a replacement mechanism
that actually works, without breaking J formats.

That includes not removing the J formats from libswscale or the jpeg
encoder.

Then we need to adjust the warning message (maybe add another one for
specifically for the jpeg encoder?), and note the change in APIchanges.

2 years later we drop the J formats and all compatibility code.

> > 
> > Either do it properly, or don't do it at all.  
> 
> Someone finally started to work on getting rid of one the oldest, most
> annoying hacks in the codebase. Help or suggestions in how to implement
> said compatibility layer and deprecation period would be much better
> than this.

+1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[James Almer]

On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
> On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol  wrote:
>> On 12/11/17, Hendrik Leppkes  wrote:
>>> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:
>
> Fine, but it's inevitable that the encoder supports the J formats still
> for a while.


 Why are you all dismissive about this?
>>>
>>>
>>> Because we have an established way to remove things like this, and
>>> that doesn't happen over night.
>>> Its not ok for stuff to stop working without a replacement in place
>>> for a sufficient time before that, so people can migrate.
>>>
>>> First, implement replacement and add visible deprecation messages -
>>> and then wait the established deprecation period before actually
>>> removing it.
>>
>> Bullshit, J formats are deprecated for ages.
> 
> 
> A deprecation is only meaningful if there is actually a replacement
> you can use - which did not exist yet.
> 
> Want to encode jpeg right now? Have to use J format. No way around
> that. And many more of such cases.
> As such, you can't just make the J format non-functional over night.
> Thats not going to fly.

And how will we get users to migrate? We have printed a "deprecated,
don't use" message that has been ignored by absolutely everyone for a
whole decade. What could we do or add now that will actually get people
to read and pay attention to a "for real now guise" warning?

The current warning gives instructions about the supposed replacement,
yet it doesn't work. Even if it suddenly starts to work, who the hell is
going to try it again after it failed time and time again for like
twenty different releases?

> 
> Either do it properly, or don't do it at all.

Someone finally started to work on getting rid of one the oldest, most
annoying hacks in the codebase. Help or suggestions in how to implement
said compatibility layer and deprecation period would be much better
than this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[wm4]

On Mon, 11 Dec 2017 15:28:31 +0100
Hendrik Leppkes  wrote:

> On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol  wrote:
> > On 12/11/17, Hendrik Leppkes  wrote:  
> >> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:  
> 
>  Fine, but it's inevitable that the encoder supports the J formats still
>  for a while.  
> >>>
> >>>
> >>> Why are you all dismissive about this?  
> >>
> >>
> >> Because we have an established way to remove things like this, and
> >> that doesn't happen over night.
> >> Its not ok for stuff to stop working without a replacement in place
> >> for a sufficient time before that, so people can migrate.
> >>
> >> First, implement replacement and add visible deprecation messages -
> >> and then wait the established deprecation period before actually
> >> removing it.  
> >
> > Bullshit, J formats are deprecated for ages.  
> 
> 
> A deprecation is only meaningful if there is actually a replacement
> you can use - which did not exist yet.
> 
> Want to encode jpeg right now? Have to use J format. No way around
> that. And many more of such cases.
> As such, you can't just make the J format non-functional over night.
> Thats not going to fly.
> 
> Either do it properly, or don't do it at all.

Yeah, it would be ok if there had been a method to do this without J
formats before. For example, I don't think it would be a problem to
change jpg _decoding_ to output normal pixfmts (if it doesn't already
do that).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Nicolas George]

Paul B Mahol (2017-12-11):
> Endless bikeshed...

It is not bikeshedding, it is preparing for the future. You should try
maintaining part of the framework, for a change. That is not as simple
as porting a filter or implementing a demuxer.

If the API is not well designed, it will need to be changed, which is
much more work than if it was done correctly from the start.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Hendrik Leppkes]

On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol  wrote:
> On 12/11/17, Hendrik Leppkes  wrote:
>> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:

 Fine, but it's inevitable that the encoder supports the J formats still
 for a while.
>>>
>>>
>>> Why are you all dismissive about this?
>>
>>
>> Because we have an established way to remove things like this, and
>> that doesn't happen over night.
>> Its not ok for stuff to stop working without a replacement in place
>> for a sufficient time before that, so people can migrate.
>>
>> First, implement replacement and add visible deprecation messages -
>> and then wait the established deprecation period before actually
>> removing it.
>
> Bullshit, J formats are deprecated for ages.


A deprecation is only meaningful if there is actually a replacement
you can use - which did not exist yet.

Want to encode jpeg right now? Have to use J format. No way around
that. And many more of such cases.
As such, you can't just make the J format non-functional over night.
Thats not going to fly.

Either do it properly, or don't do it at all.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Tobias Rapp]

On 11.12.2017 14:22, Paul B Mahol wrote:

On 12/11/17, Hendrik Leppkes  wrote:

On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:


Fine, but it's inevitable that the encoder supports the J formats still
for a while.



Why are you all dismissive about this?



Because we have an established way to remove things like this, and
that doesn't happen over night.
Its not ok for stuff to stop working without a replacement in place
for a sufficient time before that, so people can migrate.

First, implement replacement and add visible deprecation messages -
and then wait the established deprecation period before actually
removing it.


Bullshit, J formats are deprecated for ages.


ffmpeg -i input.avi -f avi -codec:v mjpeg -pix_fmt yuvj420p -y output.avi

Prints warning "deprecated pixel format".

ffmpeg -i input.avi -f avi -codec:v mjpeg -pix_fmt yuv420p -color_range 
jpeg -y output.avi


Prints warning "incompatible pixel format" plus "deprecated pixel format".

Guess which command-line is currently implemented in my (and I assume 
most other) scripts. I very much welcome your work on cleaning up this 
mess, but please allow for some migration period.


Best regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[wm4]

On Mon, 11 Dec 2017 08:32:52 -0500
"Ronald S. Bultje"  wrote:

> Hi,
> 
> On Sat, Dec 9, 2017 at 10:37 AM, Paul B Mahol  wrote:
> 
> > @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
> >  uint8_t max_lowres; ///< maximum value for lowres
> > supported by the decoder
> >  const AVClass *priv_class;  ///< AVClass for the private
> > context
> >  const AVProfile *profiles;  ///< array of recognized
> > profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> > +int color_range;///< supported color range by
> > encoder, 0 means any is supported
> >
> >  /*
> >   * No fields below this line are part of the public API. They  
> 
> 
> First: please use the properly typed enum (enum AVColorRange).

(That makes it actually less safe from an ABI perspective, but that's a
lost cause anyway, since enums are used in most places where it matters
for ABI.)

> Second: so I understand what you're trying to do here. For decoders, if
> they only support one range (or colorspace, or whatever), we can set it in
> the decode function. But for encoders, we need some introspectable way to
> make sure the input to the codec is of the proper format, else we can only
> error, right? So, if some codec only supports mpeg range but the input is
> jpeg, something needs to convert it.

libavcodec doesn't do such conversions. I guess you can be lucky if
trying to encode AVFrames with unsupported parameters gives a
meaningful error.

> Are we going to do that for all other color-related properties also? What
> if vp8 only supports bt601 but the input is bt709? Will we add a
> color_space to AVCodec?

In theory we should. Of course the goal is merely getting rid of the J
formats, which sort of provided a way to signal the color range via
pixel format. But in general, the API for signaling supported input
data for encoders is pretty bad. E.g. some encoders have random
restrictions on image size, etc., which brings us to...:

> Or do we need a more generic mechanism to validate
> an input AVFrame config (AVFrame without data)? If we want a more generic
> design, we'd better do it now before we add 10 new ints to AVCodec and then
> remove them again... (Same is true for audio also, what if the codec only
> supports some samplerates/channel configs etc? Maybe something more generic
> is useful there too.)

Yes, we would need that. You have to keep in mind that just listing
supported parameters separately is not enough either. Encoders could
support or not-support certain parameter combinations in non-trivial
ways. It's basically an N-dimensional search space (insert Paul
aneurism here).

I don't know what would be the best way to design such an API. It can
get easily too complex, while still not supporting all cases. I guess
that's the reason why it the metadata remained as "stupid" as it is,
because raising the complexity won't fix it either.

In summary, it's probably OK to extend the current API in the way Paul
wants to do.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[wm4]

On Mon, 11 Dec 2017 14:22:43 +0100
Paul B Mahol  wrote:

> On 12/11/17, Hendrik Leppkes  wrote:
> > On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:  
> >>>
> >>> Fine, but it's inevitable that the encoder supports the J formats still
> >>> for a while.  
> >>
> >>
> >> Why are you all dismissive about this?  
> >
> >
> > Because we have an established way to remove things like this, and
> > that doesn't happen over night.
> > Its not ok for stuff to stop working without a replacement in place
> > for a sufficient time before that, so people can migrate.
> >
> > First, implement replacement and add visible deprecation messages -
> > and then wait the established deprecation period before actually
> > removing it.  
> 
> Bullshit, J formats are deprecated for ages.

Yeah, this has been a favorite thing of mine, how the J formats have
been deprecated for almost a decade, yet API users can't avoid using
them, and even ffmpeg CLI will complain about them in a completely
nonsense way.

You need another layer of deprecation now, because tons of software
will probably use those formats, even though they're deprecated, and
users have no way of knowing that they're _actually_ considered
deprecated now and might _actually_ go away and there's _actually_ a
way to avoid them now.

The situation is pretty awesomely fucked.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Paul B Mahol]

On 12/11/17, Ronald S. Bultje  wrote:
> Hi,
>
> On Sat, Dec 9, 2017 at 10:37 AM, Paul B Mahol  wrote:
>
>> @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
>>  uint8_t max_lowres; ///< maximum value for lowres
>> supported by the decoder
>>  const AVClass *priv_class;  ///< AVClass for the private
>> context
>>  const AVProfile *profiles;  ///< array of recognized
>> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
>> +int color_range;///< supported color range by
>> encoder, 0 means any is supported
>>
>>  /*
>>   * No fields below this line are part of the public API. They
>
>
> First: please use the properly typed enum (enum AVColorRange).
>
> Second: so I understand what you're trying to do here. For decoders, if
> they only support one range (or colorspace, or whatever), we can set it in
> the decode function. But for encoders, we need some introspectable way to
> make sure the input to the codec is of the proper format, else we can only
> error, right? So, if some codec only supports mpeg range but the input is
> jpeg, something needs to convert it.
>
> Are we going to do that for all other color-related properties also? What
> if vp8 only supports bt601 but the input is bt709? Will we add a
> color_space to AVCodec? Or do we need a more generic mechanism to validate
> an input AVFrame config (AVFrame without data)? If we want a more generic
> design, we'd better do it now before we add 10 new ints to AVCodec and then
> remove them again... (Same is true for audio also, what if the codec only
> supports some samplerates/channel configs etc? Maybe something more generic
> is useful there too.)
>

Endless bikeshed...

Audio already have what it have and its working fine.

Do you propose to make another struct or what?

I hate how people can be so ignorant these days.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Ronald S. Bultje]

Hi,

On Sat, Dec 9, 2017 at 10:37 AM, Paul B Mahol  wrote:

> @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
>  uint8_t max_lowres; ///< maximum value for lowres
> supported by the decoder
>  const AVClass *priv_class;  ///< AVClass for the private
> context
>  const AVProfile *profiles;  ///< array of recognized
> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> +int color_range;///< supported color range by
> encoder, 0 means any is supported
>
>  /*
>   * No fields below this line are part of the public API. They


First: please use the properly typed enum (enum AVColorRange).

Second: so I understand what you're trying to do here. For decoders, if
they only support one range (or colorspace, or whatever), we can set it in
the decode function. But for encoders, we need some introspectable way to
make sure the input to the codec is of the proper format, else we can only
error, right? So, if some codec only supports mpeg range but the input is
jpeg, something needs to convert it.

Are we going to do that for all other color-related properties also? What
if vp8 only supports bt601 but the input is bt709? Will we add a
color_space to AVCodec? Or do we need a more generic mechanism to validate
an input AVFrame config (AVFrame without data)? If we want a more generic
design, we'd better do it now before we add 10 new ints to AVCodec and then
remove them again... (Same is true for audio also, what if the codec only
supports some samplerates/channel configs etc? Maybe something more generic
is useful there too.)

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Paul B Mahol]

On 12/11/17, Hendrik Leppkes  wrote:
> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:
>>>
>>> Fine, but it's inevitable that the encoder supports the J formats still
>>> for a while.
>>
>>
>> Why are you all dismissive about this?
>
>
> Because we have an established way to remove things like this, and
> that doesn't happen over night.
> Its not ok for stuff to stop working without a replacement in place
> for a sufficient time before that, so people can migrate.
>
> First, implement replacement and add visible deprecation messages -
> and then wait the established deprecation period before actually
> removing it.

Bullshit, J formats are deprecated for ages.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Hendrik Leppkes]

On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:
>>
>> Fine, but it's inevitable that the encoder supports the J formats still
>> for a while.
>
>
> Why are you all dismissive about this?


Because we have an established way to remove things like this, and
that doesn't happen over night.
Its not ok for stuff to stop working without a replacement in place
for a sufficient time before that, so people can migrate.

First, implement replacement and add visible deprecation messages -
and then wait the established deprecation period before actually
removing it.


- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[wm4]

On Mon, 11 Dec 2017 12:07:34 +0100
Paul B Mahol  wrote:

> On 12/11/17, wm4  wrote:
> > On Sat,  9 Dec 2017 16:37:53 +0100
> > Paul B Mahol  wrote:
> >  
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavcodec/avcodec.h | 1 +
> >>  libavcodec/utils.c   | 2 ++
> >>  2 files changed, 3 insertions(+)
> >>
> >> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> >> index 5db6a81320..e5de4797c8 100644
> >> --- a/libavcodec/avcodec.h
> >> +++ b/libavcodec/avcodec.h
> >> @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
> >>  uint8_t max_lowres; ///< maximum value for lowres
> >> supported by the decoder
> >>  const AVClass *priv_class;  ///< AVClass for the private
> >> context
> >>  const AVProfile *profiles;  ///< array of recognized
> >> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> >> +int color_range;///< supported color range by
> >> encoder, 0 means any is supported  
> >
> > I'd prefer if the doxygen said AVCOL_RANGE_UNSPECIFIED.
> >
> > Actually, I'd prefer if this were an array.  
> 
> What for? It can be MPEG or JPEG or UNKNOWN (one of previous two)
> 
> >
> > Actually, I'd prefer even more if there were some nicer way to export
> > supported encoder parameters, as currently it's mostly guess work on
> > the API user side (or hardcoding knowledge).
> >  
> >>
> >>  /*
> >>   * No fields below this line are part of the public API. They
> >> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> >> index baf09119fe..aa81c21ef3 100644
> >> --- a/libavcodec/utils.c
> >> +++ b/libavcodec/utils.c
> >> @@ -879,6 +879,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >>  avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ444P)
> >>  avctx->color_range = AVCOL_RANGE_JPEG;
> >>  }
> >> +if (avctx->codec->color_range)
> >> +avctx->color_range = avctx->codec->color_range;
> >>  if (avctx->codec->supported_samplerates) {
> >>  for (i = 0; avctx->codec->supported_samplerates[i] != 0; i++)
> >>  if (avctx->sample_rate ==
> >> avctx->codec->supported_samplerates[i])  
> >
> > Fine, but it's inevitable that the encoder supports the J formats still
> > for a while.  
> 
> 
> Why are you all dismissive about this?

Well, to be honest, I don't mind if this whole J* format change
suddenly breaks all API users, but others might be not so happy about
it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Paul B Mahol]

On 12/11/17, wm4  wrote:
> On Sat,  9 Dec 2017 16:37:53 +0100
> Paul B Mahol  wrote:
>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/avcodec.h | 1 +
>>  libavcodec/utils.c   | 2 ++
>>  2 files changed, 3 insertions(+)
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 5db6a81320..e5de4797c8 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
>>  uint8_t max_lowres; ///< maximum value for lowres
>> supported by the decoder
>>  const AVClass *priv_class;  ///< AVClass for the private
>> context
>>  const AVProfile *profiles;  ///< array of recognized
>> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
>> +int color_range;///< supported color range by
>> encoder, 0 means any is supported
>
> I'd prefer if the doxygen said AVCOL_RANGE_UNSPECIFIED.
>
> Actually, I'd prefer if this were an array.

What for? It can be MPEG or JPEG or UNKNOWN (one of previous two)

>
> Actually, I'd prefer even more if there were some nicer way to export
> supported encoder parameters, as currently it's mostly guess work on
> the API user side (or hardcoding knowledge).
>
>>
>>  /*
>>   * No fields below this line are part of the public API. They
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index baf09119fe..aa81c21ef3 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -879,6 +879,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>  avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ444P)
>>  avctx->color_range = AVCOL_RANGE_JPEG;
>>  }
>> +if (avctx->codec->color_range)
>> +avctx->color_range = avctx->codec->color_range;
>>  if (avctx->codec->supported_samplerates) {
>>  for (i = 0; avctx->codec->supported_samplerates[i] != 0; i++)
>>  if (avctx->sample_rate ==
>> avctx->codec->supported_samplerates[i])
>
> Fine, but it's inevitable that the encoder supports the J formats still
> for a while.


Why are you all dismissive about this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[wm4]

On Sat,  9 Dec 2017 16:37:53 +0100
Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/avcodec.h | 1 +
>  libavcodec/utils.c   | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5db6a81320..e5de4797c8 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
>  uint8_t max_lowres; ///< maximum value for lowres 
> supported by the decoder
>  const AVClass *priv_class;  ///< AVClass for the private 
> context
>  const AVProfile *profiles;  ///< array of recognized 
> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> +int color_range;///< supported color range by 
> encoder, 0 means any is supported

I'd prefer if the doxygen said AVCOL_RANGE_UNSPECIFIED.

Actually, I'd prefer if this were an array.

Actually, I'd prefer even more if there were some nicer way to export
supported encoder parameters, as currently it's mostly guess work on
the API user side (or hardcoding knowledge).

>  
>  /*
>   * No fields below this line are part of the public API. They
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index baf09119fe..aa81c21ef3 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -879,6 +879,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ444P)
>  avctx->color_range = AVCOL_RANGE_JPEG;
>  }
> +if (avctx->codec->color_range)
> +avctx->color_range = avctx->codec->color_range;
>  if (avctx->codec->supported_samplerates) {
>  for (i = 0; avctx->codec->supported_samplerates[i] != 0; i++)
>  if (avctx->sample_rate == 
> avctx->codec->supported_samplerates[i])

Fine, but it's inevitable that the encoder supports the J formats still
for a while.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel