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 ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
