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