On 12/8/17, Paul B Mahol <one...@gmail.com> wrote: > On 12/8/17, Vittorio Giovara <vittorio.giov...@gmail.com> wrote: >>> On 12/8/17, Paul B Mahole *<onemda at gmail.com >>> <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>* wrote: >>>*> This will basically break everyone encoding mjpeg right now, since it >> *>*> suddenly only accepts different formats without any common-ground >> *>*> before/after. >> *>*> Furthermore, there is no replacement for the indication that this >> *>*> encoder wants full-range data, which the old pixfmts indicated. >> *> >>> So I will add .color_range to AVCodec >>> 0 means encoder supports both. >>> >>> Is that ok? >> >> I tried in the past and it is indeed possible, however it doesn't really >> work: going that route you'll end up adding all the color properties, >> including chroma location. >> As much as I despise the J formats, it's a hacky solution at best leading >> to a very confusing API, making the negotiation and conversion >> unnecessary >> complex. > > There is nothing complex here, simply color_range is auto set for mjpeg > encoder (even thought it can support both with minimal changes) > > Also now filter links are aware of color_range and can be freely changed, > similar to sample aspect ratio. > >> If we were to break this feature, I'd suggest going the full route of >> adding a PixelFormaton and work on a sws alternative (one is allowed to >> dream no?). > > This is step to right direction, why would adding yet another API be better > solution? > > J formats are hack - misfeature - most obvious reason why nobody added > 10bit J formats, or one of alpha. Calling it otherwise, points to severe > lack of understanding of problem. >
Also asking to make additional changes and then asking to drop the thing all together is not good for project health. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
