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

[Paul B Mahol]

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.