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