[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 <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?

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