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

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

Reply via email to