[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 <jamrial at gmail.com> wrote:

> On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
> > On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol <onemda at gmail.com> wrote:  
> >> On 12/11/17, Hendrik Leppkes <h.leppkes at gmail.com> wrote:  
> >>> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol <onemda at gmail.com> 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