[FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

Paul B Mahol onemda at gmail.com
Fri Dec 8 17:29:02 EET 2017

On 12/8/17, Paul B Mahol <onemda at gmail.com> wrote:
> On 12/8/17, Vittorio Giovara <vittorio.giovara at 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.

More information about the ffmpeg-devel mailing list