[FFmpeg-devel] [PATCH v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support

Michael Niedermayer michael at niedermayer.cc
Sat Sep 21 23:44:34 EEST 2019


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 <michael at niedermayer.cc> wrote:
> > 
> > On Fri, Sep 20, 2019 at 11:55:17PM +0800, lance.lmwang at gmail.com wrote:
> >> From: Limin Wang <lance.lmwang at gmail.com>
> >> 
> >> Signed-off-by: Limin Wang <lance.lmwang at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190921/2a7c5828/attachment.sig>


More information about the ffmpeg-devel mailing list