Re: [FFmpeg-devel] [PATCH] libavcodec/mpegvideo_enc: Fix a chroma mb size error in sse_mb()
On Fri, 2022-07-01 at 13:34 +0800, Wenbin Chen wrote:
> For 422 frames we should not use hard coded 8 to calculate mb size for
> uv plane. Chroma shift should be taken into consideration to be
> compatiple with different sampling format.
>
> The error is reported by fate test when av_cpu_max_align() return 64
> on the platform supporting AVX512. This is a hidden error and it is
> exposed after commit 17a59a634c39b00a680c6ebbaea58db95594d13d.
>
> mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum of
> squared error) on current mb, reconstructed mb will be wrote to the
> previous mb space, so that the memory can be saved. However if the align
> is 64, the frame is shared in somewhere else, so the frame cannot be
> reused and a new frame to store reconstrued data is created. Because the
> height of mb is wrong when compute sse on 422 frame, starting from the
> second line of macro block, changed data is read when frame is reused
> (we need to read row 16 rather than row 8 if frame is 422), and unchanged
> data is read when frame is not reused (a new frame is created so the
> original frame will not be changed).
>
> That is why commit 17a59a634c39b00a680c6ebbaea58db95594d13d exposes this
> issue, because it add av_cpu_max_align() and this function return 64 on
> platform supporting AVX512 which lead to creating a frame in mpeg2enc,
> and this lead to the different outputs.
>
> Signed-off-by: Wenbin Chen
> ---
> libavcodec/mpegvideo_enc.c | 29 +--
> tests/ref/seek/vsynth_lena-mpeg2-422 | 40 +-
> tests/ref/vsynth/vsynth1-mpeg2-422 | 8 +++---
> tests/ref/vsynth/vsynth2-mpeg2-422 | 8 +++---
> tests/ref/vsynth/vsynth3-mpeg2-422 | 8 +++---
> tests/ref/vsynth/vsynth_lena-mpeg2-422 | 8 +++---
> 6 files changed, 56 insertions(+), 45 deletions(-)
>
> diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> index d6a85a037a..c9d9e2a764 100644
> --- a/libavcodec/mpegvideo_enc.c
> +++ b/libavcodec/mpegvideo_enc.c
> @@ -2558,24 +2558,35 @@ static int sse(MpegEncContext *s, uint8_t *src1,
> uint8_t *src2, int w, int h, in
> static int sse_mb(MpegEncContext *s){
> int w= 16;
> int h= 16;
> +int chroma_mb_w = w >> s->chroma_x_shift;
> +int chroma_mb_h = h >> s->chroma_y_shift;
>
> if(s->mb_x*16 + 16 > s->width ) w= s->width - s->mb_x*16;
> if(s->mb_y*16 + 16 > s->height) h= s->height- s->mb_y*16;
>
> if(w==16 && h==16)
>if(s->avctx->mb_cmp == FF_CMP_NSSE){
> -return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x * 16 + s-
> >mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> - s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x * 8 + s-
> >mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> - s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x * 8 + s-
> >mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> +return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x * 16 + s-
> >mb_y * s->linesize * 16,
> + s->dest[0], s->linesize, 16) +
> + s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x *
> chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[1], s->uvlinesize, chroma_mb_h) +
> + s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x *
> chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[2], s->uvlinesize, chroma_mb_h);
>}else{
> -return s->mecc.sse[0](NULL, s->new_picture->data[0] + s->mb_x * 16 +
> s->mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> - s->mecc.sse[1](NULL, s->new_picture->data[1] + s->mb_x * 8 +
> s->mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> - s->mecc.sse[1](NULL, s->new_picture->data[2] + s->mb_x * 8 +
> s->mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> +return s->mecc.sse[0](NULL, s->new_picture->data[0] + s->mb_x * 16 +
> s->mb_y * s->linesize * 16,
> + s->dest[0], s->linesize, 16) +
> + s->mecc.sse[1](NULL, s->new_picture->data[1] + s->mb_x *
> chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[1], s->uvlinesize, chroma_mb_h) +
> + s->mecc.sse[1](NULL, s->new_picture->data[2] + s->mb_x *
> chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[2], s->uvlinesize, chroma_mb_h);
>}
> else
> -return sse(s, s->new_picture->data[0] + s->mb_x*16 + s->mb_y*s-
> >linesize*16, s->dest[0], w, h, s->linesize)
> - +sse(s, s->new_picture->data[1] + s->mb_x*8 + s->mb_y*s-
> >uvlinesize*8,s->dest[1], w>>1, h>>1, s->uvlinesize)
> - +sse(s, s->new_picture->data[2] + s->mb_x*8 + s->mb_y*s-
> >uvlinesize*8,s->dest[2], w>>1, h>>1, s->uvlinesize);
> +
Re: [FFmpeg-devel] [PATCH] swscale: add NV16 input/output
On Sat, Jun 11, 2022 at 5:35 PM Michael Niedermayer wrote: > On Fri, Jun 10, 2022 at 04:11:10PM +0200, Matthieu Bouron wrote: > > On Thu, Jun 2, 2022 at 9:13 PM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Wed, Jun 01, 2022 at 10:33:37PM +0200, Matthieu Bouron wrote: > > > > --- > > > > libswscale/input.c | 1 + > > > > libswscale/utils.c | 1 + > > > > libswscale/version.h | 2 +- > > > > tests/ref/fate/filter-pixdesc-nv16 | 1 + > > > > tests/ref/fate/filter-pixfmts-copy | 1 + > > > > tests/ref/fate/filter-pixfmts-crop | 1 + > > > > tests/ref/fate/filter-pixfmts-field | 1 + > > > > tests/ref/fate/filter-pixfmts-fieldorder | 1 + > > > > tests/ref/fate/filter-pixfmts-hflip | 1 + > > > > tests/ref/fate/filter-pixfmts-il | 1 + > > > > tests/ref/fate/filter-pixfmts-null | 1 + > > > > tests/ref/fate/filter-pixfmts-pad| 1 + > > > > tests/ref/fate/filter-pixfmts-scale | 1 + > > > > tests/ref/fate/filter-pixfmts-vflip | 1 + > > > > 14 files changed, 14 insertions(+), 1 deletion(-) > > > > create mode 100644 tests/ref/fate/filter-pixdesc-nv16 > > > > > > > > Sorry for the late reply > > > > > > > has this been tested ? (various scaled and non scaled) variants ? > > > > > > > I only tested the non scaled variant using the command line doing > multiple > > round trips to/from nv16. > > Is there a particular test procedure to validate every variants ? > > you can test manually or use something like > libswscale/tests/swscale.c > I manually tested without any issue: il, field, fieldorder, copy, crop, hflip, null, pad, scale and vflip. ___ 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] libavcodec/mpegvideo_enc: Fix a chroma mb size error in sse_mb()
On Fri, Jul 1, 2022 at 10:00 AM Xiang, Haihao <
haihao.xiang-at-intel@ffmpeg.org> wrote:
> On Fri, 2022-07-01 at 13:34 +0800, Wenbin Chen wrote:
> > For 422 frames we should not use hard coded 8 to calculate mb size for
> > uv plane. Chroma shift should be taken into consideration to be
> > compatiple with different sampling format.
> >
> > The error is reported by fate test when av_cpu_max_align() return 64
> > on the platform supporting AVX512. This is a hidden error and it is
> > exposed after commit 17a59a634c39b00a680c6ebbaea58db95594d13d.
> >
> > mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum of
> > squared error) on current mb, reconstructed mb will be wrote to the
> > previous mb space, so that the memory can be saved. However if the align
> > is 64, the frame is shared in somewhere else, so the frame cannot be
> > reused and a new frame to store reconstrued data is created. Because the
> > height of mb is wrong when compute sse on 422 frame, starting from the
> > second line of macro block, changed data is read when frame is reused
> > (we need to read row 16 rather than row 8 if frame is 422), and unchanged
> > data is read when frame is not reused (a new frame is created so the
> > original frame will not be changed).
> >
> > That is why commit 17a59a634c39b00a680c6ebbaea58db95594d13d exposes this
> > issue, because it add av_cpu_max_align() and this function return 64 on
> > platform supporting AVX512 which lead to creating a frame in mpeg2enc,
> > and this lead to the different outputs.
> >
> > Signed-off-by: Wenbin Chen
> > ---
> > libavcodec/mpegvideo_enc.c | 29 +--
> > tests/ref/seek/vsynth_lena-mpeg2-422 | 40 +-
> > tests/ref/vsynth/vsynth1-mpeg2-422 | 8 +++---
> > tests/ref/vsynth/vsynth2-mpeg2-422 | 8 +++---
> > tests/ref/vsynth/vsynth3-mpeg2-422 | 8 +++---
> > tests/ref/vsynth/vsynth_lena-mpeg2-422 | 8 +++---
> > 6 files changed, 56 insertions(+), 45 deletions(-)
> >
> > diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> > index d6a85a037a..c9d9e2a764 100644
> > --- a/libavcodec/mpegvideo_enc.c
> > +++ b/libavcodec/mpegvideo_enc.c
> > @@ -2558,24 +2558,35 @@ static int sse(MpegEncContext *s, uint8_t *src1,
> > uint8_t *src2, int w, int h, in
> > static int sse_mb(MpegEncContext *s){
> > int w= 16;
> > int h= 16;
> > +int chroma_mb_w = w >> s->chroma_x_shift;
> > +int chroma_mb_h = h >> s->chroma_y_shift;
> >
> > if(s->mb_x*16 + 16 > s->width ) w= s->width - s->mb_x*16;
> > if(s->mb_y*16 + 16 > s->height) h= s->height- s->mb_y*16;
> >
> > if(w==16 && h==16)
> >if(s->avctx->mb_cmp == FF_CMP_NSSE){
> > -return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x *
> 16 + s-
> > >mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> > - s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x *
> 8 + s-
> > >mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> > - s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x *
> 8 + s-
> > >mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> > +return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x *
> 16 + s-
> > >mb_y * s->linesize * 16,
> > + s->dest[0], s->linesize, 16) +
> > + s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x *
> > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > + s->dest[1], s->uvlinesize, chroma_mb_h) +
> > + s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x *
> > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > + s->dest[2], s->uvlinesize, chroma_mb_h);
> >}else{
> > -return s->mecc.sse[0](NULL, s->new_picture->data[0] + s->mb_x *
> 16 +
> > s->mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> > - s->mecc.sse[1](NULL, s->new_picture->data[1] + s->mb_x
> * 8 +
> > s->mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> > - s->mecc.sse[1](NULL, s->new_picture->data[2] + s->mb_x
> * 8 +
> > s->mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> > +return s->mecc.sse[0](NULL, s->new_picture->data[0] + s->mb_x *
> 16 +
> > s->mb_y * s->linesize * 16,
> > + s->dest[0], s->linesize, 16) +
> > + s->mecc.sse[1](NULL, s->new_picture->data[1] + s->mb_x *
> > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > + s->dest[1], s->uvlinesize, chroma_mb_h) +
> > + s->mecc.sse[1](NULL, s->new_picture->data[2] + s->mb_x *
> > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > + s->dest[2], s->uvlinesize, chroma_mb_h);
> >}
> > else
> > -return sse(s, s->new_picture->data[0] + s->mb_x*16 + s->mb_y*s-
> > >linesize*16, s->dest[0], w, h, s->linesiz
Re: [FFmpeg-devel] [PATCH] libavcodec/mpegvideo_enc: Fix a chroma mb size error in sse_mb()
> On Fri, Jul 1, 2022 at 10:00 AM Xiang, Haihao <
> haihao.xiang-at-intel@ffmpeg.org> wrote:
>
> > On Fri, 2022-07-01 at 13:34 +0800, Wenbin Chen wrote:
> > > For 422 frames we should not use hard coded 8 to calculate mb size for
> > > uv plane. Chroma shift should be taken into consideration to be
> > > compatiple with different sampling format.
> > >
> > > The error is reported by fate test when av_cpu_max_align() return 64
> > > on the platform supporting AVX512. This is a hidden error and it is
> > > exposed after commit 17a59a634c39b00a680c6ebbaea58db95594d13d.
> > >
> > > mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum
> of
> > > squared error) on current mb, reconstructed mb will be wrote to the
> > > previous mb space, so that the memory can be saved. However if the
> align
> > > is 64, the frame is shared in somewhere else, so the frame cannot be
> > > reused and a new frame to store reconstrued data is created. Because
> the
> > > height of mb is wrong when compute sse on 422 frame, starting from the
> > > second line of macro block, changed data is read when frame is reused
> > > (we need to read row 16 rather than row 8 if frame is 422), and
> unchanged
> > > data is read when frame is not reused (a new frame is created so the
> > > original frame will not be changed).
> > >
> > > That is why commit 17a59a634c39b00a680c6ebbaea58db95594d13d
> exposes this
> > > issue, because it add av_cpu_max_align() and this function return 64 on
> > > platform supporting AVX512 which lead to creating a frame in mpeg2enc,
> > > and this lead to the different outputs.
> > >
> > > Signed-off-by: Wenbin Chen
> > > ---
> > > libavcodec/mpegvideo_enc.c | 29 +--
> > > tests/ref/seek/vsynth_lena-mpeg2-422 | 40 +-
> > > tests/ref/vsynth/vsynth1-mpeg2-422 | 8 +++---
> > > tests/ref/vsynth/vsynth2-mpeg2-422 | 8 +++---
> > > tests/ref/vsynth/vsynth3-mpeg2-422 | 8 +++---
> > > tests/ref/vsynth/vsynth_lena-mpeg2-422 | 8 +++---
> > > 6 files changed, 56 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> > > index d6a85a037a..c9d9e2a764 100644
> > > --- a/libavcodec/mpegvideo_enc.c
> > > +++ b/libavcodec/mpegvideo_enc.c
> > > @@ -2558,24 +2558,35 @@ static int sse(MpegEncContext *s, uint8_t
> *src1,
> > > uint8_t *src2, int w, int h, in
> > > static int sse_mb(MpegEncContext *s){
> > > int w= 16;
> > > int h= 16;
> > > +int chroma_mb_w = w >> s->chroma_x_shift;
> > > +int chroma_mb_h = h >> s->chroma_y_shift;
> > >
> > > if(s->mb_x*16 + 16 > s->width ) w= s->width - s->mb_x*16;
> > > if(s->mb_y*16 + 16 > s->height) h= s->height- s->mb_y*16;
> > >
> > > if(w==16 && h==16)
> > >if(s->avctx->mb_cmp == FF_CMP_NSSE){
> > > -return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x *
> > 16 + s-
> > > >mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> > > - s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x *
> > 8 + s-
> > > >mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> > > - s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x *
> > 8 + s-
> > > >mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> > > +return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x *
> > 16 + s-
> > > >mb_y * s->linesize * 16,
> > > + s->dest[0], s->linesize, 16) +
> > > + s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x *
> > > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > > + s->dest[1], s->uvlinesize, chroma_mb_h) +
> > > + s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x *
> > > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > > + s->dest[2], s->uvlinesize, chroma_mb_h);
> > >}else{
> > > -return s->mecc.sse[0](NULL, s->new_picture->data[0] + s->mb_x *
> > 16 +
> > > s->mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> > > - s->mecc.sse[1](NULL, s->new_picture->data[1] + s->mb_x
> > * 8 +
> > > s->mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> > > - s->mecc.sse[1](NULL, s->new_picture->data[2] + s->mb_x
> > * 8 +
> > > s->mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> > > +return s->mecc.sse[0](NULL, s->new_picture->data[0] + s->mb_x *
> > 16 +
> > > s->mb_y * s->linesize * 16,
> > > + s->dest[0], s->linesize, 16) +
> > > + s->mecc.sse[1](NULL, s->new_picture->data[1] + s->mb_x *
> > > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > > + s->dest[1], s->uvlinesize, chroma_mb_h) +
> > > + s->mecc.sse[1](NULL, s->new_picture->data[2] + s->mb_x *
> > > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > > +
Re: [FFmpeg-devel] [PATCH] libavcodec/mpegvideo_enc: Fix a chroma mb size error in sse_mb()
On Fri, Jul 1, 2022 at 10:47 AM Chen, Wenbin <
wenbin.chen-at-intel@ffmpeg.org> wrote:
> > On Fri, Jul 1, 2022 at 10:00 AM Xiang, Haihao <
> > haihao.xiang-at-intel@ffmpeg.org> wrote:
> >
> > > On Fri, 2022-07-01 at 13:34 +0800, Wenbin Chen wrote:
> > > > For 422 frames we should not use hard coded 8 to calculate mb size
> for
> > > > uv plane. Chroma shift should be taken into consideration to be
> > > > compatiple with different sampling format.
> > > >
> > > > The error is reported by fate test when av_cpu_max_align() return 64
> > > > on the platform supporting AVX512. This is a hidden error and it is
> > > > exposed after commit 17a59a634c39b00a680c6ebbaea58db95594d13d.
> > > >
> > > > mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum
> > of
> > > > squared error) on current mb, reconstructed mb will be wrote to the
> > > > previous mb space, so that the memory can be saved. However if the
> > align
> > > > is 64, the frame is shared in somewhere else, so the frame cannot be
> > > > reused and a new frame to store reconstrued data is created. Because
> > the
> > > > height of mb is wrong when compute sse on 422 frame, starting from
> the
> > > > second line of macro block, changed data is read when frame is reused
> > > > (we need to read row 16 rather than row 8 if frame is 422), and
> > unchanged
> > > > data is read when frame is not reused (a new frame is created so the
> > > > original frame will not be changed).
> > > >
> > > > That is why commit 17a59a634c39b00a680c6ebbaea58db95594d13d
> > exposes this
> > > > issue, because it add av_cpu_max_align() and this function return 64
> on
> > > > platform supporting AVX512 which lead to creating a frame in
> mpeg2enc,
> > > > and this lead to the different outputs.
> > > >
> > > > Signed-off-by: Wenbin Chen
> > > > ---
> > > > libavcodec/mpegvideo_enc.c | 29 +--
> > > > tests/ref/seek/vsynth_lena-mpeg2-422 | 40
> +-
> > > > tests/ref/vsynth/vsynth1-mpeg2-422 | 8 +++---
> > > > tests/ref/vsynth/vsynth2-mpeg2-422 | 8 +++---
> > > > tests/ref/vsynth/vsynth3-mpeg2-422 | 8 +++---
> > > > tests/ref/vsynth/vsynth_lena-mpeg2-422 | 8 +++---
> > > > 6 files changed, 56 insertions(+), 45 deletions(-)
> > > >
> > > > diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> > > > index d6a85a037a..c9d9e2a764 100644
> > > > --- a/libavcodec/mpegvideo_enc.c
> > > > +++ b/libavcodec/mpegvideo_enc.c
> > > > @@ -2558,24 +2558,35 @@ static int sse(MpegEncContext *s, uint8_t
> > *src1,
> > > > uint8_t *src2, int w, int h, in
> > > > static int sse_mb(MpegEncContext *s){
> > > > int w= 16;
> > > > int h= 16;
> > > > +int chroma_mb_w = w >> s->chroma_x_shift;
> > > > +int chroma_mb_h = h >> s->chroma_y_shift;
> > > >
> > > > if(s->mb_x*16 + 16 > s->width ) w= s->width - s->mb_x*16;
> > > > if(s->mb_y*16 + 16 > s->height) h= s->height- s->mb_y*16;
> > > >
> > > > if(w==16 && h==16)
> > > >if(s->avctx->mb_cmp == FF_CMP_NSSE){
> > > > -return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x
> *
> > > 16 + s-
> > > > >mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> > > > - s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x
> *
> > > 8 + s-
> > > > >mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> > > > - s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x
> *
> > > 8 + s-
> > > > >mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> > > > +return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x
> *
> > > 16 + s-
> > > > >mb_y * s->linesize * 16,
> > > > + s->dest[0], s->linesize, 16) +
> > > > + s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x
> *
> > > > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > > > + s->dest[1], s->uvlinesize,
> chroma_mb_h) +
> > > > + s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x
> *
> > > > chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> > > > + s->dest[2], s->uvlinesize,
> chroma_mb_h);
> > > >}else{
> > > > -return s->mecc.sse[0](NULL, s->new_picture->data[0] +
> s->mb_x *
> > > 16 +
> > > > s->mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> > > > - s->mecc.sse[1](NULL, s->new_picture->data[1] +
> s->mb_x
> > > * 8 +
> > > > s->mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> > > > - s->mecc.sse[1](NULL, s->new_picture->data[2] +
> s->mb_x
> > > * 8 +
> > > > s->mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> > > > +return s->mecc.sse[0](NULL, s->new_picture->data[0] +
> s->mb_x *
> > > 16 +
> > > > s->mb_y * s->linesize * 16,
> > > > + s->dest[0], s->linesize, 16) +
> > > > + s->mecc.sse[1](NULL, s->new_picture->data[1] +
Re: [FFmpeg-devel] [PATCH 1/3] Provided support for MPEG-5 EVC (Essential Video Coding) codec
Quoting Dawid Kozinski (2022-06-22 08:48:55)
> Prerequisites that must be met before adding new codec
> - Added new entry to codec IDs list
> - Added new entry to the codec descriptor list
> - Bumped libavcodec minor version
> - Changes in Changelog and MAINTAINERS files
>
> Signed-off-by: Dawid Kozinski
> ---
> Changelog | 3 ++-
> MAINTAINERS | 2 ++
> libavcodec/codec_desc.c | 8
> libavcodec/codec_id.h | 1 +
> libavcodec/profiles.c | 6 ++
> libavcodec/profiles.h | 1 +
> libavcodec/version.h| 2 +-
> 7 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index ef589705c4..0d230bde91 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -67,7 +67,8 @@ version 5.0:
> - VideoToolbox ProRes encoder
> - anlmf audio filter
> - IMF demuxer (experimental)
> -
> +- eXtra-fast Essential Video Encoder (XEVE)
> +- eXtra-fast Essential Video Decoder (XEVD)
These should be added in the commits that are actually adding the
feature in question.
>
> version 4.4:
> - AudioToolbox output device
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 274fc89203..4b33d3c1b2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -205,6 +205,7 @@ Codecs:
>libvpx* James Zern
>libxavs.c Stefan Gehrer
>libxavs2.cHuiwen Ren
> + libxev*.c, evc_parser.c Dawid Kozinski
>libzvbi-teletextdec.c Marton Balint
>lzo.h, lzo.c Reimar Doeffinger
>mdec.cMichael Niedermayer
> @@ -425,6 +426,7 @@ Muxers/Demuxers:
>dv.c Roman Shaposhnik
>electronicarts.c Peter Ross
>epafdec.c Paul B Mahol
> + evcdec.c Dawid Kozinski
>ffm* Baptiste Coudurier
>flic.cMike Melanson
>flvdec.c Michael Niedermayer
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index e2c1c67f5e..ea6f65ee9c 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1886,6 +1886,14 @@ static const AVCodecDescriptor codec_descriptors[] =
> {
> .long_name = NULL_IF_CONFIG_SMALL("QOI (Quite OK Image)"),
> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> },
> +{
> +.id= AV_CODEC_ID_EVC,
> +.type = AVMEDIA_TYPE_VIDEO,
> +.name = "evc",
> +.long_name = NULL_IF_CONFIG_SMALL("MPEG-5 EVC (Essential Video
> Coding)"),
Your mailer broke the long line here, so the patch cannot be applied.
You must send patches in a way that does not mangle them, such as
attaching them or using git send-email.
> +.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_REORDER,
> +.profiles = NULL_IF_CONFIG_SMALL(ff_evc_profiles),
> +},
>
> /* various PCM "codecs" */
> {
> diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
> index 93856a16f2..7ed4aed861 100644
> --- a/libavcodec/codec_id.h
> +++ b/libavcodec/codec_id.h
> @@ -311,6 +311,7 @@ enum AVCodecID {
> AV_CODEC_ID_VBN,
> AV_CODEC_ID_JPEGXL,
> AV_CODEC_ID_QOI,
> +AV_CODEC_ID_EVC,
>
> /* various PCM "codecs" */
> AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
> start of audio codecs
> diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
> index 7af7fbeb13..a31244e0db 100644
> --- a/libavcodec/profiles.c
> +++ b/libavcodec/profiles.c
> @@ -181,4 +181,10 @@ const AVProfile ff_arib_caption_profiles[] = {
> { FF_PROFILE_UNKNOWN }
> };
>
> +const AVProfile ff_evc_profiles[] = {
> +{ FF_PROFILE_EVC_BASELINE, "Baseline" },
> +{ FF_PROFILE_EVC_MAIN, "Main" },
Those profiles are not actually added in this patch, so this will fail
to build.
--
Anton Khirnov
___
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: add PHM decoder and encoder
Hello,
patch attached.
From cec6259e75fa56a4b064f7d5a0823449d19f3b47 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 1 Jul 2022 10:06:15 +0200
Subject: [PATCH] avcodec: add PHM decoder and encoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 2 +
libavcodec/allcodecs.c | 2 +
libavcodec/codec_desc.c | 7 +++
libavcodec/codec_id.h | 1 +
libavcodec/pnm.c| 10 +++-
libavcodec/pnm.h| 5 ++
libavcodec/pnm_parser.c | 3 +-
libavcodec/pnmdec.c | 114
libavcodec/pnmenc.c | 75 +-
libavformat/img2.c | 1 +
libavformat/img2enc.c | 2 +-
11 files changed, 217 insertions(+), 5 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 050934101c..457ec58377 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -571,6 +571,8 @@ OBJS-$(CONFIG_PGMYUV_DECODER) += pnmdec.o pnm.o
OBJS-$(CONFIG_PGMYUV_ENCODER) += pnmenc.o
OBJS-$(CONFIG_PGSSUB_DECODER) += pgssubdec.o
OBJS-$(CONFIG_PGX_DECODER) += pgxdec.o
+OBJS-$(CONFIG_PHM_DECODER) += pnmdec.o pnm.o
+OBJS-$(CONFIG_PHM_ENCODER) += pnmenc.o
OBJS-$(CONFIG_PHOTOCD_DECODER) += photocd.o
OBJS-$(CONFIG_PICTOR_DECODER) += pictordec.o cga_data.o
OBJS-$(CONFIG_PIXLET_DECODER) += pixlet.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f0b01051b0..bdfc2f6f45 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -254,6 +254,8 @@ extern const FFCodec ff_pgm_decoder;
extern const FFCodec ff_pgmyuv_encoder;
extern const FFCodec ff_pgmyuv_decoder;
extern const FFCodec ff_pgx_decoder;
+extern const FFCodec ff_phm_encoder;
+extern const FFCodec ff_phm_decoder;
extern const FFCodec ff_photocd_decoder;
extern const FFCodec ff_pictor_decoder;
extern const FFCodec ff_pixlet_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index e2c1c67f5e..44ad2d1fe8 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1886,6 +1886,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("QOI (Quite OK Image)"),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
},
+{
+.id= AV_CODEC_ID_PHM,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "phm",
+.long_name = NULL_IF_CONFIG_SMALL("PHM (Portable HalfFloatMap) image"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
/* various PCM "codecs" */
{
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 93856a16f2..81fb316cff 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -311,6 +311,7 @@ enum AVCodecID {
AV_CODEC_ID_VBN,
AV_CODEC_ID_JPEGXL,
AV_CODEC_ID_QOI,
+AV_CODEC_ID_PHM,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the start of audio codecs
diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c
index 958f2a342e..5d67e78e36 100644
--- a/libavcodec/pnm.c
+++ b/libavcodec/pnm.c
@@ -73,7 +73,9 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext * const s)
(s->bytestream[1] < '1' ||
s->bytestream[1] > '7' &&
s->bytestream[1] != 'f' &&
- s->bytestream[1] != 'F')) {
+ s->bytestream[1] != 'F' &&
+ s->bytestream[1] != 'H' &&
+ s->bytestream[1] != 'h')) {
s->bytestream += s->bytestream_end > s->bytestream;
s->bytestream += s->bytestream_end > s->bytestream;
return AVERROR_INVALIDDATA;
@@ -85,6 +87,12 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext * const s)
avctx->pix_fmt = AV_PIX_FMT_GBRPF32;
} else if (buf1[1] == 'f') {
avctx->pix_fmt = AV_PIX_FMT_GRAYF32;
+} else if (buf1[1] == 'H') {
+avctx->pix_fmt = AV_PIX_FMT_GBRPF32;
+s->half = 1;
+} else if (buf1[1] == 'h') {
+avctx->pix_fmt = AV_PIX_FMT_GRAYF32;
+s->half = 1;
} else if (s->type==1 || s->type==4) {
avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
} else if (s->type==2 || s->type==5) {
diff --git a/libavcodec/pnm.h b/libavcodec/pnm.h
index 89c3b5a2da..f109d16239 100644
--- a/libavcodec/pnm.h
+++ b/libavcodec/pnm.h
@@ -31,7 +31,12 @@ typedef struct PNMContext {
int maxval; ///< maximum value of a pixel
int type;
int endian;
+int half;
float scale;
+
+uint32_t mantissatable[2048];
+uint32_t exponenttable[64];
+uint16_t offsettable[64];
} PNMContext;
int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext * const s);
diff --git a/libavcodec/pnm_parser.c b/libavcodec/pnm_parser.c
index 309bc76a24..928b6dcd21 100644
--- a/libavcodec/pnm_parser.c
+++ b/libavcodec/pnm_parser.c
@@ -133,7 +133,8 @@ end:
const AVCodecParser ff_pnm_parser = {
.codec_ids = { AV_CODEC_ID_PGM, AV_COD
Re: [FFmpeg-devel] [PATCH 2/3] Provided support for MPEG-5 EVC (Essential Video Coding) codec
Quoting Dawid Kozinski (2022-06-22 08:49:04)
> - Added xeve encoder wrapper
> - Added xevd dencoder wrapper
> - Added documentation for xeve and xevd wrappers
> - Added parser for EVC format
> - Changes in project configuration file and libavcodec Makefile
>
> Signed-off-by: Dawid Kozinski
> ---
> configure | 8 +
> doc/decoders.texi | 24 ++
> doc/encoders.texi | 112 ++
> doc/general_contents.texi | 19 +
> libavcodec/Makefile | 3 +
> libavcodec/allcodecs.c| 2 +
> libavcodec/avcodec.h | 3 +
> libavcodec/evc_parser.c | 527 ++
> libavcodec/libxevd.c | 440 ++
> libavcodec/libxeve.c | 753 ++
> libavcodec/parsers.c | 1 +
> 11 files changed, 1892 insertions(+)
> create mode 100644 libavcodec/evc_parser.c
> create mode 100644 libavcodec/libxevd.c
> create mode 100644 libavcodec/libxeve.c
Numerous violations of our coding style, such as
- keywords (if, for, etc.) should be followed by a space before parentheses
- opening brace for blocks inside functions should be on the same line
as their keyword (if, for, etc.)
- useless extra parentheses in if()s
I will not point out each instance, please find and fix those.
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 1850c99fe9..245df680d2 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2892,6 +2892,118 @@ ffmpeg -i input -c:v libxavs2 -xavs2-params
> RdoqLevel=0 output.avs2
> @end example
> @end table
>
> +@section libxeve
> +
> +eXtra-fast Essential Video Encoder (XEVE) MPEG-5 EVC encoder wrapper.
> +
> +This encoder requires the presence of the libxeve headers and library
> +during configuration. You need to explicitly configure the build with
> +@option{--enable-libxeve}.
> +
> +@float NOTE
> +Many libxeve encoder options are mapped to FFmpeg global codec options,
> +while unique encoder options are provided through private options.
> +Additionally the xeve-params private options allows one to pass a list
> +of key=value tuples as accepted by the libxeve @code{parse_xeve_params}
> function.
> +@end float
> +
> +The xeve project website is at @url{https://github.com/mpeg5/xeve}.
> +
> +@subsection Options
> +
> +The following options are supported by the libxeve wrapper.
> +The xeve-equivalent options or values are listed in parentheses for easy
> migration.
> +
> +@float NOTE
> +To reduce the duplication of documentation, only the private options
> +and some others requiring special attention are documented here. For
> +the documentation of the undocumented generic options, see
> +@ref{codec-options,,the Codec Options chapter}.
> +@end float
> +
> +@float NOTE
> +To get a more accurate and extensive documentation of the libxeve options,
> +invoke the command @code{xeve_app --help} or consult the libxeve
> documentation.
> +@end float
> +
> +@table @option
> +@item b (@emph{bitrate})
> +Set target video bitrate in bits/s.
> +Note that FFmpeg’s b option is expressed in bits/s, while xeve’s bitrate
> is in kilobits/s.
Looks broken.
> diff --git a/libavcodec/libxeve.c b/libavcodec/libxeve.c
> new file mode 100644
> index 00..e115ce63d2
> --- /dev/null
> +++ b/libavcodec/libxeve.c
> +/**
> + * The structure stores all the states associated with the instance of Xeve
> MPEG-5 EVC encoder
> + */
> +typedef struct XeveContext {
> +const AVClass *class;
> +
> +XEVE id;// XEVE instance identifier
> +XEVE_CDSC cdsc; // coding parameters i.e profile, width & height of
> input frame, num of therads, frame rate ...
> +XEVE_BITB bitb; // bitstream buffer (output)
> +XEVE_STAT stat; // encoding status (output)
> +XEVE_IMGB imgb; // image buffer (input)
> +
> +State state;// encoder state (skipping, encoding, bumping)
> +
> +// Chroma subsampling
> +int width_luma;
> +int height_luma;
> +int width_chroma;
> +int height_chroma;
All these are only used in init, no need to store them in the context.
> +/**
> + * Gets Xeve pre-defined preset
> + *
> + * @param preset string describing Xeve encoder preset (fast, medium, slow,
> placebo)
> + * @return XEVE pre-defined profile on success, negative value on failure
> + */
> +static int get_preset_id(const char *preset)
> +{
> +if((!strcmp(preset, "fast")))
> +return XEVE_PRESET_FAST;
> +else if (!strcmp(preset, "medium"))
> +return XEVE_PRESET_MEDIUM;
> +else if (!strcmp(preset, "slow"))
> +return XEVE_PRESET_SLOW;
> +else if (!strcmp(preset, "placebo"))
> +return XEVE_PRESET_PLACEBO;
> +else
> +return AVERROR(EINVAL);
> +}
This parsing is unnecessary, change the relevant option into an int and
add named constants for it (see e.g. "coder" in libx264.c and many
others).
Same for tune.
> +/**
> + * Convert FFmpeg pixel format (AVPixelFormat) into XEVE pre-defined colo
Re: [FFmpeg-devel] [PATCH v2 1/2] avformat: add AVFormatContext.first_pkt_wallclock
Quoting Gyan Doshi (2022-06-28 08:40:58) > > > On 2022-06-28 10:43 am, Anton Khirnov wrote: > > Quoting Gyan Doshi (2022-06-25 10:29:50) > >> Stores wallclock time for the first packet received. > >> Used for crude sync offset among inputs. > >> --- > >> doc/APIchanges | 3 +++ > >> libavformat/avformat.h | 10 ++ > >> libavformat/demux.c| 3 +++ > >> libavformat/options.c | 1 + > >> libavformat/version.h | 2 +- > >> 5 files changed, 18 insertions(+), 1 deletion(-) > > Why should this be in the library? Seems to me this can be just as > > easily done by the callers who need it. > > To not add some extra latency, just like how > `use_wallclock_as_timestamps` was implemented inside lavf. Where would that extra latency come from? I see no reason for use_wallclock_as_timestamps to exist either, it can just as well be used from ffmpeg.c or whatever caller needs it. -- Anton Khirnov ___ 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 2/2] ffmpeg: add option -isync
Quoting Gyan Doshi (2022-06-25 10:29:51) > This is a per-file input option that adjusts an input's timestamps > with reference to another input, so that emitted packet timestamps > account for the difference between the start times of the two inputs. > > Typical use case is to sync two or more live inputs such as from capture > devices. Both the target and reference input source timestamps should be > based on the same clock source. If both streams are using the same clock, then why is any extra synchronization needed? -- Anton Khirnov ___ 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 2/2] ffmpeg: add option -isync
On 2022-07-01 03:33 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-06-25 10:29:51) This is a per-file input option that adjusts an input's timestamps with reference to another input, so that emitted packet timestamps account for the difference between the start times of the two inputs. Typical use case is to sync two or more live inputs such as from capture devices. Both the target and reference input source timestamps should be based on the same clock source. If both streams are using the same clock, then why is any extra synchronization needed? Because ffmpeg.c normalizes timestamps by default. We can keep timestamps using -copyts, but these inputs are usually preprocessed using single-input filters which won't have access to the reference inputs, or the merge filters like e.g. amix don't sync by timestamp. What this option does is allow keeping 0-start timestamps but offset the target input relatively. Then it's possible to filter/merge in sync. Regards, 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".
[FFmpeg-devel] [PATCH 1/2] avcodec/cbs: Add specialization for ff_cbs_(read|write)_unsigned()
These functions allow not only to read and write unsigned values,
but also to check ranges and to emit trace output which can be
beautified when processing arrays (indices like "[i]" are replaced
by their actual numbers).
Yet lots of callers actually only need something simpler:
Their range is only implicitly restricted by the amount
of bits used and they are not part of arrays, hence don't
need this beautification.
This commit adds specializations for these callers;
this is very beneficial size-wise (it reduced the size
of .text by 14928 bytes here), as a call is now cheaper.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs.c | 34 ++
libavcodec/cbs_av1.c | 28 +++-
libavcodec/cbs_h2645.c| 15 +--
libavcodec/cbs_internal.h | 11 ++-
libavcodec/cbs_mpeg2.c| 15 +--
libavcodec/cbs_vp9.c | 14 --
6 files changed, 97 insertions(+), 20 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index e829caa0a0..8bd63aa831 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -536,10 +536,13 @@ void ff_cbs_trace_syntax_element(CodedBitstreamContext
*ctx, int position,
position, name, pad, bits, value);
}
-int ff_cbs_read_unsigned(CodedBitstreamContext *ctx, GetBitContext *gbc,
- int width, const char *name,
- const int *subscripts, uint32_t *write_to,
- uint32_t range_min, uint32_t range_max)
+static av_always_inline int cbs_read_unsigned(CodedBitstreamContext *ctx,
+ GetBitContext *gbc,
+ int width, const char *name,
+ const int *subscripts,
+ uint32_t *write_to,
+ uint32_t range_min,
+ uint32_t range_max)
{
uint32_t value;
int position;
@@ -579,6 +582,22 @@ int ff_cbs_read_unsigned(CodedBitstreamContext *ctx,
GetBitContext *gbc,
return 0;
}
+int ff_cbs_read_unsigned(CodedBitstreamContext *ctx, GetBitContext *gbc,
+ int width, const char *name,
+ const int *subscripts, uint32_t *write_to,
+ uint32_t range_min, uint32_t range_max)
+{
+return cbs_read_unsigned(ctx, gbc, width, name, subscripts,
+ write_to, range_min, range_max);
+}
+
+int ff_cbs_read_simple_unsigned(CodedBitstreamContext *ctx, GetBitContext *gbc,
+int width, const char *name, uint32_t
*write_to)
+{
+return cbs_read_unsigned(ctx, gbc, width, name, NULL,
+ write_to, 0, UINT32_MAX);
+}
+
int ff_cbs_write_unsigned(CodedBitstreamContext *ctx, PutBitContext *pbc,
int width, const char *name,
const int *subscripts, uint32_t value,
@@ -615,6 +634,13 @@ int ff_cbs_write_unsigned(CodedBitstreamContext *ctx,
PutBitContext *pbc,
return 0;
}
+int ff_cbs_write_simple_unsigned(CodedBitstreamContext *ctx, PutBitContext
*pbc,
+ int width, const char *name, uint32_t value)
+{
+return ff_cbs_write_unsigned(ctx, pbc, width, name, NULL,
+ value, 0, MAX_UINT_BITS(width));
+}
+
int ff_cbs_read_signed(CodedBitstreamContext *ctx, GetBitContext *gbc,
int width, const char *name,
const int *subscripts, int32_t *write_to,
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 1229480567..114d8580b3 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -412,9 +412,8 @@ static int cbs_av1_read_subexp(CodedBitstreamContext *ctx,
GetBitContext *gbc,
}
if (len < max_len) {
-err = ff_cbs_read_unsigned(ctx, gbc, range_bits,
- "subexp_bits", NULL, &value,
- 0, MAX_UINT_BITS(range_bits));
+err = ff_cbs_read_simple_unsigned(ctx, gbc, range_bits,
+ "subexp_bits", &value);
if (err < 0)
return err;
@@ -476,10 +475,9 @@ static int cbs_av1_write_subexp(CodedBitstreamContext
*ctx, PutBitContext *pbc,
return err;
if (len < max_len) {
-err = ff_cbs_write_unsigned(ctx, pbc, range_bits,
-"subexp_bits", NULL,
-value - range_offset,
-0, MAX_UINT_BITS(range_bits));
+err = ff_cbs_write_simple_unsigned(ctx, pbc, range_bits,
+ "subexp_bits",
+ value - range_offset);
if (err < 0)
return err;
@@ -546,8 +544,6 @@ static size_t
Re: [FFmpeg-devel] [PATCH v2 01/18] avcodec/pthread_slice: Don't reinitialise initialised mutex
Quoting Andreas Rheinhardt (2022-06-30 23:48:00) > It results in undefined behaviour. Instead initialize the mutexes > and condition variables once during init (and check these > initializations). > > Also combine the corresponding mutex and condition variable > into one structure so that one can allocate their array > jointly. > > Signed-off-by: Andreas Rheinhardt > --- > Now also adding the fallback function in case threads are disabled. LGTM -- Anton Khirnov ___ 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] avcodec/cbs: Mark init and close functions as av_cold
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 8bd63aa831..0a9fda8469 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -73,8 +73,8 @@ const enum AVCodecID ff_cbs_all_codec_ids[] = {
AV_CODEC_ID_NONE
};
-int ff_cbs_init(CodedBitstreamContext **ctx_ptr,
-enum AVCodecID codec_id, void *log_ctx)
+av_cold int ff_cbs_init(CodedBitstreamContext **ctx_ptr,
+enum AVCodecID codec_id, void *log_ctx)
{
CodedBitstreamContext *ctx;
const CodedBitstreamType *type;
@@ -118,13 +118,13 @@ int ff_cbs_init(CodedBitstreamContext **ctx_ptr,
return 0;
}
-void ff_cbs_flush(CodedBitstreamContext *ctx)
+av_cold void ff_cbs_flush(CodedBitstreamContext *ctx)
{
if (ctx->codec->flush)
ctx->codec->flush(ctx);
}
-void ff_cbs_close(CodedBitstreamContext **ctx_ptr)
+av_cold void ff_cbs_close(CodedBitstreamContext **ctx_ptr)
{
CodedBitstreamContext *ctx = *ctx_ptr;
@@ -168,7 +168,7 @@ void ff_cbs_fragment_reset(CodedBitstreamFragment *frag)
frag->data_bit_padding = 0;
}
-void ff_cbs_fragment_free(CodedBitstreamFragment *frag)
+av_cold void ff_cbs_fragment_free(CodedBitstreamFragment *frag)
{
ff_cbs_fragment_reset(frag);
--
2.34.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 v2 1/2] avformat: add AVFormatContext.first_pkt_wallclock
On 2022-07-01 03:20 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-06-28 08:40:58) On 2022-06-28 10:43 am, Anton Khirnov wrote: Quoting Gyan Doshi (2022-06-25 10:29:50) Stores wallclock time for the first packet received. Used for crude sync offset among inputs. --- doc/APIchanges | 3 +++ libavformat/avformat.h | 10 ++ libavformat/demux.c| 3 +++ libavformat/options.c | 1 + libavformat/version.h | 2 +- 5 files changed, 18 insertions(+), 1 deletion(-) Why should this be in the library? Seems to me this can be just as easily done by the callers who need it. To not add some extra latency, just like how `use_wallclock_as_timestamps` was implemented inside lavf. Where would that extra latency come from? The interval between its current assigment inside ff_read_packet() and the chance for assignment in process_input() in ffmpeg.c Regards, 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 07/18] avcodec/hevc_mvs: Pass HEVCLocalContext when slice-threading
Quoting Andreas Rheinhardt (2022-07-01 00:29:38) > The HEVC decoder has both HEVCContext and HEVCLocalContext > structures. The latter is supposed to be the structure > containing the per-slicethread state. > > Yet that is not how it is handled in practice: Each HEVCLocalContext > has a unique HEVCContext allocated for it and each of these > coincides except in exactly one field: The corresponding > HEVCLocalContext. This makes it possible to pass the HEVCContext > everywhere where logically a HEVCLocalContext should be used. > > This commit stops doing this for lavc/hevc_mvs.c; it also constifies > everything that is possible in order to ensure that no slice thread > accidentally modifies the main HEVCContext state. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/hevc_mvs.c | 56 +-- > libavcodec/hevcdec.c | 27 +++-- > libavcodec/hevcdec.h | 6 ++--- > 3 files changed, 45 insertions(+), 44 deletions(-) Looks very reasonable -- Anton Khirnov ___ 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 17/18] avcodec/pthread_slice: Reuse buffer if possible
On Fri, Jul 1, 2022 at 12:32 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/pthread_slice.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
> index 756cc59dbf..a4d31c6f4d 100644
> --- a/libavcodec/pthread_slice.c
> +++ b/libavcodec/pthread_slice.c
> @@ -242,9 +242,11 @@ int ff_slice_thread_allocz_entries(AVCodecContext
> *avctx, int count)
> if (avctx->active_thread_type & FF_THREAD_SLICE) {
> SliceThreadContext *p = avctx->internal->thread_ctx;
>
> -if (p->entries) {
> -av_freep(&p->entries);
> +if (p->entries_count == count) {
> +memset(p->entries, 0, p->entries_count * sizeof(*p->entries));
> +return 0;
> }
> +av_freep(&p->entries);
>
> p->entries = av_calloc(count, sizeof(*p->entries));
> if (!p->entries) {
> --
> 2.34.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 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 09/18] avcodec/hevcdec: Add stat_coeffs to HEVCABACState
Quoting Andreas Rheinhardt (2022-07-01 00:29:40)
> diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
> index e2dba54f26..b97b7d1354 100644
> --- a/libavcodec/hevcdec.h
> +++ b/libavcodec/hevcdec.h
> @@ -226,6 +226,11 @@ enum ScanType {
> SCAN_VERT,
> };
>
> +typedef struct HEVCCABACState {
> +uint8_t state[HEVC_CONTEXTS];
> +uint8_t stat_coeff[HEVC_STAT_COEFFS];
> +} HEVCCABACState;
Might be good to mention why this is allocated separately from
HEVCContext.
Otherwise patch looks good.
--
Anton Khirnov
___
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 17/18] avcodec/pthread_slice: Reuse buffer if possible
fre 2022-07-01 klockan 00:29 +0200 skrev Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/pthread_slice.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
> index 756cc59dbf..a4d31c6f4d 100644
> --- a/libavcodec/pthread_slice.c
> +++ b/libavcodec/pthread_slice.c
> @@ -242,9 +242,11 @@ int
> ff_slice_thread_allocz_entries(AVCodecContext *avctx, int count)
> if (avctx->active_thread_type & FF_THREAD_SLICE) {
> SliceThreadContext *p = avctx->internal->thread_ctx;
>
> - if (p->entries) {
> - av_freep(&p->entries);
> + if (p->entries_count == count) {
> + memset(p->entries, 0, p->entries_count * sizeof(*p-
> >entries));
> + return 0;
Couldn't this trivially handle p->entries_count < count also?
> }
> + av_freep(&p->entries);
>
> p->entries = av_calloc(count, sizeof(*p->entries));
> if (!p->entries) {
Looks like we could use an av_fast_calloc()
/Tomas
___
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 01/18] avcodec/pthread_slice: Don't reinitialise initialised mutex
tor 2022-06-30 klockan 23:48 +0200 skrev Andreas Rheinhardt: > It results in undefined behaviour. Instead initialize the mutexes > and condition variables once during init (and check these > initializations). > > Also combine the corresponding mutex and condition variable > into one structure so that one can allocate their array > jointly. > Makes the code simpler to boot. Nice! Passes FATE and works with the threading patch I have on here as well. THREAD_TYPE=slice THREADS=4 and THREAD_TYPE=slice THREADS=1 /Tomas ___ 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 0/4] add ARIB caption decoder using libaribcaption
In aribcaption_close() (libaribcaption.c):
```
if (ctx->renderer) {
aribcc_renderer_free(ctx->renderer);
ctx->decoder = NULL;
}
```
This should be `ctx->renderer = NULL;`.
In set_ass_header() (libaribcaption.c):
```
if (fonts && *fonts) {
font_name = av_get_token(&fonts, ",");
if (!font_name)
return AVERROR(ENOMEM);
} else
font_name = av_strdup(DEFAULT_FONT_FAMILY);
```
You should reposition `if (!font_name) return AVERROR(ENOMEM);`, because
av_strdup() can also return NULL.
On some "return"s in aribcaption_init(), I think you have forgotten
aribcaption_close(avctx).
I have tested the features of this patch using some sample files. As you
recommend, the files under https://streams.videolan.org/streams/ts/ARIB/
are good samples. In particular,
https://streams.videolan.org/streams/ts/ARIB/japan/osaka_15.ts uses
various subtitle expressions, I like it.
# ASS formatted text
$ ffmpeg -fix_sub_duration -i osaka_15.ts osaka_15.ass
I think the created ASS by the above command is much better than that of
aribb24. (Erase timing for each subtitle of aribb24 was very
inaccurate.) Then, it's trivial, but is there any reason to set the
default "Alignment" to 2 and always override it with "{\an7}"? I think
the default "Alignment" should be 7.
# Overlay subtitles on the video
$ ffmpeg -sub_type bitmap -i osaka_15.ts -filter_complex
"[0:v][0:s]overlay" -s 1280x720 osaka_15.mp4
The bitmap feature is a cool one. Its output quality is the same as the
subtitles I usually watch on Japanese TV devices. I tested the feature
with many personal files, no particular problem found.
Mao Hata
On 2022/06/24 19:06, TADANO Tokumei wrote:
3rd ping!
Are there any other objections to this patch set?
If not, would someone push it to the repository?
A comment inline:
On 2022/06/17 0:30, TADANO Tokumei wrote:
On 2022/06/16 22:40, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
TADANO Tokumei
Sent: Thursday, June 16, 2022 3:23 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v4 0/4] add ARIB caption decoder
using libaribcaption
ping again!
Are there any objections to this patch set?
If not, would someone push it to the repository?
On 2022/06/08 18:48, TADANO Tokumei wrote:
ping
The patch set has been well tested by Japanese ISDB-related
developers and works fine.
I think it already has good quality to merge.
It requires external library like libaribb24, but the feature is
disabled by default.
There is no impact to current code without `--enable-
libaribcaption` option is
specified at configuration. The patch set provide better subtitle
feature
for ISDB users than libaribb24 if enabled.
What exactly is better than with the other ARIB decoder?
On 2022/05/30 23:55, TADANO Tokumei wrote:
This patch set add another ARIB caption decoder using
libaribcaption
external library: https://github.com/xqq/libaribcaption
The library decodes subtitles of ISDB-based TV broadcasting.
It is not only for Japanese ARIB STD-B24 caption, but also for
Brazilian ABNT NBR 15606-1 and Philippines version of ISDB-T.
Unlike libaribb24, it supports 3 types of subtitle outputs:
* text: plain text
* ass: ASS formatted text
* bitmap: bitmap image
This will become obsolete with the introduction of subtitle
filtering (https://github.com/ffstaging/FFmpeg/pull/18).
The subtitle filtering is not ready yet.
There is no reason to prevent to apply this patch set.
After the subtitle filtering will be ready, I can modify it to follow
new API.
Just recently, Traian has joined and contributed a filter
for converting text subtitles to graphic subtitles
(https://github.com/softworkz/FFmpeg/pull/1), which fills
the last remaining gap for subtitle conversions.
Is this the only advantage over the existing ARIB caption decoder?
The existing ARIB caption decoder (libaribb24) has lower reproducibility.
For example, it lacks position information that is in original ARIB
caption data.
With this patch set, the intended caption is almost reproduced as ARIB
standard
states.
Thanks,
TADANO
Thanks,
sw
___
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/2] avutil/channel_layout: av_channel_layout_describe_bprint: Check for buffer end
Fixes: Timeout printing a billion channels
Fixes:
48099/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-6754782204788736
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavutil/channel_layout.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 21b70173b7..72969eff14 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -757,6 +757,10 @@ int av_channel_layout_describe_bprint(const
AVChannelLayout *channel_layout,
if (channel_layout->order == AV_CHANNEL_ORDER_CUSTOM &&
channel_layout->u.map[i].name[0])
av_bprintf(bp, "@%s", channel_layout->u.map[i].name);
+
+if (!av_bprint_is_complete(bp))
+return AVERROR(EINVAL);
+
}
if (channel_layout->nb_channels) {
av_bprintf(bp, ")");
--
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] avcodec/tiff: Check pixel format types for dng
Fixes: out of array access
Fixes:
48271/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-6149705769287680
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index e4a5d3c537..bf69b083b3 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -761,6 +761,7 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
if (s->is_bayer) {
av_assert0(width == (s->bpp * s->width + 7) >> 3);
}
+av_assert0(!(s->is_bayer && is_yuv));
if (p->format == AV_PIX_FMT_GRAY12) {
av_fast_padded_malloc(&s->yuv_line, &s->yuv_line_size, width);
if (s->yuv_line == NULL) {
@@ -844,6 +845,8 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
av_log(s->avctx, AV_LOG_ERROR, "More than one DNG JPEG strips
unsupported\n");
return AVERROR_PATCHWELCOME;
}
+if (!s->is_bayer)
+return AVERROR_PATCHWELCOME;
if ((ret = dng_decode_jpeg(s->avctx, p, s->stripsize, 0, 0, s->width,
s->height)) < 0)
return ret;
return 0;
--
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 1/2] avutil/channel_layout: av_channel_layout_describe_bprint: Check for buffer end
On 7/1/2022 4:25 PM, Michael Niedermayer wrote:
Fixes: Timeout printing a billion channels
Fixes:
48099/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-6754782204788736
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavutil/channel_layout.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 21b70173b7..72969eff14 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -757,6 +757,10 @@ int av_channel_layout_describe_bprint(const
AVChannelLayout *channel_layout,
if (channel_layout->order == AV_CHANNEL_ORDER_CUSTOM &&
channel_layout->u.map[i].name[0])
av_bprintf(bp, "@%s", channel_layout->u.map[i].name);
+
+if (!av_bprint_is_complete(bp))
+return AVERROR(EINVAL);
Should be ENOMEM.
LGTM with that change.
+
}
if (channel_layout->nb_channels) {
av_bprintf(bp, ")");
___
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] fftools/ffmpeg_filter: Fix audio_drift_threshold check
On Thu, Jun 30, 2022 at 10:55:46AM +0200, Anton Khirnov wrote: > Variant 2 is less bad, but the whole check seems hacky to me, since it > seems to make assumptions about swr defaults > > Won't setting this unconditionally have the same effect? it has the same effect but its not so nice to the user to recommand extra arguments which make no difference thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle 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] libavcodec/mpegvideo_enc: Fix a chroma mb size error in sse_mb()
On Fri, Jul 01, 2022 at 01:34:34PM +0800, Wenbin Chen wrote:
> For 422 frames we should not use hard coded 8 to calculate mb size for
> uv plane. Chroma shift should be taken into consideration to be
> compatiple with different sampling format.
>
> The error is reported by fate test when av_cpu_max_align() return 64
> on the platform supporting AVX512. This is a hidden error and it is
> exposed after commit 17a59a634c39b00a680c6ebbaea58db95594d13d.
>
> mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum of
> squared error) on current mb, reconstructed mb will be wrote to the
> previous mb space, so that the memory can be saved. However if the align
> is 64, the frame is shared in somewhere else, so the frame cannot be
> reused and a new frame to store reconstrued data is created. Because the
> height of mb is wrong when compute sse on 422 frame, starting from the
> second line of macro block, changed data is read when frame is reused
> (we need to read row 16 rather than row 8 if frame is 422), and unchanged
> data is read when frame is not reused (a new frame is created so the
> original frame will not be changed).
>
> That is why commit 17a59a634c39b00a680c6ebbaea58db95594d13d exposes this
> issue, because it add av_cpu_max_align() and this function return 64 on
> platform supporting AVX512 which lead to creating a frame in mpeg2enc,
> and this lead to the different outputs.
>
> Signed-off-by: Wenbin Chen
> ---
> libavcodec/mpegvideo_enc.c | 29 +--
> tests/ref/seek/vsynth_lena-mpeg2-422 | 40 +-
> tests/ref/vsynth/vsynth1-mpeg2-422 | 8 +++---
> tests/ref/vsynth/vsynth2-mpeg2-422 | 8 +++---
> tests/ref/vsynth/vsynth3-mpeg2-422 | 8 +++---
> tests/ref/vsynth/vsynth_lena-mpeg2-422 | 8 +++---
> 6 files changed, 56 insertions(+), 45 deletions(-)
>
> diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> index d6a85a037a..c9d9e2a764 100644
> --- a/libavcodec/mpegvideo_enc.c
> +++ b/libavcodec/mpegvideo_enc.c
> @@ -2558,24 +2558,35 @@ static int sse(MpegEncContext *s, uint8_t *src1,
> uint8_t *src2, int w, int h, in
> static int sse_mb(MpegEncContext *s){
> int w= 16;
> int h= 16;
> +int chroma_mb_w = w >> s->chroma_x_shift;
> +int chroma_mb_h = h >> s->chroma_y_shift;
>
> if(s->mb_x*16 + 16 > s->width ) w= s->width - s->mb_x*16;
> if(s->mb_y*16 + 16 > s->height) h= s->height- s->mb_y*16;
>
> if(w==16 && h==16)
>if(s->avctx->mb_cmp == FF_CMP_NSSE){
> -return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x * 16 +
> s->mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> +return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x * 16 +
> s->mb_y * s->linesize * 16,
> + s->dest[0], s->linesize, 16) +
This doesnt belong in this patch, its not a functional change and makes it
harder to see what is changed
please seperate this in a seperate patch if you want to suggest this whitespace
change
thx
> - s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x * 8 +
> s->mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> - s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x * 8 +
> s->mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> + s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x *
> chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[1], s->uvlinesize, chroma_mb_h) +
> + s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x *
> chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[2], s->uvlinesize, chroma_mb_h);
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
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 v5 0/6] Implement SEI parsing for QSV decoders
Missing SEI information has always been a major drawback when using the QSV decoders. I used to think that there's no chance to get at the data without explicit implementation from the MSDK side (or doing something weird like parsing in parallel). It turned out that there's a hardly known api method that provides access to all SEI (h264/hevc) or user data (mpeg2video). This allows to get things like closed captions, frame packing, display orientation, HDR data (mastering display, content light level, etc.) without having to rely on those data being provided by the MSDK as extended buffers. The commit "Implement SEI parsing for QSV decoders" includes some hard-coded workarounds for MSDK bugs which I reported: https://github.com/Intel-Media-SDK/MediaSDK/issues/2597#issuecomment-1072795311 But that doesn't help. Those bugs exist and I'm sharing my workarounds, which are empirically determined by testing a range of files. If someone is interested, I can provide private access to a repository where we have been testing this. Alternatively, I could also leave those workarounds out, and just skip those SEI types. In a previous version of this patchset, there was a concern that payload data might need to be re-ordered. Meanwhile I have researched this carefully and the conclusion is that this is not required. My detailed analysis can be found here: https://gist.github.com/softworkz/36c49586a8610813a32270ee3947a932 v4 * add new dependencies in makefile Now, build still works when someone uses configure --disable-decoder=h264 --disable-decoder=hevc --disable-decoder=mpegvideo --disable-decoder=mpeg1video --disable-decoder=mpeg2video --enable-libmfx v3 * frame.h: clarify doc text for av_frame_copy_side_data() v2 * qsvdec: make error handling consistent and clear * qsvdec: remove AV_CODEC_ID_MPEG1VIDEO constants * hevcdec: rename function to ff_hevc_set_side_data(), add doc text v3 * qsvdec: fix c/p error softworkz (6): avutil/frame: Add av_frame_copy_side_data() and av_frame_remove_all_side_data() avcodec/vpp_qsv: Copy side data from input to output frame avcodec/mpeg12dec: make mpeg_decode_user_data() accessible avcodec/hevcdec: make set_side_data() accessible avcodec/h264dec: make h264_export_frame_props() accessible avcodec/qsvdec: Implement SEI parsing for QSV decoders doc/APIchanges | 4 + libavcodec/Makefile | 6 +- libavcodec/h264_slice.c | 98 --- libavcodec/h264dec.h | 2 + libavcodec/hevcdec.c | 117 +- libavcodec/hevcdec.h | 9 ++ libavcodec/hevcdsp.c | 4 + libavcodec/mpeg12.h | 28 + libavcodec/mpeg12dec.c | 40 +- libavcodec/qsvdec.c | 234 +++ libavfilter/qsvvpp.c | 6 + libavfilter/vf_overlay_qsv.c | 19 ++- libavutil/frame.c| 67 ++ libavutil/frame.h| 32 + libavutil/version.h | 2 +- 15 files changed, 494 insertions(+), 174 deletions(-) base-commit: 6a82412bf33108111eb3f63076fd5a51349ae114 Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-31%2Fsoftworkz%2Fsubmit_qsv_sei-v5 Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-31/softworkz/submit_qsv_sei-v5 Pull-Request: https://github.com/ffstaging/FFmpeg/pull/31 Range-diff vs v4: 1: 7656477360 = 1: 7656477360 avutil/frame: Add av_frame_copy_side_data() and av_frame_remove_all_side_data() 2: 06976606c5 = 2: 06976606c5 avcodec/vpp_qsv: Copy side data from input to output frame 3: 320a8a535c = 3: 320a8a535c avcodec/mpeg12dec: make mpeg_decode_user_data() accessible 4: e58ad6564f = 4: e58ad6564f avcodec/hevcdec: make set_side_data() accessible 5: a57bfaebb9 = 5: 4c0b6eb4cb avcodec/h264dec: make h264_export_frame_props() accessible 6: 3f2588563e ! 6: 19bc00be4d avcodec/qsvdec: Implement SEI parsing for QSV decoders @@ Commit message Signed-off-by: softworkz + ## libavcodec/Makefile ## +@@ libavcodec/Makefile: OBJS-$(CONFIG_MSS34DSP)+= mss34dsp.o + OBJS-$(CONFIG_PIXBLOCKDSP) += pixblockdsp.o + OBJS-$(CONFIG_QPELDSP) += qpeldsp.o + OBJS-$(CONFIG_QSV) += qsv.o +-OBJS-$(CONFIG_QSVDEC) += qsvdec.o ++OBJS-$(CONFIG_QSVDEC) += qsvdec.o h264_slice.o h264_cabac.o h264_cavlc.o \ ++ h264_direct.o h264_mb.o h264_picture.o h264_loopfilter.o \ ++ h264dec.o h264_refs.o cabac.o hevcdec.o hevc_refs.o \ ++ hevc_filter.o hevc_cabac.o hevc_mvs.o hevcpred.o hevcdsp.o \ ++ h274.o dovi_rpu.o mpeg12dec.o + OBJS-$(CONFIG_Q
[FFmpeg-devel] [PATCH v5 4/6] avcodec/hevcdec: make set_side_data() accessible
From: softworkz
Signed-off-by: softworkz
---
libavcodec/hevcdec.c | 117 +--
libavcodec/hevcdec.h | 9
2 files changed, 67 insertions(+), 59 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index e84c30dd13..b4d8db8c6b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2726,23 +2726,22 @@ error:
return res;
}
-static int set_side_data(HEVCContext *s)
+int ff_hevc_set_side_data(AVCodecContext *logctx, HEVCSEI *sei, HEVCContext
*s, AVFrame *out)
{
-AVFrame *out = s->ref->frame;
-int ret;
+int ret = 0;
-if (s->sei.frame_packing.present &&
-s->sei.frame_packing.arrangement_type >= 3 &&
-s->sei.frame_packing.arrangement_type <= 5 &&
-s->sei.frame_packing.content_interpretation_type > 0 &&
-s->sei.frame_packing.content_interpretation_type < 3) {
+if (sei->frame_packing.present &&
+sei->frame_packing.arrangement_type >= 3 &&
+sei->frame_packing.arrangement_type <= 5 &&
+sei->frame_packing.content_interpretation_type > 0 &&
+sei->frame_packing.content_interpretation_type < 3) {
AVStereo3D *stereo = av_stereo3d_create_side_data(out);
if (!stereo)
return AVERROR(ENOMEM);
-switch (s->sei.frame_packing.arrangement_type) {
+switch (sei->frame_packing.arrangement_type) {
case 3:
-if (s->sei.frame_packing.quincunx_subsampling)
+if (sei->frame_packing.quincunx_subsampling)
stereo->type = AV_STEREO3D_SIDEBYSIDE_QUINCUNX;
else
stereo->type = AV_STEREO3D_SIDEBYSIDE;
@@ -2755,21 +2754,21 @@ static int set_side_data(HEVCContext *s)
break;
}
-if (s->sei.frame_packing.content_interpretation_type == 2)
+if (sei->frame_packing.content_interpretation_type == 2)
stereo->flags = AV_STEREO3D_FLAG_INVERT;
-if (s->sei.frame_packing.arrangement_type == 5) {
-if (s->sei.frame_packing.current_frame_is_frame0_flag)
+if (sei->frame_packing.arrangement_type == 5) {
+if (sei->frame_packing.current_frame_is_frame0_flag)
stereo->view = AV_STEREO3D_VIEW_LEFT;
else
stereo->view = AV_STEREO3D_VIEW_RIGHT;
}
}
-if (s->sei.display_orientation.present &&
-(s->sei.display_orientation.anticlockwise_rotation ||
- s->sei.display_orientation.hflip ||
s->sei.display_orientation.vflip)) {
-double angle = s->sei.display_orientation.anticlockwise_rotation * 360
/ (double) (1 << 16);
+if (sei->display_orientation.present &&
+(sei->display_orientation.anticlockwise_rotation ||
+ sei->display_orientation.hflip || sei->display_orientation.vflip)) {
+double angle = sei->display_orientation.anticlockwise_rotation * 360 /
(double) (1 << 16);
AVFrameSideData *rotation = av_frame_new_side_data(out,
AV_FRAME_DATA_DISPLAYMATRIX,
sizeof(int32_t) *
9);
@@ -2788,17 +2787,17 @@ static int set_side_data(HEVCContext *s)
* (1 - 2 * !!s->sei.display_orientation.vflip);
av_display_rotation_set((int32_t *)rotation->data, angle);
av_display_matrix_flip((int32_t *)rotation->data,
- s->sei.display_orientation.hflip,
- s->sei.display_orientation.vflip);
+ sei->display_orientation.hflip,
+ sei->display_orientation.vflip);
}
// Decrement the mastering display flag when IRAP frame has
no_rasl_output_flag=1
// so the side data persists for the entire coded video sequence.
-if (s->sei.mastering_display.present > 0 &&
+if (s && sei->mastering_display.present > 0 &&
IS_IRAP(s) && s->no_rasl_output_flag) {
-s->sei.mastering_display.present--;
+sei->mastering_display.present--;
}
-if (s->sei.mastering_display.present) {
+if (sei->mastering_display.present) {
// HEVC uses a g,b,r ordering, which we convert to a more natural r,g,b
const int mapping[3] = {2, 0, 1};
const int chroma_den = 5;
@@ -2811,25 +2810,25 @@ static int set_side_data(HEVCContext *s)
for (i = 0; i < 3; i++) {
const int j = mapping[i];
-metadata->display_primaries[i][0].num =
s->sei.mastering_display.display_primaries[j][0];
+metadata->display_primaries[i][0].num =
sei->mastering_display.display_primaries[j][0];
metadata->display_primaries[i][0].den = chroma_den;
-metadata->display_primaries[i][1].num =
s->sei.mastering_display.display_primaries[j][1];
+metadata->display_primaries[i][1].num =
sei->mastering_display.display_primaries[j][1];
[FFmpeg-devel] [PATCH v5 5/6] avcodec/h264dec: make h264_export_frame_props() accessible
From: softworkz
Signed-off-by: softworkz
---
libavcodec/h264_slice.c | 98 +
libavcodec/h264dec.h| 2 +
2 files changed, 52 insertions(+), 48 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index d56722a5c2..f2a4c1c657 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1157,11 +1157,10 @@ static int h264_init_ps(H264Context *h, const
H264SliceContext *sl, int first_sl
return 0;
}
-static int h264_export_frame_props(H264Context *h)
+int ff_h264_export_frame_props(AVCodecContext *logctx, H264SEIContext *sei,
H264Context *h, AVFrame *out)
{
-const SPS *sps = h->ps.sps;
-H264Picture *cur = h->cur_pic_ptr;
-AVFrame *out = cur->f;
+const SPS *sps = h ? h->ps.sps : NULL;
+H264Picture *cur = h ? h->cur_pic_ptr : NULL;
out->interlaced_frame = 0;
out->repeat_pict = 0;
@@ -1169,19 +1168,19 @@ static int h264_export_frame_props(H264Context *h)
/* Signal interlacing information externally. */
/* Prioritize picture timing SEI information over used
* decoding process if it exists. */
-if (h->sei.picture_timing.present) {
-int ret = ff_h264_sei_process_picture_timing(&h->sei.picture_timing,
sps,
- h->avctx);
+if (sps && sei->picture_timing.present) {
+int ret = ff_h264_sei_process_picture_timing(&sei->picture_timing, sps,
+ logctx);
if (ret < 0) {
-av_log(h->avctx, AV_LOG_ERROR, "Error processing a picture timing
SEI\n");
-if (h->avctx->err_recognition & AV_EF_EXPLODE)
+av_log(logctx, AV_LOG_ERROR, "Error processing a picture timing
SEI\n");
+if (logctx->err_recognition & AV_EF_EXPLODE)
return ret;
-h->sei.picture_timing.present = 0;
+sei->picture_timing.present = 0;
}
}
-if (sps->pic_struct_present_flag && h->sei.picture_timing.present) {
-H264SEIPictureTiming *pt = &h->sei.picture_timing;
+if (h && sps && sps->pic_struct_present_flag &&
sei->picture_timing.present) {
+H264SEIPictureTiming *pt = &sei->picture_timing;
switch (pt->pic_struct) {
case H264_SEI_PIC_STRUCT_FRAME:
break;
@@ -1215,21 +1214,23 @@ static int h264_export_frame_props(H264Context *h)
if ((pt->ct_type & 3) &&
pt->pic_struct <= H264_SEI_PIC_STRUCT_BOTTOM_TOP)
out->interlaced_frame = (pt->ct_type & (1 << 1)) != 0;
-} else {
+} else if (h) {
/* Derive interlacing flag from used decoding process. */
out->interlaced_frame = FIELD_OR_MBAFF_PICTURE(h);
}
-h->prev_interlaced_frame = out->interlaced_frame;
-if (cur->field_poc[0] != cur->field_poc[1]) {
+if (h)
+h->prev_interlaced_frame = out->interlaced_frame;
+
+if (sps && cur->field_poc[0] != cur->field_poc[1]) {
/* Derive top_field_first from field pocs. */
out->top_field_first = cur->field_poc[0] < cur->field_poc[1];
-} else {
-if (sps->pic_struct_present_flag && h->sei.picture_timing.present) {
+} else if (sps) {
+if (sps->pic_struct_present_flag && sei->picture_timing.present) {
/* Use picture timing SEI information. Even if it is a
* information of a past frame, better than nothing. */
-if (h->sei.picture_timing.pic_struct ==
H264_SEI_PIC_STRUCT_TOP_BOTTOM ||
-h->sei.picture_timing.pic_struct ==
H264_SEI_PIC_STRUCT_TOP_BOTTOM_TOP)
+if (sei->picture_timing.pic_struct ==
H264_SEI_PIC_STRUCT_TOP_BOTTOM ||
+sei->picture_timing.pic_struct ==
H264_SEI_PIC_STRUCT_TOP_BOTTOM_TOP)
out->top_field_first = 1;
else
out->top_field_first = 0;
@@ -1243,11 +1244,11 @@ static int h264_export_frame_props(H264Context *h)
}
}
-if (h->sei.frame_packing.present &&
-h->sei.frame_packing.arrangement_type <= 6 &&
-h->sei.frame_packing.content_interpretation_type > 0 &&
-h->sei.frame_packing.content_interpretation_type < 3) {
-H264SEIFramePacking *fp = &h->sei.frame_packing;
+if (sei->frame_packing.present &&
+sei->frame_packing.arrangement_type <= 6 &&
+sei->frame_packing.content_interpretation_type > 0 &&
+sei->frame_packing.content_interpretation_type < 3) {
+H264SEIFramePacking *fp = &sei->frame_packing;
AVStereo3D *stereo = av_stereo3d_create_side_data(out);
if (stereo) {
switch (fp->arrangement_type) {
@@ -1289,11 +1290,11 @@ static int h264_export_frame_props(H264Context *h)
}
}
-if (h->sei.display_orientation.present &&
-(h->sei.display_orientation.anticlockwise_rotation ||
- h->sei.display_orientation.hflip ||
- h->sei.display_orientation.vflip)) {
[FFmpeg-devel] [PATCH v5 1/6] avutil/frame: Add av_frame_copy_side_data() and av_frame_remove_all_side_data()
From: softworkz
Signed-off-by: softworkz
Signed-off-by: Anton Khirnov
---
doc/APIchanges | 4 +++
libavutil/frame.c | 67 +++--
libavutil/frame.h | 32 ++
libavutil/version.h | 2 +-
4 files changed, 78 insertions(+), 27 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 20b944933a..6b5bf61d85 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,10 @@ libavutil: 2021-04-27
API changes, most recent first:
+2022-05-26 - x - lavu 57.28.100 - frame.h
+ Add av_frame_remove_all_side_data(), av_frame_copy_side_data(),
+ AV_FRAME_TRANSFER_SD_COPY, and AV_FRAME_TRANSFER_SD_FILTER.
+
2022-06-12 - xx - lavf 59.25.100 - avio.h
Add avio_vprintf(), similar to avio_printf() but allow to use it
from within a function taking a variable argument list as input.
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 4c16488c66..5d34fde904 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -271,9 +271,45 @@ FF_ENABLE_DEPRECATION_WARNINGS
return AVERROR(EINVAL);
}
+void av_frame_remove_all_side_data(AVFrame *frame)
+{
+wipe_side_data(frame);
+}
+
+int av_frame_copy_side_data(AVFrame* dst, const AVFrame* src, int flags)
+{
+for (unsigned i = 0; i < src->nb_side_data; i++) {
+const AVFrameSideData *sd_src = src->side_data[i];
+AVFrameSideData *sd_dst;
+if ((flags & AV_FRAME_TRANSFER_SD_FILTER) &&
+sd_src->type == AV_FRAME_DATA_PANSCAN &&
+(src->width != dst->width || src->height != dst->height))
+continue;
+if (flags & AV_FRAME_TRANSFER_SD_COPY) {
+sd_dst = av_frame_new_side_data(dst, sd_src->type,
+sd_src->size);
+if (!sd_dst) {
+wipe_side_data(dst);
+return AVERROR(ENOMEM);
+}
+memcpy(sd_dst->data, sd_src->data, sd_src->size);
+} else {
+AVBufferRef *ref = av_buffer_ref(sd_src->buf);
+sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
+if (!sd_dst) {
+av_buffer_unref(&ref);
+wipe_side_data(dst);
+return AVERROR(ENOMEM);
+}
+}
+av_dict_copy(&sd_dst->metadata, sd_src->metadata, 0);
+}
+return 0;
+}
+
static int frame_copy_props(AVFrame *dst, const AVFrame *src, int force_copy)
{
-int ret, i;
+int ret;
dst->key_frame = src->key_frame;
dst->pict_type = src->pict_type;
@@ -309,31 +345,10 @@ static int frame_copy_props(AVFrame *dst, const AVFrame
*src, int force_copy)
av_dict_copy(&dst->metadata, src->metadata, 0);
-for (i = 0; i < src->nb_side_data; i++) {
-const AVFrameSideData *sd_src = src->side_data[i];
-AVFrameSideData *sd_dst;
-if ( sd_src->type == AV_FRAME_DATA_PANSCAN
-&& (src->width != dst->width || src->height != dst->height))
-continue;
-if (force_copy) {
-sd_dst = av_frame_new_side_data(dst, sd_src->type,
-sd_src->size);
-if (!sd_dst) {
-wipe_side_data(dst);
-return AVERROR(ENOMEM);
-}
-memcpy(sd_dst->data, sd_src->data, sd_src->size);
-} else {
-AVBufferRef *ref = av_buffer_ref(sd_src->buf);
-sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
-if (!sd_dst) {
-av_buffer_unref(&ref);
-wipe_side_data(dst);
-return AVERROR(ENOMEM);
-}
-}
-av_dict_copy(&sd_dst->metadata, sd_src->metadata, 0);
-}
+if ((ret = av_frame_copy_side_data(dst, src,
+(force_copy ? AV_FRAME_TRANSFER_SD_COPY : 0) |
+AV_FRAME_TRANSFER_SD_FILTER) < 0))
+return ret;
ret = av_buffer_replace(&dst->opaque_ref, src->opaque_ref);
ret |= av_buffer_replace(&dst->private_ref, src->private_ref);
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 33fac2054c..f72b6fae71 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -850,6 +850,30 @@ int av_frame_copy(AVFrame *dst, const AVFrame *src);
*/
int av_frame_copy_props(AVFrame *dst, const AVFrame *src);
+
+/**
+ * Copy side data, rather than creating new references.
+ */
+#define AV_FRAME_TRANSFER_SD_COPY (1 << 0)
+/**
+ * Filter out side data that does not match dst properties.
+ */
+#define AV_FRAME_TRANSFER_SD_FILTER(1 << 1)
+
+/**
+ * Copy all side-data from src to dst.
+ *
+ * @param dst a frame to which the side data should be copied.
+ * @param src a frame from which to copy the side data.
+ * @param flags a combination of AV_FRAME_TRANSFER_SD_*
+ *
+ * @return 0 on success, a negative AVERROR on error.
+ *
+ * @note This function will create new references to side data buffers i
[FFmpeg-devel] [PATCH v5 2/6] avcodec/vpp_qsv: Copy side data from input to output frame
From: softworkz
Signed-off-by: softworkz
---
libavfilter/qsvvpp.c | 6 ++
libavfilter/vf_overlay_qsv.c | 19 +++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 954f882637..f4bf628073 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -843,6 +843,12 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s, AVFilterLink
*inlink, AVFrame *picr
return AVERROR(EAGAIN);
break;
}
+
+av_frame_remove_all_side_data(out_frame->frame);
+ret = av_frame_copy_side_data(out_frame->frame, in_frame->frame, 0);
+if (ret < 0)
+return ret;
+
out_frame->frame->pts = av_rescale_q(out_frame->surface.Data.TimeStamp,
default_tb, outlink->time_base);
diff --git a/libavfilter/vf_overlay_qsv.c b/libavfilter/vf_overlay_qsv.c
index 7e76b39aa9..e15214dbf2 100644
--- a/libavfilter/vf_overlay_qsv.c
+++ b/libavfilter/vf_overlay_qsv.c
@@ -231,13 +231,24 @@ static int process_frame(FFFrameSync *fs)
{
AVFilterContext *ctx = fs->parent;
QSVOverlayContext *s = fs->opaque;
+AVFrame *frame0 = NULL;
AVFrame*frame = NULL;
-int ret = 0, i;
+int ret = 0;
-for (i = 0; i < ctx->nb_inputs; i++) {
+for (unsigned i = 0; i < ctx->nb_inputs; i++) {
ret = ff_framesync_get_frame(fs, i, &frame, 0);
-if (ret == 0)
-ret = ff_qsvvpp_filter_frame(s->qsv, ctx->inputs[i], frame);
+
+if (ret == 0) {
+if (i == 0)
+frame0 = frame;
+else {
+av_frame_remove_all_side_data(frame);
+ret = av_frame_copy_side_data(frame, frame0, 0);
+}
+
+ret = ret < 0 ? ret : ff_qsvvpp_filter_frame(s->qsv,
ctx->inputs[i], frame);
+}
+
if (ret < 0 && ret != AVERROR(EAGAIN))
break;
}
--
ffmpeg-codebot
___
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 v5 6/6] avcodec/qsvdec: Implement SEI parsing for QSV decoders
From: softworkz
Signed-off-by: softworkz
---
libavcodec/Makefile | 6 +-
libavcodec/hevcdsp.c | 4 +
libavcodec/qsvdec.c | 234 +++
3 files changed, 243 insertions(+), 1 deletion(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3b8f7b5e01..7b98391745 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -144,7 +144,11 @@ OBJS-$(CONFIG_MSS34DSP)+= mss34dsp.o
OBJS-$(CONFIG_PIXBLOCKDSP) += pixblockdsp.o
OBJS-$(CONFIG_QPELDSP) += qpeldsp.o
OBJS-$(CONFIG_QSV) += qsv.o
-OBJS-$(CONFIG_QSVDEC) += qsvdec.o
+OBJS-$(CONFIG_QSVDEC) += qsvdec.o h264_slice.o h264_cabac.o
h264_cavlc.o \
+ h264_direct.o h264_mb.o
h264_picture.o h264_loopfilter.o \
+ h264dec.o h264_refs.o cabac.o
hevcdec.o hevc_refs.o \
+
hevc_filter.o hevc_cabac.o hevc_mvs.o hevcpred.o hevcdsp.o \
+
h274.o dovi_rpu.o mpeg12dec.o
OBJS-$(CONFIG_QSVENC) += qsvenc.o
OBJS-$(CONFIG_RANGECODER) += rangecoder.o
OBJS-$(CONFIG_RDFT)+= rdft.o
diff --git a/libavcodec/hevcdsp.c b/libavcodec/hevcdsp.c
index 2ca551df1d..c7a436d30f 100644
--- a/libavcodec/hevcdsp.c
+++ b/libavcodec/hevcdsp.c
@@ -22,6 +22,8 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include "config_components.h"
+
#include "hevcdsp.h"
static const int8_t transform[32][32] = {
@@ -257,6 +259,7 @@ int i = 0;
break;
}
+#if CONFIG_HEVC_DECODER
#if ARCH_AARCH64
ff_hevc_dsp_init_aarch64(hevcdsp, bit_depth);
#elif ARCH_ARM
@@ -270,4 +273,5 @@ int i = 0;
#elif ARCH_LOONGARCH
ff_hevc_dsp_init_loongarch(hevcdsp, bit_depth);
#endif
+#endif
}
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 5fc5bed4c8..e854f363ec 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -49,6 +49,12 @@
#include "hwconfig.h"
#include "qsv.h"
#include "qsv_internal.h"
+#include "h264dec.h"
+#include "h264_sei.h"
+#include "hevcdec.h"
+#include "hevc_ps.h"
+#include "hevc_sei.h"
+#include "mpeg12.h"
static const AVRational mfx_tb = { 1, 9 };
@@ -60,6 +66,8 @@ static const AVRational mfx_tb = { 1, 9 };
AV_NOPTS_VALUE : pts_tb.num ? \
av_rescale_q(mfx_pts, mfx_tb, pts_tb) : mfx_pts)
+#define PAYLOAD_BUFFER_SIZE 65535
+
typedef struct QSVAsyncFrame {
mfxSyncPoint *sync;
QSVFrame *frame;
@@ -101,6 +109,9 @@ typedef struct QSVContext {
mfxExtBuffer **ext_buffers;
int nb_ext_buffers;
+
+mfxU8 payload_buffer[PAYLOAD_BUFFER_SIZE];
+Mpeg1Context mpeg_ctx;
} QSVContext;
static const AVCodecHWConfigInternal *const qsv_hw_configs[] = {
@@ -599,6 +610,210 @@ static int qsv_export_film_grain(AVCodecContext *avctx,
mfxExtAV1FilmGrainParam
return 0;
}
#endif
+static int find_start_offset(mfxU8 data[4])
+{
+if (data[0] == 0 && data[1] == 0 && data[2] == 1)
+return 3;
+
+if (data[0] == 0 && data[1] == 0 && data[2] == 0 && data[3] == 1)
+return 4;
+
+return 0;
+}
+
+static int parse_sei_h264(AVCodecContext* avctx, QSVContext* q, AVFrame* out)
+{
+H264SEIContext sei = { 0 };
+GetBitContext gb = { 0 };
+mfxPayload payload = { 0, .Data = &q->payload_buffer[0], .BufSize =
sizeof(q->payload_buffer) };
+mfxU64 ts;
+int ret;
+
+while (1) {
+int start;
+memset(payload.Data, 0, payload.BufSize);
+
+ret = MFXVideoDECODE_GetPayload(q->session, &ts, &payload);
+if (ret == MFX_ERR_NOT_ENOUGH_BUFFER) {
+av_log(avctx, AV_LOG_WARNING, "Warning: Insufficient buffer on
GetPayload(). Size: %"PRIu64" Needed: %d\n", sizeof(q->payload_buffer),
payload.BufSize);
+return 0;
+}
+if (ret != MFX_ERR_NONE)
+return ret;
+
+if (payload.NumBit == 0 || payload.NumBit >= payload.BufSize * 8)
+break;
+
+start = find_start_offset(payload.Data);
+
+switch (payload.Type) {
+case SEI_TYPE_BUFFERING_PERIOD:
+case SEI_TYPE_PIC_TIMING:
+continue;
+}
+
+if (init_get_bits(&gb, &payload.Data[start], payload.NumBit - start *
8) < 0)
+av_log(avctx, AV_LOG_ERROR, "Error initializing bitstream reader
SEI type: %d Numbits %d error: %d\n", payload.Type, payload.NumBit, ret);
+else {
+ret = ff_h264_sei_decode(&sei, &gb, NULL, avctx);
+
+if (ret < 0)
+av_log(avctx, AV_LOG_WARNING, "Failed to parse SEI type: %d
Numbits %d error: %d\n", payload.Type, payload.NumBit, ret);
+else
+av_log(avctx, AV_LOG_DEBUG, "mfxPayload Type: %d Numbits
%d\n",
[FFmpeg-devel] [PATCH v5 3/6] avcodec/mpeg12dec: make mpeg_decode_user_data() accessible
From: softworkz
Signed-off-by: softworkz
---
libavcodec/mpeg12.h| 28
libavcodec/mpeg12dec.c | 40 +---
2 files changed, 33 insertions(+), 35 deletions(-)
diff --git a/libavcodec/mpeg12.h b/libavcodec/mpeg12.h
index e0406b32d9..84a829cdd3 100644
--- a/libavcodec/mpeg12.h
+++ b/libavcodec/mpeg12.h
@@ -23,6 +23,7 @@
#define AVCODEC_MPEG12_H
#include "mpegvideo.h"
+#include "libavutil/stereo3d.h"
/* Start codes. */
#define SEQ_END_CODE0x01b7
@@ -34,6 +35,31 @@
#define EXT_START_CODE 0x01b5
#define USER_START_CODE 0x01b2
+typedef struct Mpeg1Context {
+MpegEncContext mpeg_enc_ctx;
+int mpeg_enc_ctx_allocated; /* true if decoding context allocated */
+int repeat_field; /* true if we must repeat the field */
+AVPanScan pan_scan; /* some temporary storage for the panscan */
+AVStereo3D stereo3d;
+int has_stereo3d;
+AVBufferRef *a53_buf_ref;
+uint8_t afd;
+int has_afd;
+int slice_count;
+unsigned aspect_ratio_info;
+AVRational save_aspect;
+int save_width, save_height, save_progressive_seq;
+int rc_buffer_size;
+AVRational frame_rate_ext; /* MPEG-2 specific framerate modificator */
+unsigned frame_rate_index;
+int sync; /* Did we reach a sync point like a
GOP/SEQ/KEYFrame? */
+int closed_gop;
+int tmpgexs;
+int first_slice;
+int extradata_decoded;
+int64_t timecode_frame_start; /*< GOP timecode frame start number, in non
drop frame format */
+} Mpeg1Context;
+
void ff_mpeg12_common_init(MpegEncContext *s);
void ff_mpeg1_clean_buffers(MpegEncContext *s);
@@ -45,4 +71,6 @@ void ff_mpeg12_find_best_frame_rate(AVRational frame_rate,
int *code, int *ext_n, int *ext_d,
int nonstandard);
+void ff_mpeg_decode_user_data(AVCodecContext *avctx, Mpeg1Context *s1, const
uint8_t *p, int buf_size);
+
#endif /* AVCODEC_MPEG12_H */
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index e9bde48f7a..11d2b58185 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -58,31 +58,6 @@
#define A53_MAX_CC_COUNT 2000
-typedef struct Mpeg1Context {
-MpegEncContext mpeg_enc_ctx;
-int mpeg_enc_ctx_allocated; /* true if decoding context allocated */
-int repeat_field; /* true if we must repeat the field */
-AVPanScan pan_scan; /* some temporary storage for the panscan */
-AVStereo3D stereo3d;
-int has_stereo3d;
-AVBufferRef *a53_buf_ref;
-uint8_t afd;
-int has_afd;
-int slice_count;
-unsigned aspect_ratio_info;
-AVRational save_aspect;
-int save_width, save_height, save_progressive_seq;
-int rc_buffer_size;
-AVRational frame_rate_ext; /* MPEG-2 specific framerate modificator */
-unsigned frame_rate_index;
-int sync; /* Did we reach a sync point like a
GOP/SEQ/KEYFrame? */
-int closed_gop;
-int tmpgexs;
-int first_slice;
-int extradata_decoded;
-int64_t timecode_frame_start; /*< GOP timecode frame start number, in non
drop frame format */
-} Mpeg1Context;
-
#define MB_TYPE_ZERO_MV 0x2000
static const uint32_t ptype2mb_type[7] = {
@@ -2198,11 +2173,9 @@ static int vcr2_init_sequence(AVCodecContext *avctx)
return 0;
}
-static int mpeg_decode_a53_cc(AVCodecContext *avctx,
+static int mpeg_decode_a53_cc(AVCodecContext *avctx, Mpeg1Context *s1,
const uint8_t *p, int buf_size)
{
-Mpeg1Context *s1 = avctx->priv_data;
-
if (buf_size >= 6 &&
p[0] == 'G' && p[1] == 'A' && p[2] == '9' && p[3] == '4' &&
p[4] == 3 && (p[5] & 0x40)) {
@@ -2333,12 +2306,9 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
return 0;
}
-static void mpeg_decode_user_data(AVCodecContext *avctx,
- const uint8_t *p, int buf_size)
+void ff_mpeg_decode_user_data(AVCodecContext *avctx, Mpeg1Context *s1, const
uint8_t *p, int buf_size)
{
-Mpeg1Context *s = avctx->priv_data;
const uint8_t *buf_end = p + buf_size;
-Mpeg1Context *s1 = avctx->priv_data;
#if 0
int i;
@@ -2352,7 +2322,7 @@ static void mpeg_decode_user_data(AVCodecContext *avctx,
int i;
for(i=0; i<20; i++)
if (!memcmp(p+i, "\0TMPGEXS\0", 9)){
-s->tmpgexs= 1;
+s1->tmpgexs= 1;
}
}
/* we parse the DTG active format information */
@@ -2398,7 +2368,7 @@ static void mpeg_decode_user_data(AVCodecContext *avctx,
break;
}
}
-} else if (mpeg_decode_a53_cc(avctx, p, buf_size)) {
+} else if (mpeg_decode_a53_cc(avctx, s1, p, buf_size)) {
return;
}
}
@@ -2590,7 +2560,7 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame
*picture,
}
b
Re: [FFmpeg-devel] [PATCH] avfilter: add remap_opencl filter
On Thu, Jun 30, 2022 at 08:59:53AM +0200, Paul B Mahol wrote: > Updated. > libavfilter/Makefile |2 > libavfilter/allfilters.c |1 > libavfilter/opencl/remap.cl | 69 > libavfilter/opencl_source.h |1 > libavfilter/vf_remap_opencl.c | 362 > ++ > libavutil/hwcontext_opencl.c |5 > 6 files changed, 439 insertions(+), 1 deletion(-) > d6ec16b957d70b99edb4afe997ede6c683749ede > 0001-avfilter-add-remap-opencl-filter.patch > From 2b6b653bebec01d9d523102c1bfe2ce4b1be93dd Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Wed, 29 Jun 2022 19:12:24 +0200 > Subject: [PATCH] avfilter: add remap opencl filter > > Signed-off-by: Paul B Mahol > --- > libavfilter/Makefile | 2 + > libavfilter/allfilters.c | 1 + > libavfilter/opencl/remap.cl | 69 +++ > libavfilter/opencl_source.h | 1 + > libavfilter/vf_remap_opencl.c | 362 ++ > libavutil/hwcontext_opencl.c | 5 +- > 6 files changed, 439 insertions(+), 1 deletion(-) > create mode 100644 libavfilter/opencl/remap.cl > create mode 100644 libavfilter/vf_remap_opencl.c breaks build here (ubuntu x86-64) make CC libavfilter/opencl.o In file included from libavfilter/opencl.h:31:0, from libavfilter/opencl.c:26: ./libavutil/hwcontext_opencl.h:25:10: fatal error: CL/cl.h: No such file or directory #include ^ compilation terminated. ffbuild/common.mak:81: recipe for target 'libavfilter/opencl.o' failed make: *** [libavfilter/opencl.o] Error 1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire 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] libavcodec/mpegvideo_enc: Fix a chroma mb size error in sse_mb()
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Wenbin Chen
> Sent: Friday, July 1, 2022 7:35 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] libavcodec/mpegvideo_enc: Fix a
> chroma mb size error in sse_mb()
>
> For 422 frames we should not use hard coded 8 to calculate mb size
> for
> uv plane. Chroma shift should be taken into consideration to be
> compatiple with different sampling format.
>
> The error is reported by fate test when av_cpu_max_align() return 64
> on the platform supporting AVX512. This is a hidden error and it is
> exposed after commit 17a59a634c39b00a680c6ebbaea58db95594d13d.
>
> mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum
> of
> squared error) on current mb, reconstructed mb will be wrote to the
> previous mb space, so that the memory can be saved. However if the
> align
> is 64, the frame is shared in somewhere else, so the frame cannot be
> reused and a new frame to store reconstrued data is created. Because
> the
> height of mb is wrong when compute sse on 422 frame, starting from
> the
> second line of macro block, changed data is read when frame is reused
> (we need to read row 16 rather than row 8 if frame is 422), and
> unchanged
> data is read when frame is not reused (a new frame is created so the
> original frame will not be changed).
>
> That is why commit 17a59a634c39b00a680c6ebbaea58db95594d13d exposes
> this
> issue, because it add av_cpu_max_align() and this function return 64
> on
> platform supporting AVX512 which lead to creating a frame in
> mpeg2enc,
> and this lead to the different outputs.
>
> Signed-off-by: Wenbin Chen
> ---
> libavcodec/mpegvideo_enc.c | 29 +--
> tests/ref/seek/vsynth_lena-mpeg2-422 | 40 +---
> --
> tests/ref/vsynth/vsynth1-mpeg2-422 | 8 +++---
> tests/ref/vsynth/vsynth2-mpeg2-422 | 8 +++---
> tests/ref/vsynth/vsynth3-mpeg2-422 | 8 +++---
> tests/ref/vsynth/vsynth_lena-mpeg2-422 | 8 +++---
> 6 files changed, 56 insertions(+), 45 deletions(-)
>
> diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> index d6a85a037a..c9d9e2a764 100644
> --- a/libavcodec/mpegvideo_enc.c
> +++ b/libavcodec/mpegvideo_enc.c
> @@ -2558,24 +2558,35 @@ static int sse(MpegEncContext *s, uint8_t
> *src1, uint8_t *src2, int w, int h, in
> static int sse_mb(MpegEncContext *s){
> int w= 16;
> int h= 16;
> +int chroma_mb_w = w >> s->chroma_x_shift;
> +int chroma_mb_h = h >> s->chroma_y_shift;
>
> if(s->mb_x*16 + 16 > s->width ) w= s->width - s->mb_x*16;
> if(s->mb_y*16 + 16 > s->height) h= s->height- s->mb_y*16;
>
> if(w==16 && h==16)
>if(s->avctx->mb_cmp == FF_CMP_NSSE){
> -return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x
> * 16 + s->mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) +
> - s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x
> * 8 + s->mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) +
> - s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x
> * 8 + s->mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8);
> +return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x
> * 16 + s->mb_y * s->linesize * 16,
> + s->dest[0], s->linesize, 16) +
> + s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x
> * chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[1], s->uvlinesize,
> chroma_mb_h) +
> + s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x
> * chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[2], s->uvlinesize,
> chroma_mb_h);
>}else{
> -return s->mecc.sse[0](NULL, s->new_picture->data[0] + s-
> >mb_x * 16 + s->mb_y * s->linesize * 16, s->dest[0], s->linesize,
> 16) +
> - s->mecc.sse[1](NULL, s->new_picture->data[1] + s-
> >mb_x * 8 + s->mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize,
> 8) +
> - s->mecc.sse[1](NULL, s->new_picture->data[2] + s-
> >mb_x * 8 + s->mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize,
> 8);
> +return s->mecc.sse[0](NULL, s->new_picture->data[0] + s-
> >mb_x * 16 + s->mb_y * s->linesize * 16,
> + s->dest[0], s->linesize, 16) +
> + s->mecc.sse[1](NULL, s->new_picture->data[1] + s-
> >mb_x * chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[1], s->uvlinesize,
> chroma_mb_h) +
> + s->mecc.sse[1](NULL, s->new_picture->data[2] + s-
> >mb_x * chroma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h,
> + s->dest[2], s->uvlinesize,
> chroma_mb_h);
>}
> else
> -return sse(s, s->new_picture->data[0] + s->mb_x*16 + s-
> >mb_y*s->linesize*16, s->dest[0], w, h, s->linesize)
> - +sse(s, s->new_picture-
Re: [FFmpeg-devel] [PATCH 14/18] avcodec/hevcdec: Don't allocate redundant HEVCContexts
On Fri, Jul 01, 2022 at 12:29:45AM +0200, Andreas Rheinhardt wrote:
> The HEVC decoder has both HEVCContext and HEVCLocalContext
> structures. The latter is supposed to be the structure
> containing the per-slicethread state.
>
> Yet up until now that is not how it is handled in practice:
> Each HEVCLocalContext has a unique HEVCContext allocated for it
> and each of these coincides except in exactly one field: The
> corresponding HEVCLocalContext. This makes it possible to pass
> the HEVCContext everywhere where logically a HEVCLocalContext
> should be used. And up until recently, this is how it has been done.
>
> Yet the preceding patches changed this, making it possible
> to avoid allocating redundant HEVCContexts.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/hevcdec.c | 40
> libavcodec/hevcdec.h | 2 --
> 2 files changed, 16 insertions(+), 26 deletions(-)
>
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 9d1241f293..048fcc76b4 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2548,13 +2548,12 @@ static int hls_decode_entry_wpp(AVCodecContext
> *avctxt, void *hevc_lclist,
> {
> HEVCLocalContext *lc = ((HEVCLocalContext**)hevc_lclist)[self_id];
> const HEVCContext *const s = lc->parent;
> -HEVCContext *s1 = avctxt->priv_data;
> -int ctb_size= 1<< s1->ps.sps->log2_ctb_size;
> +int ctb_size= 1 << s->ps.sps->log2_ctb_size;
> int more_data = 1;
> int ctb_row = job;
> -int ctb_addr_rs = s1->sh.slice_ctb_addr_rs + ctb_row *
> ((s1->ps.sps->width + ctb_size - 1) >> s1->ps.sps->log2_ctb_size);
> -int ctb_addr_ts = s1->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
> -int thread = ctb_row % s1->threads_number;
> +int ctb_addr_rs = s->sh.slice_ctb_addr_rs + ctb_row * ((s->ps.sps->width
> + ctb_size - 1) >> s->ps.sps->log2_ctb_size);
> +int ctb_addr_ts = s->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
> +int thread = ctb_row % s->threads_number;
> int ret;
>
> if(ctb_row) {
> @@ -2572,7 +2571,7 @@ static int hls_decode_entry_wpp(AVCodecContext *avctxt,
> void *hevc_lclist,
>
> ff_thread_await_progress2(s->avctx, ctb_row, thread, SHIFT_CTB_WPP);
>
> -if (atomic_load(&s1->wpp_err)) {
> +if (atomic_load(&s->wpp_err)) {
> ff_thread_report_progress2(s->avctx, ctb_row , thread,
> SHIFT_CTB_WPP);
the consts in "const HEVCContext *const " make clang version 6.0.0-1ubuntu2
unhappy
(this was building shared libs)
CC libavcodec/hevcdec.o
src/libavcodec/hevcdec.c:2574:13: error: address argument to atomic operation
must be a pointer to non-const _Atomic type ('const atomic_int *' (aka 'const
_Atomic(int) *') invalid)
if (atomic_load(&s->wpp_err)) {
^ ~~~
/usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:134:29: note: expanded
from macro 'atomic_load'
#define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
^ ~~
1 error generated.
src/ffbuild/common.mak:81: recipe for target 'libavcodec/hevcdec.o' failed
make: *** [libavcodec/hevcdec.o] Error 1
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
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] avfilter: add remap_opencl filter
On Fri, Jul 1, 2022 at 11:04 PM Michael Niedermayer wrote: > On Thu, Jun 30, 2022 at 08:59:53AM +0200, Paul B Mahol wrote: > > Updated. > > > libavfilter/Makefile |2 > > libavfilter/allfilters.c |1 > > libavfilter/opencl/remap.cl | 69 > > libavfilter/opencl_source.h |1 > > libavfilter/vf_remap_opencl.c | 362 > ++ > > libavutil/hwcontext_opencl.c |5 > > 6 files changed, 439 insertions(+), 1 deletion(-) > > d6ec16b957d70b99edb4afe997ede6c683749ede > 0001-avfilter-add-remap-opencl-filter.patch > > From 2b6b653bebec01d9d523102c1bfe2ce4b1be93dd Mon Sep 17 00:00:00 2001 > > From: Paul B Mahol > > Date: Wed, 29 Jun 2022 19:12:24 +0200 > > Subject: [PATCH] avfilter: add remap opencl filter > > > > Signed-off-by: Paul B Mahol > > --- > > libavfilter/Makefile | 2 + > > libavfilter/allfilters.c | 1 + > > libavfilter/opencl/remap.cl | 69 +++ > > libavfilter/opencl_source.h | 1 + > > libavfilter/vf_remap_opencl.c | 362 ++ > > libavutil/hwcontext_opencl.c | 5 +- > > 6 files changed, 439 insertions(+), 1 deletion(-) > > create mode 100644 libavfilter/opencl/remap.cl > > create mode 100644 libavfilter/vf_remap_opencl.c > > breaks build here (ubuntu x86-64) > > make > CC libavfilter/opencl.o > In file included from libavfilter/opencl.h:31:0, > from libavfilter/opencl.c:26: > ./libavutil/hwcontext_opencl.h:25:10: fatal error: CL/cl.h: No such file > or directory > #include > ^ > compilation terminated. > ffbuild/common.mak:81: recipe for target 'libavfilter/opencl.o' failed > make: *** [libavfilter/opencl.o] Error 1 > > thx > Already spotted and fixed days ago. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is dangerous to be right in matters on which the established authorities > are wrong. -- Voltaire > ___ > 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".
[FFmpeg-devel] [PATCH] avformat/isom: support 16:9 DV in QuickTime
Attached patch adds input support for 16:9 DV video in QuickTime. I found some old files produced by Adobe Premiere and Radius SoftDV which were affected by this: 4:3 files were marked as type 'dvc ' which already worked; 16:9 files as 'dvl ' which was missing. PAL uses 'p' in place of the ' ' space character of NTSC in both versions, but I have no PAL sample files. Confirmed to work on real NTSC files; PAL not tested. -- brion 0001-Support-for-16-9-DV-in-QuickTime.patch Description: Binary data ___ 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 14/18] avcodec/hevcdec: Don't allocate redundant HEVCContexts
Michael Niedermayer:
> On Fri, Jul 01, 2022 at 12:29:45AM +0200, Andreas Rheinhardt wrote:
>> The HEVC decoder has both HEVCContext and HEVCLocalContext
>> structures. The latter is supposed to be the structure
>> containing the per-slicethread state.
>>
>> Yet up until now that is not how it is handled in practice:
>> Each HEVCLocalContext has a unique HEVCContext allocated for it
>> and each of these coincides except in exactly one field: The
>> corresponding HEVCLocalContext. This makes it possible to pass
>> the HEVCContext everywhere where logically a HEVCLocalContext
>> should be used. And up until recently, this is how it has been done.
>>
>> Yet the preceding patches changed this, making it possible
>> to avoid allocating redundant HEVCContexts.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/hevcdec.c | 40
>> libavcodec/hevcdec.h | 2 --
>> 2 files changed, 16 insertions(+), 26 deletions(-)
>>
>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>> index 9d1241f293..048fcc76b4 100644
>> --- a/libavcodec/hevcdec.c
>> +++ b/libavcodec/hevcdec.c
>> @@ -2548,13 +2548,12 @@ static int hls_decode_entry_wpp(AVCodecContext
>> *avctxt, void *hevc_lclist,
>> {
>> HEVCLocalContext *lc = ((HEVCLocalContext**)hevc_lclist)[self_id];
>> const HEVCContext *const s = lc->parent;
>> -HEVCContext *s1 = avctxt->priv_data;
>> -int ctb_size= 1<< s1->ps.sps->log2_ctb_size;
>> +int ctb_size= 1 << s->ps.sps->log2_ctb_size;
>> int more_data = 1;
>> int ctb_row = job;
>> -int ctb_addr_rs = s1->sh.slice_ctb_addr_rs + ctb_row *
>> ((s1->ps.sps->width + ctb_size - 1) >> s1->ps.sps->log2_ctb_size);
>> -int ctb_addr_ts = s1->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
>> -int thread = ctb_row % s1->threads_number;
>> +int ctb_addr_rs = s->sh.slice_ctb_addr_rs + ctb_row *
>> ((s->ps.sps->width + ctb_size - 1) >> s->ps.sps->log2_ctb_size);
>> +int ctb_addr_ts = s->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
>> +int thread = ctb_row % s->threads_number;
>> int ret;
>>
>> if(ctb_row) {
>> @@ -2572,7 +2571,7 @@ static int hls_decode_entry_wpp(AVCodecContext
>> *avctxt, void *hevc_lclist,
>>
>> ff_thread_await_progress2(s->avctx, ctb_row, thread, SHIFT_CTB_WPP);
>>
>> -if (atomic_load(&s1->wpp_err)) {
>> +if (atomic_load(&s->wpp_err)) {
>> ff_thread_report_progress2(s->avctx, ctb_row , thread,
>> SHIFT_CTB_WPP);
>
> the consts in "const HEVCContext *const " make clang version 6.0.0-1ubuntu2
> unhappy
> (this was building shared libs)
>
>
> CClibavcodec/hevcdec.o
> src/libavcodec/hevcdec.c:2574:13: error: address argument to atomic operation
> must be a pointer to non-const _Atomic type ('const atomic_int *' (aka 'const
> _Atomic(int) *') invalid)
> if (atomic_load(&s->wpp_err)) {
> ^ ~~~
> /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:134:29: note: expanded
> from macro 'atomic_load'
> #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
> ^ ~~
> 1 error generated.
> src/ffbuild/common.mak:81: recipe for target 'libavcodec/hevcdec.o' failed
> make: *** [libavcodec/hevcdec.o] Error 1
>
> thx
>
Thanks for testing this. atomic_load is indeed declared without const in
7.17.7.2:
C atomic_load(volatile A *object);
Upon reflection this makes sense, because if atomics are implemented via
mutexes, even a read may involve a preceding write. So I'll cast const
away here, too, and add a comment. (It works when casting const away,
doesn't it?)
- 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".
Re: [FFmpeg-devel] [PATCH] avfilter: add remap_opencl filter
New version:
Added docs, and more cleanups and fixes.
From 22716c9f853d33769c1e63f7e010a5540a2e455b Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 29 Jun 2022 19:12:24 +0200
Subject: [PATCH] avfilter: add remap opencl filter
Signed-off-by: Paul B Mahol
---
configure | 1 +
doc/filters.texi | 24 +++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 1 +
libavfilter/opencl/remap.cl | 73 +++
libavfilter/opencl_source.h | 1 +
libavfilter/vf_remap_opencl.c | 354 ++
libavutil/hwcontext_opencl.c | 5 +-
8 files changed, 460 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/opencl/remap.cl
create mode 100644 libavfilter/vf_remap_opencl.c
diff --git a/configure b/configure
index fea512e8ef..7d5c4900bf 100755
--- a/configure
+++ b/configure
@@ -3706,6 +3706,7 @@ prewitt_opencl_filter_deps="opencl"
procamp_vaapi_filter_deps="vaapi"
program_opencl_filter_deps="opencl"
pullup_filter_deps="gpl"
+remap_opencl_filter_deps="opencl"
removelogo_filter_deps="avcodec avformat swscale"
repeatfields_filter_deps="gpl"
roberts_opencl_filter_deps="opencl"
diff --git a/doc/filters.texi b/doc/filters.texi
index e525e87b3c..7d383715da 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -25683,6 +25683,30 @@ __kernel void blend_images(__write_only image2d_t dst,
@end itemize
+@section remap_opencl
+
+Remap pixels using 2nd: Xmap and 3rd: Ymap input video stream.
+
+Destination pixel at position (X, Y) will be picked from source (x, y) position
+where x = Xmap(X, Y) and y = Ymap(X, Y). If mapping values are out of range, zero
+value for pixel will be used for destination pixel.
+
+Xmap and Ymap input video streams must be of same dimensions. Output video stream
+will have Xmap/Ymap video stream dimensions.
+Xmap and Ymap input video streams are 32bit float pixel format, single channel.
+
+@table @option
+@item interp
+Specify interpolation used for remapping of pixels.
+Allowed values are @code{near} and @code{linear}.
+Default value is @code{linear}.
+
+@item fill
+Specify the color of the unmapped pixels. For the syntax of this option,
+check the @ref{color syntax,,"Color" section in the ffmpeg-utils
+manual,ffmpeg-utils}. Default color is @code{black}.
+@end table
+
@section roberts_opencl
Apply the Roberts cross operator (@url{https://en.wikipedia.org/wiki/Roberts_cross}) to input video stream.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 22b0a0ca15..139f7cb751 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -420,6 +420,8 @@ OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
OBJS-$(CONFIG_READVITC_FILTER) += vf_readvitc.o
OBJS-$(CONFIG_REALTIME_FILTER) += f_realtime.o
OBJS-$(CONFIG_REMAP_FILTER) += vf_remap.o framesync.o
+OBJS-$(CONFIG_REMAP_OPENCL_FILTER) += vf_remap_opencl.o framesync.o opencl.o \
+opencl/remap.o
OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o vf_removelogo.o
OBJS-$(CONFIG_REPEATFIELDS_FILTER) += vf_repeatfields.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ec70feef11..3018850b4b 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -399,6 +399,7 @@ extern const AVFilter ff_vf_readeia608;
extern const AVFilter ff_vf_readvitc;
extern const AVFilter ff_vf_realtime;
extern const AVFilter ff_vf_remap;
+extern const AVFilter ff_vf_remap_opencl;
extern const AVFilter ff_vf_removegrain;
extern const AVFilter ff_vf_removelogo;
extern const AVFilter ff_vf_repeatfields;
diff --git a/libavfilter/opencl/remap.cl b/libavfilter/opencl/remap.cl
new file mode 100644
index 00..fba82d134e
--- /dev/null
+++ b/libavfilter/opencl/remap.cl
@@ -0,0 +1,73 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+const sampler_t linear_sampler = (CLK_NORMALIZED_COORDS_FALSE |
+ CLK_FILTER_LINEAR);
+
+const sampler_t nearest_sampler = (CLK_NORMALIZED_COORDS_FALSE |
+ CLK_FILTER_NEAREST);
+
+__k
