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

Looks nobody have valid opinion. So will aply this as is.