Message ID | 20190921124235.31729-1-lance.lmwang@gmail.com |
---|---|
State | New |
Headers | show |
Am Sa., 21. Sept. 2019 um 14:42 Uhr schrieb <lance.lmwang@gmail.com>: > > From: Limin Wang <lance.lmwang@gmail.com> > > With the patch, we simply reuse the same source chroma line for each pair > of lines in the output Is there really no quality hit for a 20% speed-up? Carl Eugen
On Sat, Sep 21, 2019 at 03:13:46PM +0200, Carl Eugen Hoyos wrote: > Am Sa., 21. Sept. 2019 um 14:42 Uhr schrieb <lance.lmwang@gmail.com>: > > > > From: Limin Wang <lance.lmwang@gmail.com> > > > > With the patch, we simply reuse the same source chroma line for each pair > > of lines in the output > > Is there really no quality hit for a 20% speed-up? The quality is OK by my testing for the 420 to 422, I have no idea how to compare with the difference between them, Micheal can give more suggestion on that. however the patch try to fix the autoscale, if user prefer to use swscale conversion, he can use it still by claims pix_fmt clearly. The following command shows how to use the old conversion by swscale. no swscale: ./ffmpeg -y -lavfi testsrc2=s=4096x3072:r=10:d=10,format=pix_fmts=yuv420p -c:v v210 -f null - swscale: ./ffmpeg -y -lavfi testsrc2=s=4096x3072:r=10:d=10,format=pix_fmts=yuv420p -c:v v210 -pix_fmt yuv422p -f null - Thanks, Limin > > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Am Sa., 21. Sept. 2019 um 16:49 Uhr schrieb Limin Wang <lance.lmwang@gmail.com>: > however the patch try to fix the autoscale, if user prefer to use > swscale conversion, he can use it still by claims pix_fmt clearly. This seems like a very bad argument assuming there is a quality hit and the speed gain is very limited. Carl Eugen
diff --git a/libavcodec/v210_template.c b/libavcodec/v210_template.c index 9e1d9f9..083a9f1 100644 --- a/libavcodec/v210_template.c +++ b/libavcodec/v210_template.c @@ -43,11 +43,31 @@ static void RENAME(v210_enc)(AVCodecContext *avctx, const TYPE *y = (const TYPE *)pic->data[0]; const TYPE *u = (const TYPE *)pic->data[1]; const TYPE *v = (const TYPE *)pic->data[2]; + const TYPE *u_even = u; + const TYPE *v_even = v; const int sample_size = 6 * s->RENAME(sample_factor); const int sample_w = avctx->width / sample_size; for (h = 0; h < avctx->height; h++) { uint32_t val; + + if (pic->format == AV_PIX_FMT_YUV420P10 || + pic->format == AV_PIX_FMT_YUV420P) { + int mod = pic->interlaced_frame == 1 ? 4 : 2; + if (h % mod == 0) { + u_even = u; + v_even = v; + } else { + /* progressive chroma */ + if (mod == 2) { + u = u_even; + v = v_even; + } else if (h % 4 == 2) { + u = u_even; + v = v_even; + } + } + } w = sample_w * sample_size; s->RENAME(pack_line)(y, u, v, dst, w); diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c index 16e8810..2180737 100644 --- a/libavcodec/v210enc.c +++ b/libavcodec/v210enc.c @@ -131,9 +131,9 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt, } dst = pkt->data; - if (pic->format == AV_PIX_FMT_YUV422P10) + if (pic->format == AV_PIX_FMT_YUV422P10 || pic->format == AV_PIX_FMT_YUV420P10) v210_enc_10(avctx, dst, pic); - else if(pic->format == AV_PIX_FMT_YUV422P) + else if(pic->format == AV_PIX_FMT_YUV422P || pic->format == AV_PIX_FMT_YUV420P) v210_enc_8(avctx, dst, pic); side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC); @@ -165,5 +165,7 @@ AVCodec ff_v210_encoder = { .priv_data_size = sizeof(V210EncContext), .init = encode_init, .encode2 = encode_frame, - .pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV422P, AV_PIX_FMT_NONE }, + .pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV422P, + AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV420P, + AV_PIX_FMT_NONE }, };