On 12/11/17, Vittorio Giovara <vittorio.giov...@gmail.com> wrote:
>>* On 12/8/17, Paul B Mahol <onemda at gmail.com <http://gmail.com>>*
>>> On 12/8/17, Vittorio Giovara <vittorio.giovara at gmail.com
>>> <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>> wrote:
>>*> 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.
> I am perfectly aware that the J formats are a hack, that's why it would be
> nice to avoid introducing more hacks to get rid of them.
> As it has been pointed out in the other thread, simply adding .color_range
> does not properly solve this problem, it is a breaking change without
> proper deprecation period, and in general it seems like not a good idea
> API-wise to add an endless number of fields to AVCodec.
> Like I said, having dealt with the problem in the past, the only way I
> suggest to go forward is decoupling codec/filter negotiation from pixel
> formats and use a different scaling/color conversion library.

AVCodec can handle few more items. The vaporware you propose is futile.
ffmpeg-devel mailing list

Reply via email to