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

[Paul B Mahol]

On 12/11/17, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> 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.

So, do you want color_range as array or as int?