On 12/11/17, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Mon, Dec 11, 2017 at 3:36 PM, James Almer <jamr...@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 <one...@gmail.com> wrote:
>>>> On 12/11/17, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
>>>>> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol <one...@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.

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

Reply via email to