On Fri, Sep 20, 2019 at 03:19:52PM -0400, Devin Heitmueller wrote: > Hello Michael, > > > > On Sep 20, 2019, at 12:10 PM, Michael Niedermayer <mich...@niedermayer.cc> > > wrote: > > > > On Fri, Sep 20, 2019 at 11:55:17PM +0800, lance.lmw...@gmail.com wrote: > >> From: Limin Wang <lance.lmw...@gmail.com> > >> > >> Signed-off-by: Limin Wang <lance.lmw...@gmail.com> > >> --- > >> libavcodec/v210_template.c | 20 ++++++++++++++++++++ > >> libavcodec/v210enc.c | 8 +++++--- > >> 2 files changed, 25 insertions(+), 3 deletions(-) > > > > Adding a nearest neighbor scaler or in fact any scaler > > into an encoder is not ok > > > > This belongs in swscale and it is already there. > > > Just to be clear, there is no scaling going on here.
> The patch just expands 4:2:0 to 4:2:2 while properly supporting interlaced > chroma. 4:2:0 and 4:2:2 have a chroma plane with different resolution. converting between planes of different resolution is what i called scaling. > It avoids having to auto insert the swscale filter in the case where there is > no scaling required (e.g. H.264 4:2:0 video being output to decklink in its > original resolution). yes, doing an operation in the encoder avoids a filter being inserted which does that operation. Thats true for every encoder and every filter. Also replacing interpolation by a nearest neighbor implementation is quite expectedly faster. one problem is the user can setup the scale filter with high quality in mind or with low quality and speed in mind. But after this patch she always gets low quality because the low quality convertion code is hardcoded in the encoder which pretends to support 420. The outside code has no chance to know it shouldnt feed 420 if high quality is wanted. Also why should this be in one encoder and not be available to other encoders supporting 4:2:2 input ? A solution should work for all of them Iam not sure what is the best solution but simply hardcoding this in one encoder feels rather wrong Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
