On 12/11/17, Paul B Mahol <one...@gmail.com> wrote: > 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. > > So, do you want color_range as array or as int? >
Looks nobody have valid opinion. So will aply this as is. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
