Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers
> -Original Message-
> From: ffmpeg-devel On Behalf Of Max
> Dmitrichenko
> Sent: Wednesday, November 20, 2019 3:04 PM
> To: FFmpeg development discussions and patches
> Cc: Li, Zhong
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
>
> On Sun, Sep 29, 2019 at 3:19 AM Fu, Linjie wrote:
>
> > > -Original Message-
> > > From: Li, Zhong
> > > Sent: Friday, September 13, 2019 00:05
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > Cc: Fu, Linjie
> > > Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> > > vaMapBuffer returns multiple buffers
> > >
> > > > From: ffmpeg-devel On Behalf Of
> > > Linjie Fu
> > > > Sent: Friday, May 31, 2019 8:35 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: Fu, Linjie
> > > > Subject: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> > > > vaMapBuffer returns multiple buffers
> > > >
> > > > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to
> > > map
> > > > buffer for each slice.
The patch LGTM. But the above line of commit message seems not too much
relevant.
Will remove this line of commit message and apply the patch if no objection.
Thanks!
Ruiling
> > > >
> > > > Currently, assigning new buffer for pkt when multiple buffer returns
> > from
> > > > vaMapBuffer will cover the previous encoded pkt data and lead to encode
> > > issues.
> > > >
> > > > Iterate through the buf_list first to find out the total buffer size
> > needed for
> > > the
> > > > pkt, allocate the whole pkt to avoid repeated reallocation and memcpy,
> > > then copy
> > > > data from each buf to pkt.
> > > >
> > > > Signed-off-by: Linjie Fu
> > > > ---
> > > > [v2]: allocate the whole pkt to avoid repeated reallocation and memcpy
> > > >
> > > > libavcodec/vaapi_encode.c | 18 +-
> > > > 1 file changed, 13 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index
> > > > 2dda451..9c9e5dd 100644
> > > > --- a/libavcodec/vaapi_encode.c
> > > > +++ b/libavcodec/vaapi_encode.c
> > > > @@ -489,6 +489,8 @@ static int vaapi_encode_output(AVCodecContext
> > > *avctx,
> > > > VAAPIEncodeContext *ctx = avctx->priv_data;
> > > > VACodedBufferSegment *buf_list, *buf;
> > > > VAStatus vas;
> > > > +int total_size = 0;
> > > > +uint8_t *ptr;
> > > > int err;
> > > >
> > > > err = vaapi_encode_wait(avctx, pic); @@ -505,15 +507,21 @@ static
> > int
> > > > vaapi_encode_output(AVCodecContext *avctx,
> > > > goto fail;
> > > > }
> > > >
> > > > +for (buf = buf_list; buf; buf = buf->next)
> > > > +total_size += buf->size;
> > > > +
> > > > +err = av_new_packet(pkt, total_size);
> > > > +ptr = pkt->data;
> > > > +
> > > > +if (err < 0)
> > > > +goto fail_mapped;
> > > > +
> > > > for (buf = buf_list; buf; buf = buf->next) {
> > > > av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> > > > "(status %08x).\n", buf->size, buf->status);
> > > >
> > > > -err = av_new_packet(pkt, buf->size);
> > > > -if (err < 0)
> > > > -goto fail_mapped;
> > > > -
> > > > -memcpy(pkt->data, buf->buf, buf->size);
> > > > +memcpy(ptr, buf->buf, buf->size);
> > > > +ptr += buf->size;
> > > > }
> > > >
> > > > if (pic->type == PICTURE_TYPE_IDR)
> > > > --
> > > > 2.7.4
> > >
> > > LGTM
> >
> > Thanks for review.
> > A kindly ping.
> >
> > - linjie
> >
>
> LGTM
>
> regards
> Max
> ___
> 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".
___
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".
Re: [FFmpeg-devel] [PATCH 01/11] avformat/mov: Use ff_alloc_extradata for dvdsub extradata
On Wed, Dec 11, 2019 at 6:00 AM Andreas Rheinhardt
wrote:
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mov.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7553a7fdfc..733f4e4a34 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2255,7 +2255,7 @@ static int mov_rewrite_dvd_sub_extradata(AVStream *st)
> {
> char buf[256] = {0};
> uint8_t *src = st->codecpar->extradata;
> -int i;
> +int i, ret;
>
> if (st->codecpar->extradata_size != 64)
> return 0;
> @@ -2275,12 +2275,9 @@ static int mov_rewrite_dvd_sub_extradata(AVStream *st)
> if (av_strlcat(buf, "\n", sizeof(buf)) >= sizeof(buf))
> return 0;
>
> -av_freep(&st->codecpar->extradata);
> -st->codecpar->extradata_size = 0;
> -st->codecpar->extradata = av_mallocz(strlen(buf) +
> AV_INPUT_BUFFER_PADDING_SIZE);
> -if (!st->codecpar->extradata)
> -return AVERROR(ENOMEM);
> -st->codecpar->extradata_size = strlen(buf);
> +ret = ff_alloc_extradata(st->codecpar, strlen(buf));
> +if (ret < 0)
> +return ret;
> memcpy(st->codecpar->extradata, buf, st->codecpar->extradata_size);
>
> return 0;
> --
> 2.20.1
>
LGTM
___
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".
[FFmpeg-devel] [PATCHv2] fate: Add an option for disabling the 2k/4k tests
When testing on a memory limited system, these tests consume a significant amount of memory and can often fail if testing by running multiple processes in parallel. --- Adjusted to use ALLYES instead of a -yes-yes construct. Also moved the 2k tests to the same option. --- configure | 3 +++ tests/fate/seek.mak | 3 ++- tests/fate/vcodec.mak | 5 +++-- 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/configure b/configure index ca7137f341..922cd8d0ee 100755 --- a/configure +++ b/configure @@ -482,6 +482,7 @@ Developer options (useful when working on FFmpeg itself): --ignore-tests=TESTS comma-separated list (without "fate-" prefix in the name) of tests whose result is ignored --enable-linux-perf enable Linux Performance Monitor API + --disable-large-testsdisable tests that use a large amount of memory NOTE: Object files are built at the place where configure is launched. EOF @@ -1931,6 +1932,7 @@ CONFIG_LIST=" $SUBSYSTEM_LIST autodetect fontconfig +large_tests linux_perf memory_poisoning neon_clobber_test @@ -3724,6 +3726,7 @@ enable asm enable debug enable doc enable faan faandct faanidct +enable large_tests enable optimizations enable runtime_cpudetect enable safe_bitstream_reader diff --git a/tests/fate/seek.mak b/tests/fate/seek.mak index 04f54ee6c4..98d2b54674 100644 --- a/tests/fate/seek.mak +++ b/tests/fate/seek.mak @@ -64,7 +64,6 @@ FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, ASV1, AVI) += asv1 FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, ASV2, AVI) += asv2 FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, DNXHD, DNXHD) += dnxhd-720p FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, DNXHD, DNXHD) += dnxhd-720p-rd -FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, DNXHD, DNXHD) += dnxhd-4k-hr-lb FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, DNXHD, MOV) += dnxhd-1080i FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, DVVIDEO, DV) += dv FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, DVVIDEO, DV) += dv-411 @@ -80,6 +79,8 @@ FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, JPEGLS,AVI) += jpegls FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, LJPEG MJPEG, AVI) += ljpeg FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, MJPEG, AVI) += mjpeg +FATE_SEEK_VSYNTH_LENA-$(call ALLYES, DNXHD_ENCODER DNXHD_DECODER LARGE_TESTS) += dnxhd-4k-hr-lb + FATE_SEEK_VSYNTH_LENA-$(call ENCDEC, MPEG1VIDEO, MPEG1VIDEO MPEGVIDEO) +=\ mpeg1\ mpeg1b diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index 452246689e..fc27da5456 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -29,13 +29,14 @@ FATE_VCODEC-$(call ENCDEC, DNXHD, DNXHD) += dnxhd-720p \ dnxhd-720p-rd \ dnxhd-720p-10bit\ dnxhd-720p-hr-lb\ -dnxhd-4k-hr-lb \ dnxhd-uhd-hr-sq \ -dnxhd-2k-hr-hq \ dnxhd-edge1-hr \ dnxhd-edge2-hr \ dnxhd-edge3-hr +FATE_VCODEC-$(call ALLYES, DNXHD_ENCODER DNXHD_DECODER LARGE_TESTS) += dnxhd-4k-hr-lb \ + dnxhd-2k-hr-hq + FATE_VCODEC-$(call ENCDEC, VC2 DIRAC, MOV) += vc2-420p vc2-420p10 vc2-420p12 \ vc2-422p vc2-422p10 vc2-422p12 \ vc2-444p vc2-444p10 vc2-444p12 \ -- 2.17.1 ___ 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".
[FFmpeg-devel] [PATCH 1/4] tests/checkasm: add overflow test for hevc_add_res
Add overflow test for hevc_add_res when int16_t coeff = -32768. The result of C is good, while ASM is not. To verify: make fate-checkasm-hevc_add_res ffmpeg/tests/checkasm/checkasm --test=hevc_add_res ./checkasm --test=hevc_add_res checkasm: using random seed 679391863 MMXEXT: hevc_add_res_4x4_8_mmxext (hevc_add_res.c:69) - hevc_add_res.add_residual [FAILED] SSE2: hevc_add_res_8x8_8_sse2 (hevc_add_res.c:69) hevc_add_res_16x16_8_sse2 (hevc_add_res.c:69) hevc_add_res_32x32_8_sse2 (hevc_add_res.c:69) - hevc_add_res.add_residual [FAILED] AVX: hevc_add_res_8x8_8_avx (hevc_add_res.c:69) hevc_add_res_16x16_8_avx (hevc_add_res.c:69) hevc_add_res_32x32_8_avx (hevc_add_res.c:69) - hevc_add_res.add_residual [FAILED] AVX2: hevc_add_res_32x32_8_avx2 (hevc_add_res.c:69) - hevc_add_res.add_residual [FAILED] checkasm: 8 of 14 tests have failed Signed-off-by: Xu Guangxin Signed-off-by: Linjie Fu --- tests/checkasm/hevc_add_res.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/checkasm/hevc_add_res.c b/tests/checkasm/hevc_add_res.c index e92c6b4..a6e3b8a 100644 --- a/tests/checkasm/hevc_add_res.c +++ b/tests/checkasm/hevc_add_res.c @@ -58,6 +58,7 @@ static void check_add_res(HEVCDSPContext h, int bit_depth) randomize_buffers(res0, size); randomize_buffers2(dst0, size); +res0[0] = 0x8000;// overflow test memcpy(res1, res0, sizeof(*res0) * size); memcpy(dst1, dst0, sizeof(int16_t) * size); -- 2.7.4 ___ 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".
[FFmpeg-devel] [PATCH 2/4] lavc/x86/hevc_add_res: Fix overflow in ADD_RES_MMX_4_8
Fix overflow for coeff -32768 in function ADD_RES_MMX_4_8 with no performance drop. ./checkasm --test=hevc_add_res --bench Mainline: - hevc_add_res.add_residual [OK] hevc_add_res_4x4_8_mmxext: 15.5 Add overflow test case: - hevc_add_res.add_residual [FAILED] After: - hevc_add_res.add_residual [OK] hevc_add_res_4x4_8_mmxext: 15.0 Signed-off-by: Xu Guangxin Signed-off-by: Linjie Fu --- libavcodec/x86/hevc_add_res.asm | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/libavcodec/x86/hevc_add_res.asm b/libavcodec/x86/hevc_add_res.asm index 36d4d8e..249c607 100644 --- a/libavcodec/x86/hevc_add_res.asm +++ b/libavcodec/x86/hevc_add_res.asm @@ -30,27 +30,26 @@ cextern pw_1023 %macro ADD_RES_MMX_4_8 0 mova m0, [r1] mova m2, [r1+8] -pxor m1, m1 -pxor m3, m3 -psubw m1, m0 -psubw m3, m2 -packuswb m0, m2 -packuswb m1, m3 -movd m2, [r0] +movd m1, [r0] movd m3, [r0+r2] -punpckldq m2, m3 -paddusb m0, m2 -psubusb m0, m1 +punpcklbw m1, m4 +punpcklbw m3, m4 + +paddswm0, m1 +paddswm2, m3 +packuswb m0, m4 +packuswb m2, m4 + movd[r0], m0 -psrlq m0, 32 -movd [r0+r2], m0 +movd [r0+r2], m2 %endmacro INIT_MMX mmxext ; void ff_hevc_add_residual_4_8_mmxext(uint8_t *dst, int16_t *res, ptrdiff_t stride) cglobal hevc_add_residual_4_8, 3, 3, 6 +pxor m4, m4 ADD_RES_MMX_4_8 add r1, 16 lea r0, [r0+r2*2] -- 2.7.4 ___ 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".
[FFmpeg-devel] [PATCH 4/4] lavc/x86/hevc_add_res: Fix coeff overflow in ADD_RES_SSE_16_32_8
Fix overflow for coeff -32768 in function ADD_RES_SSE_16_32_8 with no performance drop.(SSE2/AVX/AVX2) ./checkasm --test=hevc_add_res --bench Mainline: - hevc_add_res.add_residual [OK] hevc_add_res_32x32_8_sse2: 127.5 hevc_add_res_32x32_8_avx: 127.0 hevc_add_res_32x32_8_avx2: 86.5 Add overflow test case: - hevc_add_res.add_residual [FAILED] After: - hevc_add_res.add_residual [OK] hevc_add_res_32x32_8_sse2: 126.8 hevc_add_res_32x32_8_avx: 128.3 hevc_add_res_32x32_8_avx2: 86.8 Signed-off-by: Xu Guangxin Signed-off-by: Linjie Fu --- libavcodec/x86/hevc_add_res.asm | 50 + 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/libavcodec/x86/hevc_add_res.asm b/libavcodec/x86/hevc_add_res.asm index e5e9f24..4d3aefc 100644 --- a/libavcodec/x86/hevc_add_res.asm +++ b/libavcodec/x86/hevc_add_res.asm @@ -84,34 +84,36 @@ cglobal hevc_add_residual_4_8, 3, 3, 6 %endmacro %macro ADD_RES_SSE_16_32_8 3 -mova xm2, [r1+%1] -mova xm6, [r1+%1+16] +movam1, [%2] +movam2, m1 +punpcklbw m1, m0 +punpckhbw m2, m0 +mova xm5, [r1+%1] +mova xm6, [r1+%1+16] %if cpuflag(avx2) -vinserti128 m2, m2, [r1+%1+32], 1 -vinserti128 m6, m6, [r1+%1+48], 1 +vinserti128 m5, m5, [r1+%1+32], 1 +vinserti128 m6, m6, [r1+%1+48], 1 %endif -psubw m1, m0, m2 -psubw m5, m0, m6 -packuswb m2, m6 -packuswb m1, m5 - -mova xm4, [r1+%1+mmsize*2] -mova xm6, [r1+%1+mmsize*2+16] +paddsw m1, m5 +paddsw m2, m6 + +movam3, [%3] +movam4, m3 +punpcklbw m3, m0 +punpckhbw m4, m0 +mova xm5, [r1+%1+mmsize*2] +mova xm6, [r1+%1+mmsize*2+16] %if cpuflag(avx2) -vinserti128 m4, m4, [r1+%1+96 ], 1 -vinserti128 m6, m6, [r1+%1+112], 1 +vinserti128 m5, m5, [r1+%1+96], 1 +vinserti128 m6, m6, [r1+%1+112], 1 %endif -psubw m3, m0, m4 -psubw m5, m0, m6 -packuswb m4, m6 -packuswb m3, m5 - -paddusb m2, [%2] -paddusb m4, [%3] -psubusb m2, m1 -psubusb m4, m3 -mova[%2], m2 -mova[%3], m4 +paddsw m3, m5 +paddsw m4, m6 + +packuswbm1, m2 +packuswbm3, m4 +mova [%2], m1 +mova [%3], m3 %endmacro -- 2.7.4 ___ 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".
[FFmpeg-devel] [PATCH 3/4] lavc/x86/hevc_add_res: Fix overflow in ADD_RES_SSE_8_8
Fix overflow for coeff -32768 in function ADD_RES_SSE_8_8 with no performance drop. ./checkasm --test=hevc_add_res --bench Mainline: - hevc_add_res.add_residual [OK] hevc_add_res_8x8_8_sse2: 15.5 Add overflow test case: - hevc_add_res.add_residual [FAILED] After: - hevc_add_res.add_residual [OK] hevc_add_res_8x8_8_sse2: 15.5 Signed-off-by: Xu Guangxin Signed-off-by: Linjie Fu --- libavcodec/x86/hevc_add_res.asm | 45 - 1 file changed, 22 insertions(+), 23 deletions(-) diff --git a/libavcodec/x86/hevc_add_res.asm b/libavcodec/x86/hevc_add_res.asm index 249c607..e5e9f24 100644 --- a/libavcodec/x86/hevc_add_res.asm +++ b/libavcodec/x86/hevc_add_res.asm @@ -57,32 +57,30 @@ cglobal hevc_add_residual_4_8, 3, 3, 6 RET %macro ADD_RES_SSE_8_8 0 -pxor m3, m3 -mova m4, [r1] -mova m6, [r1+16] -mova m0, [r1+32] -mova m2, [r1+48] -psubw m5, m3, m4 -psubw m7, m3, m6 -psubw m1, m3, m0 -packuswb m4, m0 -packuswb m5, m1 -psubw m3, m2 -packuswb m6, m2 -packuswb m7, m3 - movq m0, [r0] movq m1, [r0+r2] -movhpsm0, [r0+r2*2] -movhpsm1, [r0+r3] -paddusb m0, m4 -paddusb m1, m6 -psubusb m0, m5 -psubusb m1, m7 +punpcklbw m0, m4 +punpcklbw m1, m4 +mova m2, [r1] +mova m3, [r1+16] +paddswm0, m2 +paddswm1, m3 +packuswb m0, m1 + +movq m2, [r0+r2*2] +movq m3, [r0+r3] +punpcklbw m2, m4 +punpcklbw m3, m4 +mova m6, [r1+32] +mova m7, [r1+48] +paddswm2, m6 +paddswm3, m7 +packuswb m2, m3 + movq[r0], m0 -movq [r0+r2], m1 -movhps [r0+2*r2], m0 -movhps [r0+r3], m1 +movhps [r0+r2], m0 +movq [r0+r2*2], m2 +movhps [r0+r3], m2 %endmacro %macro ADD_RES_SSE_16_32_8 3 @@ -120,6 +118,7 @@ cglobal hevc_add_residual_4_8, 3, 3, 6 %macro TRANSFORM_ADD_8 0 ; void ff_hevc_add_residual_8_8_(uint8_t *dst, int16_t *res, ptrdiff_t stride) cglobal hevc_add_residual_8_8, 3, 4, 8 +pxor m4, m4 lea r3, [r2*3] ADD_RES_SSE_8_8 add r1, 64 -- 2.7.4 ___ 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".
[FFmpeg-devel] [PATCH] lavc/mips: simplify the switch code
Signed-off-by: Linjie Fu
---
libavcodec/mips/h264pred_init_mips.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/mips/h264pred_init_mips.c
b/libavcodec/mips/h264pred_init_mips.c
index 63637b8..e537ad8 100644
--- a/libavcodec/mips/h264pred_init_mips.c
+++ b/libavcodec/mips/h264pred_init_mips.c
@@ -73,10 +73,7 @@ static av_cold void h264_pred_init_msa(H264PredContext *h,
int codec_id,
switch (codec_id) {
case AV_CODEC_ID_SVQ3:
-;
-break;
case AV_CODEC_ID_RV40:
-;
break;
case AV_CODEC_ID_VP7:
case AV_CODEC_ID_VP8:
--
2.7.4
___
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".
[FFmpeg-devel] [PATCH] lavc/hevc_cabac: fix cbf_cb and cbf_cr for transform depth 4
The max transform depth is 5(from 0 to 4), so we need 5 cabac states for
cbf_cb and cbf_cr.
See Table 9-4 for details.
Signed-off-by: Xu Guangxin
Signed-off-by: Linjie Fu
---
libavcodec/hevc_cabac.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c
index 8abb780..3dc0987 100644
--- a/libavcodec/hevc_cabac.c
+++ b/libavcodec/hevc_cabac.c
@@ -66,7 +66,7 @@ static const int8_t num_bins_in_se[] = {
1, // no_residual_data_flag
3, // split_transform_flag
2, // cbf_luma
- 4, // cbf_cb, cbf_cr
+ 5, // cbf_cb, cbf_cr
2, // transform_skip_flag[][]
2, // explicit_rdpcm_flag[][]
2, // explicit_rdpcm_dir_flag[][]
@@ -122,23 +122,23 @@ static const int elem_offset[sizeof(num_bins_in_se)] = {
37, // split_transform_flag
40, // cbf_luma
42, // cbf_cb, cbf_cr
-46, // transform_skip_flag[][]
-48, // explicit_rdpcm_flag[][]
-50, // explicit_rdpcm_dir_flag[][]
-52, // last_significant_coeff_x_prefix
-70, // last_significant_coeff_y_prefix
-88, // last_significant_coeff_x_suffix
-88, // last_significant_coeff_y_suffix
-88, // significant_coeff_group_flag
-92, // significant_coeff_flag
-136, // coeff_abs_level_greater1_flag
-160, // coeff_abs_level_greater2_flag
-166, // coeff_abs_level_remaining
-166, // coeff_sign_flag
-166, // log2_res_scale_abs
-174, // res_scale_sign_flag
-176, // cu_chroma_qp_offset_flag
-177, // cu_chroma_qp_offset_idx
+47, // transform_skip_flag[][]
+49, // explicit_rdpcm_flag[][]
+51, // explicit_rdpcm_dir_flag[][]
+53, // last_significant_coeff_x_prefix
+71, // last_significant_coeff_y_prefix
+89, // last_significant_coeff_x_suffix
+89, // last_significant_coeff_y_suffix
+89, // significant_coeff_group_flag
+93, // significant_coeff_flag
+137, // coeff_abs_level_greater1_flag
+161, // coeff_abs_level_greater2_flag
+167, // coeff_abs_level_remaining
+167, // coeff_sign_flag
+167, // log2_res_scale_abs
+175, // res_scale_sign_flag
+177, // cu_chroma_qp_offset_flag
+178, // cu_chroma_qp_offset_idx
};
#define CNU 154
@@ -189,7 +189,7 @@ static const uint8_t init_values[3][HEVC_CONTEXTS] = {
// cbf_luma
111, 141,
// cbf_cb, cbf_cr
- 94, 138, 182, 154,
+ 94, 138, 182, 154, 154,
// transform_skip_flag
139, 139,
// explicit_rdpcm_flag
@@ -266,7 +266,7 @@ static const uint8_t init_values[3][HEVC_CONTEXTS] = {
// cbf_luma
153, 111,
// cbf_cb, cbf_cr
- 149, 107, 167, 154,
+ 149, 107, 167, 154, 154,
// transform_skip_flag
139, 139,
// explicit_rdpcm_flag
@@ -343,7 +343,7 @@ static const uint8_t init_values[3][HEVC_CONTEXTS] = {
// cbf_luma
153, 111,
// cbf_cb, cbf_cr
- 149, 92, 167, 154,
+ 149, 92, 167, 154, 154,
// transform_skip_flag
139, 139,
// explicit_rdpcm_flag
--
2.7.4
___
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".
[FFmpeg-devel] [PATCH] lavc/utils.c: fix code indentations
Introduced since 4b4a02b8.
Signed-off-by: Linjie Fu
---
libavcodec/utils.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 75e7035..8a49234 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -654,12 +654,12 @@ int attribute_align_arg avcodec_open2(AVCodecContext
*avctx, const AVCodec *code
// only call ff_set_dimensions() for non H.264/VP6F/DXV codecs so as not
to overwrite previously setup dimensions
if (!(avctx->coded_width && avctx->coded_height && avctx->width &&
avctx->height &&
(avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
AV_CODEC_ID_VP6F || avctx->codec_id == AV_CODEC_ID_DXV))) {
-if (avctx->coded_width && avctx->coded_height)
-ret = ff_set_dimensions(avctx, avctx->coded_width,
avctx->coded_height);
-else if (avctx->width && avctx->height)
-ret = ff_set_dimensions(avctx, avctx->width, avctx->height);
-if (ret < 0)
-goto free_and_end;
+if (avctx->coded_width && avctx->coded_height)
+ret = ff_set_dimensions(avctx, avctx->coded_width,
avctx->coded_height);
+else if (avctx->width && avctx->height)
+ret = ff_set_dimensions(avctx, avctx->width, avctx->height);
+if (ret < 0)
+goto free_and_end;
}
if ((avctx->coded_width || avctx->coded_height || avctx->width ||
avctx->height)
--
2.7.4
___
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".
[FFmpeg-devel] 回复: [PATCH 1/1] add without_captureblt option for libavdevice/gdigrab.c, when useing the bitblt function with CAPTUREBLT it caused the mouse cursor flicker. most time we dont need this
did someone review the patch?
发件人: _ FgoDt
发送时间: 2019年11月15日 15:03
收件人: ffmpeg-devel@ffmpeg.org
抄送: _ FgoDt
主题: [PATCH 1/1] add without_captureblt option for libavdevice/gdigrab.c, when
useing the bitblt function with CAPTUREBLT it caused the mouse cursor flicker.
most time we dont need this flag to capture window
From: fgodt
Signed-off-by: fgodt
---
libavdevice/gdigrab.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index f406fa..0ab0cfed01 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -53,6 +53,8 @@ struct gdigrab {
intoffset_x;/**< Capture x offset (private option) */
intoffset_y;/**< Capture y offset (private option) */
+intwithout_captureblt; /**< capture without captureblt */
+
HWND hwnd;/**< Handle of the window for the grab */
HDCsource_hdc; /**< Source device context */
HDCdest_hdc;/**< Destination, source-compatible DC */
@@ -542,6 +544,8 @@ static int gdigrab_read_packet(AVFormatContext *s1,
AVPacket *pkt)
int64_t curtime, delay;
+unsigned long flag;
+
/* Calculate the time of the next frame */
time_frame += INT64_C(100);
@@ -570,12 +574,16 @@ static int gdigrab_read_packet(AVFormatContext *s1,
AVPacket *pkt)
return AVERROR(ENOMEM);
pkt->pts = curtime;
+flag = SRCCOPY;
+if(!gdigrab->without_captureblt)
+flag |= CAPTUREBLT;
+
/* Blit screen grab */
if (!BitBlt(dest_hdc, 0, 0,
clip_rect.right - clip_rect.left,
clip_rect.bottom - clip_rect.top,
source_hdc,
-clip_rect.left, clip_rect.top, SRCCOPY | CAPTUREBLT)) {
+clip_rect.left, clip_rect.top, flag)) {
WIN32_API_ERROR("Failed to capture image");
return AVERROR(EIO);
}
@@ -639,6 +647,7 @@ static const AVOption options[] = {
{ "video_size", "set video frame size", OFFSET(width),
AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, DEC },
{ "offset_x", "capture area x offset", OFFSET(offset_x), AV_OPT_TYPE_INT,
{.i64 = 0}, INT_MIN, INT_MAX, DEC },
{ "offset_y", "capture area y offset", OFFSET(offset_y), AV_OPT_TYPE_INT,
{.i64 = 0}, INT_MIN, INT_MAX, DEC },
+{ "without_captureblt", "capture without captureblt",
OFFSET(without_captureblt), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, DEC },
{ NULL },
};
--
2.23.0
___
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".
[FFmpeg-devel] [PATCH] lavf/zf_zscale: remove unused code
Signed-off-by: Linjie Fu
---
libavfilter/vf_zscale.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index db2dd17..bd5825f 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -287,13 +287,6 @@ static int config_props(AVFilterLink *outlink)
outlink->w = w;
outlink->h = h;
-if (inlink->w == outlink->w &&
-inlink->h == outlink->h &&
-inlink->format == outlink->format)
-;
-else {
-}
-
if (inlink->sample_aspect_ratio.num){
outlink->sample_aspect_ratio = av_mul_q((AVRational){outlink->h *
inlink->w, outlink->w * inlink->h}, inlink->sample_aspect_ratio);
} else
--
2.7.4
___
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".
[FFmpeg-devel] [PATCH] checkasm: af_afir: Use a dynamic tolerance depending on values
As the values generated by av_bmg_get can be arbitrarily large
(only the stddev is specified), we can't use a fixed tolerance.
Calculate a dynamic tolerance (like in float_dsp from 38f966bdb),
based on the individual steps of the calculation.
This fixes running this test with certain seeds, when built with
clang for mingw/x86_32.
---
tests/checkasm/af_afir.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tests/checkasm/af_afir.c b/tests/checkasm/af_afir.c
index e3fb76e8e0..e791f88b97 100644
--- a/tests/checkasm/af_afir.c
+++ b/tests/checkasm/af_afir.c
@@ -53,7 +53,19 @@ static void test_fcmul_add(const float *src0, const float
*src1, const float *sr
call_ref(cdst, src1, src2, LEN);
call_new(odst, src1, src2, LEN);
for (i = 0; i <= LEN*2; i++) {
-if (!float_near_abs_eps(cdst[i], odst[i], 6.2e-05)) {
+int idx = i & ~1;
+float cre = src2[idx];
+float cim = src2[idx + 1];
+float tre = src1[idx];
+float tim = src1[idx + 1];
+double t = fabs(src0[i]) +
+ fabs(tre) + fabs(tim) + fabs(cre) + fabs(tim) +
+ fabs(tre * cre) + fabs(tim * cim) +
+ fabs(tre * cim) + fabs(tim * cre) +
+ fabs(tre * cre - tim * cim) +
+ fabs(tre * cim + tim * cre) +
+ fabs(cdst[i]) + 1.0;
+if (!float_near_abs_eps(cdst[i], odst[i], t * 2 * FLT_EPSILON)) {
fprintf(stderr, "%d: %- .12f - %- .12f = % .12g\n",
i, cdst[i], odst[i], cdst[i] - odst[i]);
fail();
--
2.17.1
___
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".
[FFmpeg-devel] [PATCHv2 2/2] checkasm: float_dsp: Scale FLT/DBL_EPSILON sufficiently when comparing
As the values generated by av_bmg_get can be arbitrarily large
(only the stddev is specified), we can't use a fixed tolerance.
This matches what was done for test_vector_dmul_scalar in
38f966bdb.
This fixes the float_dsp checkasm test for some seeds, when built
with clang for mingw/x86_32.
---
Tweaked the form of the tolerance to match the existing case, removed
unnecessarily wordy comments.
---
tests/checkasm/float_dsp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tests/checkasm/float_dsp.c b/tests/checkasm/float_dsp.c
index 2abe4eccbd..a1616a61a8 100644
--- a/tests/checkasm/float_dsp.c
+++ b/tests/checkasm/float_dsp.c
@@ -51,7 +51,8 @@ static void test_vector_fmul(const float *src0, const float
*src1)
call_ref(cdst, src0, src1, LEN);
call_new(odst, src0, src1, LEN);
for (i = 0; i < LEN; i++) {
-if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) {
+double t = fabs(src0[i]) + fabs(src1[i]) + fabs(src0[i] * src1[i]) +
1.0;
+if (!float_near_abs_eps(cdst[i], odst[i], t * 2 * FLT_EPSILON)) {
fprintf(stderr, "%d: %- .12f - %- .12f = % .12g\n",
i, cdst[i], odst[i], cdst[i] - odst[i]);
fail();
@@ -73,7 +74,8 @@ static void test_vector_dmul(const double *src0, const double
*src1)
call_ref(cdst, src0, src1, LEN);
call_new(odst, src0, src1, LEN);
for (i = 0; i < LEN; i++) {
-if (!double_near_abs_eps(cdst[i], odst[i], DBL_EPSILON)) {
+double t = fabs(src0[i]) + fabs(src1[i]) + fabs(src0[i] * src1[i]) +
1.0;
+if (!double_near_abs_eps(cdst[i], odst[i], t * 2 * DBL_EPSILON)) {
fprintf(stderr, "%d: %- .12f - %- .12f = % .12g\n",
i, cdst[i], odst[i], cdst[i] - odst[i]);
fail();
@@ -117,7 +119,8 @@ static void test_vector_fmul_scalar(const float *src0,
const float *src1)
call_ref(cdst, src0, src1[0], LEN);
call_new(odst, src0, src1[0], LEN);
for (i = 0; i < LEN; i++) {
-if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) {
+double t = fabs(src0[i]) + fabs(src1[0]) + fabs(src0[i] * src1[0])
+ 1.0;
+if (!float_near_abs_eps(cdst[i], odst[i], t * 2 * FLT_EPSILON)) {
fprintf(stderr, "%d: %- .12f - %- .12f = % .12g\n",
i, cdst[i], odst[i], cdst[i] - odst[i]);
fail();
--
2.17.1
___
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".
Re: [FFmpeg-devel] [PATCH v6 1/2] lavf/isom: support for demuxing and remuxing of MPEG-H 3D Audio in MP4
Hello James, On 2019/12/10 22:30, "James Almer" wrote: >> diff --git a/libavformat/utils.c b/libavformat/utils.c >> index 8196442dd1..70f9e23d8c 100644 >> --- a/libavformat/utils.c >> +++ b/libavformat/utils.c >> @@ -1021,7 +1021,8 @@ static int is_intra_only(enum AVCodecID id) >> const AVCodecDescriptor *d = avcodec_descriptor_get(id); >> if (!d) >> return 0; >> -if (d->type == AVMEDIA_TYPE_VIDEO && !(d->props & AV_CODEC_PROP_INTRA_ONLY)) >> +if ((d->type == AVMEDIA_TYPE_VIDEO && !(d->props & AV_CODEC_PROP_INTRA_ONLY)) || >> +id == AV_CODEC_ID_MPEGH_3D_AUDIO) >Instead of changing generic code like this to prevent all MPEG-H 3D >Audio packets from being tagged as key, you should add a custom function >much like the VC1 and the TrueHD ones called at the end of >ff_mov_write_packet() to set the MOV_SYNC_SAMPLE flag and increase the >track->has_keyframes counter where corresponds. If the modification in the is_intra_only() is removed, all demuxed frames will be tagged as key frame. This means that all single frames got from av_read_frame() will be key frame so it is difficult to start decoding from actual key frame. I think this modification or something like other method for keeping key frame information from stss box is required. Do you have any idea? ___ 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". ___ 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".
Re: [FFmpeg-devel] [PATCHv2] fate: Add an option for disabling the 2k/4k tests
Am Mi., 11. Dez. 2019 um 09:39 Uhr schrieb Martin Storsjö : > > When testing on a memory limited system, these tests consume a > significant amount of memory and can often fail if testing by running > multiple processes in parallel. > --- > Adjusted to use ALLYES instead of a -yes-yes construct. > > Also moved the 2k tests to the same option. > --- > configure | 3 +++ > tests/fate/seek.mak | 3 ++- > tests/fate/vcodec.mak | 5 +++-- > 3 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/configure b/configure > index ca7137f341..922cd8d0ee 100755 > --- a/configure > +++ b/configure > @@ -482,6 +482,7 @@ Developer options (useful when working on FFmpeg itself): >--ignore-tests=TESTS comma-separated list (without "fate-" prefix > in the name) of tests whose result is ignored >--enable-linux-perf enable Linux Performance Monitor API > + --disable-large-testsdisable tests that use a large amount of memory I would have suggested to control this when running the tests, if the configure setting makes sense, it should at least be possible to change the setting when calling make. Or is that possible anyway? Thank you for the useful change, 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/scale_eval: remove redundant mathematical constants
On 11-12-2019 11:45 am, Gyan wrote: On 10-12-2019 07:30 pm, Gyan wrote: Regards, Gyan Will push soon. Pushed as 78676ee8f81269937afdcaa2d9bb7bf77f53c1ba Gyan ___ 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".
Re: [FFmpeg-devel] [PATCHv2] fate: Add an option for disabling the 2k/4k tests
On Wed, 11 Dec 2019, Carl Eugen Hoyos wrote: Am Mi., 11. Dez. 2019 um 09:39 Uhr schrieb Martin Storsjö : When testing on a memory limited system, these tests consume a significant amount of memory and can often fail if testing by running multiple processes in parallel. --- Adjusted to use ALLYES instead of a -yes-yes construct. Also moved the 2k tests to the same option. --- configure | 3 +++ tests/fate/seek.mak | 3 ++- tests/fate/vcodec.mak | 5 +++-- 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/configure b/configure index ca7137f341..922cd8d0ee 100755 --- a/configure +++ b/configure @@ -482,6 +482,7 @@ Developer options (useful when working on FFmpeg itself): --ignore-tests=TESTS comma-separated list (without "fate-" prefix in the name) of tests whose result is ignored --enable-linux-perf enable Linux Performance Monitor API + --disable-large-testsdisable tests that use a large amount of memory I would have suggested to control this when running the tests, if the configure setting makes sense, it should at least be possible to change the setting when calling make. Or is that possible anyway? It's possible to do e.g. "make fate CONFIG_LARGE_TESTS=no"; any var=value assignment on the make command line overrides any var=othervalue assignment within the makefiles themselves, but that doesn't seem very convenient. But I'd like to have it as a configure option, to easily be able to set it e.g. in a fate setup. //Martin ___ 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".
[FFmpeg-devel] [PATCH] avformat/apngdec: Return error for incomplete header
When an incomplete header is encountered, apng_read_header would under certain circumstances only return the return value of the last successfull call. So override this by returning AVERROR(EIO) manually. Signed-off-by: Andreas Rheinhardt --- libavformat/apngdec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c index 0f1d04a365..65332c3fc5 100644 --- a/libavformat/apngdec.c +++ b/libavformat/apngdec.c @@ -240,6 +240,8 @@ static int apng_read_header(AVFormatContext *s) } } +return AVERROR(EIO); + fail: return ret; } -- 2.20.1 ___ 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".
Re: [FFmpeg-devel] [PATCH] lavc/hevc_cabac: fix cbf_cb and cbf_cr for transform depth 4
Am Mi., 11. Dez. 2019 um 09:57 Uhr schrieb Linjie Fu : > > The max transform depth is 5(from 0 to 4), so we need 5 cabac states for > cbf_cb and cbf_cr. > > See Table 9-4 for details. Does this change the output of a file? If yes, please provide it / implement a fate test. 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-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/apngdec: Remove goto fail that does nothing
Signed-off-by: Andreas Rheinhardt
---
Resending because of a merge conflict due to the other change.
libavformat/apngdec.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
index 65332c3fc5..424b450d69 100644
--- a/libavformat/apngdec.c
+++ b/libavformat/apngdec.c
@@ -151,17 +151,17 @@ static int apng_read_header(AVFormatContext *s)
uint32_t len, tag;
AVStream *st;
int acTL_found = 0;
-int64_t ret = AVERROR_INVALIDDATA;
+int64_t ret;
/* verify PNGSIG */
if (avio_rb64(pb) != PNGSIG)
-return ret;
+return AVERROR_INVALIDDATA;
/* parse IHDR (must be first chunk) */
len = avio_rb32(pb);
tag = avio_rl32(pb);
if (len != 13 || tag != MKTAG('I', 'H', 'D', 'R'))
-return ret;
+return AVERROR_INVALIDDATA;
st = avformat_new_stream(s, NULL);
if (!st)
@@ -186,18 +186,16 @@ static int apng_read_header(AVFormatContext *s)
AV_WB32(st->codecpar->extradata+8, st->codecpar->width);
AV_WB32(st->codecpar->extradata+12, st->codecpar->height);
if ((ret = avio_read(pb, st->codecpar->extradata+16, 9)) < 0)
-goto fail;
+return ret;
while (!avio_feof(pb)) {
if (acTL_found && ctx->num_play != 1) {
int64_t size = avio_size(pb);
int64_t offset = avio_tell(pb);
if (size < 0) {
-ret = size;
-goto fail;
+return size;
} else if (offset < 0) {
-ret = offset;
-goto fail;
+return offset;
} else if ((ret = ffio_ensure_seekback(pb, size - offset)) < 0) {
av_log(s, AV_LOG_WARNING, "Could not ensure seekback, will not
loop\n");
ctx->num_play = 1;
@@ -205,12 +203,11 @@ static int apng_read_header(AVFormatContext *s)
}
if ((ctx->num_play == 1 || !acTL_found) &&
((ret = ffio_ensure_seekback(pb, 4 /* len */ + 4 /* tag */)) < 0))
-goto fail;
+return ret;
len = avio_rb32(pb);
if (len > 0x7fff) {
-ret = AVERROR_INVALIDDATA;
-goto fail;
+return AVERROR_INVALIDDATA;
}
tag = avio_rl32(pb);
@@ -218,7 +215,7 @@ static int apng_read_header(AVFormatContext *s)
case MKTAG('a', 'c', 'T', 'L'):
if ((ret = avio_seek(pb, -8, SEEK_CUR)) < 0 ||
(ret = append_extradata(st->codecpar, pb, len + 12)) < 0)
-goto fail;
+return ret;
acTL_found = 1;
ctx->num_frames = AV_RB32(st->codecpar->extradata + ret + 8);
ctx->num_play = AV_RB32(st->codecpar->extradata + ret + 12);
@@ -227,23 +224,19 @@ static int apng_read_header(AVFormatContext *s)
break;
case MKTAG('f', 'c', 'T', 'L'):
if (!acTL_found) {
- ret = AVERROR_INVALIDDATA;
- goto fail;
+ return AVERROR_INVALIDDATA;
}
if ((ret = avio_seek(pb, -8, SEEK_CUR)) < 0)
-goto fail;
+return ret;
return 0;
default:
if ((ret = avio_seek(pb, -8, SEEK_CUR)) < 0 ||
(ret = append_extradata(st->codecpar, pb, len + 12)) < 0)
-goto fail;
+return ret;
}
}
return AVERROR(EIO);
-
-fail:
-return ret;
}
static int decode_fctl_chunk(AVFormatContext *s, APNGDemuxContext *ctx,
AVPacket *pkt)
--
2.20.1
___
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".
[FFmpeg-devel] [PATCH] avformat: Don't free old extradata before ff_alloc/get_extradata
These functions already free it themselves before they allocate the new
extradata.
Signed-off-by: Andreas Rheinhardt
---
Resending because I got the commit title wrong: There is no
ff_allocate_extradata.
libavformat/avidec.c | 2 --
libavformat/cafdec.c | 7 ++-
libavformat/concatdec.c| 4
libavformat/flic.c | 1 -
libavformat/flvdec.c | 1 -
libavformat/matroskaenc.c | 1 -
libavformat/mov.c | 4
libavformat/nuv.c | 4
libavformat/oggparseogm.c | 1 -
libavformat/oggparseopus.c | 1 -
libavformat/riffdec.c | 2 --
libavformat/rtpdec_latm.c | 1 -
libavformat/rtpdec_mpeg4.c | 2 +-
libavformat/rtpdec_qdm2.c | 2 +-
libavformat/rtpdec_svq3.c | 4
libavformat/utils.c| 1 -
libavformat/wavdec.c | 1 -
libavformat/xmv.c | 2 --
18 files changed, 4 insertions(+), 37 deletions(-)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 21871feb8d..ae0c227bb9 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -770,7 +770,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
st->codecpar->extradata_size = size - 10 * 4;
if (st->codecpar->extradata) {
av_log(s, AV_LOG_WARNING, "New extradata in strf
chunk, freeing previous one.\n");
-av_freep(&st->codecpar->extradata);
}
ret = ff_get_extradata(s, st->codecpar, pb,
st->codecpar->extradata_size);
@@ -932,7 +931,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (size<(1<<30)) {
if (st->codecpar->extradata) {
av_log(s, AV_LOG_WARNING, "New extradata in strd
chunk, freeing previous one.\n");
-av_freep(&st->codecpar->extradata);
}
if ((ret = ff_get_extradata(s, st->codecpar, pb, size)) <
0)
return ret;
diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
index 85356ec439..d0f942f3e4 100644
--- a/libavformat/cafdec.c
+++ b/libavformat/cafdec.c
@@ -135,7 +135,6 @@ static int read_kuki_chunk(AVFormatContext *s, int64_t size)
return AVERROR_INVALIDDATA;
}
-av_freep(&st->codecpar->extradata);
if ((ret = ff_alloc_extradata(st->codecpar, ALAC_HEADER)) < 0)
return ret;
@@ -175,10 +174,8 @@ static int read_kuki_chunk(AVFormatContext *s, int64_t
size)
return AVERROR_PATCHWELCOME;
}
avio_skip(pb, size);
-} else {
-av_freep(&st->codecpar->extradata);
-if ((ret = ff_get_extradata(s, st->codecpar, pb, size)) < 0)
-return ret;
+} else if ((ret = ff_get_extradata(s, st->codecpar, pb, size)) < 0) {
+return ret;
}
return 0;
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index b80294efbf..e826821241 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -171,10 +171,6 @@ static int copy_stream_props(AVStream *st, AVStream
*source_st)
if (st->codecpar->codec_id || !source_st->codecpar->codec_id) {
if (st->codecpar->extradata_size <
source_st->codecpar->extradata_size) {
-if (st->codecpar->extradata) {
-av_freep(&st->codecpar->extradata);
-st->codecpar->extradata_size = 0;
-}
ret = ff_alloc_extradata(st->codecpar,
source_st->codecpar->extradata_size);
if (ret < 0)
diff --git a/libavformat/flic.c b/libavformat/flic.c
index 4ba72fb037..615d6b25c5 100644
--- a/libavformat/flic.c
+++ b/libavformat/flic.c
@@ -175,7 +175,6 @@ static int flic_read_header(AVFormatContext *s)
avio_seek(pb, 12, SEEK_SET);
/* send over abbreviated FLIC header chunk */
-av_freep(&st->codecpar->extradata);
if ((ret = ff_alloc_extradata(st->codecpar, 12)) < 0)
return ret;
memcpy(st->codecpar->extradata, header, 12);
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 03b0c22f9d..7c3e5b06c6 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -799,7 +799,6 @@ static int flv_get_extradata(AVFormatContext *s, AVStream
*st, int size)
if (!size)
return 0;
-av_freep(&st->codecpar->extradata);
if ((ret = ff_get_extradata(s, st->codecpar, s->pb, size)) < 0)
return ret;
st->internal->need_context_update = 1;
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 570f361351..469b604de6 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -2264,7 +2264,6 @@ static int mkv_check_new_extra_data(AVFormatContext *s,
AVPacket *pkt)
return ret;
if (!output_sample_rate)
output_sample_rate = track->sample_rate; // Space is already
reserved, so it's this or a void ele
[FFmpeg-devel] [PATCH 1/2] rtsp: Use AVERROR() with errno.h error codes for error returns
For this particular function, it's only required to return nonzero, but use the common AVERROR() pattern for consistency. --- libavformat/rtsp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c index 859defa592..cd6fc32a29 100644 --- a/libavformat/rtsp.c +++ b/libavformat/rtsp.c @@ -1319,7 +1319,7 @@ static int rtsp_send_cmd_with_content_async(AVFormatContext *s, char base64buf[AV_BASE64_SIZE(sizeof(buf))]; if (!rt->rtsp_hd_out) -return ENOTCONN; +return AVERROR(ENOTCONN); /* Add in RTSP headers */ out_buf = buf; -- 2.17.1 ___ 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".
[FFmpeg-devel] [PATCH 2/2] network: Define ENOTCONN as WSAENOTCONN if not defined
This fixes compilation with old mingw.org toolchains, which has got much fewer errno.h entries. --- There's still a couple fate instances that use mingw.org headers/libs, and this is the only detail that currently stops them from building. --- libavformat/network.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/network.h b/libavformat/network.h index 7f467304a8..71347e815b 100644 --- a/libavformat/network.h +++ b/libavformat/network.h @@ -50,6 +50,9 @@ #ifndef EINPROGRESS #define EINPROGRESS WSAEINPROGRESS #endif +#ifndef ENOTCONN +#define ENOTCONNWSAENOTCONN +#endif #define getsockopt(a, b, c, d, e) getsockopt(a, b, c, (char*) d, e) #define setsockopt(a, b, c, d, e) setsockopt(a, b, c, (const char*) d, e) -- 2.17.1 ___ 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".
Re: [FFmpeg-devel] [PATCH] lavf/zf_zscale: remove unused code
On Wed, Dec 11, 2019 at 16:52:17 +0800, Linjie Fu wrote: > Subject: lavf/zf_zscale: remove unused code ^ vf_ ;-) Moritz ___ 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".
Re: [FFmpeg-devel] [PATCHv2] fate: Use a oneoff test for the tremolo filter
On 12/11/2019 4:43 AM, Martin Storsjö wrote: > The tremolo filter uses floating point internally, and uses > multiplication factors derived from sin(fmod()), neither of > which is bitexact for use with framecrc. > > This fixes running this test with mingw/x86_32 binaries when run > in wine on linux (unsure if the same issue is present when run > on actual windows). > > In this case, a 1 ulp difference in the output from fmod() would > end up in an output from the filter that differs by 1 ulp, but > which makes the lrint() in swresample/audioconvert.c round in a > different direction. > > --- > Updated with the existing reference file removed. > --- > tests/fate/filter-audio.mak | 5 - > tests/ref/fate/filter-tremolo | 26 -- > 2 files changed, 4 insertions(+), 27 deletions(-) > delete mode 100644 tests/ref/fate/filter-tremolo > > diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak > index fed2644ccf..b1dcb9787a 100644 > --- a/tests/fate/filter-audio.mak > +++ b/tests/fate/filter-audio.mak > @@ -189,7 +189,10 @@ fate-filter-stereotools: CMD = framecrc -i $(SRC) > -frames:a 20 -af stereotools=m > FATE_AFILTER-$(call FILTERDEMDECENCMUX, TREMOLO, WAV, PCM_S16LE, PCM_S16LE, > WAV) += fate-filter-tremolo Needs to be FATE_AFILTER_SAMPLES now that it's using a reference sample rather than only the autogenerated asynth-44100-2.wav. > fate-filter-tremolo: tests/data/asynth-44100-2.wav > fate-filter-tremolo: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav > -fate-filter-tremolo: CMD = framecrc -i $(SRC) -frames:a 20 -af tremolo > +fate-filter-tremolo: CMD = ffmpeg -i $(SRC) -frames:a 20 -af tremolo -f wav > -f s16le - > +fate-filter-tremolo: REF = $(SAMPLES)/filter/tremolo.pcm Created and uploaded it, so feel free to push this patch after you fix the above and confirm the ref sample is ok. > +fate-filter-tremolo: CMP = oneoff > +fate-filter-tremolo: CMP_UNIT = s16 > > FATE_AFILTER-$(call FILTERDEMDECENCMUX, COMPAND, WAV, PCM_S16LE, PCM_S16LE, > WAV) += fate-filter-compand > fate-filter-compand: tests/data/asynth-44100-2.wav > diff --git a/tests/ref/fate/filter-tremolo b/tests/ref/fate/filter-tremolo > deleted file mode 100644 > index c6cff52c0e..00 > --- a/tests/ref/fate/filter-tremolo > +++ /dev/null > @@ -1,26 +0,0 @@ > -#tb 0: 1/44100 > -#media_type 0: audio > -#codec_id 0: pcm_s16le > -#sample_rate 0: 44100 > -#channel_layout 0: 3 > -#channel_layout_name 0: stereo > -0, 0, 0, 1024, 4096, 0x5d3be907 > -0, 1024, 1024, 1024, 4096, 0xea151fbe > -0, 2048, 2048, 1024, 4096, 0xa5bc19f4 > -0, 3072, 3072, 1024, 4096, 0x8706ec6d > -0, 4096, 4096, 1024, 4096, 0x334ff275 > -0, 5120, 5120, 1024, 4096, 0xcd0ff7ad > -0, 6144, 6144, 1024, 4096, 0x29a1e9c9 > -0, 7168, 7168, 1024, 4096, 0x1d41e77f > -0, 8192, 8192, 1024, 4096, 0x99e7fe07 > -0, 9216, 9216, 1024, 4096, 0x4bbf09ce > -0, 10240, 10240, 1024, 4096, 0x94600236 > -0, 11264, 11264, 1024, 4096, 0xc8af0c9e > -0, 12288, 12288, 1024, 4096, 0x70eef88f > -0, 13312, 13312, 1024, 4096, 0xb222ec47 > -0, 14336, 14336, 1024, 4096, 0x1071ee27 > -0, 15360, 15360, 1024, 4096, 0x7c390bd2 > -0, 16384, 16384, 1024, 4096, 0x68bdf655 > -0, 17408, 17408, 1024, 4096, 0x810cfacb > -0, 18432, 18432, 1024, 4096, 0x9639e41f > -0, 19456, 19456, 1024, 4096, 0xa30be70f > ___ 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".
Re: [FFmpeg-devel] 回复: [PATCH 1/1] add without_captureblt option for libavdevice/gdigrab.c, when useing the bitblt function with CAPTUREBLT it caused the mouse cursor flicker. most time we dont need t
On Wed, 11. Dec 09:01, _ FgoDt wrote:
> did someone review the patch?
>
>
> 发件人: _ FgoDt
> 发送时间: 2019年11月15日 15:03
> 收件人: ffmpeg-devel@ffmpeg.org
> 抄送: _ FgoDt
> 主题: [PATCH 1/1] add without_captureblt option for libavdevice/gdigrab.c, when
> useing the bitblt function with CAPTUREBLT it caused the mouse cursor
> flicker. most time we dont need this flag to capture window
>
> From: fgodt
This would be in commit, you should use your name.
>
> Signed-off-by: fgodt
> ---
> libavdevice/gdigrab.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
> index f406fa..0ab0cfed01 100644
> --- a/libavdevice/gdigrab.c
> +++ b/libavdevice/gdigrab.c
> @@ -53,6 +53,8 @@ struct gdigrab {
> intoffset_x;/**< Capture x offset (private option) */
> intoffset_y;/**< Capture y offset (private option) */
>
> +intwithout_captureblt; /**< capture without captureblt */
> +
> HWND hwnd;/**< Handle of the window for the grab */
> HDCsource_hdc; /**< Source device context */
> HDCdest_hdc;/**< Destination, source-compatible DC */
> @@ -542,6 +544,8 @@ static int gdigrab_read_packet(AVFormatContext *s1,
> AVPacket *pkt)
>
> int64_t curtime, delay;
>
> +unsigned long flag;
> +
> /* Calculate the time of the next frame */
> time_frame += INT64_C(100);
>
> @@ -570,12 +574,16 @@ static int gdigrab_read_packet(AVFormatContext *s1,
> AVPacket *pkt)
> return AVERROR(ENOMEM);
> pkt->pts = curtime;
>
> +flag = SRCCOPY;
> +if(!gdigrab->without_captureblt)
> +flag |= CAPTUREBLT;
> +
> /* Blit screen grab */
> if (!BitBlt(dest_hdc, 0, 0,
> clip_rect.right - clip_rect.left,
> clip_rect.bottom - clip_rect.top,
> source_hdc,
> -clip_rect.left, clip_rect.top, SRCCOPY | CAPTUREBLT)) {
> +clip_rect.left, clip_rect.top, flag)) {
> WIN32_API_ERROR("Failed to capture image");
> return AVERROR(EIO);
> }
> @@ -639,6 +647,7 @@ static const AVOption options[] = {
> { "video_size", "set video frame size", OFFSET(width),
> AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, DEC },
> { "offset_x", "capture area x offset", OFFSET(offset_x),
> AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX, DEC },
> { "offset_y", "capture area y offset", OFFSET(offset_y),
> AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX, DEC },
> +{ "without_captureblt", "capture without captureblt",
> OFFSET(without_captureblt), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, DEC },
> { NULL },
> };
IMO a not negated option would be better. i.e. use_captureblt that's enabled by
default.
You also need to update the docs.
I don't have windows so can't test on my machine.
--
Andriy
___
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".
Re: [FFmpeg-devel] [PATCHv2] fate: Use a oneoff test for the tremolo filter
On Wed, 11 Dec 2019, James Almer wrote: On 12/11/2019 4:43 AM, Martin Storsjö wrote: The tremolo filter uses floating point internally, and uses multiplication factors derived from sin(fmod()), neither of which is bitexact for use with framecrc. This fixes running this test with mingw/x86_32 binaries when run in wine on linux (unsure if the same issue is present when run on actual windows). In this case, a 1 ulp difference in the output from fmod() would end up in an output from the filter that differs by 1 ulp, but which makes the lrint() in swresample/audioconvert.c round in a different direction. --- Updated with the existing reference file removed. --- tests/fate/filter-audio.mak | 5 - tests/ref/fate/filter-tremolo | 26 -- 2 files changed, 4 insertions(+), 27 deletions(-) delete mode 100644 tests/ref/fate/filter-tremolo diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak index fed2644ccf..b1dcb9787a 100644 --- a/tests/fate/filter-audio.mak +++ b/tests/fate/filter-audio.mak @@ -189,7 +189,10 @@ fate-filter-stereotools: CMD = framecrc -i $(SRC) -frames:a 20 -af stereotools=m FATE_AFILTER-$(call FILTERDEMDECENCMUX, TREMOLO, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-tremolo Needs to be FATE_AFILTER_SAMPLES now that it's using a reference sample rather than only the autogenerated asynth-44100-2.wav. Ah, good catch - amended locally fate-filter-tremolo: tests/data/asynth-44100-2.wav fate-filter-tremolo: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav -fate-filter-tremolo: CMD = framecrc -i $(SRC) -frames:a 20 -af tremolo +fate-filter-tremolo: CMD = ffmpeg -i $(SRC) -frames:a 20 -af tremolo -f wav -f s16le - +fate-filter-tremolo: REF = $(SAMPLES)/filter/tremolo.pcm Created and uploaded it, so feel free to push this patch after you fix the above and confirm the ref sample is ok. Thanks! Seems to work fine for me, so I'll push this one a bit later then. // Martin ___ 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".
Re: [FFmpeg-devel] [PATCH] lavf/zf_zscale: remove unused code
Am Mi., 11. Dez. 2019 um 14:30 Uhr schrieb Moritz Barsnick : > > On Wed, Dec 11, 2019 at 16:52:17 +0800, Linjie Fu wrote: > > Subject: lavf/zf_zscale: remove unused code > ^ vf_ While there, change "lavf" to lavfi or avfilter 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/apngdec: Return error for incomplete header
Am Mi., 11. Dez. 2019 um 12:14 Uhr schrieb Andreas Rheinhardt : > > When an incomplete header is encountered, apng_read_header would under > certain circumstances only return the return value of the last > successfull call. So override this by returning AVERROR(EIO) manually. What does this fix / does it possibly break files which where decoded so far? 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] network: Define ENOTCONN as WSAENOTCONN if not defined
Am Mi., 11. Dez. 2019 um 13:21 Uhr schrieb Martin Storsjö : > > This fixes compilation with old mingw.org toolchains, which has got > much fewer errno.h entries. > --- > There's still a couple fate instances that use mingw.org headers/libs, > and this is the only detail that currently stops them from building. > --- > libavformat/network.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/network.h b/libavformat/network.h > index 7f467304a8..71347e815b 100644 > --- a/libavformat/network.h > +++ b/libavformat/network.h > @@ -50,6 +50,9 @@ > #ifndef EINPROGRESS > #define EINPROGRESS WSAEINPROGRESS > #endif > +#ifndef ENOTCONN > +#define ENOTCONNWSAENOTCONN > +#endif Looks very useful. Please commit, 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2 2/2] checkasm: float_dsp: Scale FLT/DBL_EPSILON sufficiently when comparing
On Wed, Dec 11, 2019 at 11:21:14AM +0200, Martin Storsjö wrote: > As the values generated by av_bmg_get can be arbitrarily large > (only the stddev is specified), we can't use a fixed tolerance. > > This matches what was done for test_vector_dmul_scalar in > 38f966bdb. > > This fixes the float_dsp checkasm test for some seeds, when built > with clang for mingw/x86_32. > --- > Tweaked the form of the tolerance to match the existing case, removed > unnecessarily wordy comments. > --- > tests/checkasm/float_dsp.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) LGTM thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato 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".
Re: [FFmpeg-devel] [PATCH] avcodec/v210dec: move the stride read after its fully initialized
On Sun, Dec 01, 2019 at 11:26:47PM +0100, Michael Niedermayer wrote:
> Fixes: out of array read
> Fixes:
> 19129/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_V210_fuzzer-5068171023482880
> Maybe fixes:
> 19130/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_V210_fuzzer-5637264407527424
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/v210dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
> index 8483023815..044d35338b 100644
> --- a/libavcodec/v210dec.c
> +++ b/libavcodec/v210dec.c
> @@ -153,7 +153,6 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
> int aligned_width = ((avctx->width + 47) / 48) * 48;
> stride = aligned_width * 8 / 3;
> }
> -td.stride = stride;
>
> if (avpkt->size < stride * avctx->height) {
> if avctx->width + 23) / 24) * 24 * 8) / 3 * avctx->height ==
> avpkt->size) {
> @@ -166,6 +165,7 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
> return AVERROR_INVALIDDATA;
> }
> }
> +td.stride = stride;
LGTM
> if ( avctx->codec_tag == MKTAG('C', '2', '1', '0')
> && avpkt->size > 64
> && AV_RN32(psrc) == AV_RN32("INFO")
> --
> 2.23.0
>
> ___
> 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".
___
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".
Re: [FFmpeg-devel] [PATCH 1/7] avcodec/cbs: Check for overflow when reading
On Tue, Dec 10, 2019 at 11:12 PM Andriy Gelman
wrote:
> On Mon, 09. Dec 23:25, Andreas Rheinhardt wrote:
> > While CBS itself uses size_t for sizes, it relies on other APIs that use
> > int for their sizes; in particular, AVBuffer uses int for their size
> > parameters and so does GetBitContext with their number of bits. While
> > CBS aims to be a safe API, the checks it employed were not sufficient to
> > prevent overflows: E.g. if the size of a unit was > UINT_MAX / 8, 8 *
> > said size may be truncated to a positive integer before being passed to
> > init_get_bits() in which case its return value would not indicate an
> > error.
> >
> > These checks have been improved to really capture these kinds of errors;
> > furthermore, although the sizes are still size_t, they are now de-facto
> > restricted to 0..INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE.
> >
> > Signed-off-by: Andreas Rheinhardt
> > ---
> > The check in cbs_insert_unit() can currently not be triggered, because
> > av_malloc_array makes sure that it doesn't allocate more than INT_MAX;
> > so the allocation will fail long before we get even close to INT_MAX.
> >
> > av1 and H.26x have not been changed, because their split functions
> > already check the size (in case of H.264 and H.265 this happens in
> > ff_h2645_packet_split()).
> >
> > It would btw be possible to open the GetBitContext generically. The
> > read_unit function would then get the already opened GetBitContext
> > as a parameter.
> >
> > libavcodec/cbs.c | 6 ++
> > libavcodec/cbs_jpeg.c | 2 +-
> > libavcodec/cbs_mpeg2.c | 2 +-
> > libavcodec/cbs_vp9.c | 2 +-
> > 4 files changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> > index 0badb192d9..805049404b 100644
> > --- a/libavcodec/cbs.c
> > +++ b/libavcodec/cbs.c
> > @@ -206,6 +206,9 @@ static int
> cbs_fill_fragment_data(CodedBitstreamContext *ctx,
> > {
> > av_assert0(!frag->data && !frag->data_ref);
> >
> > +if (size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE)
> > +return AVERROR(ERANGE);
> > +
> > frag->data_ref =
> > av_buffer_alloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
> > if (!frag->data_ref)
> > @@ -693,6 +696,9 @@ static int cbs_insert_unit(CodedBitstreamContext
> *ctx,
> > memmove(units + position + 1, units + position,
> > (frag->nb_units - position) * sizeof(*units));
> > } else {
>
> > +if (frag->nb_units == INT_MAX)
> > +return AVERROR(ERANGE);
> > +
>
> Why did you decide to include this? As you say in your comments it cannot
> be
> triggered.
>
> It can currently not be triggered; but the parameters of av_malloc_array
are size_t and a future version of said function might remove the 2 GB
allocation limit.
- Andreas
___
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".
[FFmpeg-devel] [PATCH v1 2/2] avcodec/h265_metadata_bsf: add option to insert a string as SEI unregistered user data
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/bitstream_filters.texi | 8 ++
libavcodec/h265_metadata_bsf.c | 65 +-
2 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 8fe5b3a..81b41d7 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -376,6 +376,14 @@ The argument must be the name of a level (for example,
@samp{5.1}), a
or the special name @samp{auto} indicating that the filter should
attempt to guess the level from the input stream properties.
+@item sei_user_data
+Insert a string as SEI unregistered user data. The argument must
+be of the form @emph{UUID+string}, where the UUID is as a 32-character
+(16 bytes) hexadecimal string possibly separated by hyphens, and the
+string can be anything.
+
+For example, @samp{086f3693-b7b3-4f2c-9653-21492feee5b8+hello} will
+insert the string ``hello'' associated with the given 32-bit UUID.
@end table
@section hevc_mp4toannexb
diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
index b3a1fda..f32ddf0 100644
--- a/libavcodec/h265_metadata_bsf.c
+++ b/libavcodec/h265_metadata_bsf.c
@@ -16,6 +16,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include "libavutil/avstring.h"
#include "libavutil/common.h"
#include "libavutil/opt.h"
@@ -23,6 +24,7 @@
#include "cbs.h"
#include "cbs_h265.h"
#include "hevc.h"
+#include "hevc_sei.h"
#include "h265_profile_level.h"
enum {
@@ -65,6 +67,8 @@ typedef struct H265MetadataContext {
int crop_top;
int crop_bottom;
+const char *sei_user_data;
+
int level;
int level_guess;
int level_warned;
@@ -340,7 +344,7 @@ static int h265_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
{
H265MetadataContext *ctx = bsf->priv_data;
CodedBitstreamFragment *au = &ctx->access_unit;
-int err, i;
+int err, i, j, has_sps = 0, has_vps = 0;
err = ff_bsf_get_packet_ref(bsf, pkt);
if (err < 0)
@@ -410,11 +414,67 @@ static int h265_metadata_filter(AVBSFContext *bsf,
AVPacket *pkt)
err = h265_metadata_update_vps(bsf, au->units[i].content);
if (err < 0)
goto fail;
+has_vps = 1;
}
if (au->units[i].type == HEVC_NAL_SPS) {
err = h265_metadata_update_sps(bsf, au->units[i].content);
if (err < 0)
goto fail;
+has_sps = 1;
+}
+}
+
+// Only insert the SEI in access units containing SPSs or VPSs
+if (ctx->sei_user_data && (has_sps || has_vps)) {
+H265RawSEIPayload payload = {
+.payload_type = HEVC_SEI_TYPE_USER_DATA_UNREGISTERED,
+};
+H265RawSEIUserDataUnregistered *udu =
+&payload.payload.user_data_unregistered;
+
+for (i = j = 0; j < 32 && ctx->sei_user_data[i]; i++) {
+int c, v;
+c = ctx->sei_user_data[i];
+if (c == '-') {
+continue;
+} else if (av_isxdigit(c)) {
+c = av_tolower(c);
+v = (c <= '9' ? c - '0' : c - 'a' + 10);
+} else {
+goto invalid_user_data;
+}
+if (i & 1)
+udu->uuid_iso_iec_11578[j / 2] |= v;
+else
+udu->uuid_iso_iec_11578[j / 2] = v << 4;
+++j;
+}
+if (j == 32 && ctx->sei_user_data[i] == '+') {
+size_t len = strlen(ctx->sei_user_data + i + 1);
+
+udu->data_ref = av_buffer_alloc(len + 1);
+if (!udu->data_ref) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+udu->data= udu->data_ref->data;
+udu->data_length = len + 1;
+memcpy(udu->data, ctx->sei_user_data + i + 1, len + 1);
+
+err = ff_cbs_h265_add_sei_prefix_message(ctx->cbc, au, &payload);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
+ "message to access unit.\n");
+goto fail;
+}
+
+} else {
+invalid_user_data:
+av_log(bsf, AV_LOG_ERROR, "Invalid user data: "
+ "must be \"UUID+string\".\n");
+err = AVERROR(EINVAL);
+goto fail;
}
}
@@ -547,6 +607,9 @@ static const AVOption h265_metadata_options[] = {
OFFSET(crop_bottom), AV_OPT_TYPE_INT,
{ .i64 = -1 }, -1, HEVC_MAX_HEIGHT, FLAGS },
+{ "sei_user_data", "Insert SEI user data (UUID+string)",
+OFFSET(sei_user_data), AV_OPT_TYPE_STRING, { .str = NULL }, .flags =
FLAGS },
+
{ "level", "Set level (tables A.6 and A.7)",
OFFSET(level), AV_OPT_TYPE_INT,
{ .i64 = LEVEL_UNSET }, LEVEL_UNSET, 0xff, FLAGS, "level" },
--
2.9.5
___
f
[FFmpeg-devel] [PATCH v1 1/2] avcodec/cbs_h2645: add helper functions to insert and delete SEI PREFIX messages
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/cbs_h2645.c | 93 ++
libavcodec/cbs_h265.h | 25 ++
2 files changed, 118 insertions(+)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 5f71d80..2fc957d 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1612,3 +1612,96 @@ void
ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
(sei->payload_count - position) * sizeof(*sei->payload));
}
}
+
+int ff_cbs_h265_add_sei_prefix_message(CodedBitstreamContext *ctx,
+CodedBitstreamFragment *au,
+H265RawSEIPayload *payload)
+{
+H265RawSEI *sei = NULL;
+int err, i;
+
+// Find an existing SEI PREFIX NAL unit to add to.
+for (i = 0; i < au->nb_units; i++) {
+if (au->units[i].type == HEVC_NAL_SEI_PREFIX) {
+sei = au->units[i].content;
+if (sei->payload_count < H265_MAX_SEI_PAYLOADS)
+break;
+
+sei = NULL;
+}
+}
+
+if (!sei) {
+// Need to make a new SEI NAL unit. Insert it before the first
+// slice data NAL unit; if no slice data, add at the end.
+AVBufferRef *sei_ref;
+
+sei = av_mallocz(sizeof(*sei));
+if (!sei) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+sei->nal_unit_header.nal_unit_type = HEVC_NAL_SEI_PREFIX;
+sei->nal_unit_header.nuh_layer_id = 0;
+sei->nal_unit_header.nuh_temporal_id_plus1 = 1;
+
+sei_ref = av_buffer_create((uint8_t*)sei, sizeof(*sei),
+ &cbs_h265_free_sei, NULL, 0);
+if (!sei_ref) {
+av_freep(&sei);
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+for (i = 0; i < au->nb_units; i++) {
+if (au->units[i].type == HEVC_NAL_IDR_W_RADL ||
+au->units[i].type == HEVC_NAL_IDR_N_LP)
+break;
+}
+
+err = ff_cbs_insert_unit_content(ctx, au, i, HEVC_NAL_SEI_PREFIX,
+ sei, sei_ref);
+av_buffer_unref(&sei_ref);
+if (err < 0)
+goto fail;
+}
+
+memcpy(&sei->payload[sei->payload_count], payload, sizeof(*payload));
+++sei->payload_count;
+
+return 0;
+fail:
+cbs_h265_free_sei_payload(payload);
+return err;
+}
+
+void ff_cbs_h265_delete_sei_prefix_message(CodedBitstreamContext *ctx,
+CodedBitstreamFragment *au,
+CodedBitstreamUnit *nal,
+int position)
+{
+H265RawSEI *sei = nal->content;
+
+av_assert0(nal->type == HEVC_NAL_SEI_PREFIX);
+av_assert0(position >= 0 && position < sei->payload_count);
+
+if (position == 0 && sei->payload_count == 1) {
+// Deleting NAL unit entirely.
+int i;
+
+for (i = 0; i < au->nb_units; i++) {
+if (&au->units[i] == nal)
+break;
+}
+
+ff_cbs_delete_unit(ctx, au, i);
+} else {
+cbs_h265_free_sei_payload(&sei->payload[position]);
+
+--sei->payload_count;
+memmove(sei->payload + position,
+sei->payload + position + 1,
+(sei->payload_count - position) * sizeof(*sei->payload));
+}
+}
diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
index ad746bf..b7e7dff 100644
--- a/libavcodec/cbs_h265.h
+++ b/libavcodec/cbs_h265.h
@@ -22,6 +22,7 @@
#include
#include
+#include "cbs.h"
#include "cbs_h2645.h"
#include "hevc.h"
@@ -745,5 +746,29 @@ typedef struct CodedBitstreamH265Context {
const H265RawPPS *active_pps;
} CodedBitstreamH265Context;
+/**
+ * Add an SEI message to an access unit.
+ *
+ * On success, the payload will be owned by a unit in access_unit;
+ * on failure, the content of the payload will be freed.
+ */
+int ff_cbs_h265_add_sei_prefix_message(CodedBitstreamContext *ctx,
+CodedBitstreamFragment *access_unit,
+H265RawSEIPayload *payload);
+
+/**
+ * Delete an SEI message from an access unit.
+ *
+ * Deletes from nal_unit, which must be an SEI PREFIX NAL unit. If this is the
+ * last message in nal_unit, also deletes it from access_unit.
+ *
+ * Requires nal_unit to be a unit in access_unit and position to be >= 0
+ * and < the payload count of the SEI nal_unit.
+ */
+void ff_cbs_h265_delete_sei_prefix_message(CodedBitstreamContext *ctx,
+CodedBitstreamFragment *access_unit,
+CodedBitstreamUnit *nal_unit,
+int position);
+
#endif /* AVCODEC_CBS_H265_H */
--
2.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
T
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/cbs_mpeg2: Change assertion from bytes to bits
On Mon, Dec 09, 2019 at 12:52:45PM +0100, Andreas Rheinhardt wrote: > On Mon, Dec 9, 2019 at 2:54 AM James Almer wrote: > > > On 12/8/2019 6:31 PM, Michael Niedermayer wrote: > > > This allows writing empty slices > > > > Are empty slices valid in mpeg2 to begin with? Or is that the result of > > invalid/truncated data exclusively? > > > > It's invalid data, unless data partitioning (which we do not and IMO > should never support) is in use. Data partitioning allows to split the > bitstream into two that can be sent independently (and over channels of > different reliability) and it allows the slice in the base layer to only > contain everything excluding the macroblocks (i.e. everything that we put > into the slice header). > > But if data partitioning is not in use, there has to be a macroblock after > the extra_information_slice and a macroblock consists of more than zero > bits; in fact, there always has to be a bit set to 1 among the first eight > bits (which is not meant to imply that every macroblock needs to contain > eight bits at all). > > I will add a check to error out if slices without data beyond the slice > header are encountered upon reading. And also similar patches for cbs_h2645. well, we can be more picky and error out yes. Thats primarly a question what to do when the input isnt strictly valid, do we support maintaining all parts in their invalid form or do we do something else like droping parts that arent valid. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope 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".
Re: [FFmpeg-devel] [PATCH v4] avfilter/buffersrc: deprecate sws_param option
Ping for review, thanks!
> On Dec 4, 2019, at 6:57 PM, quinkbl...@foxmail.com wrote:
>
> From: Zhao Zhili
>
> ---
> patch v4: update doc
>
> doc/filters.texi| 8
> libavfilter/buffersrc.c | 14 --
> libavfilter/version.h | 5 -
> 3 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 5fdec6f015..d15cf74c84 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -21014,9 +21014,9 @@ Specify the frame rate expected for the video stream.
> The sample (pixel) aspect ratio of the input video.
>
> @item sws_param
> -Specify the optional parameters to be used for the scale filter which
> -is automatically inserted when an input change is detected in the
> -input size or format.
> +This option is deprecated and ignored. Prepend @code{sws_flags=@var{flags};}
> +to the filtergraph description to specify swscale flags for automatically
> +inserted scalers. See @ref{Filtergraph syntax}.
>
> @item hw_frames_ctx
> When using a hardware pixel format, this should be a reference to an
> @@ -21041,7 +21041,7 @@
> buffer=size=320x240:pixfmt=6:time_base=1/24:pixel_aspect=1/1
> Alternatively, the options can be specified as a flat string, but this
> syntax is deprecated:
>
> -@var{width}:@var{height}:@var{pix_fmt}:@var{time_base.num}:@var{time_base.den}:@var{pixel_aspect.num}:@var{pixel_aspect.den}[:@var{sws_param}]
> +@var{width}:@var{height}:@var{pix_fmt}:@var{time_base.num}:@var{time_base.den}:@var{pixel_aspect.num}:@var{pixel_aspect.den}
>
> @section cellauto
>
> diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
> index bae7d86695..73a7eb82ca 100644
> --- a/libavfilter/buffersrc.c
> +++ b/libavfilter/buffersrc.c
> @@ -52,7 +52,9 @@ typedef struct BufferSourceContext {
> int w, h;
> enum AVPixelFormat pix_fmt;
> AVRationalpixel_aspect;
> +#if FF_API_SWS_PARAM_OPTION
> char *sws_param;
> +#endif
>
> AVBufferRef *hw_frames_ctx;
>
> @@ -287,10 +289,16 @@ static av_cold int init_video(AVFilterContext *ctx)
> if (!(c->fifo = av_fifo_alloc(sizeof(AVFrame*
> return AVERROR(ENOMEM);
>
> -av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d
> sar:%d/%d sws_param:%s\n",
> +av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d
> sar:%d/%d\n",
>c->w, c->h, av_get_pix_fmt_name(c->pix_fmt),
>c->time_base.num, c->time_base.den, c->frame_rate.num,
> c->frame_rate.den,
> - c->pixel_aspect.num, c->pixel_aspect.den, (char
> *)av_x_if_null(c->sws_param, ""));
> + c->pixel_aspect.num, c->pixel_aspect.den);
> +
> +#if FF_API_SWS_PARAM_OPTION
> +if (c->sws_param)
> +av_log(ctx, AV_LOG_WARNING, "sws_param option is deprecated and
> ignored\n");
> +#endif
> +
> return 0;
> }
>
> @@ -312,7 +320,9 @@ static const AVOption buffer_options[] = {
> { "pixel_aspect", "sample aspect ratio",OFFSET(pixel_aspect),
> AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> { "time_base", NULL, OFFSET(time_base),
> AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> { "frame_rate",NULL, OFFSET(frame_rate),
> AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> +#if FF_API_SWS_PARAM_OPTION
> { "sws_param", NULL, OFFSET(sws_param),
> AV_OPT_TYPE_STRING,.flags = V },
> +#endif
> { NULL },
> };
>
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index 7e8d849e0c..bf57d64d1f 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -31,7 +31,7 @@
>
> #define LIBAVFILTER_VERSION_MAJOR 7
> #define LIBAVFILTER_VERSION_MINOR 67
> -#define LIBAVFILTER_VERSION_MICRO 100
> +#define LIBAVFILTER_VERSION_MICRO 101
>
>
> #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
> @@ -59,6 +59,9 @@
> #ifndef FF_API_FILTER_GET_SET
> #define FF_API_FILTER_GET_SET (LIBAVFILTER_VERSION_MAJOR < 8)
> #endif
> +#ifndef FF_API_SWS_PARAM_OPTION
> +#define FF_API_SWS_PARAM_OPTION (LIBAVFILTER_VERSION_MAJOR < 8)
> +#endif
> #ifndef FF_API_NEXT
> #define FF_API_NEXT (LIBAVFILTER_VERSION_MAJOR < 8)
> #endif
> --
> 2.22.0
>
> From: Zhao Zhili
>
> ---
> patch v4: update doc
>
> doc/filters.texi| 8
> libavfilter/buffersrc.c | 14 --
> libavfilter/version.h | 5 -
> 3 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 5fdec6f015..d15cf74c84 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -21014,9 +21014,9 @@ Specify the frame rate expected for the video stream.
> The sample (pixel) aspect ratio of the input video.
>
> @item sws_param
> -Specify the optional parameters to be used for the scale filter which
> -is automatically inserted when an inpu
Re: [FFmpeg-devel] [PATCH 1/3] avformat/apc: Remove unnecessary resetting of flags
On Tue, Dec 10, 2019 at 02:41:43AM +0100, Andreas Rheinhardt wrote: > The packet a demuxer receives is freshly initialized, hence it is > unnecessary to reset any flags on them (as none are set), yet apc did > this. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/apc.c | 1 - > 1 file changed, 1 deletion(-) will apply patchset thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides 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".
[FFmpeg-devel] [PATCH] avformat/tls_openssl: don't use libcrypto locking functions with newer OpenSLL versions
They have been removed altogheter without a compat implementatino, and are
either no-ops or return NULL.
This fixes compiler warnings about checks always evaluating to false, and leaks
of allocated mutexes.
Signed-off-by: James Almer
---
libavformat/tls_openssl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index 53f8363a12..e305b2465a 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -48,7 +48,7 @@ typedef struct TLSContext {
#endif
} TLSContext;
-#if HAVE_THREADS
+#if HAVE_THREADS && OPENSSL_VERSION_NUMBER < 0x1010L
#include
pthread_mutex_t *openssl_mutexes;
static void openssl_lock(int mode, int type, const char *file, int line)
@@ -79,7 +79,7 @@ int ff_openssl_init(void)
SSL_library_init();
SSL_load_error_strings();
#endif
-#if HAVE_THREADS
+#if HAVE_THREADS && OPENSSL_VERSION_NUMBER < 0x1010L
if (!CRYPTO_get_locking_callback()) {
int i;
openssl_mutexes = av_malloc_array(sizeof(pthread_mutex_t),
CRYPTO_num_locks());
@@ -108,7 +108,7 @@ void ff_openssl_deinit(void)
ff_lock_avformat();
openssl_init--;
if (!openssl_init) {
-#if HAVE_THREADS
+#if HAVE_THREADS && OPENSSL_VERSION_NUMBER < 0x1010L
if (CRYPTO_get_locking_callback() == openssl_lock) {
int i;
CRYPTO_set_locking_callback(NULL);
--
2.24.0
___
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".
Re: [FFmpeg-devel] [PATCH] avformat/tls_openssl: don't use libcrypto locking functions with newer OpenSLL versions
A few typos: (in commit title) OpenSLL --> OpenSSL On 11-12-2019 09:45 pm, James Almer wrote: They have been removed altogheter without a compat implementatino, and are altogheter --> altogether implementatino --> implementation Gyan ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/tls_openssl: don't use libcrypto locking functions with newer OpenSLL versions
On 12/11/2019 1:37 PM, Gyan wrote: > A few typos: > > (in commit title) > OpenSLL --> OpenSSL > > On 11-12-2019 09:45 pm, James Almer wrote: >> They have been removed altogheter without a compat implementatino, and >> are > altogheter --> altogether > > implementatino --> implementation Amended locally (Plus a mental note to proofread commit messages before git send-email). ___ 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".
Re: [FFmpeg-devel] [PATCH v6 1/2] lavf/isom: support for demuxing and remuxing of MPEG-H 3D Audio in MP4
On 12/11/2019 7:15 AM, Tsuchiya, Yuki (SHES) wrote: > Hello James, > > On 2019/12/10 22:30, "James Almer" wrote: > > >> diff --git a/libavformat/utils.c b/libavformat/utils.c > >> index 8196442dd1..70f9e23d8c 100644 > >> --- a/libavformat/utils.c > >> +++ b/libavformat/utils.c > >> @@ -1021,7 +1021,8 @@ static int is_intra_only(enum AVCodecID id) > >> const AVCodecDescriptor *d = avcodec_descriptor_get(id); > >> if (!d) > >> return 0; > >> -if (d->type == AVMEDIA_TYPE_VIDEO && !(d->props & > AV_CODEC_PROP_INTRA_ONLY)) > >> +if ((d->type == AVMEDIA_TYPE_VIDEO && !(d->props & > AV_CODEC_PROP_INTRA_ONLY)) || > >> +id == AV_CODEC_ID_MPEGH_3D_AUDIO) > > >Instead of changing generic code like this to prevent all MPEG-H 3D > >Audio packets from being tagged as key, you should add a custom function > >much like the VC1 and the TrueHD ones called at the end of > >ff_mov_write_packet() to set the MOV_SYNC_SAMPLE flag and increase the > >track->has_keyframes counter where corresponds. > > If the modification in the is_intra_only() is removed, all demuxed frames > will be tagged as key frame. > This means that all single frames got from av_read_frame() will be key frame > so it is difficult to start decoding from actual key frame. > I think this modification or something like other method for keeping key > frame information from stss box is required. > Do you have any idea? I see now, this is during demuxing. I was thinking about muxing. I can reproduce what you mean with TrueHD which has sync frames every 128 or so frames. Despite the mp4 and matroska files having the sync frames correctly marked, lavf tags every frame as key. A general approach at fixing this issue would be to change is_intra_only() to not just look at video codecs but also audio codecs, and updating all the audio entries in libavcodec/codec_desc.c that are not currently set as AV_CODEC_PROP_INTRA_ONLY and require it. ___ 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".
Re: [FFmpeg-devel] [PATCH v2] avcodec/cbs_av1: rename enable_intraintra_compound flag
On 12/10/2019 10:54 PM, Fei Wang wrote:
> rename enable_intraintra_compound to enable_interintra_compound,
> which keep same as AV1 sepc(v1.0.0-errata1).
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/cbs_av1.h | 2 +-
> libavcodec/cbs_av1_syntax_template.c | 4 ++--
> libavformat/av1.c| 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
> index 9eaf5c4de6..50a05d2168 100644
> --- a/libavcodec/cbs_av1.h
> +++ b/libavcodec/cbs_av1.h
> @@ -105,7 +105,7 @@ typedef struct AV1RawSequenceHeader {
> uint8_t use_128x128_superblock;
> uint8_t enable_filter_intra;
> uint8_t enable_intra_edge_filter;
> -uint8_t enable_intraintra_compound;
> +uint8_t enable_interintra_compound;
> uint8_t enable_masked_compound;
> uint8_t enable_warped_motion;
> uint8_t enable_dual_filter;
> diff --git a/libavcodec/cbs_av1_syntax_template.c
> b/libavcodec/cbs_av1_syntax_template.c
> index 6c4816f964..f53955c52e 100644
> --- a/libavcodec/cbs_av1_syntax_template.c
> +++ b/libavcodec/cbs_av1_syntax_template.c
> @@ -268,7 +268,7 @@ static int
> FUNC(sequence_header_obu)(CodedBitstreamContext *ctx, RWContext *rw,
> flag(enable_intra_edge_filter);
>
> if (current->reduced_still_picture_header) {
> -infer(enable_intraintra_compound, 0);
> +infer(enable_interintra_compound, 0);
> infer(enable_masked_compound, 0);
> infer(enable_warped_motion, 0);
> infer(enable_dual_filter, 0);
> @@ -281,7 +281,7 @@ static int
> FUNC(sequence_header_obu)(CodedBitstreamContext *ctx, RWContext *rw,
> infer(seq_force_integer_mv,
>AV1_SELECT_INTEGER_MV);
> } else {
> -flag(enable_intraintra_compound);
> +flag(enable_interintra_compound);
> flag(enable_masked_compound);
> flag(enable_warped_motion);
> flag(enable_dual_filter);
> diff --git a/libavformat/av1.c b/libavformat/av1.c
> index 132f4e987b..5ad9222900 100644
> --- a/libavformat/av1.c
> +++ b/libavformat/av1.c
> @@ -257,7 +257,7 @@ static int parse_sequence_header(AV1SequenceParameters
> *seq_params, const uint8_
> if (!reduced_still_picture_header) {
> int enable_order_hint, seq_force_screen_content_tools;
>
> -skip_bits(&gb, 4); // enable_intraintra_compound (1),
> enable_masked_compound (1)
> +skip_bits(&gb, 4); // enable_interintra_compound (1),
> enable_masked_compound (1)
> // enable_warped_motion (1), enable_dual_filter
> (1)
>
> enable_order_hint = get_bits1(&gb);
Applied, thanks.
___
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".
[FFmpeg-devel] [PATCH 3/3] tools/target_dec_fuzzer: Adjust threshold for RASC
Fixes: Timeout(35sec -> 4sec)
Fixes:
19289/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RASC_fuzzer-5676526398078976
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index cf66e2c449..4ac3153410 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -144,6 +144,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_FFWAVESYNTH: maxsamples /= 16384; break;
case AV_CODEC_ID_MSRLE: maxpixels /= 16; break;
case AV_CODEC_ID_QTRLE: maxpixels /= 16; break;
+case AV_CODEC_ID_RASC: maxpixels /= 16; break;
case AV_CODEC_ID_SANM: maxpixels /= 16; break;
case AV_CODEC_ID_G2M: maxpixels /= 64; break;
case AV_CODEC_ID_GIF: maxpixels /= 16; break;
--
2.24.0
___
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".
[FFmpeg-devel] [PATCH 2/3] avcodec/cbs_h2645: Do not shorten reserved and unspecified NAL units in H264
Its unclear if shortening these NAL units would have no effect on them
Fixes: assertion failure
Fixes:
19286/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5707990724509696
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_h2645.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 5f71d80584..b38b1d99ef 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -564,11 +564,16 @@ static int
cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
const H2645NAL *nal = &packet->nals[i];
AVBufferRef *ref;
size_t size = nal->size;
+int shorten = 1;
+
+// Do not shorten reserved and unspecified NALs
+if (ctx->codec->codec_id == AV_CODEC_ID_H264) {
+shorten = nal->type > 0 && nal->type < 23;
+}
// Remove trailing zeroes.
-while (size > 0 && nal->data[size - 1] == 0)
+while (shorten && size > 0 && nal->data[size - 1] == 0)
--size;
-av_assert0(size > 0);
ref = (nal->data == nal->raw_data) ? frag->data_ref
: packet->rbsp.rbsp_buffer_ref;
--
2.24.0
___
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".
[FFmpeg-devel] [PATCH 1/3] avcodec/cbs_av1_syntax_template: Check num_y_points
"It is a requirement of bitstream conformance that num_y_points is less than or
equal to 14."
Fixes: index 24 out of bounds for type 'uint8_t [24]'
Fixes:
19282/clusterfuzz-testcase-minimized-ffmpeg_BSF_AV1_FRAME_MERGE_fuzzer-5747424845103104
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_av1_syntax_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs_av1_syntax_template.c
b/libavcodec/cbs_av1_syntax_template.c
index 6c4816f964..5da54b695d 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1155,7 +1155,7 @@ static int FUNC(film_grain_params)(CodedBitstreamContext
*ctx, RWContext *rw,
return 0;
}
-fb(4, num_y_points);
+fc(4, num_y_points, 0, 14);
for (i = 0; i < current->num_y_points; i++) {
fbs(8, point_y_value[i], 1, i);
fbs(8, point_y_scaling[i], 1, i);
--
2.24.0
___
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".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/cbs_h2645: Do not shorten reserved and unspecified NAL units in H264
On 12/11/2019 6:03 PM, Michael Niedermayer wrote:
> Its unclear if shortening these NAL units would have no effect on them
>
> Fixes: assertion failure
> Fixes:
> 19286/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5707990724509696
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/cbs_h2645.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 5f71d80584..b38b1d99ef 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -564,11 +564,16 @@ static int
> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
> const H2645NAL *nal = &packet->nals[i];
> AVBufferRef *ref;
> size_t size = nal->size;
> +int shorten = 1;
> +
> +// Do not shorten reserved and unspecified NALs
> +if (ctx->codec->codec_id == AV_CODEC_ID_H264) {
> +shorten = nal->type > 0 && nal->type < 23;
> +}
>
> // Remove trailing zeroes.
> -while (size > 0 && nal->data[size - 1] == 0)
> +while (shorten && size > 0 && nal->data[size - 1] == 0)
> --size;
> -av_assert0(size > 0);
So this is a NAL unit with a bunch of zero bytes? How did it go through
the filter in h2645_parse? It's supposed to skip any NAL like this.
>
> ref = (nal->data == nal->raw_data) ? frag->data_ref
> : packet->rbsp.rbsp_buffer_ref;
>
___
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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cbs_av1_syntax_template: Check num_y_points
On 12/11/2019 6:03 PM, Michael Niedermayer wrote:
> "It is a requirement of bitstream conformance that num_y_points is less than
> or equal to 14."
>
> Fixes: index 24 out of bounds for type 'uint8_t [24]'
> Fixes:
> 19282/clusterfuzz-testcase-minimized-ffmpeg_BSF_AV1_FRAME_MERGE_fuzzer-5747424845103104
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/cbs_av1_syntax_template.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/cbs_av1_syntax_template.c
> b/libavcodec/cbs_av1_syntax_template.c
> index 6c4816f964..5da54b695d 100644
> --- a/libavcodec/cbs_av1_syntax_template.c
> +++ b/libavcodec/cbs_av1_syntax_template.c
> @@ -1155,7 +1155,7 @@ static int
> FUNC(film_grain_params)(CodedBitstreamContext *ctx, RWContext *rw,
> return 0;
> }
>
> -fb(4, num_y_points);
> +fc(4, num_y_points, 0, 14);
> for (i = 0; i < current->num_y_points; i++) {
> fbs(8, point_y_value[i], 1, i);
> fbs(8, point_y_scaling[i], 1, i);
LGTM.
You could also while at it reduce point_y_value and point_y_scaling from
uint8_t[16] to uint8_t[14].
___
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".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/cbs_h2645: Do not shorten reserved and unspecified NAL units in H264
On Wed, Dec 11, 2019 at 10:38 PM James Almer wrote:
> On 12/11/2019 6:03 PM, Michael Niedermayer wrote:
> > Its unclear if shortening these NAL units would have no effect on them
> >
> > Fixes: assertion failure
> > Fixes:
> 19286/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5707990724509696
> >
> > Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/cbs_h2645.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> > index 5f71d80584..b38b1d99ef 100644
> > --- a/libavcodec/cbs_h2645.c
> > +++ b/libavcodec/cbs_h2645.c
> > @@ -564,11 +564,16 @@ static int
> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
> > const H2645NAL *nal = &packet->nals[i];
> > AVBufferRef *ref;
> > size_t size = nal->size;
> > +int shorten = 1;
> > +
> > +// Do not shorten reserved and unspecified NALs
> > +if (ctx->codec->codec_id == AV_CODEC_ID_H264) {
> > +shorten = nal->type > 0 && nal->type < 23;
> > +}
> >
> > // Remove trailing zeroes.
> > -while (size > 0 && nal->data[size - 1] == 0)
> > +while (shorten && size > 0 && nal->data[size - 1] == 0)
> > --size;
> > -av_assert0(size > 0);
>
> So this is a NAL unit with a bunch of zero bytes? How did it go through
> the filter in h2645_parse? It's supposed to skip any NAL like this.
>
> I guess it triggered this workaround:
/* see commit 3566042a0 */
if (bytestream2_get_bytes_left(&bc) >= 4 &&
bytestream2_peek_be32(&bc) == 0x01E0)
skip_trailing_zeros = 0;
If I am not mistaken, then all NAL units except one consisting solely of a
single 0x00 (where the RBSP is empty) have to have a rbsp_stop_one_bit. So
the only instance where stripping zeroes is not good is for such a 0x00
unit. And such a unit should be stripped, because it actually can't be
represented in annex b (which we output) at all.
- Andreas
___
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".
[FFmpeg-devel] [PATCH] avcodec/cbs_av1: fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128
Taking into account the code
fb(2, ar_coeff_lag);
num_pos_luma = 2 * current->ar_coeff_lag * (current->ar_coeff_lag + 1);
if (current->num_y_points)
num_pos_chroma = num_pos_luma + 1;
else
num_pos_chroma = num_pos_luma;
Max value for ar_coeff_lag is 3 (two bits), for num_pos_luma 24, and for
num_pos_chroma 25.
Both ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128 may have up to
num_pos_chroma values.
Signed-off-by: James Almer
---
libavcodec/cbs_av1.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index 50a05d2168..643e76793f 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -268,8 +268,8 @@ typedef struct AV1RawFrameHeader {
uint8_t grain_scaling_minus_8;
uint8_t ar_coeff_lag;
uint8_t ar_coeffs_y_plus_128[24];
-uint8_t ar_coeffs_cb_plus_128[24];
-uint8_t ar_coeffs_cr_plus_128[24];
+uint8_t ar_coeffs_cb_plus_128[25];
+uint8_t ar_coeffs_cr_plus_128[25];
uint8_t ar_coeff_shift_minus_6;
uint8_t grain_scale_shift;
uint8_t cb_mult;
--
2.24.0
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_av1: fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128
Hi,
On Wed, Dec 11, 2019 at 5:00 PM James Almer wrote:
> Taking into account the code
>
> fb(2, ar_coeff_lag);
> num_pos_luma = 2 * current->ar_coeff_lag * (current->ar_coeff_lag + 1);
> if (current->num_y_points)
> num_pos_chroma = num_pos_luma + 1;
> else
> num_pos_chroma = num_pos_luma;
>
> Max value for ar_coeff_lag is 3 (two bits), for num_pos_luma 24, and for
> num_pos_chroma 25.
>
> Both ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128 may have up to
> num_pos_chroma values.
>
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_av1.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
> index 50a05d2168..643e76793f 100644
> --- a/libavcodec/cbs_av1.h
> +++ b/libavcodec/cbs_av1.h
> @@ -268,8 +268,8 @@ typedef struct AV1RawFrameHeader {
> uint8_t grain_scaling_minus_8;
> uint8_t ar_coeff_lag;
> uint8_t ar_coeffs_y_plus_128[24];
> -uint8_t ar_coeffs_cb_plus_128[24];
> -uint8_t ar_coeffs_cr_plus_128[24];
> +uint8_t ar_coeffs_cb_plus_128[25];
> +uint8_t ar_coeffs_cr_plus_128[25];
> uint8_t ar_coeff_shift_minus_6;
> uint8_t grain_scale_shift;
> uint8_t cb_mult;
lgtm.
Ronald
___
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".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/cbs_h2645: Do not shorten reserved and unspecified NAL units in H264
On Wed, Dec 11, 2019 at 10:50:54PM +0100, Andreas Rheinhardt wrote:
> On Wed, Dec 11, 2019 at 10:38 PM James Almer wrote:
>
> > On 12/11/2019 6:03 PM, Michael Niedermayer wrote:
> > > Its unclear if shortening these NAL units would have no effect on them
> > >
> > > Fixes: assertion failure
> > > Fixes:
> > 19286/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5707990724509696
> > >
> > > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavcodec/cbs_h2645.c | 9 +++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> > > index 5f71d80584..b38b1d99ef 100644
> > > --- a/libavcodec/cbs_h2645.c
> > > +++ b/libavcodec/cbs_h2645.c
> > > @@ -564,11 +564,16 @@ static int
> > cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
> > > const H2645NAL *nal = &packet->nals[i];
> > > AVBufferRef *ref;
> > > size_t size = nal->size;
> > > +int shorten = 1;
> > > +
> > > +// Do not shorten reserved and unspecified NALs
> > > +if (ctx->codec->codec_id == AV_CODEC_ID_H264) {
> > > +shorten = nal->type > 0 && nal->type < 23;
> > > +}
> > >
> > > // Remove trailing zeroes.
> > > -while (size > 0 && nal->data[size - 1] == 0)
> > > +while (shorten && size > 0 && nal->data[size - 1] == 0)
> > > --size;
> > > -av_assert0(size > 0);
> >
> > So this is a NAL unit with a bunch of zero bytes? How did it go through
yes
> > the filter in h2645_parse? It's supposed to skip any NAL like this.
> >
> > I guess it triggered this workaround:
> /* see commit 3566042a0 */
> if (bytestream2_get_bytes_left(&bc) >= 4 &&
> bytestream2_peek_be32(&bc) == 0x01E0)
> skip_trailing_zeros = 0;
yes
>
> If I am not mistaken, then all NAL units except one consisting solely of a
> single 0x00 (where the RBSP is empty) have to have a rbsp_stop_one_bit. So
> the only instance where stripping zeroes is not good is for such a 0x00
> unit. And such a unit should be stripped, because it actually can't be
> represented in annex b (which we output) at all.
I dont see why it could not be represented.
Also the code you quoted above shows that there are NAL units where the
removal of zeros would damage the units.
I wonder if we should assume that NALs not described in the current H26* specs
follow exactly the RBSP syntax and can saftely be truncated.
My patch went in the direction of rather leaving that alone.
But of course we can do something else or i can try to implement that more
completely also preserving that on the input side but having no real world
testcase that would not be tested.
What do you prefer? you seem to have a strong oppinion here
Thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
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".
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_av1: fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128
On Wed, Dec 11, 2019 at 07:00:06PM -0300, James Almer wrote: > Taking into account the code > > fb(2, ar_coeff_lag); > num_pos_luma = 2 * current->ar_coeff_lag * (current->ar_coeff_lag + 1); > if (current->num_y_points) > num_pos_chroma = num_pos_luma + 1; > else > num_pos_chroma = num_pos_luma; > > Max value for ar_coeff_lag is 3 (two bits), for num_pos_luma 24, and for > num_pos_chroma 25. > > Both ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128 may have up to > num_pos_chroma values. > > Signed-off-by: James Almer > --- > libavcodec/cbs_av1.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) LGTM and i should have realized this when i looked at the fuzzer case thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras 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".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/cbs_h2645: Do not shorten reserved and unspecified NAL units in H264
On Wed, Dec 11, 2019 at 10:50 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> On Wed, Dec 11, 2019 at 10:38 PM James Almer wrote:
>
>> On 12/11/2019 6:03 PM, Michael Niedermayer wrote:
>> > Its unclear if shortening these NAL units would have no effect on them
>> >
>> > Fixes: assertion failure
>> > Fixes:
>> 19286/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5707990724509696
>> >
>> > Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> > Signed-off-by: Michael Niedermayer
>> > ---
>> > libavcodec/cbs_h2645.c | 9 +++--
>> > 1 file changed, 7 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>> > index 5f71d80584..b38b1d99ef 100644
>> > --- a/libavcodec/cbs_h2645.c
>> > +++ b/libavcodec/cbs_h2645.c
>> > @@ -564,11 +564,16 @@ static int
>> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>> > const H2645NAL *nal = &packet->nals[i];
>> > AVBufferRef *ref;
>> > size_t size = nal->size;
>> > +int shorten = 1;
>> > +
>> > +// Do not shorten reserved and unspecified NALs
>> > +if (ctx->codec->codec_id == AV_CODEC_ID_H264) {
>> > +shorten = nal->type > 0 && nal->type < 23;
>> > +}
>> >
>> > // Remove trailing zeroes.
>> > -while (size > 0 && nal->data[size - 1] == 0)
>> > +while (shorten && size > 0 && nal->data[size - 1] == 0)
>> > --size;
>> > -av_assert0(size > 0);
>>
>> So this is a NAL unit with a bunch of zero bytes? How did it go through
>> the filter in h2645_parse? It's supposed to skip any NAL like this.
>>
>> I guess it triggered this workaround:
> /* see commit 3566042a0 */
> if (bytestream2_get_bytes_left(&bc) >= 4 &&
> bytestream2_peek_be32(&bc) == 0x01E0)
> skip_trailing_zeros = 0;
>
> If I am not mistaken, then all NAL units except one consisting solely of a
> single 0x00 (where the RBSP is empty) have to have a rbsp_stop_one_bit. So
> the only instance where stripping zeroes is not good is for such a 0x00
> unit. And such a unit should be stripped, because it actually can't be
> represented in annex b (which we output) at all.
>
> I think I am wrong about the very last part. From the H.264 spec (the HEVC
is the same):
"NumBytesInNALunit is set equal to the number of bytes starting with the
byte at the current position in the byte
stream up to and including the last byte that precedes the location of any
of the following:
– A subsequent byte-aligned three-byte sequence equal to 0x00,
– A subsequent byte-aligned three-byte sequence equal to 0x01,
– The end of the byte stream, as determined by unspecified means."
My earlier interpretation was that the three bytes following the first
startcode in this sequence 00 00 01 00 00 00 01 xx would mean that
NumBytesinNALunit were zero, because the last byte in the above sentence is
the 0x01 from the first startcode. But upon rereading I think that this is
ruled out by "subsequent", so that the NAL unit would be ended upon
encountering the second startcode (in this case, three bytes long).
But it still shows that if someone used one of the unspecified NAL units
and if these NAL units were allowed to end with zero bytes that are part of
the NAL unit, then said unit can't be represented in annex b (which
cbs_h2645 outputs) anyway. Furthermore, cbs_h2645 currently presumes that
all NAL units are escaped and consequently unescapes them upon reading and
escapes them upon writing. If unspecified NAL units were to deviate from
this, they would not survive this process unharmed (0x03 escapes might be
added). In particular, this applies to the aggregators from ISO/IEC
14496-15:
"The syntax of Aggregators may not follow the NAL unit syntax and the NAL
unit constraints specified in ISO/IEC
14496-10 or ISO/IEC 23008-2. For example, there may exist three continuous
bytes equal to a value in the range of
0x00 to 0x10, inclusive. This specifiation disallows the presence
of Aggregators in a video bitstream output
from parsing a file, therefore formal non-compliance with the video
specifications is immaterial as they will never be
presented to a video decoder."
Such units can't be represented in annex b at all, given the potential for
start code emulation. So I think the best we can do is what we already do:
Unescape every unit and escape them later. If any of the unspecified NAL
units uses the typical escaping scheme, it is fine; if not, we can't do
anything anyway.
Furthermore, our code for splitting a packet searches for 0x00 00 01 inside
an mp4/mkv NAL unit and views these as start of a new NAL unit (because
there are invalid files out there doing it that way). This of course has a
potential for start code emulation and so input that may contain start
codes within the NAL units would already be broken at this stage. I don't
think that there is
Re: [FFmpeg-devel] [PATCH 4/4] fate/filter-video: add two tests for dnn_processing with format rgb24 and grayf32
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Guo, Yejun > Sent: Thursday, November 28, 2019 4:44 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 4/4] fate/filter-video: add two tests for > dnn_processing with format rgb24 and grayf32 > > These two tests need model files under fate-suite/dnn_processing, I've > > attached them > > in the email, could someone help to upload them, thanks. > > > > to see how these two models are generated, please see > > https://github.com/guoyejun/dnn_processing, thanks. > > this patch set asks for review, thanks. this patch set asks for review, thanks. ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_av1: fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128
On Thu, Dec 12, 2019 at 12:15:14AM +0100, Michael Niedermayer wrote: > On Wed, Dec 11, 2019 at 07:00:06PM -0300, James Almer wrote: > > Taking into account the code > > > > fb(2, ar_coeff_lag); > > num_pos_luma = 2 * current->ar_coeff_lag * (current->ar_coeff_lag + 1); > > if (current->num_y_points) > > num_pos_chroma = num_pos_luma + 1; > > else > > num_pos_chroma = num_pos_luma; > > > > Max value for ar_coeff_lag is 3 (two bits), for num_pos_luma 24, and for > > num_pos_chroma 25. > > > > Both ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128 may have up to > > num_pos_chroma values. > > > > Signed-off-by: James Almer > > --- > > libavcodec/cbs_av1.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > LGTM and i should have realized this when i looked at the fuzzer case This needs a update to fate though --- ./tests/ref/fate/cbs-av1-av1-1-b8-23-film_grain-50 2019-12-11 15:53:24.616370434 +0100 +++ tests/data/fate/cbs-av1-av1-1-b8-23-film_grain-50 2019-12-12 01:25:39.813093782 +0100 @@ -1 +1 @@ -93e578da4b2bdb70ce0a92262da930ec +2556d6d30469c647c6262130d8eb0531 --- ./tests/ref/fate/cbs-av1-av1-1-b10-23-film_grain-50 2019-12-11 15:53:24.616370434 +0100 +++ tests/data/fate/cbs-av1-av1-1-b10-23-film_grain-50 2019-12-12 01:25:39.825093782 +0100 @@ -1 +1 @@ -5fe6622ac6cb22dd10dfbe9e70e82d4e +aaddbf87bdf9b5ac4b1ab4fe802c410b TESTwmav1-encode Test cbs-av1-av1-1-b8-23-film_grain-50 failed. Look at tests/data/fate/cbs-av1-av1-1-b8-23-film_grain-50.err for details. make: *** [fate-cbs-av1-av1-1-b8-23-film_grain-50] Error 1 Test cbs-av1-av1-1-b10-23-film_grain-50 failed. Look at tests/data/fate/cbs-av1-av1-1-b10-23-film_grain-50.err for details. make: *** [fate-cbs-av1-av1-1-b10-23-film_grain-50] Error 1 Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. 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".
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_av1: fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128
On 12/11/2019 9:33 PM, Michael Niedermayer wrote: > On Thu, Dec 12, 2019 at 12:15:14AM +0100, Michael Niedermayer wrote: >> On Wed, Dec 11, 2019 at 07:00:06PM -0300, James Almer wrote: >>> Taking into account the code >>> >>> fb(2, ar_coeff_lag); >>> num_pos_luma = 2 * current->ar_coeff_lag * (current->ar_coeff_lag + 1); >>> if (current->num_y_points) >>> num_pos_chroma = num_pos_luma + 1; >>> else >>> num_pos_chroma = num_pos_luma; >>> >>> Max value for ar_coeff_lag is 3 (two bits), for num_pos_luma 24, and for >>> num_pos_chroma 25. >>> >>> Both ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128 may have up to >>> num_pos_chroma values. >>> >>> Signed-off-by: James Almer >>> --- >>> libavcodec/cbs_av1.h | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> LGTM and i should have realized this when i looked at the fuzzer case > > This needs a update to fate though > > --- ./tests/ref/fate/cbs-av1-av1-1-b8-23-film_grain-502019-12-11 > 15:53:24.616370434 +0100 > +++ tests/data/fate/cbs-av1-av1-1-b8-23-film_grain-50 2019-12-12 > 01:25:39.813093782 +0100 > @@ -1 +1 @@ > -93e578da4b2bdb70ce0a92262da930ec > +2556d6d30469c647c6262130d8eb0531 > --- ./tests/ref/fate/cbs-av1-av1-1-b10-23-film_grain-50 2019-12-11 > 15:53:24.616370434 +0100 > +++ tests/data/fate/cbs-av1-av1-1-b10-23-film_grain-502019-12-12 > 01:25:39.825093782 +0100 > @@ -1 +1 @@ > -5fe6622ac6cb22dd10dfbe9e70e82d4e > +aaddbf87bdf9b5ac4b1ab4fe802c410b > TESTwmav1-encode > Test cbs-av1-av1-1-b8-23-film_grain-50 failed. Look at > tests/data/fate/cbs-av1-av1-1-b8-23-film_grain-50.err for details. > make: *** [fate-cbs-av1-av1-1-b8-23-film_grain-50] Error 1 > Test cbs-av1-av1-1-b10-23-film_grain-50 failed. Look at > tests/data/fate/cbs-av1-av1-1-b10-23-film_grain-50.err for details. > make: *** [fate-cbs-av1-av1-1-b10-23-film_grain-50] Error 1 > > Thanks Great. So these tests are meant to ensure that the output is the same with or without calling the corresponding metadata bsf, as it runs it in passthrough mode. After this patch, it changed the output of both cases, so it means the bsf is being used even if not explicitly called, and i'm fairly sure it's the ivf muxer's fault. I'll update it now, then will see about making another patch to stop using the ivf muxer. ___ 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".
[FFmpeg-devel] [PATCH] fate/cbs: use the rawvideo muxer for AV1 tests
The IVF muxer autoinserts the av1_metadata filter unconditionally, which is not desirable for these tests. Signed-off-by: James Almer --- tests/fate/cbs.mak | 6 +++--- tests/ref/fate/cbs-av1-av1-1-b10-23-film_grain-50 | 2 +- tests/ref/fate/cbs-av1-av1-1-b8-02-allintra| 2 +- tests/ref/fate/cbs-av1-av1-1-b8-03-sizedown| 2 +- tests/ref/fate/cbs-av1-av1-1-b8-03-sizeup | 2 +- tests/ref/fate/cbs-av1-av1-1-b8-04-cdfupdate | 2 +- tests/ref/fate/cbs-av1-av1-1-b8-05-mv | 2 +- tests/ref/fate/cbs-av1-av1-1-b8-06-mfmv| 2 +- tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L1T2| 2 +- tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L2T1| 2 +- tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L2T2| 2 +- tests/ref/fate/cbs-av1-av1-1-b8-23-film_grain-50 | 2 +- tests/ref/fate/cbs-av1-decode_model| 2 +- tests/ref/fate/cbs-av1-frames_refs_short_signaling | 2 +- tests/ref/fate/cbs-av1-non_uniform_tiling | 2 +- tests/ref/fate/cbs-av1-seq_hdr_op_param_info | 2 +- tests/ref/fate/cbs-av1-switch_frame| 2 +- 17 files changed, 19 insertions(+), 19 deletions(-) diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak index 824e6c86ab..ad9c85863b 100644 --- a/tests/fate/cbs.mak +++ b/tests/fate/cbs.mak @@ -34,10 +34,10 @@ FATE_CBS_AV1_SAMPLES = \ seq_hdr_op_param_info.ivf \ switch_frame.ivf -$(foreach N,$(FATE_CBS_AV1_CONFORMANCE_SAMPLES),$(eval $(call FATE_CBS_TEST,av1,$(basename $(N)),av1-test-vectors/$(N),ivf))) -$(foreach N,$(FATE_CBS_AV1_SAMPLES),$(eval $(call FATE_CBS_TEST,av1,$(basename $(N)),av1/$(N),ivf))) +$(foreach N,$(FATE_CBS_AV1_CONFORMANCE_SAMPLES),$(eval $(call FATE_CBS_TEST,av1,$(basename $(N)),av1-test-vectors/$(N),rawvideo))) +$(foreach N,$(FATE_CBS_AV1_SAMPLES),$(eval $(call FATE_CBS_TEST,av1,$(basename $(N)),av1/$(N),rawvideo))) -FATE_CBS_AV1-$(call ALLYES, IVF_DEMUXER AV1_PARSER AV1_METADATA_BSF IVF_MUXER) = $(FATE_CBS_av1) +FATE_CBS_AV1-$(call ALLYES, IVF_DEMUXER AV1_PARSER AV1_METADATA_BSF RAWVIDEO_MUXER) = $(FATE_CBS_av1) FATE_SAMPLES_AVCONV += $(FATE_CBS_AV1-yes) fate-cbs-av1: $(FATE_CBS_AV1-yes) diff --git a/tests/ref/fate/cbs-av1-av1-1-b10-23-film_grain-50 b/tests/ref/fate/cbs-av1-av1-1-b10-23-film_grain-50 index d1a5512daf..500e655803 100644 --- a/tests/ref/fate/cbs-av1-av1-1-b10-23-film_grain-50 +++ b/tests/ref/fate/cbs-av1-av1-1-b10-23-film_grain-50 @@ -1 +1 @@ -aaddbf87bdf9b5ac4b1ab4fe802c410b +0ab934a437181d0275dc6c26bb9f6281 diff --git a/tests/ref/fate/cbs-av1-av1-1-b8-02-allintra b/tests/ref/fate/cbs-av1-av1-1-b8-02-allintra index 9a127ff90c..11abf2f336 100644 --- a/tests/ref/fate/cbs-av1-av1-1-b8-02-allintra +++ b/tests/ref/fate/cbs-av1-av1-1-b8-02-allintra @@ -1 +1 @@ -b905c6f2bf68fddbf58a50f940c5f5a2 +134b447b04086088de4da127a97731f3 diff --git a/tests/ref/fate/cbs-av1-av1-1-b8-03-sizedown b/tests/ref/fate/cbs-av1-av1-1-b8-03-sizedown index 6d771a2331..7188d16dad 100644 --- a/tests/ref/fate/cbs-av1-av1-1-b8-03-sizedown +++ b/tests/ref/fate/cbs-av1-av1-1-b8-03-sizedown @@ -1 +1 @@ -4db2f13b7028a2bb6a5a067badf1b0ad +e5924930773efdbbd82da02c96747f27 diff --git a/tests/ref/fate/cbs-av1-av1-1-b8-03-sizeup b/tests/ref/fate/cbs-av1-av1-1-b8-03-sizeup index 689934c2fb..9d767bbede 100644 --- a/tests/ref/fate/cbs-av1-av1-1-b8-03-sizeup +++ b/tests/ref/fate/cbs-av1-av1-1-b8-03-sizeup @@ -1 +1 @@ -964ea060d898a4358708b3f83ecda4b5 +0348fba6ebf6caadfe80b19a6ad93caa diff --git a/tests/ref/fate/cbs-av1-av1-1-b8-04-cdfupdate b/tests/ref/fate/cbs-av1-av1-1-b8-04-cdfupdate index f0a2481f8a..9325deac36 100644 --- a/tests/ref/fate/cbs-av1-av1-1-b8-04-cdfupdate +++ b/tests/ref/fate/cbs-av1-av1-1-b8-04-cdfupdate @@ -1 +1 @@ -e24ce6a099ce9389f06606b0a7653007 +aec87cd950fb985b1e345d0366709aea diff --git a/tests/ref/fate/cbs-av1-av1-1-b8-05-mv b/tests/ref/fate/cbs-av1-av1-1-b8-05-mv index b3350a283b..aa4ab5138b 100644 --- a/tests/ref/fate/cbs-av1-av1-1-b8-05-mv +++ b/tests/ref/fate/cbs-av1-av1-1-b8-05-mv @@ -1 +1 @@ -b39c0edaf5695367ec07eeffce57303d +33f548eeef87e12b93b9bf4a3b79c70e diff --git a/tests/ref/fate/cbs-av1-av1-1-b8-06-mfmv b/tests/ref/fate/cbs-av1-av1-1-b8-06-mfmv index 929a2a4498..ede34aede0 100644 --- a/tests/ref/fate/cbs-av1-av1-1-b8-06-mfmv +++ b/tests/ref/fate/cbs-av1-av1-1-b8-06-mfmv @@ -1 +1 @@ -95c1fcf60b4fc4530d38f0896c783e28 +2e20870d44ba5ec5a8e1450b287e20b4 diff --git a/tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L1T2 b/tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L1T2 index 1c3cc5cebd..d17f202fdc 100644 --- a/tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L1T2 +++ b/tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L1T2 @@ -1 +1 @@ -16f91c11586a53336ee8b2e57a6503c9 +f7138eaa1e572260a8a34f73f91e058a diff --git a/tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L2T1 b/tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L2T1 index 09368ac3fd..a23f3cbd4e 100644 --- a/tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L2T1 +++ b/tests/ref/fate/cbs-av1-av1-1-b8-22-svc-L2T1
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/cbs_h2645: Do not shorten reserved and unspecified NAL units in H264
On Wed, Dec 11, 2019 at 11:58 PM Michael Niedermayer
wrote:
> On Wed, Dec 11, 2019 at 10:50:54PM +0100, Andreas Rheinhardt wrote:
> > On Wed, Dec 11, 2019 at 10:38 PM James Almer wrote:
> >
> > > On 12/11/2019 6:03 PM, Michael Niedermayer wrote:
> > > > Its unclear if shortening these NAL units would have no effect on
> them
> > > >
> > > > Fixes: assertion failure
> > > > Fixes:
> > >
> 19286/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5707990724509696
> > > >
> > > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavcodec/cbs_h2645.c | 9 +++--
> > > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> > > > index 5f71d80584..b38b1d99ef 100644
> > > > --- a/libavcodec/cbs_h2645.c
> > > > +++ b/libavcodec/cbs_h2645.c
> > > > @@ -564,11 +564,16 @@ static int
> > > cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
> > > > const H2645NAL *nal = &packet->nals[i];
> > > > AVBufferRef *ref;
> > > > size_t size = nal->size;
> > > > +int shorten = 1;
> > > > +
> > > > +// Do not shorten reserved and unspecified NALs
> > > > +if (ctx->codec->codec_id == AV_CODEC_ID_H264) {
> > > > +shorten = nal->type > 0 && nal->type < 23;
> > > > +}
> > > >
> > > > // Remove trailing zeroes.
> > > > -while (size > 0 && nal->data[size - 1] == 0)
> > > > +while (shorten && size > 0 && nal->data[size - 1] == 0)
> > > > --size;
> > > > -av_assert0(size > 0);
> > >
> > > So this is a NAL unit with a bunch of zero bytes? How did it go through
>
> yes
>
>
> > > the filter in h2645_parse? It's supposed to skip any NAL like this.
> > >
> > > I guess it triggered this workaround:
> > /* see commit 3566042a0 */
> > if (bytestream2_get_bytes_left(&bc) >= 4 &&
> > bytestream2_peek_be32(&bc) == 0x01E0)
> > skip_trailing_zeros = 0;
>
> yes
>
>
> >
> > If I am not mistaken, then all NAL units except one consisting solely of
> a
> > single 0x00 (where the RBSP is empty) have to have a rbsp_stop_one_bit.
> So
> > the only instance where stripping zeroes is not good is for such a 0x00
> > unit. And such a unit should be stripped, because it actually can't be
> > represented in annex b (which we output) at all.
>
> I dont see why it could not be represented.
>
I think I was wrong.
> Also the code you quoted above shows that there are NAL units where the
> removal of zeros would damage the units.
>
> Yes. But not removing zeroes could also alter the units, because these
zeroes might lead to the addition of 0x03 escape bytes when reassembling.
Btw: Where is the sample that triggered this?
> I wonder if we should assume that NALs not described in the current H26*
> specs
> follow exactly the RBSP syntax and can saftely be truncated.
>
As has been said in my other mail: Anything that may contain start codes
inside their NAL units can't be put into annex b anyway. Unfortunately
systems using such units exist.
> My patch went in the direction of rather leaving that alone.
>
Even with your patch they would not be left completely alone: The
unescaping->escaping process changes things for units initially unescaped;
not to mention the possibility of start code emulation within NAL units for
units that may contain start codes.
(The utmost that could be done to leave these units alone would be to use
the raw data of the unit instead of the unescaped unit in case it is one of
the unspecified units. And upon reassembling, no escaping would have to be
performed for these units, just a straight memcpy. But this would still not
solve the problem that h2645_packet_split searches the units for start
codes and treats them as start of new units. And even if this were solved,
one would have the problem that units that contain start codes can't be put
in annex b anyway. It's just a mess.)
> But of course we can do something else or i can try to implement that more
> completely also preserving that on the input side but having no real world
> testcase that would not be tested.
>
> What do you prefer? you seem to have a strong oppinion here
>
> The current code works with systems that follow the typical RBSP scheme;
supporting anything else would require significant changes to not only
cbs_h2645, but also the H.2645 parsing functions (or cbs_h2645 would have
to abandon them and implement their own). I don't think we have the
manpower, the samples and the motivation for this. So if it works, fine; if
not, then not. (We don't even support the SVC/MVC/3d extensions yet and
these are official.)
While this RBSP scheme would allow a NAL unit with empty RBSP that consists
of a single 0x00, I don't think that this will intentionally happen in
practice. And now that I have found
[FFmpeg-devel] [PATCH V4] avfilter: Add tonemap vaapi filter for H2S
From: Xinpeng Sun
It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range) conversion
with tone-mapping. It only supports HDR10 as input temporarily.
An example command to use this filter with vaapi codecs:
FFMPEG -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format
vaapi \
-i INPUT -vf 'tonemap_vaapi=format=p010' -c:v hevc_vaapi -profile 2 OUTPUT
Signed-off-by: Xinpeng Sun
Signed-off-by: Zachary Zhou
Signed-off-by: Ruiling Song
---
When I re-think about the document part. I find it is not necessary to repeat
how to set up vaapi device in this filter part. There is already good
explanation
of it(https://trac.ffmpeg.org/wiki/Hardware/VAAPI), so I add a link to it.
I only make code changes requested by Vittoria and me. So if no further comment,
I am going to apply the patch next week. Thanks!
Ruiling
configure | 2 +
doc/filters.texi | 59 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_tonemap_vaapi.c | 419 +
5 files changed, 482 insertions(+)
create mode 100644 libavfilter/vf_tonemap_vaapi.c
diff --git a/configure b/configure
index 42e7df3941..74f2d38317 100755
--- a/configure
+++ b/configure
@@ -3576,6 +3576,7 @@ tinterlace_filter_deps="gpl"
tinterlace_merge_test_deps="tinterlace_filter"
tinterlace_pad_test_deps="tinterlace_filter"
tonemap_filter_deps="const_nan"
+tonemap_vaapi_filter_deps="vaapi
VAProcPipelineParameterBuffer_output_hdr_metadata"
tonemap_opencl_filter_deps="opencl const_nan"
transpose_opencl_filter_deps="opencl"
transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
@@ -6577,6 +6578,7 @@ if enabled vaapi; then
check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
+check_struct "va/va.h va/va_vpp.h" "VAProcPipelineParameterBuffer"
output_hdr_metadata
check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
diff --git a/doc/filters.texi b/doc/filters.texi
index 99da266cec..1d934b84f3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21034,6 +21034,65 @@ Apply a strong blur of both luma and chroma parameters:
@c man end OPENCL VIDEO FILTERS
+@chapter VAAPI Video Filters
+@c man begin VAAPI VIDEO FILTERS
+
+VAAPI Video filters are usually used with VAAPI decoder and VAAPI encoder.
Below is a description of VAAPI video filters.
+
+To enable compilation of these filters you need to configure FFmpeg with
+@code{--enable-vaapi}.
+
+To use vaapi filters, you need to setup the vaapi device correctly. For more
information, please read @url{https://trac.ffmpeg.org/wiki/Hardware/VAAPI}
+
+@section tonemap_vappi
+
+Perform HDR(High Dynamic Range) to SDR(Standard Dynamic Range) conversion with
tone-mapping.
+It maps the dynamic range of HDR10 content to the SDR content.
+It currently only accepts HDR10 as input.
+
+It accepts the following parameters:
+
+@table @option
+@item format
+Specify the output pixel format.
+
+Currently supported formats are:
+@table @var
+@item p010
+@item nv12
+@end table
+
+Default is nv12.
+
+@item primaries, p
+Set the output color primaries.
+
+Default is same as input.
+
+@item transfer, t
+Set the output transfer characteristics.
+
+Default is bt709.
+
+@item matrix, m
+Set the output colorspace matrix.
+
+Default is same as input.
+
+@end table
+
+@subsection Example
+
+@itemize
+@item
+Convert HDR(HDR10) video to bt2020-transfer-characteristic p010 format
+@example
+tonemap_vaapi=format=p010:t=bt2020-10
+@end example
+@end itemize
+
+@c man end VAAPI VIDEO FILTERS
+
@chapter Video Sources
@c man begin VIDEO SOURCES
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 446c802b98..37d4eee858 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -411,6 +411,7 @@ OBJS-$(CONFIG_TMIX_FILTER) += vf_mix.o
framesync.o
OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o colorspace.o
OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) += vf_tonemap_opencl.o
colorspace.o opencl.o \
opencl/tonemap.o
opencl/colorspace_common.o
+OBJS-$(CONFIG_TONEMAP_VAAPI_FILTER) += vf_tonemap_vaapi.o vaapi_vpp.o
OBJS-$(CONFIG_TPAD_FILTER) += vf_tpad.o
OBJS-$(CONFIG_TRANSPOSE_FILTER) += vf_transpose.o
OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER) += vf_transpose_npp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 69953832da..c295f8e403 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -391,6 +391,7 @@ extern AVFilter ff_vf_tlut2;
extern AVFilter ff_vf_tmix;
extern AVFilter ff_vf_tonemap;
extern AVFilter ff_vf_tonemap_opencl;
+extern AVFilter ff_v
Re: [FFmpeg-devel] [PATCH v6 1/2] lavf/isom: support for demuxing and remuxing of MPEG-H 3D Audio in MP4
Hi James, > I see now, this is during demuxing. I was thinking about muxing. > I can reproduce what you mean with TrueHD which has sync frames every > 128 or so frames. Despite the mp4 and matroska files having the sync > frames correctly marked, lavf tags every frame as key. > > A general approach at fixing this issue would be to change > is_intra_only() to not just look at video codecs but also audio codecs, > and updating all the audio entries in libavcodec/codec_desc.c that are > not currently set as AV_CODEC_PROP_INTRA_ONLY and require it. Thank you for your suggestion. I will send new patch soon, so please review again. ___ 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".
Re: [FFmpeg-devel] 回复: [PATCH 1/1] add without_captureblt option for libavdevice/gdigrab.c, when useing the bitblt function with CAPTUREBLT it caused the mouse cursor flicker. most time we dont need t
On 2019/12/11 下午10:19, Andriy Gelman wrote:
On Wed, 11. Dec 09:01, _ FgoDt wrote:
did someone review the patch?
发件人: _ FgoDt
发送时间: 2019年11月15日 15:03
收件人: ffmpeg-devel@ffmpeg.org
抄送: _ FgoDt
主题: [PATCH 1/1] add without_captureblt option for libavdevice/gdigrab.c, when
useing the bitblt function with CAPTUREBLT it caused the mouse cursor flicker.
most time we dont need this flag to capture window
From: fgodt
This would be in commit, you should use your name.
Signed-off-by: fgodt
---
libavdevice/gdigrab.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index f406fa..0ab0cfed01 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -53,6 +53,8 @@ struct gdigrab {
intoffset_x;/**< Capture x offset (private option) */
intoffset_y;/**< Capture y offset (private option) */
+intwithout_captureblt; /**< capture without captureblt */
+
HWND hwnd;/**< Handle of the window for the grab */
HDCsource_hdc; /**< Source device context */
HDCdest_hdc;/**< Destination, source-compatible DC */
@@ -542,6 +544,8 @@ static int gdigrab_read_packet(AVFormatContext *s1,
AVPacket *pkt)
int64_t curtime, delay;
+unsigned long flag;
+
/* Calculate the time of the next frame */
time_frame += INT64_C(100);
@@ -570,12 +574,16 @@ static int gdigrab_read_packet(AVFormatContext *s1,
AVPacket *pkt)
return AVERROR(ENOMEM);
pkt->pts = curtime;
+flag = SRCCOPY;
+if(!gdigrab->without_captureblt)
+flag |= CAPTUREBLT;
+
/* Blit screen grab */
if (!BitBlt(dest_hdc, 0, 0,
clip_rect.right - clip_rect.left,
clip_rect.bottom - clip_rect.top,
source_hdc,
-clip_rect.left, clip_rect.top, SRCCOPY | CAPTUREBLT)) {
+clip_rect.left, clip_rect.top, flag)) {
WIN32_API_ERROR("Failed to capture image");
return AVERROR(EIO);
}
@@ -639,6 +647,7 @@ static const AVOption options[] = {
{ "video_size", "set video frame size", OFFSET(width),
AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, DEC },
{ "offset_x", "capture area x offset", OFFSET(offset_x), AV_OPT_TYPE_INT,
{.i64 = 0}, INT_MIN, INT_MAX, DEC },
{ "offset_y", "capture area y offset", OFFSET(offset_y), AV_OPT_TYPE_INT,
{.i64 = 0}, INT_MIN, INT_MAX, DEC },
+{ "without_captureblt", "capture without captureblt",
OFFSET(without_captureblt), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, DEC },
{ NULL },
};
IMO a not negated option would be better. i.e. use_captureblt that's enabled by
default.
You also need to update the docs.
I don't have windows so can't test on my machine.
Thanks
I will send an other patch, change without_captureblt to use_captureblt
and update the docs, also test on my pc
___
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".
Re: [FFmpeg-devel] [PATCH v4] avfilter/buffersrc: deprecate sws_param option
On Wed, Dec 11, 2019 at 11:33 PM Zhao Zhili wrote:
>
> Ping for review, thanks!
>
> > On Dec 4, 2019, at 6:57 PM, quinkbl...@foxmail.com wrote:
> >
> > From: Zhao Zhili
> >
> > ---
> > patch v4: update doc
> >
> > doc/filters.texi| 8
> > libavfilter/buffersrc.c | 14 --
> > libavfilter/version.h | 5 -
> > 3 files changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 5fdec6f015..d15cf74c84 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -21014,9 +21014,9 @@ Specify the frame rate expected for the video
> > stream.
> > The sample (pixel) aspect ratio of the input video.
> >
> > @item sws_param
> > -Specify the optional parameters to be used for the scale filter which
> > -is automatically inserted when an input change is detected in the
> > -input size or format.
> > +This option is deprecated and ignored. Prepend
> > @code{sws_flags=@var{flags};}
> > +to the filtergraph description to specify swscale flags for automatically
> > +inserted scalers. See @ref{Filtergraph syntax}.
> >
> > @item hw_frames_ctx
> > When using a hardware pixel format, this should be a reference to an
> > @@ -21041,7 +21041,7 @@
> > buffer=size=320x240:pixfmt=6:time_base=1/24:pixel_aspect=1/1
> > Alternatively, the options can be specified as a flat string, but this
> > syntax is deprecated:
> >
> > -@var{width}:@var{height}:@var{pix_fmt}:@var{time_base.num}:@var{time_base.den}:@var{pixel_aspect.num}:@var{pixel_aspect.den}[:@var{sws_param}]
> > +@var{width}:@var{height}:@var{pix_fmt}:@var{time_base.num}:@var{time_base.den}:@var{pixel_aspect.num}:@var{pixel_aspect.den}
> >
> > @section cellauto
> >
> > diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
> > index bae7d86695..73a7eb82ca 100644
> > --- a/libavfilter/buffersrc.c
> > +++ b/libavfilter/buffersrc.c
> > @@ -52,7 +52,9 @@ typedef struct BufferSourceContext {
> > int w, h;
> > enum AVPixelFormat pix_fmt;
> > AVRationalpixel_aspect;
> > +#if FF_API_SWS_PARAM_OPTION
> > char *sws_param;
> > +#endif
> >
> > AVBufferRef *hw_frames_ctx;
> >
> > @@ -287,10 +289,16 @@ static av_cold int init_video(AVFilterContext *ctx)
> > if (!(c->fifo = av_fifo_alloc(sizeof(AVFrame*
> > return AVERROR(ENOMEM);
> >
> > -av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d
> > sar:%d/%d sws_param:%s\n",
> > +av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d
> > sar:%d/%d\n",
> >c->w, c->h, av_get_pix_fmt_name(c->pix_fmt),
> >c->time_base.num, c->time_base.den, c->frame_rate.num,
> > c->frame_rate.den,
> > - c->pixel_aspect.num, c->pixel_aspect.den, (char
> > *)av_x_if_null(c->sws_param, ""));
> > + c->pixel_aspect.num, c->pixel_aspect.den);
> > +
> > +#if FF_API_SWS_PARAM_OPTION
> > +if (c->sws_param)
> > +av_log(ctx, AV_LOG_WARNING, "sws_param option is deprecated and
> > ignored\n");
> > +#endif
> > +
> > return 0;
> > }
> >
> > @@ -312,7 +320,9 @@ static const AVOption buffer_options[] = {
> > { "pixel_aspect", "sample aspect ratio",OFFSET(pixel_aspect),
> > AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> > { "time_base", NULL, OFFSET(time_base),
> > AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> > { "frame_rate",NULL, OFFSET(frame_rate),
> > AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> > +#if FF_API_SWS_PARAM_OPTION
> > { "sws_param", NULL, OFFSET(sws_param),
> > AV_OPT_TYPE_STRING,.flags = V },
> > +#endif
> > { NULL },
> > };
> >
> > diff --git a/libavfilter/version.h b/libavfilter/version.h
> > index 7e8d849e0c..bf57d64d1f 100644
> > --- a/libavfilter/version.h
> > +++ b/libavfilter/version.h
> > @@ -31,7 +31,7 @@
> >
> > #define LIBAVFILTER_VERSION_MAJOR 7
> > #define LIBAVFILTER_VERSION_MINOR 67
> > -#define LIBAVFILTER_VERSION_MICRO 100
> > +#define LIBAVFILTER_VERSION_MICRO 101
> >
> >
> > #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
> > @@ -59,6 +59,9 @@
> > #ifndef FF_API_FILTER_GET_SET
> > #define FF_API_FILTER_GET_SET (LIBAVFILTER_VERSION_MAJOR < 8)
> > #endif
> > +#ifndef FF_API_SWS_PARAM_OPTION
> > +#define FF_API_SWS_PARAM_OPTION (LIBAVFILTER_VERSION_MAJOR < 8)
> > +#endif
> > #ifndef FF_API_NEXT
> > #define FF_API_NEXT (LIBAVFILTER_VERSION_MAJOR < 8)
> > #endif
> > --
> > 2.22.0
> >
> > From: Zhao Zhili
> >
> > ---
> > patch v4: update doc
> >
> > doc/filters.texi| 8
> > libavfilter/buffersrc.c | 14 --
> > libavfilter/version.h | 5 -
> > 3 files changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 5fdec6f015..d15cf74c84 100644
> > --- a/doc/fi
Re: [FFmpeg-devel] [PATCH] lavc/hevc_cabac: fix cbf_cb and cbf_cr for transform depth 4
> -Original Message- > From: ffmpeg-devel On Behalf Of > Carl Eugen Hoyos > Sent: Wednesday, December 11, 2019 18:19 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/hevc_cabac: fix cbf_cb and cbf_cr > for transform depth 4 > > Am Mi., 11. Dez. 2019 um 09:57 Uhr schrieb Linjie Fu : > > > > The max transform depth is 5(from 0 to 4), so we need 5 cabac states for > > cbf_cb and cbf_cr. > > > > See Table 9-4 for details. > > Does this change the output of a file? > If yes, please provide it / implement a fate test. Yes, this issue was found in some license-limited clips and does affect the decoding. Hence it takes some efforts to generate an available file for verifying/test in the community. I've created a ticket for this and attached the clips and the decode result with/without this patch: https://trac.ffmpeg.org/ticket/8425 Please help to verify. Thx, - linjie ___ 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".
