On Mon, Dec 11, 2017 at 12:09:33PM -0500, Vittorio Giovara 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.

The problem is completely unrelated to the scaling/color conversion
library. Its difficult to remove them from libavcodec and libavfilter.
And i belive paul is doing good and hard work here.

If there is a issue in swscale from spliting range out, iam happy to
look into fixing that if someone gives me a reproduceable test case


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data

Attachment: signature.asc
Description: Digital signature

ffmpeg-devel mailing list

Reply via email to