On Mon, 11 Dec 2017 15:28:31 +0100 Hendrik Leppkes <h.lepp...@gmail.com> 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. > > Either do it properly, or don't do it at all. Yeah, it would be ok if there had been a method to do this without J formats before. For example, I don't think it would be a problem to change jpg _decoding_ to output normal pixfmts (if it doesn't already do that). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
