Re: [FFmpeg-devel] [PATCH v1 1/1] swscale/swscale_unscaled: fixed the issue that when width/height is not 2-multiple, transition of nv12 to u/v planes is not completed.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Michael Niedermayer > Sent: 2019年3月28日 8:06 > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH v1 1/1] swscale/swscale_unscaled: fixed > the issue that when width/height is not 2-multiple, transition of nv12 to u/v > planes is not completed. > > On Wed, Mar 27, 2019 at 06:18:28PM +0800, Decai Lin wrote: > > From: "Dong, Jerry" > > > > Signed-off-by: Dong, Jerry > > Signed-off-by: Decai Lin > > --- > > libswscale/swscale_unscaled.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/libswscale/swscale_unscaled.c > > b/libswscale/swscale_unscaled.c index 058f2b9..2ba2907 100644 > > --- a/libswscale/swscale_unscaled.c > > +++ b/libswscale/swscale_unscaled.c > > @@ -150,10 +150,10 @@ static int planarToNv12Wrapper(SwsContext *c, > const uint8_t *src[], > >dstParam[0], dstStride[0]); > > > > if (c->dstFormat == AV_PIX_FMT_NV12) > > -interleaveBytes(src[1], src[2], dst, c->srcW / 2, srcSliceH / 2, > > +interleaveBytes(src[1], src[2], dst, (c->srcW + 1) / 2, > > + (srcSliceH + 1) / 2, > > srcStride[1], srcStride[2], dstStride[1]); > > else > > -interleaveBytes(src[2], src[1], dst, c->srcW / 2, srcSliceH / 2, > > +interleaveBytes(src[2], src[1], dst, (c->srcW + 1) / 2, > > + (srcSliceH + 1) / 2, > > srcStride[2], srcStride[1], dstStride[1]); > > > > return srcSliceH; > > this can probably use chrSrcW Yes it is. Will update it. 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 ___ 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/h264_parse: no need check ref list1 for P slices.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Michael Niedermayer > Sent: 2019年2月1日 1:12 > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref > list1 for P slices. > > On Thu, Jan 31, 2019 at 03:36:56PM +0800, Decai Lin wrote: > > This is robust for some corner case there is incorrect list1 count in > > pps header, but it's a P slice and can be decoded well. > > please provide a sample h264 video that needs this > Attached the test clip for this patch. Thanks IP_with invalid_reflist1_cnt.264 Description: IP_with invalid_reflist1_cnt.264 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref list1 for P slices.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > myp...@gmail.com > Sent: 2019年2月1日 15:14 > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref > list1 for P slices. > > On Fri, Feb 1, 2019 at 1:28 PM Lin, Decai wrote: > > > > > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > > Behalf Of Michael Niedermayer > > > Sent: 2019年2月1日 1:12 > > > To: FFmpeg development discussions and patches > > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need > > > check ref > > > list1 for P slices. > > > > > > On Thu, Jan 31, 2019 at 03:36:56PM +0800, Decai Lin wrote: > > > > This is robust for some corner case there is incorrect list1 count > > > > in pps header, but it's a P slice and can be decoded well. > > > > > > please provide a sample h264 video that needs this > > > > > > > Attached the test clip for this patch. > > > > I think the better way is to add a new fate test case with the test clip for > h264dec, isn't it? Yes, I can file another patch for the related fate test case. Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264_levels: add MaxMBPS checking and update fate test.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: 2019年3月7日 8:24
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/h264_levels: add MaxMBPS
> checking and update fate test.
>
> On 06/03/2019 08:21, Decai Lin wrote:
> > 1. add MaxMBPS checking for level idc setting to align with AVC spec
> >AnnexA table A-1/A-6 level limits.
> > 2. update h264 level fate test.
> >
> > Signed-off-by: Decai Lin
> > ---
> > libavcodec/h264_levels.c | 5 +
> > libavcodec/h264_levels.h | 1 +
> > libavcodec/h264_metadata_bsf.c | 14 +-
> > libavcodec/tests/h264_levels.c | 41
> > ++---
> > libavcodec/vaapi_encode_h264.c | 13 +
> > 5 files changed, 70 insertions(+), 4 deletions(-)
>
> Nice, this is a good idea. Some comments below.
>
> > diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c index
> > 7a55116..e457dbe 100644
> > --- a/libavcodec/h264_levels.c
> > +++ b/libavcodec/h264_levels.c
> > @@ -89,11 +89,13 @@ const H264LevelDescriptor *ff_h264_get_level(int
> > level_idc,
> >
> > const H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> > int64_t bitrate,
> > + int framerate,
> > int width, int
> height,
> > int
> > max_dec_frame_buffering) {
> > int width_mbs = (width + 15) / 16;
> > int height_mbs = (height + 15) / 16;
> > +int64_t mb_processing_rate = (int64_t) (width_mbs * height_mbs *
> > + framerate);
>
> This doesn't work - if it overflows you've already hit undefined behaviour in
> the calculation before the cast.
>
> > int no_cs3f = !(profile_idc == 66 ||
> > profile_idc == 77 ||
> > profile_idc == 88); @@ -108,6 +110,9 @@ const
> > H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> > if (bitrate > (int64_t)level->max_br *
> h264_get_br_factor(profile_idc))
> > continue;
> >
> > +if (mb_processing_rate > (int64_t)level->max_mbps)
> > +continue;
> > +
> > if (width_mbs * height_mbs > level->max_fs)
> > continue;
> > if (width_mbs * width_mbs > 8 * level->max_fs) diff --git
> > a/libavcodec/h264_levels.h b/libavcodec/h264_levels.h index
> > 4189fc6..0a0f410 100644
> > --- a/libavcodec/h264_levels.h
> > +++ b/libavcodec/h264_levels.h
> > @@ -46,6 +46,7 @@ const H264LevelDescriptor *ff_h264_get_level(int
> level_idc,
> > */
> > const H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> > int64_t bitrate,
> > + int framerate,
> > int width, int
> height,
> > int
> > max_dec_frame_buffering);
> >
> > diff --git a/libavcodec/h264_metadata_bsf.c
> > b/libavcodec/h264_metadata_bsf.c index a17987a..61c2711 100644
> > --- a/libavcodec/h264_metadata_bsf.c
> > +++ b/libavcodec/h264_metadata_bsf.c
> > @@ -223,6 +223,7 @@ static int
> h264_metadata_update_sps(AVBSFContext *bsf,
> > const H264LevelDescriptor *desc;
> > int64_t bit_rate;
> > int width, height, dpb_frames;
> > +int framerate, fr_num, fr_den;
> >
> > if (sps->vui.nal_hrd_parameters_present_flag) {
> > bit_rate =
> > (sps->vui.nal_hrd_parameters.bit_rate_value_minus1[0] + 1) * @@ -244,7
> +245,18 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
> > height = 16 * (sps->pic_height_in_map_units_minus1 + 1)
> *
> > (2 - sps->frame_mbs_only_flag);
> >
> > -desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
> > +if (ctx->tick_rate.num > 0 && ctx->tick_rate.den > 0)
> > +av_reduce(&fr_num, &fr_den,
> > +ctx->tick_rate.num, ctx->tick_rate.den,
> 65535);
> > +else
> > +av_reduce(&fr_num, &fr_den,
> > +ctx->tick_rate.den, ctx->tick_rate.num,
> > + 65535);
>
> Since the VUI fields are set above, I suggest using them instead here because
> that will include an existing rate in the stream.
>
> Also, the tick rate is only directly usable as fieldrate if
> fixed_frame_rate_flag
> is set.
>
> > +if (fr_den > 0)
> > +framerate = fr_num / fr_den;
> > +else
> > +framerate = fr_num;
>
> I'm not sure what this is trying to do. If the number isn't valid, the
> framerate should be passed as zero to avoid constraining anything.
>
> > +
> > +desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
> > + framerate,
> >
Re: [FFmpeg-devel] [PATCH v2 1/1] lavc/h264_levels: add MaxMBPS checking and update fate test.
Any comments before applying the patch?
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Decai Lin
> Sent: 2019年3月8日 14:39
> To: ffmpeg-devel@ffmpeg.org
> Cc: Lin, Decai
> Subject: [FFmpeg-devel] [PATCH v2 1/1] lavc/h264_levels: add MaxMBPS
> checking and update fate test.
>
> 1. add MaxMBPS checking for level idc setting to align with AVC spec
>AnnexA table A-1/A-6 level limits.
> 2. update h264 level fate test.
>
> Signed-off-by: Decai Lin
> ---
> libavcodec/h264_levels.c | 6 +
> libavcodec/h264_levels.h | 1 +
> libavcodec/h264_metadata_bsf.c | 10 +++-
> libavcodec/tests/h264_levels.c | 58
> +++---
> libavcodec/vaapi_encode_h264.c | 7 +
> 5 files changed, 78 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c index
> 7a55116..7fdb61d 100644
> --- a/libavcodec/h264_levels.c
> +++ b/libavcodec/h264_levels.c
> @@ -89,6 +89,7 @@ const H264LevelDescriptor *ff_h264_get_level(int
> level_idc,
>
> const H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> int64_t bitrate,
> + int framerate,
> int width, int height,
> int
> max_dec_frame_buffering) { @@ -116,6 +117,11 @@ const
> H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> continue;
>
> if (width_mbs && height_mbs) {
> +if (framerate > level->max_mbps / (width_mbs *
> height_mbs))
> +continue;
> +}
> +
> +if (width_mbs && height_mbs) {
> int max_dpb_frames =
> FFMIN(level->max_dpb_mbs / (width_mbs *
> height_mbs), 16);
> if (max_dec_frame_buffering > max_dpb_frames) diff --git
> a/libavcodec/h264_levels.h b/libavcodec/h264_levels.h index
> 4189fc6..0a0f410 100644
> --- a/libavcodec/h264_levels.h
> +++ b/libavcodec/h264_levels.h
> @@ -46,6 +46,7 @@ const H264LevelDescriptor *ff_h264_get_level(int
> level_idc,
> */
> const H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> int64_t bitrate,
> + int framerate,
> int width, int height,
> int
> max_dec_frame_buffering);
>
> diff --git a/libavcodec/h264_metadata_bsf.c
> b/libavcodec/h264_metadata_bsf.c index a17987a..4ad9664 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -223,6 +223,7 @@ static int
> h264_metadata_update_sps(AVBSFContext *bsf,
> const H264LevelDescriptor *desc;
> int64_t bit_rate;
> int width, height, dpb_frames;
> +int framerate;
>
> if (sps->vui.nal_hrd_parameters_present_flag) {
> bit_rate =
> (sps->vui.nal_hrd_parameters.bit_rate_value_minus1[0] + 1) * @@ -244,7
> +245,14 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
> height = 16 * (sps->pic_height_in_map_units_minus1 + 1) *
> (2 - sps->frame_mbs_only_flag);
>
> -desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
> +if (sps->vui.timing_info_present_flag) {
> +framerate = sps->vui.time_scale /
> sps->vui.num_units_in_tick;
> +}
> +else {
> +framerate = 0;
> +}
> +
> +desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
> + framerate,
> width, height, dpb_frames);
> if (desc) {
> level_idc = desc->level_idc; diff --git
> a/libavcodec/tests/h264_levels.c b/libavcodec/tests/h264_levels.c index
> 0e00f05..1f2c2eb 100644
> --- a/libavcodec/tests/h264_levels.c
> +++ b/libavcodec/tests/h264_levels.c
> @@ -62,6 +62,48 @@ static const struct { static const struct {
> int width;
> int height;
> +int framerate;
> +int level_idc;
> +} test_framerate[] = {
> +// Some typical sizes and frame rates.
> +// (From H.264 table A-1 and table A-6)
> +{ 176, 144, 15, 10 },
> +{ 176, 144, 16, 11 },
> +{ 320, 240, 10, 11 },
> +{ 320, 240, 20, 12 },
> +{ 320, 240, 40, 21 },
> +{ 352, 288, 30, 13 },
> +{ 352, 288, 51, 22 },
> +{ 352, 576, 25, 21 },
> +
Re: [FFmpeg-devel] [PATCH v2 1/1] lavc/h264_levels: add MaxMBPS checking and update fate test.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: 2019年3月20日 16:33
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/1] lavc/h264_levels: add MaxMBPS
> checking and update fate test.
>
> 2019-03-08 7:39 GMT+01:00, Decai Lin :
> > 1. add MaxMBPS checking for level idc setting to align with AVC spec
> >AnnexA table A-1/A-6 level limits.
> > 2. update h264 level fate test.
> >
> > Signed-off-by: Decai Lin
> > ---
> > libavcodec/h264_levels.c | 6 +
> > libavcodec/h264_levels.h | 1 +
> > libavcodec/h264_metadata_bsf.c | 10 +++-
> > libavcodec/tests/h264_levels.c | 58
> > +++---
> > libavcodec/vaapi_encode_h264.c | 7 +
> > 5 files changed, 78 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c index
> > 7a55116..7fdb61d 100644
> > --- a/libavcodec/h264_levels.c
> > +++ b/libavcodec/h264_levels.c
> > @@ -89,6 +89,7 @@ const H264LevelDescriptor *ff_h264_get_level(int
> > level_idc,
> >
> > const H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> > int64_t bitrate,
> > + int framerate,
> > int width, int
> height,
> > int
> > max_dec_frame_buffering) { @@ -116,6 +117,11 @@ const
> > H264LevelDescriptor *ff_h264_guess_level(int profile_idc,
> > continue;
> >
> > if (width_mbs && height_mbs) {
> > +if (framerate > level->max_mbps / (width_mbs *
> height_mbs))
> > +continue;
> > +}
> > +
> > +if (width_mbs && height_mbs) {
>
> This looks very strange:
> Do I miss something or can these blocks be merged / the last two inserts be
> removed?
OK, will merge them in one block.
> [...]
>
> > @@ -244,7 +245,14 @@ static int
> h264_metadata_update_sps(AVBSFContext *bsf,
> > height = 16 * (sps->pic_height_in_map_units_minus1 + 1)
> *
> > (2 - sps->frame_mbs_only_flag);
> >
> > -desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
> > +if (sps->vui.timing_info_present_flag) {
> > +framerate = sps->vui.time_scale /
> > sps->vui.num_units_in_tick;
>
> > +}
> > +else {
>
> Please merge these lines.
Thanks, will merge these lines.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free issue.
> -Original Message- > From: Fu, Linjie > Sent: 2019年3月21日 20:20 > To: FFmpeg development discussions and patches > > Cc: Yan, FengX ; Lin, Decai > Subject: RE: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free > issue. > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > > Of Decai Lin > > Sent: Thursday, March 21, 2019 17:30 > > To: ffmpeg-devel@ffmpeg.org > > Cc: Yan, FengX ; Lin, Decai > > Subject: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free issue. > > > > From: "Yan, FengX" > > > > Signed-off-by: Yan, FengX > > Signed-off-by: Decai Lin > > --- > > libavcodec/vaapi_hevc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c index > > 19aabcd..373ffc4 100644 > > --- a/libavcodec/vaapi_hevc.c > > +++ b/libavcodec/vaapi_hevc.c > > @@ -271,7 +271,7 @@ static int vaapi_hevc_end_frame(AVCodecContext > > *avctx) > > > > ret = ff_vaapi_decode_issue(avctx, &pic->pic); > > if (ret < 0) > > -goto fail; > > +return ret; > > > > return 0; > > fail: > > I believe this should match the behavior in vaapi_h264/mpeg4/.../vc1.c, and > remove the redundant ff_vaapi_decode_cancel in vaapi_hevc_end_frame(). > > --Linjie Hello Linjie, there is little different between vaapi_hevc and other vaapi codecs. vaapi_hevc has an extra code block to handle slice buffer before ff_vaapi_decode_issue() , and if it's failed to handle, the buffers have to be destroyed separately. So the calling of ff_vaapi_decode_cancel() here is a must for hevc. ___ 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".
