Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: add va_profile format map support for HEVC_REXT

[Fu, Linjie]

> -Original Message-
> From: myp...@gmail.com [mailto:myp...@gmail.com]
> Sent: Thursday, March 28, 2019 13:03
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: add va_profile
> format map support for HEVC_REXT
> 
> On Thu, Mar 28, 2019 at 12:03 PM Linjie Fu  wrote:
> >
> > HEVC_REXT will be map to {VAProfileHEVCMain422_10,
> VAProfileHEVCMain444,
> > VAProfileHEVCMain444_10} in vaapi_profile_map[], since need to be
> distinguished
> > to select the exact va_profile.
> >
> > Add va_profile -> AV_PIX_FMT map for FF_PROFILE_HEVC_REXT to match
> the
> > exact va_profile.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/vaapi_decode.c | 29 +
> >  1 file changed, 25 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 015154b879..1cb8683b7c 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -414,6 +414,18 @@ static const struct {
> >  #undef MAP
> >  };
> >
> > +static const struct {
> > +VAProfile va_profile;
> > +enum AVPixelFormat pix_fmt;
> > +} rext_format_map[] = {
> > +#define MAP(vp, av) { VAProfileHEVCMain ## vp, AV_PIX_FMT_ ## av }
> > +MAP(422_10,  YUYV422),
> > +MAP(422_10,  YUV422P10LE),
> > +MAP(444, YUV444P),
> > +MAP(444_10,  YUV444P10LE),
> > +#undef MAP
> > +};
> > +
> >  /*
> >   * Set *va_config and the frames_ref fields from the current codec
> parameters
> >   * in avctx.
> > @@ -426,7 +438,7 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
> >  AVVAAPIHWConfig   *hwconfig= NULL;
> >  AVHWFramesConstraints *constraints = NULL;
> >  VAStatus vas;
> > -int err, i, j;
> > +int err, i, j, k;
> >  const AVCodecDescriptor *codec_desc;
> >  VAProfile *profile_list = NULL, matched_va_profile;
> >  int profile_count, exact_match, matched_ff_profile;
> > @@ -467,13 +479,22 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
> >  if (avctx->profile == vaapi_profile_map[i].codec_profile ||
> >  vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
> >  profile_match = 1;
> > -for (j = 0; j < profile_count; j++) {
> > -if (vaapi_profile_map[i].va_profile == profile_list[j]) {
> > +if (avctx->profile == FF_PROFILE_HEVC_REXT) {
> > +/* find the exact va_profile for HEVC_REXT */
> > +for (j = 0; j < FF_ARRAY_ELEMS(rext_format_map); j++) {
> > +if (avctx->pix_fmt == rext_format_map[j].pix_fmt)
> > +   break;
> > +}
> > +if (vaapi_profile_map[i].va_profile !=
> rext_format_map[j].va_profile)
> > +continue;
> > +}
> > +for (k = 0; k < profile_count; k++) {
> > +if (vaapi_profile_map[i].va_profile == profile_list[k]) {
> >  exact_match = profile_match;
> >  break;
> >  }
> >  }
> > -if (j < profile_count) {
> > +if (k < profile_count) {
> >  matched_va_profile = vaapi_profile_map[i].va_profile;
> >  matched_ff_profile = vaapi_profile_map[i].codec_profile;
> >  if (exact_match)
> > --
> 
> What  intel platform supported HEVCMain422 or 444?
Will be supported [ICE LAKE+].
___
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] configure: include pkgconfig path as vaapi header search

[Song, Ruiling]

> > >
> > > Neo is the successor to Beignet, correct?
> > Yes, that's the truth.
> > Currently we simply checking against the specific header file of OpenCL,
> > which is in-fact not accurate.
> > I am not sure whether you would like to use Neo together with
> > intel-media-driver, which is the most targeted opencl usage in FFmpeg.
> > If that's the case, I think it may be hard to find a matching
> > intel-media-driver to work with Neo release package.
> > Because Neo release version depends on a very outdated libva revision.
> > I just sent a patch to Neo to update libva revision dependency. Once they
> > accept the patch and new Neo release package comes out,
> > I think we can change to check against Neo package. People would not need
> > to build Neo themselves then.
> >
> > Thanks!
> > Ruiling
> > >
> > > Enabling similar functionality for Neo should allow for the same feature
> > > support for these not using Beignet.
> >
> >
> Indeed, I'd want to use Neo + intel-media-driver.
> Judging by the (relatively low) development activity on Beignet of late,
> its' considered ready to deprecate in place of Neo, applicable on anything
> newer than Kabylake.
I think Mark don't have plan to deprecate Beignet now, and me too.
FFmpeg-OpenCL currently use direct buffer sharing between OpenCL and vaapi 
driver.
One obvious limitation I didn't notice before is 10bit or 12bit buffer sharing 
is not supported by Neo.
I pinged the author of cl_intel_va_api_media_sharing, but got no response.
Maybe I will take some effort to update the extension spec and implement them 
in Neo myself.
I am not sure any other Neo limitation that Mark wants to add?

> Let's see how long it takes for the libva revision to be bumped up Neo.
> Here's the request for the version bump:
> https://github.com/intel/compute-runtime/issues/131
> And the PR, for these following along:
> https://github.com/intel/compute-runtime/pull/151
> ___
> 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] lavc/vaapi_decode: add va_profile format map support for HEVC_REXT

[myp...@gmail.com]

On Thu, Mar 28, 2019 at 12:03 PM Linjie Fu  wrote:
>
> HEVC_REXT will be map to {VAProfileHEVCMain422_10, VAProfileHEVCMain444,
> VAProfileHEVCMain444_10} in vaapi_profile_map[], since need to be 
> distinguished
> to select the exact va_profile.
>
> Add va_profile -> AV_PIX_FMT map for FF_PROFILE_HEVC_REXT to match the
> exact va_profile.
>
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/vaapi_decode.c | 29 +
>  1 file changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 015154b879..1cb8683b7c 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -414,6 +414,18 @@ static const struct {
>  #undef MAP
>  };
>
> +static const struct {
> +VAProfile va_profile;
> +enum AVPixelFormat pix_fmt;
> +} rext_format_map[] = {
> +#define MAP(vp, av) { VAProfileHEVCMain ## vp, AV_PIX_FMT_ ## av }
> +MAP(422_10,  YUYV422),
> +MAP(422_10,  YUV422P10LE),
> +MAP(444, YUV444P),
> +MAP(444_10,  YUV444P10LE),
> +#undef MAP
> +};
> +
>  /*
>   * Set *va_config and the frames_ref fields from the current codec parameters
>   * in avctx.
> @@ -426,7 +438,7 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
>  AVVAAPIHWConfig   *hwconfig= NULL;
>  AVHWFramesConstraints *constraints = NULL;
>  VAStatus vas;
> -int err, i, j;
> +int err, i, j, k;
>  const AVCodecDescriptor *codec_desc;
>  VAProfile *profile_list = NULL, matched_va_profile;
>  int profile_count, exact_match, matched_ff_profile;
> @@ -467,13 +479,22 @@ static int vaapi_decode_make_config(AVCodecContext 
> *avctx,
>  if (avctx->profile == vaapi_profile_map[i].codec_profile ||
>  vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
>  profile_match = 1;
> -for (j = 0; j < profile_count; j++) {
> -if (vaapi_profile_map[i].va_profile == profile_list[j]) {
> +if (avctx->profile == FF_PROFILE_HEVC_REXT) {
> +/* find the exact va_profile for HEVC_REXT */
> +for (j = 0; j < FF_ARRAY_ELEMS(rext_format_map); j++) {
> +if (avctx->pix_fmt == rext_format_map[j].pix_fmt)
> +   break;
> +}
> +if (vaapi_profile_map[i].va_profile != 
> rext_format_map[j].va_profile)
> +continue;
> +}
> +for (k = 0; k < profile_count; k++) {
> +if (vaapi_profile_map[i].va_profile == profile_list[k]) {
>  exact_match = profile_match;
>  break;
>  }
>  }
> -if (j < profile_count) {
> +if (k < profile_count) {
>  matched_va_profile = vaapi_profile_map[i].va_profile;
>  matched_ff_profile = vaapi_profile_map[i].codec_profile;
>  if (exact_match)
> --

What  intel platform supported HEVCMain422 or 444?
___
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 3/5] doc/general.texi: remove note about regressed AviSynth+ header

[Gyan]

On 25-03-2019 01:59 AM, Stephen Hutchinson wrote:

It's been fixed both AviSynth+-side and locally.
---
  doc/general.texi | 13 -
  1 file changed, 13 deletions(-)

diff --git a/doc/general.texi b/doc/general.texi
index fe94c40386..6ec52962ff 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -51,19 +51,6 @@ For Windows, supported AviSynth variants are
  For Linux and OS X, the supported AviSynth variant is
  @url{https://github.com/avxsynth/avxsynth, AvxSynth}.
  
-@float NOTE

-There is currently a regression in AviSynth+'s @code{capi.h} header as of
-October 2016, which interferes with the ability for builds of FFmpeg to use
-MSVC-built binaries of AviSynth. Until this is resolved, you can make sure
-a known good version is installed by checking out a version from before
-the regression occurred:


This would still be an issue for older versions. Maybe keep the note, 
but add a date and revision range for the affected versions.


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] x11grab: fix vertical repositioning

[Octavio Alvarez]

There is a calculation error in xcbgrab_reposition() that breaks
vertical repositioning on follow_mouse. It made the bottom
reposition occur when moving the mouse lower than N pixels after
the capture bottom edge, instead of before.

This commit fixes the calculation to match the documentation.

follow_mouse: centered or number of pixels. The documentation says:

When it is specified with "centered", the grabbing region follows
the mouse pointer and keeps the pointer at the center of region;
otherwise, the region follows only when the mouse pointer reaches
within PIXELS (greater than zero) to the edge of region.

The patch is untested, but it looks fairly straightforward.

---
 libavdevice/xcbgrab.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index 6d142abd4f..b7e689343e 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -127,7 +127,7 @@ static int xcbgrab_reposition(AVFormatContext *s,
 int left   = x + f;
 int right  = x + w - f;
 int top= y + f;
-int bottom = y + h + f;
+int bottom = y + h - f;
 if (p_x > right) {
 x += p_x - right;
 } else if (p_x < left) {
-- 
2.20.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] libavcodec/vp8dec: fix the multi-thread HWAccel decode error

[Shaofei Wang]

Fix the issue: https://github.com/intel/media-driver/issues/317

the root cause is update_dimensions will be called multple times
when decoder thread number is not only 1, but update_dimensions
call get_pixel_format in each decode thread will trigger the
hwaccel_uninit/hwaccel_init more than once. But only one hwaccel
should be shared with all decode threads.
in current context,
there are 3 situations in the update_dimensions():
1. First time calling. No matter single thread or multithread,
   get_pixel_format() should be called after dimensions were
   set;
2. Dimention changed at the runtime. Dimention need to be
   updated when macroblocks_base is already allocated,
   get_pixel_format() should be called to recreate new frames
   according to updated dimention;
3. Multithread first time calling. After decoder init, the
   other threads will call update_dimensions() at first time
   to allocate macroblocks_base and set dimensions.
   But get_pixel_format() is shouldn't be called due to low
   level frames and context are already created.

In this fix, we only call update_dimensions as need.

Signed-off-by: Wang, Shaofei 
Reviewed-by: Jun, Zhao 
Reviewed-by: Haihao Xiang 
---
Previous code reviews:
2019-03-06 9:25 GMT+01:00, Wang, Shaofei :
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf 
>> Of Carl Eugen Hoyos
>> Sent: Wednesday, March 6, 2019 3:49 PM
>> To: FFmpeg development discussions and patches 
>> 
>> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/vp8dec: fix the 
>> multi-thread HWAccel decode error
>>
>> 2018-08-09 9:09 GMT+02:00, Jun Zhao :
>> > the root cause is update_dimentions call get_pixel_format will 
>> > trigger the hwaccel_uninit/hwaccel_init , in current context, there 
>> > are 3 situations in the update_dimentions():
>> > 1. First time calling. No matter single thread or multithread,
>> >get_pixel_format() should be called after dimentions were
>> >set;
>> > 2. Dimention changed at the runtime. Dimention need to be
>> >updated when macroblocks_base is already allocated,
>> >get_pixel_format() should be called to recreate new frames
>> >according to updated dimention;
>> > 3. Multithread first time calling. After decoder init, the
>> >other threads will call update_dimentions() at first time
>> >to allocate macroblocks_base and set dimentions.
>> >But get_pixel_format() is shouldn't be called due to low
>> >level frames and context are already created.
>> > In this fix, we only call update_dimentions as need.
>> >
>> > Signed-off-by: Wang, Shaofei 
>> > Reviewed-by: Jun, Zhao 
>> > ---
>> >  libavcodec/vp8.c |7 +--
>> >  1 files changed, 5 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c index 
>> > 3adfeac..18d1ada 100644
>> > --- a/libavcodec/vp8.c
>> > +++ b/libavcodec/vp8.c
>> > @@ -187,7 +187,7 @@ static av_always_inline  int 
>> > update_dimensions(VP8Context *s, int width, int height, int is_vp7)  {
>> >  AVCodecContext *avctx = s->avctx;
>> > -int i, ret;
>> > +int i, ret, dim_reset = 0;
>> >
>> >  if (width  != s->avctx->width || ((width+15)/16 != s->mb_width 
>> > ||
>> > (height+15)/16 != s->mb_height) && s->macroblocks_base ||
>> >  height != s->avctx->height) { @@ -196,9 +196,12 @@ int 
>> > update_dimensions(VP8Context *s, int width, int height, int is_vp7)
>> >  ret = ff_set_dimensions(s->avctx, width, height);
>> >  if (ret < 0)
>> >  return ret;
>> > +
>> > +dim_reset = (s->macroblocks_base != NULL);
>> >  }
>> >
>> > -if (!s->actually_webp && !is_vp7) {
>> > +if ((s->pix_fmt == AV_PIX_FMT_NONE || dim_reset) &&
>> > + !s->actually_webp && !is_vp7) {
>>
>> Why is the new variable dim_reset needed?
>> Wouldn't the patch be simpler if you used s->macroblocks_base here?
> Since dim_reset was set in the "if" segment, it equal to (width != 
> s->avctx->width || ((width+15)/16 != s->mb_width ||
> (height+15)/16 != s->mb_height) || height != s->avctx->height) &&
> s->macroblocks_base

Thank you!

Carl Eugen


 libavcodec/vp8.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index ba79e5f..0a7f38b 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -187,7 +187,7 @@ static av_always_inline
 int update_dimensions(VP8Context *s, int width, int height, int is_vp7)
 {
 AVCodecContext *avctx = s->avctx;
-int i, ret;
+int i, ret, dim_reset = 0;
 
 if (width  != s->avctx->width || ((width+15)/16 != s->mb_width || 
(height+15)/16 != s->mb_height) && s->macroblocks_base ||
 height != s->avctx->height) {
@@ -196,9 +196,12 @@ int update_dimensions(VP8Context *s, int width, int 
height, int is_vp7)
 ret = ff_set_dimensions(s->avctx, width, height);
 if (ret < 0)
 return ret;
+
+dim_reset = (s->macroblocks_base != NULL);
 }
 
-if 

[FFmpeg-devel] [PATCH] lavc/vaapi_decode: add va_profile format map support for HEVC_REXT

[Linjie Fu]

HEVC_REXT will be map to {VAProfileHEVCMain422_10, VAProfileHEVCMain444,
VAProfileHEVCMain444_10} in vaapi_profile_map[], since need to be distinguished
to select the exact va_profile.

Add va_profile -> AV_PIX_FMT map for FF_PROFILE_HEVC_REXT to match the
exact va_profile.

Signed-off-by: Linjie Fu 
---
 libavcodec/vaapi_decode.c | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 015154b879..1cb8683b7c 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -414,6 +414,18 @@ static const struct {
 #undef MAP
 };
 
+static const struct {
+VAProfile va_profile;
+enum AVPixelFormat pix_fmt;
+} rext_format_map[] = {
+#define MAP(vp, av) { VAProfileHEVCMain ## vp, AV_PIX_FMT_ ## av }
+MAP(422_10,  YUYV422),
+MAP(422_10,  YUV422P10LE),
+MAP(444, YUV444P),
+MAP(444_10,  YUV444P10LE),
+#undef MAP
+};
+
 /*
  * Set *va_config and the frames_ref fields from the current codec parameters
  * in avctx.
@@ -426,7 +438,7 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
 AVVAAPIHWConfig   *hwconfig= NULL;
 AVHWFramesConstraints *constraints = NULL;
 VAStatus vas;
-int err, i, j;
+int err, i, j, k;
 const AVCodecDescriptor *codec_desc;
 VAProfile *profile_list = NULL, matched_va_profile;
 int profile_count, exact_match, matched_ff_profile;
@@ -467,13 +479,22 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
 if (avctx->profile == vaapi_profile_map[i].codec_profile ||
 vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
 profile_match = 1;
-for (j = 0; j < profile_count; j++) {
-if (vaapi_profile_map[i].va_profile == profile_list[j]) {
+if (avctx->profile == FF_PROFILE_HEVC_REXT) {
+/* find the exact va_profile for HEVC_REXT */
+for (j = 0; j < FF_ARRAY_ELEMS(rext_format_map); j++) {
+if (avctx->pix_fmt == rext_format_map[j].pix_fmt)
+   break;
+}
+if (vaapi_profile_map[i].va_profile != 
rext_format_map[j].va_profile)
+continue;
+}
+for (k = 0; k < profile_count; k++) {
+if (vaapi_profile_map[i].va_profile == profile_list[k]) {
 exact_match = profile_match;
 break;
 }
 }
-if (j < profile_count) {
+if (k < profile_count) {
 matched_va_profile = vaapi_profile_map[i].va_profile;
 matched_ff_profile = vaapi_profile_map[i].codec_profile;
 if (exact_match)
-- 
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] configure: include pkgconfig path as vaapi header search

[Dennis Mungai]

On Thu, 28 Mar 2019 at 06:27, Song, Ruiling  wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Dennis Mungai
> > Sent: Thursday, March 28, 2019 11:15 AM
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as
> vaapi
> > header search
> >
> > On Thu, 28 Mar 2019 at 06:10, Song, Ruiling 
> wrote:
> >
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of
> > > > Dennis Mungai
> > > > Sent: Thursday, March 28, 2019 7:11 AM
> > > > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig
> path as
> > > vaapi
> > > > header search
> > > >
> > > > On Thu, 28 Mar 2019 at 02:05, Mark Thompson  wrote:
> > > >
> > > > > On 20/03/2019 07:57, Zhong Li wrote:
> > > > > > Currectly just standard header path and be found,
> > > > > > check_type/struct will fail if vaapi is installed somewhere else.
> > > > > > ---
> > > > > >  configure | 18 ++
> > > > > >  1 file changed, 10 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/configure b/configure
> > > > > > index eaf543df96..0e3c2d24bf 100755
> > > > > > --- a/configure
> > > > > > +++ b/configure
> > > > > > @@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h"
> > > > > "ID3D11VideoDecoder"
> > > > > >  check_type "windows.h d3d11.h" "ID3D11VideoContext"
> > > > > >  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
> > > > > -D_WIN32_WINNT=0x0602
> > > > > >
> > > > > > -check_type "va/va.h va/va_dec_hevc.h"
> > "VAPictureParameterBufferHEVC"
> > > > > > -check_struct "va/va.h" "VADecPictureParameterBufferVP9"
> bit_depth
> > > > > > -check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> > > rotation_flags
> > > > > > -check_type "va/va.h va/va_enc_hevc.h"
> > > > "VAEncPictureParameterBufferHEVC"
> > > > > > -check_type "va/va.h va/va_enc_jpeg.h"
> > > > "VAEncPictureParameterBufferJPEG"
> > > > > > -check_type "va/va.h va/va_enc_vp8.h"
> > > "VAEncPictureParameterBufferVP8"
> > > > > > -check_type "va/va.h va/va_enc_vp9.h"
> > > "VAEncPictureParameterBufferVP9"
> > > > > > -
> > > > > >  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
> > > > > >
> > > > > >  if enabled cuda_sdk; then
> > > > > > @@ -6469,6 +6461,16 @@ if enabled vaapi; then
> > > > > >  check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1,
> 0,
> > > 0)"
> > > > > >  fi
> > > > > >
> > > > > > +if enabled vaapi; then
> > > > >
> > > > > Merge this into the previous block, which has the same condition.
> > > > >
> > > > > > +check_type "va/va.h va/va_dec_hevc.h"
> > > > "VAPictureParameterBufferHEVC"
> > > > > > +check_struct "va/va.h" "VADecPictureParameterBufferVP9"
> > > bit_depth
> > > > > > +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> > > > > rotation_flags
> > > > > > +check_type "va/va.h va/va_enc_hevc.h"
> > > > > "VAEncPictureParameterBufferHEVC"
> > > > > > +check_type "va/va.h va/va_enc_jpeg.h"
> > > > > "VAEncPictureParameterBufferJPEG"
> > > > > > +check_type "va/va.h va/va_enc_vp8.h"
> > > > > "VAEncPictureParameterBufferVP8"
> > > > > > +check_type "va/va.h va/va_enc_vp9.h"
> > > > > "VAEncPictureParameterBufferVP9"
> > > > > > +fi
> > > > > > +
> > > > > >  if enabled_all opencl libdrm ; then
> > > > > >  check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
> > > > > >  enable opencl_drm_beignet
> > > > > >
> > > > >
> > > > > LGTM with that.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > - Mark
> > > > >
> > > > >
> > > > Does a similar check exist for Intel's Neo OpenCL runtime?
> > > Do you mean checking whether package intel-opencl (Neo package) exists
> in
> > > the system?
> > >
> > >
> >
> > Yes.
> >
> > Neo is the successor to Beignet, correct?
> Yes, that's the truth.
> Currently we simply checking against the specific header file of OpenCL,
> which is in-fact not accurate.
> I am not sure whether you would like to use Neo together with
> intel-media-driver, which is the most targeted opencl usage in FFmpeg.
> If that's the case, I think it may be hard to find a matching
> intel-media-driver to work with Neo release package.
> Because Neo release version depends on a very outdated libva revision.
> I just sent a patch to Neo to update libva revision dependency. Once they
> accept the patch and new Neo release package comes out,
> I think we can change to check against Neo package. People would not need
> to build Neo themselves then.
>
> Thanks!
> Ruiling
> >
> > Enabling similar functionality for Neo should allow for the same feature
> > support for these not using Beignet.
>
>
Indeed, I'd want to use Neo + intel-media-driver.
Judging by the (relatively low) development activity on Beignet of late,
its' considered ready to deprecate in place of Neo, 

Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi header search

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Dennis Mungai
> Sent: Thursday, March 28, 2019 11:15 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi
> header search
> 
> On Thu, 28 Mar 2019 at 06:10, Song, Ruiling  wrote:
> 
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of
> > > Dennis Mungai
> > > Sent: Thursday, March 28, 2019 7:11 AM
> > > To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as
> > vaapi
> > > header search
> > >
> > > On Thu, 28 Mar 2019 at 02:05, Mark Thompson  wrote:
> > >
> > > > On 20/03/2019 07:57, Zhong Li wrote:
> > > > > Currectly just standard header path and be found,
> > > > > check_type/struct will fail if vaapi is installed somewhere else.
> > > > > ---
> > > > >  configure | 18 ++
> > > > >  1 file changed, 10 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/configure b/configure
> > > > > index eaf543df96..0e3c2d24bf 100755
> > > > > --- a/configure
> > > > > +++ b/configure
> > > > > @@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h"
> > > > "ID3D11VideoDecoder"
> > > > >  check_type "windows.h d3d11.h" "ID3D11VideoContext"
> > > > >  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
> > > > -D_WIN32_WINNT=0x0602
> > > > >
> > > > > -check_type "va/va.h va/va_dec_hevc.h"
> "VAPictureParameterBufferHEVC"
> > > > > -check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > > > > -check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> > rotation_flags
> > > > > -check_type "va/va.h va/va_enc_hevc.h"
> > > "VAEncPictureParameterBufferHEVC"
> > > > > -check_type "va/va.h va/va_enc_jpeg.h"
> > > "VAEncPictureParameterBufferJPEG"
> > > > > -check_type "va/va.h va/va_enc_vp8.h"
> > "VAEncPictureParameterBufferVP8"
> > > > > -check_type "va/va.h va/va_enc_vp9.h"
> > "VAEncPictureParameterBufferVP9"
> > > > > -
> > > > >  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
> > > > >
> > > > >  if enabled cuda_sdk; then
> > > > > @@ -6469,6 +6461,16 @@ if enabled vaapi; then
> > > > >  check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0,
> > 0)"
> > > > >  fi
> > > > >
> > > > > +if enabled vaapi; then
> > > >
> > > > Merge this into the previous block, which has the same condition.
> > > >
> > > > > +check_type "va/va.h va/va_dec_hevc.h"
> > > "VAPictureParameterBufferHEVC"
> > > > > +check_struct "va/va.h" "VADecPictureParameterBufferVP9"
> > bit_depth
> > > > > +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> > > > rotation_flags
> > > > > +check_type "va/va.h va/va_enc_hevc.h"
> > > > "VAEncPictureParameterBufferHEVC"
> > > > > +check_type "va/va.h va/va_enc_jpeg.h"
> > > > "VAEncPictureParameterBufferJPEG"
> > > > > +check_type "va/va.h va/va_enc_vp8.h"
> > > > "VAEncPictureParameterBufferVP8"
> > > > > +check_type "va/va.h va/va_enc_vp9.h"
> > > > "VAEncPictureParameterBufferVP9"
> > > > > +fi
> > > > > +
> > > > >  if enabled_all opencl libdrm ; then
> > > > >  check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
> > > > >  enable opencl_drm_beignet
> > > > >
> > > >
> > > > LGTM with that.
> > > >
> > > > Thanks,
> > > >
> > > > - Mark
> > > >
> > > >
> > > Does a similar check exist for Intel's Neo OpenCL runtime?
> > Do you mean checking whether package intel-opencl (Neo package) exists in
> > the system?
> >
> >
> 
> Yes.
> 
> Neo is the successor to Beignet, correct?
Yes, that's the truth.
Currently we simply checking against the specific header file of OpenCL, which 
is in-fact not accurate.
I am not sure whether you would like to use Neo together with 
intel-media-driver, which is the most targeted opencl usage in FFmpeg.
If that's the case, I think it may be hard to find a matching 
intel-media-driver to work with Neo release package.
Because Neo release version depends on a very outdated libva revision.
I just sent a patch to Neo to update libva revision dependency. Once they 
accept the patch and new Neo release package comes out,
I think we can change to check against Neo package. People would not need to 
build Neo themselves then.

Thanks!
Ruiling
> 
> Enabling similar functionality for Neo should allow for the same feature
> support for these not using Beignet.
> ___
> 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

Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi header search

[Dennis Mungai]

On Thu, 28 Mar 2019 at 06:10, Song, Ruiling  wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Dennis Mungai
> > Sent: Thursday, March 28, 2019 7:11 AM
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as
> vaapi
> > header search
> >
> > On Thu, 28 Mar 2019 at 02:05, Mark Thompson  wrote:
> >
> > > On 20/03/2019 07:57, Zhong Li wrote:
> > > > Currectly just standard header path and be found,
> > > > check_type/struct will fail if vaapi is installed somewhere else.
> > > > ---
> > > >  configure | 18 ++
> > > >  1 file changed, 10 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/configure b/configure
> > > > index eaf543df96..0e3c2d24bf 100755
> > > > --- a/configure
> > > > +++ b/configure
> > > > @@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h"
> > > "ID3D11VideoDecoder"
> > > >  check_type "windows.h d3d11.h" "ID3D11VideoContext"
> > > >  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
> > > -D_WIN32_WINNT=0x0602
> > > >
> > > > -check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> > > > -check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > > > -check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> rotation_flags
> > > > -check_type "va/va.h va/va_enc_hevc.h"
> > "VAEncPictureParameterBufferHEVC"
> > > > -check_type "va/va.h va/va_enc_jpeg.h"
> > "VAEncPictureParameterBufferJPEG"
> > > > -check_type "va/va.h va/va_enc_vp8.h"
> "VAEncPictureParameterBufferVP8"
> > > > -check_type "va/va.h va/va_enc_vp9.h"
> "VAEncPictureParameterBufferVP9"
> > > > -
> > > >  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
> > > >
> > > >  if enabled cuda_sdk; then
> > > > @@ -6469,6 +6461,16 @@ if enabled vaapi; then
> > > >  check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0,
> 0)"
> > > >  fi
> > > >
> > > > +if enabled vaapi; then
> > >
> > > Merge this into the previous block, which has the same condition.
> > >
> > > > +check_type "va/va.h va/va_dec_hevc.h"
> > "VAPictureParameterBufferHEVC"
> > > > +check_struct "va/va.h" "VADecPictureParameterBufferVP9"
> bit_depth
> > > > +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> > > rotation_flags
> > > > +check_type "va/va.h va/va_enc_hevc.h"
> > > "VAEncPictureParameterBufferHEVC"
> > > > +check_type "va/va.h va/va_enc_jpeg.h"
> > > "VAEncPictureParameterBufferJPEG"
> > > > +check_type "va/va.h va/va_enc_vp8.h"
> > > "VAEncPictureParameterBufferVP8"
> > > > +check_type "va/va.h va/va_enc_vp9.h"
> > > "VAEncPictureParameterBufferVP9"
> > > > +fi
> > > > +
> > > >  if enabled_all opencl libdrm ; then
> > > >  check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
> > > >  enable opencl_drm_beignet
> > > >
> > >
> > > LGTM with that.
> > >
> > > Thanks,
> > >
> > > - Mark
> > >
> > >
> > Does a similar check exist for Intel's Neo OpenCL runtime?
> Do you mean checking whether package intel-opencl (Neo package) exists in
> the system?
>
>

Yes.

Neo is the successor to Beignet, correct?

Enabling similar functionality for Neo should allow for the same feature
support for these not using Beignet.
___
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] configure: include pkgconfig path as vaapi header search

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Dennis Mungai
> Sent: Thursday, March 28, 2019 7:11 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi
> header search
> 
> On Thu, 28 Mar 2019 at 02:05, Mark Thompson  wrote:
> 
> > On 20/03/2019 07:57, Zhong Li wrote:
> > > Currectly just standard header path and be found,
> > > check_type/struct will fail if vaapi is installed somewhere else.
> > > ---
> > >  configure | 18 ++
> > >  1 file changed, 10 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/configure b/configure
> > > index eaf543df96..0e3c2d24bf 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h"
> > "ID3D11VideoDecoder"
> > >  check_type "windows.h d3d11.h" "ID3D11VideoContext"
> > >  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
> > -D_WIN32_WINNT=0x0602
> > >
> > > -check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> > > -check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > > -check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
> > > -check_type "va/va.h va/va_enc_hevc.h"
> "VAEncPictureParameterBufferHEVC"
> > > -check_type "va/va.h va/va_enc_jpeg.h"
> "VAEncPictureParameterBufferJPEG"
> > > -check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
> > > -check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
> > > -
> > >  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
> > >
> > >  if enabled cuda_sdk; then
> > > @@ -6469,6 +6461,16 @@ if enabled vaapi; then
> > >  check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
> > >  fi
> > >
> > > +if enabled vaapi; then
> >
> > Merge this into the previous block, which has the same condition.
> >
> > > +check_type "va/va.h va/va_dec_hevc.h"
> "VAPictureParameterBufferHEVC"
> > > +check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > > +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> > rotation_flags
> > > +check_type "va/va.h va/va_enc_hevc.h"
> > "VAEncPictureParameterBufferHEVC"
> > > +check_type "va/va.h va/va_enc_jpeg.h"
> > "VAEncPictureParameterBufferJPEG"
> > > +check_type "va/va.h va/va_enc_vp8.h"
> > "VAEncPictureParameterBufferVP8"
> > > +check_type "va/va.h va/va_enc_vp9.h"
> > "VAEncPictureParameterBufferVP9"
> > > +fi
> > > +
> > >  if enabled_all opencl libdrm ; then
> > >  check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
> > >  enable opencl_drm_beignet
> > >
> >
> > LGTM with that.
> >
> > Thanks,
> >
> > - Mark
> >
> >
> Does a similar check exist for Intel's Neo OpenCL runtime?
Do you mean checking whether package intel-opencl (Neo package) exists in the 
system?

> ___
> 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] lavf/tls_gnutls: retry gnutls_handshake on non fatal errors

[amine remita]

this patch is based on the documentation for gnutls_handshake
:

> On these non-fatal errors call this function again, until it returns 0
>
and the examples from the gnutls manual, such as:
https://gnutls.org/manual/html_node/Client-with-Resume-capability-example.html
https://gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html
https://gnutls.org/manual/html_node/Datagram-TLS-client-example.html

On Thu, Mar 28, 2019 at 12:51 AM Michael Niedermayer 
wrote:

> On Wed, Mar 27, 2019 at 01:03:07PM +0100, Remita Amine wrote:
> > fixes #7801
> >
> > Signed-off-by: Remita Amine 
> > ---
> >  libavformat/tls_gnutls.c | 12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
> > index e3c43683be..f32bc2821b 100644
> > --- a/libavformat/tls_gnutls.c
> > +++ b/libavformat/tls_gnutls.c
> > @@ -182,11 +182,13 @@ static int tls_open(URLContext *h, const char
> *uri, int flags, AVDictionary **op
> >  gnutls_transport_set_push_function(p->session, gnutls_url_push);
> >  gnutls_transport_set_ptr(p->session, c->tcp);
> >  gnutls_priority_set_direct(p->session, "NORMAL", NULL);
> > -ret = gnutls_handshake(p->session);
> > -if (ret) {
> > -ret = print_tls_error(h, ret);
> > -goto fail;
> > -}
> > +do {
> > +ret = gnutls_handshake(p->session);
> > +if (gnutls_error_is_fatal(ret)) {
> > +ret = print_tls_error(h, ret);
> > +goto fail;
> > +}
> > +} while (ret);
>
> is retrying the correct action for every non fatal error ?
> is there a maximum retry count ? if not this could potentially
> loop forever
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Old school: Use the lowest level language in which you can solve the
> problem
> conveniently.
> New school: Use the highest level language in which the latest
> supercomputer
> can solve the problem without the user falling asleep waiting.
> ___
> 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 v1 1/1] swscale/swscale_unscaled: fixed the issue that when width/height is not 2-multiple, transition of nv12 to u/v planes is not completed.

[Michael Niedermayer]

On Wed, Mar 27, 2019 at 06:18:28PM +0800, Decai Lin wrote:
> From: "Dong, Jerry" 
> 
> Signed-off-by: Dong, Jerry 
> Signed-off-by: Decai Lin 
> ---
>  libswscale/swscale_unscaled.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> index 058f2b9..2ba2907 100644
> --- a/libswscale/swscale_unscaled.c
> +++ b/libswscale/swscale_unscaled.c
> @@ -150,10 +150,10 @@ static int planarToNv12Wrapper(SwsContext *c, const 
> uint8_t *src[],
>dstParam[0], dstStride[0]);
>  
>  if (c->dstFormat == AV_PIX_FMT_NV12)
> -interleaveBytes(src[1], src[2], dst, c->srcW / 2, srcSliceH / 2,
> +interleaveBytes(src[1], src[2], dst, (c->srcW + 1) / 2, (srcSliceH + 
> 1) / 2,
>  srcStride[1], srcStride[2], dstStride[1]);
>  else
> -interleaveBytes(src[2], src[1], dst, c->srcW / 2, srcSliceH / 2,
> +interleaveBytes(src[2], src[1], dst, (c->srcW + 1) / 2, (srcSliceH + 
> 1) / 2,
>  srcStride[2], srcStride[1], dstStride[1]);
>  
>  return srcSliceH;

this can probably use chrSrcW

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]configure: Use -Wno-gnu-variable-sized-type-not-at-end with clang

[Carl Eugen Hoyos]

2019-03-27 15:18 GMT+01:00, Carl Eugen Hoyos :

> Attached patch fixes many warnings when compiling vaapi with clang.
> Also tested with clang-3.4.

Will push if there are no comments.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavc/vaap_hevc: Do not initialize fields twice

[Carl Eugen Hoyos]

2019-03-27 23:10 GMT+01:00, Mark Thompson :
> On 27/03/2019 13:58, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes a warning when compiling vaapi with clang.
>>
>> From 6463a3cf5730be9e9e6003f4aaf6c9fab7f68407 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Wed, 27 Mar 2019 14:52:35 +0100
>> Subject: [PATCH] lavc/vaapi_hevc: Do not initialize fields twice.
>>
>> Fixes the following compilation warnings:
>> libavcodec/vaapi_hevc.c:155:21: warning: initializer overrides prior
>> initialization of this subobject [-Winitializer-overrides]
>> .pic_fields.bits = {
>>~^~~~
>> libavcodec/vaapi_hevc.c:125:57: note: previous initialization is here
>> .pic_fields.value = 0,
>> ^
>> libavcodec/vaapi_hevc.c:175:31: warning: initializer overrides prior
>> initialization of this subobject [-Winitializer-overrides]
>> .slice_parsing_fields.bits = {
>>  ~^~~~
>> libavcodec/vaapi_hevc.c:126:57: note: previous initialization is here
>> .slice_parsing_fields.value   = 0,
>> ---
>>  libavcodec/vaapi_hevc.c |2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
>> index 19aabcd..c69d63d 100644
>> --- a/libavcodec/vaapi_hevc.c
>> +++ b/libavcodec/vaapi_hevc.c
>> @@ -122,8 +122,6 @@ static int vaapi_hevc_start_frame(AVCodecContext
>>*avctx,
>>  pic->pic.output_surface = ff_vaapi_get_surface_id(h->ref->frame);
>>
>>  pic->pic_param = (VAPictureParameterBufferHEVC) {
>> -.pic_fields.value = 0,
>> -.slice_parsing_fields.value   = 0,
>>  .pic_width_in_luma_samples= sps->width,
>>  .pic_height_in_luma_samples   = sps->height,
>>  .log2_min_luma_coding_block_size_minus3   =
>> sps->log2_min_cb_size - 3,
>> --
>> 1.7.10.4
>
> LGTM.

Patch applied.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavc/vaapi_h264: Do not set unused deprecated fields

[Carl Eugen Hoyos]

2019-03-27 23:16 GMT+01:00, Mark Thompson :
> On 27/03/2019 14:02, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> I don't think setting vaapi fields that are deprecated makes sense, this
>> also silences a warning when compiling with clang.
>>
>> Please comment, Carl Eugen
>>
>> From b1f4e64e577ffecd1eab7b95d8d6f90e261cdd74 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Wed, 27 Mar 2019 14:58:51 +0100
>> Subject: [PATCH] lavc/vaapi_264: Do not set deprecated unused fields.
>>
>> Fixes the following warnings:
>> libavcodec/vaapi_h264.c:259:10: warning: 'num_slice_groups_minus1' is
>> deprecated [-Wdeprecated-declarations]
>> .num_slice_groups_minus1=
>> pps->slice_group_count - 1,
>>  ^
>> libavcodec/vaapi_h264.c:260:10: warning: 'slice_group_map_type' is
>> deprecated [-Wdeprecated-declarations]
>> .slice_group_map_type   =
>> pps->mb_slice_group_map_type,
>>  ^
>> libavcodec/vaapi_h264.c:261:10: warning: 'slice_group_change_rate_minus1'
>> is deprecated [-Wdeprecated-declarations]
>> .slice_group_change_rate_minus1 = 0, /* FMO is not
>> implemented */
>>  ^
>> ---
>>  libavcodec/vaapi_h264.c |3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
>> index 5854587..dd2a657 100644
>> --- a/libavcodec/vaapi_h264.c
>> +++ b/libavcodec/vaapi_h264.c
>> @@ -256,9 +256,6 @@ static int vaapi_h264_start_frame(AVCodecContext
>>*avctx,
>>  .log2_max_pic_order_cnt_lsb_minus4  =
>> sps->log2_max_poc_lsb - 4,
>>  .delta_pic_order_always_zero_flag   =
>> sps->delta_pic_order_always_zero_flag,
>>  },
>> -.num_slice_groups_minus1=
>> pps->slice_group_count - 1,
>> -.slice_group_map_type   =
>> pps->mb_slice_group_map_type,
>> -.slice_group_change_rate_minus1 = 0, /* FMO is not
>> implemented */
>>  .pic_init_qp_minus26= pps->init_qp - 26,
>>  .pic_init_qs_minus26= pps->init_qs - 26,
>>  .chroma_qp_index_offset =
>> pps->chroma_qp_index_offset[0],
>> --
>> 1.7.10.4
>
> They aren't deprecated on all VAAPI versions we support (try building with
> libva < 2).
>
> I think the change is ok anyway because zero is fine as a value for them?
> The commit message should probably mention that if you want to go with it.

Pushed with a more verbose commit message.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavf/tls_gnutls: retry gnutls_handshake on non fatal errors

[Michael Niedermayer]

On Wed, Mar 27, 2019 at 01:03:07PM +0100, Remita Amine wrote:
> fixes #7801
> 
> Signed-off-by: Remita Amine 
> ---
>  libavformat/tls_gnutls.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
> index e3c43683be..f32bc2821b 100644
> --- a/libavformat/tls_gnutls.c
> +++ b/libavformat/tls_gnutls.c
> @@ -182,11 +182,13 @@ static int tls_open(URLContext *h, const char *uri, int 
> flags, AVDictionary **op
>  gnutls_transport_set_push_function(p->session, gnutls_url_push);
>  gnutls_transport_set_ptr(p->session, c->tcp);
>  gnutls_priority_set_direct(p->session, "NORMAL", NULL);
> -ret = gnutls_handshake(p->session);
> -if (ret) {
> -ret = print_tls_error(h, ret);
> -goto fail;
> -}
> +do {
> +ret = gnutls_handshake(p->session);
> +if (gnutls_error_is_fatal(ret)) {
> +ret = print_tls_error(h, ret);
> +goto fail;
> +}
> +} while (ret);

is retrying the correct action for every non fatal error ?
is there a maximum retry count ? if not this could potentially
loop forever


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: add bink2 video decoder

[Carl Eugen Hoyos]

2019-03-27 21:21 GMT+01:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol 
> ---
> Missing deblocking.

Patch contains an "if (0 && ..." somewhere, I assume this
is unintended.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: get vps extradata from MSDK

[Mark Thompson]

On 27/03/2019 10:27, Zhong Li wrote:
> Signed-off-by: Zhong Li 
> ---
> V2: Fix the regression of qsv h264 encoding since no VPS for h264
> 
>  libavcodec/qsvenc.c  | 53 ++--
>  libavcodec/qsvenc.h  |  3 +++
>  libavcodec/qsvenc_hevc.c | 10 +---
>  3 files changed, 54 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 576d88c259..2f128597db 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -810,6 +810,16 @@ static int qsv_retrieve_enc_params(AVCodecContext 
> *avctx, QSVEncContext *q)
>  };
>  #endif
>  
> +#if QSV_HAVE_CO_VPS
> +uint8_t vps_buf[128];

Is this necessarily enough?  A VPS can be large when it defines sublayers.

> +mfxExtCodingOptionVPS extradata_vps = {
> +.Header.BufferId = MFX_EXTBUFF_CODING_OPTION_VPS,
> +.Header.BufferSz = sizeof(extradata_vps),
> +.VPSBuffer   = vps_buf,
> +.VPSBufSize  = sizeof(vps_buf),
> +};
> +#endif
> +
>  mfxExtBuffer *ext_buffers[] = {
>  (mfxExtBuffer*),
>  (mfxExtBuffer*),
> @@ -818,14 +828,24 @@ static int qsv_retrieve_enc_params(AVCodecContext 
> *avctx, QSVEncContext *q)
>  #endif
>  #if QSV_HAVE_CO3
>  (mfxExtBuffer*),
> +#endif
> +#if QSV_HAVE_CO_VPS
> +(mfxExtBuffer*)_vps,
>  #endif
>  };
>  
>  int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
> -int ret;
> +int ret, extradata_offset = 0;
>  
>  q->param.ExtParam= ext_buffers;
> +
> +#if QSV_HAVE_CO_VPS
> +q->hevc_vps = ((avctx->codec_id == AV_CODEC_ID_HEVC) && 
> QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 17));
> +q->param.NumExtParam = FF_ARRAY_ELEMS(ext_buffers) - 1 + q->hevc_vps;

The array definition and then this length feels a bit overly tricky - any 
change here will be quite confusing (consider adding a new ExtBuffer).

Making ext_buffers large enough with a running nb_ext_buffers total and then 
adding the extra one only if H.265 would feel safer to me?

> +#else
> +q->hevc_vps = 0;
>  q->param.NumExtParam = FF_ARRAY_ELEMS(ext_buffers);
> +#endif
>  
>  ret = MFXVideoENCODE_GetVideoParam(q->session, >param);
>  if (ret < 0)
> @@ -834,20 +854,37 @@ static int qsv_retrieve_enc_params(AVCodecContext 
> *avctx, QSVEncContext *q)
>  
>  q->packet_size = q->param.mfx.BufferSizeInKB * 
> q->param.mfx.BRCParamMultiplier * 1000;
>  
> -if (!extradata.SPSBufSize || (need_pps && !extradata.PPSBufSize)) {
> +if (!extradata.SPSBufSize || (need_pps && !extradata.PPSBufSize)
> +#if QSV_HAVE_CO_VPS
> +|| (q->hevc_vps && !extradata_vps.VPSBufSize)
> +#endif
> +) {
>  av_log(avctx, AV_LOG_ERROR, "No extradata returned from libmfx.\n");
>  return AVERROR_UNKNOWN;
>  }
>  
> -avctx->extradata = av_malloc(extradata.SPSBufSize + need_pps * 
> extradata.PPSBufSize +
> - AV_INPUT_BUFFER_PADDING_SIZE);
> +avctx->extradata_size = extradata.SPSBufSize + need_pps * 
> extradata.PPSBufSize;
> +#if QSV_HAVE_CO_VPS
> +avctx->extradata_size += q->hevc_vps * extradata_vps.VPSBufSize;
> +#endif
> +
> +avctx->extradata = av_malloc(avctx->extradata_size + 
> AV_INPUT_BUFFER_PADDING_SIZE);
>  if (!avctx->extradata)
>  return AVERROR(ENOMEM);
>  
> -memcpy(avctx->extradata,sps_buf, 
> extradata.SPSBufSize);
> -if (need_pps)
> -memcpy(avctx->extradata + extradata.SPSBufSize, pps_buf, 
> extradata.PPSBufSize);
> -avctx->extradata_size = extradata.SPSBufSize + need_pps * 
> extradata.PPSBufSize;
> +#if QSV_HAVE_CO_VPS
> +if (q->hevc_vps) {
> +memcpy(avctx->extradata, vps_buf, extradata_vps.VPSBufSize);
> +extradata_offset += extradata_vps.VPSBufSize;
> +}
> +#endif
> +
> +memcpy(avctx->extradata + extradata_offset, sps_buf, 
> extradata.SPSBufSize);
> +extradata_offset += extradata.SPSBufSize;
> +if (need_pps) {
> +memcpy(avctx->extradata + extradata_offset, pps_buf, 
> extradata.PPSBufSize);
> +extradata_offset += extradata.PPSBufSize;
> +}
>  memset(avctx->extradata + avctx->extradata_size, 0, 
> AV_INPUT_BUFFER_PADDING_SIZE);
>  
>  cpb_props = ff_add_cpb_side_data(avctx);
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index 25105894f2..f01453e67f 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -36,6 +36,7 @@
>  
>  #define QSV_HAVE_CO2 QSV_VERSION_ATLEAST(1, 6)
>  #define QSV_HAVE_CO3 QSV_VERSION_ATLEAST(1, 11)
> +#define QSV_HAVE_CO_VPS  QSV_VERSION_ATLEAST(1, 17)
>  
>  #define QSV_HAVE_TRELLIS QSV_VERSION_ATLEAST(1, 8)
>  #define QSV_HAVE_MAX_SLICE_SIZE QSV_VERSION_ATLEAST(1, 9)
> @@ -135,6 +136,8 @@ typedef struct QSVEncContext {
>  
>  mfxVersion  ver;
>  
> +int hevc_vps;
> +
>  // options set by the caller
>  int async_depth;
>  int idr_interval;
> diff --git a/libavcodec/qsvenc_hevc.c 

Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi header search

[Dennis Mungai]

On Thu, 28 Mar 2019 at 02:05, Mark Thompson  wrote:

> On 20/03/2019 07:57, Zhong Li wrote:
> > Currectly just standard header path and be found,
> > check_type/struct will fail if vaapi is installed somewhere else.
> > ---
> >  configure | 18 ++
> >  1 file changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/configure b/configure
> > index eaf543df96..0e3c2d24bf 100755
> > --- a/configure
> > +++ b/configure
> > @@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h"
> "ID3D11VideoDecoder"
> >  check_type "windows.h d3d11.h" "ID3D11VideoContext"
> >  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
> -D_WIN32_WINNT=0x0602
> >
> > -check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> > -check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > -check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
> > -check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
> > -check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
> > -check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
> > -check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
> > -
> >  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
> >
> >  if enabled cuda_sdk; then
> > @@ -6469,6 +6461,16 @@ if enabled vaapi; then
> >  check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
> >  fi
> >
> > +if enabled vaapi; then
>
> Merge this into the previous block, which has the same condition.
>
> > +check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> > +check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> rotation_flags
> > +check_type "va/va.h va/va_enc_hevc.h"
> "VAEncPictureParameterBufferHEVC"
> > +check_type "va/va.h va/va_enc_jpeg.h"
> "VAEncPictureParameterBufferJPEG"
> > +check_type "va/va.h va/va_enc_vp8.h"
> "VAEncPictureParameterBufferVP8"
> > +check_type "va/va.h va/va_enc_vp9.h"
> "VAEncPictureParameterBufferVP9"
> > +fi
> > +
> >  if enabled_all opencl libdrm ; then
> >  check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
> >  enable opencl_drm_beignet
> >
>
> LGTM with that.
>
> Thanks,
>
> - Mark
>
>
Does a similar check exist for Intel's Neo OpenCL runtime?
___
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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage

[Carl Eugen Hoyos]

2019-03-23 16:11 GMT+01:00, Thilo Borgmann :
> Hi,
>
>> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany!
>> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March.
>> You can find more details on their homepage:
>>
>> https://chemnitzer.linux-tage.de/2019/en/
>
> we returned from last weekends CLT. We again had a great time there with a
> lot of interested users and even some involvement in the capturing and
> streaming of the talks.
>
> We presented the usual demos showing filters and capturing. We could acquire
> new hardware for the project during the fair, so we'll be ablte to
> significantly update our presentation for the next conference to run on that
> hardware.
>
> Hotel and transportation has been handled like in the years before, so there
> will be some requests about that soon.

My flight from Vienna to Berlin and back (Thilo drove us to Chemnitz)
was 103,50, I will send the invoice to Stefano.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi header search

[Mark Thompson]

On 20/03/2019 07:57, Zhong Li wrote:
> Currectly just standard header path and be found,
> check_type/struct will fail if vaapi is installed somewhere else.
> ---
>  configure | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/configure b/configure
> index eaf543df96..0e3c2d24bf 100755
> --- a/configure
> +++ b/configure
> @@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
>  check_type "windows.h d3d11.h" "ID3D11VideoContext"
>  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode 
> -D_WIN32_WINNT=0x0602
>  
> -check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> -check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> -check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
> -check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
> -check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
> -check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
> -check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
> -
>  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
>  
>  if enabled cuda_sdk; then
> @@ -6469,6 +6461,16 @@ if enabled vaapi; then
>  check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
>  fi
>  
> +if enabled vaapi; then

Merge this into the previous block, which has the same condition.

> +check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> +check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
> +check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
> +check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
> +check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
> +check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
> +fi
> +
>  if enabled_all opencl libdrm ; then
>  check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
>  enable opencl_drm_beignet
> 

LGTM with that.

Thanks,

- Mark
___
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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage

[Thomas Volkert]

Hi,

On 23.03.2019 16:11, Thilo Borgmann wrote:
> Hi,
>
>> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany!
>> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March.
>> You can find more details on their homepage:
>>
>> https://chemnitzer.linux-tage.de/2019/en/
> we returned from last weekends CLT. We again had a great time there with a 
> lot of interested users and even some involvement in the capturing and 
> streaming of the talks.
>
> We presented the usual demos showing filters and capturing. We could acquire 
> new hardware for the project during the fair, so we'll be ablte to 
> significantly update our presentation for the next conference to run on that 
> hardware.
>
> Hotel and transportation has been handled like in the years before, so there 
> will be some requests about that soon.

My expenses contained:
- 200,41 € for 1080 km of traveling from the area of Stuttgart to Chemnitz
(transporting monitor and other equipment, stopped midway again)
- 280€ for the hotel suite during the weekend for our team (Thilo Borgmann, 
Carl Eugen Hoyos, Alexander Strasser & me)

=> 480,41 €

If this gets acknowledged, I will send the invoices to Stefano.


Best regards,
Thomas.

___
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] configure: Do not enable both OpenCL-VAAPI interop modes simultaneously

[Mark Thompson]

On 27/03/2019 00:59, Song, Ruiling wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Mark Thompson
>> Sent: Wednesday, March 27, 2019 7:39 AM
>> To: FFmpeg development discussions and patches 
>> Subject: [FFmpeg-devel] [PATCH] configure: Do not enable both OpenCL-VAAPI
>> interop modes simultaneously
>>
>> Beignet offers a far more flexiable and complete interface, so choose it
>> by default if available.
> Sorry I missed your last mail. Sure, I agree Beignet sharing is far more 
> flexible.
> The patch LGTM.

Applied.

Thanks,

- Mark
___
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] Fix loss of precision for silencedetecton large files

[Carl Eugen Hoyos]

2019-03-27 23:13 GMT+01:00, Allan Cady via ffmpeg-devel
:
>  On Tue, Mar 26, 2019 at 10:07:10PM +, Allan Cady via ffmpeg-devel
> wrote:
>
>> When the silencedetect filter is run against very large files, the
>> output timestamps gradually lose precision as the scan proceeds
>> further into the file. This is because the output is formatted (in
>> libavutil/timestamp.h) as "%.6g", which limits the total field length.
>> Eventually, for offsets greater than 10 seconds (about 28 hours),
>> fractions of a second disappear altogether, and the timestamps
>> are logged as whole integers. This is insufficient precision for
>> my purposes.
>>
>> I propose changing the format to "%.3f", which will give millisecond
>> precision for all timestamps regardless of offset.
>>
>> Patch file is attached.
>>
>> EXAMPLE
>>
>> For a sample scan on a file that's about 35 hours (126000 seconds) length:
>>
>> $ ffmpeg -i input.mp3 -filter_complex
>> silencedetect=n=-30dB:d=3,ametadata=mode=print:file=silence-out.txt -f
>> null -
>>
>> The output looks like this near the beginning:
>>
>> frame:83085 pts:47856431 pts_time:2170.36
>> lavfi.silence_start=2166.86
>> frame:83139 pts:47887535 pts_time:2171.77
>> lavfi.silence_end=2171.77
>> lavfi.silence_duration=4.91061
>>
>> Further on we get this:
>>
>> frame:2450348 pts:1411399919 pts_time:64009.1
>> lavfi.silence_start=64005.6
>> frame:2450371 pts:1411413167 pts_time:64009.7
>> lavfi.silence_end=64009.7
>> lavfi.silence_duration=4.10082
>>
>> Eventually after it passes 10 seconds:
>>
>> frame:4738029 pts:2729104175 pts_time:123769
>> lavfi.silence_start=123765
>> frame:4738055 pts:2729119151 pts_time:123770
>> lavfi.silence_end=123770
>> lavfi.silence_duration=4.17918
>>
>> The start and end times are now in whole integers (seconds).
>>
>> After making this patch and building the code myself, I now get this
>> output near the end:
>>
>> frame:4738029 pts:2729104175 pts_time:123768.897
>> lavfi.silence_start=123765.411
>> frame:4738055 pts:2729119151 pts_time:123769.576
>> lavfi.silence_end=123769.584
>> lavfi.silence_duration=4.173
>>
>> This gives me the output I want.
>>
>> Thank you,
>>
>> Allan Cady
>> Seattle WA
>
>>  timestamp.h |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> a997e2f7d02d14a3761cf389b8096e55f3670fb5
>> 0001-Fix-loss-of-precision-for-silencedetect-on-large-fil.patch
>> From 59b82d49516926173ab03944a73fd7fc9e5d7bcc Mon Sep 17 00:00:00 2001
>> From: Allan Cady 
>> Date: Tue, 26 Mar 2019 14:11:03 -0700
>> Subject: [PATCH] Fix loss of precision for silencedetect on large files
>
>
> On Wednesday, March 27, 2019, 11:19:23 AM PDT, Michael Niedermayer
>  wrote:
>
> this breaks make fate
>
> also if fate is updated it should be ensured it still checks enough
> precission
> and that it does produce the same results (fate passes) on all relevant
> platforms. This change may bring non significant differences into
> significance
>
> thanks
>
> [...]
> --
> MichaelGnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Thank you Michael for moving this forward. I've been able to reproduce the
> failure for myself and I'm starting to look into how big a deal it will be.
> First glance it looks like there are pre-built reference output files in the
> tests that may need to be re-generated, and that may be all that's required.
> I'll continue digging to try to understand what's going on.
>
> I'm brand new here and not very experienced with open source
> collaboration... any hints how to proceed or corrections if I break protocol
> would be appreciated. So far so good though it seems.

I didn't look at this specific test but if the reference files are downloaded
you cannot replace them (in the repository), you can only add new
reference files.

Please fix your quoting, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] qsv: fix the dangerous macro definitions

[Mark Thompson]

On 27/03/2019 10:24, Zhong Li wrote:
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsv_internal.h | 8 
>  libavfilter/qsvvpp.h  | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
> index 394c558883..86a5dbad98 100644
> --- a/libavcodec/qsv_internal.h
> +++ b/libavcodec/qsv_internal.h
> @@ -35,12 +35,12 @@
>  #define QSV_MAX_ENC_PAYLOAD 2   // # of mfxEncodeCtrl payloads supported
>  
>  #define QSV_VERSION_ATLEAST(MAJOR, MINOR)   \
> -(MFX_VERSION_MAJOR > (MAJOR) || \
> - MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR))
> +((MFX_VERSION_MAJOR > (MAJOR) || \
> + MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR)))

I don't understand why this makes a difference?

Removing the whitespace, I see:

-  (MFX_VERSION_MAJOR > (MAJOR) || MFX_VERSION_MAJOR == (MAJOR) && 
MFX_VERSION_MINOR >= (MINOR))
+ ((MFX_VERSION_MAJOR > (MAJOR) || MFX_VERSION_MAJOR == (MAJOR) && 
MFX_VERSION_MINOR >= (MINOR)))

which looks like you've just added redundant parentheses around the whole thing 
which already had them?

(Alternative question: what case is this trying to fix?  I could see a problem 
if the MFX_VERSION_* fields were macros expanding to something containing 
operators with lower precedence than relationals, but that doesn't change with 
what you've done here.)

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavc/vaapi_h264: Do not set unused deprecated fields

[Mark Thompson]

On 27/03/2019 14:02, Carl Eugen Hoyos wrote:
> Hi!
> 
> I don't think setting vaapi fields that are deprecated makes sense, this
> also silences a warning when compiling with clang.
> 
> Please comment, Carl Eugen
> 
> From b1f4e64e577ffecd1eab7b95d8d6f90e261cdd74 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Wed, 27 Mar 2019 14:58:51 +0100
> Subject: [PATCH] lavc/vaapi_264: Do not set deprecated unused fields.
> 
> Fixes the following warnings:
> libavcodec/vaapi_h264.c:259:10: warning: 'num_slice_groups_minus1' is 
> deprecated [-Wdeprecated-declarations]
> .num_slice_groups_minus1= pps->slice_group_count 
> - 1,
>  ^
> libavcodec/vaapi_h264.c:260:10: warning: 'slice_group_map_type' is deprecated 
> [-Wdeprecated-declarations]
> .slice_group_map_type   = 
> pps->mb_slice_group_map_type,
>  ^
> libavcodec/vaapi_h264.c:261:10: warning: 'slice_group_change_rate_minus1' is 
> deprecated [-Wdeprecated-declarations]
> .slice_group_change_rate_minus1 = 0, /* FMO is not 
> implemented */
>  ^
> ---
>  libavcodec/vaapi_h264.c |3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> index 5854587..dd2a657 100644
> --- a/libavcodec/vaapi_h264.c
> +++ b/libavcodec/vaapi_h264.c
> @@ -256,9 +256,6 @@ static int vaapi_h264_start_frame(AVCodecContext  
> *avctx,
>  .log2_max_pic_order_cnt_lsb_minus4  = sps->log2_max_poc_lsb 
> - 4,
>  .delta_pic_order_always_zero_flag   = 
> sps->delta_pic_order_always_zero_flag,
>  },
> -.num_slice_groups_minus1= pps->slice_group_count 
> - 1,
> -.slice_group_map_type   = 
> pps->mb_slice_group_map_type,
> -.slice_group_change_rate_minus1 = 0, /* FMO is not 
> implemented */
>  .pic_init_qp_minus26= pps->init_qp - 26,
>  .pic_init_qs_minus26= pps->init_qs - 26,
>  .chroma_qp_index_offset = 
> pps->chroma_qp_index_offset[0],
> -- 
> 1.7.10.4

They aren't deprecated on all VAAPI versions we support (try building with 
libva < 2).

I think the change is ok anyway because zero is fine as a value for them?  The 
commit message should probably mention that if you want to go with it.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavc/vaap_hevc: Do not initialize fields twice

[Mark Thompson]

On 27/03/2019 13:58, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes a warning when compiling vaapi with clang.
> 
> From 6463a3cf5730be9e9e6003f4aaf6c9fab7f68407 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Wed, 27 Mar 2019 14:52:35 +0100
> Subject: [PATCH] lavc/vaapi_hevc: Do not initialize fields twice.
> 
> Fixes the following compilation warnings:
> libavcodec/vaapi_hevc.c:155:21: warning: initializer overrides prior 
> initialization of this subobject [-Winitializer-overrides]
> .pic_fields.bits = {
>~^~~~
> libavcodec/vaapi_hevc.c:125:57: note: previous initialization is here
> .pic_fields.value = 0,
> ^
> libavcodec/vaapi_hevc.c:175:31: warning: initializer overrides prior 
> initialization of this subobject [-Winitializer-overrides]
> .slice_parsing_fields.bits = {
>  ~^~~~
> libavcodec/vaapi_hevc.c:126:57: note: previous initialization is here
> .slice_parsing_fields.value   = 0,
> ---
>  libavcodec/vaapi_hevc.c |2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
> index 19aabcd..c69d63d 100644
> --- a/libavcodec/vaapi_hevc.c
> +++ b/libavcodec/vaapi_hevc.c
> @@ -122,8 +122,6 @@ static int vaapi_hevc_start_frame(AVCodecContext  
> *avctx,
>  pic->pic.output_surface = ff_vaapi_get_surface_id(h->ref->frame);
>  
>  pic->pic_param = (VAPictureParameterBufferHEVC) {
> -.pic_fields.value = 0,
> -.slice_parsing_fields.value   = 0,
>  .pic_width_in_luma_samples= sps->width,
>  .pic_height_in_luma_samples   = sps->height,
>  .log2_min_luma_coding_block_size_minus3   = 
> sps->log2_min_cb_size - 3,
> -- 
> 1.7.10.4

LGTM.

Thanks,

- Mark
___
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] Fix loss of precision for silencedetecton large files

[Allan Cady via ffmpeg-devel]

 On Tue, Mar 26, 2019 at 10:07:10PM +, Allan Cady via ffmpeg-devel wrote:

> When the silencedetect filter is run against very large files, the
> output timestamps gradually lose precision as the scan proceeds
> further into the file. This is because the output is formatted (in
> libavutil/timestamp.h) as "%.6g", which limits the total field length.
> Eventually, for offsets greater than 10 seconds (about 28 hours),
> fractions of a second disappear altogether, and the timestamps
> are logged as whole integers. This is insufficient precision for
> my purposes.
> 
> I propose changing the format to "%.3f", which will give millisecond
> precision for all timestamps regardless of offset.
> 
> Patch file is attached.
> 
> EXAMPLE
> 
> For a sample scan on a file that's about 35 hours (126000 seconds) length:
> 
> $ ffmpeg -i input.mp3 -filter_complex 
> silencedetect=n=-30dB:d=3,ametadata=mode=print:file=silence-out.txt -f null -
> 
> The output looks like this near the beginning:
> 
> frame:83085 pts:47856431 pts_time:2170.36
> lavfi.silence_start=2166.86
> frame:83139 pts:47887535 pts_time:2171.77
> lavfi.silence_end=2171.77
> lavfi.silence_duration=4.91061
> 
> Further on we get this:
> 
> frame:2450348 pts:1411399919 pts_time:64009.1
> lavfi.silence_start=64005.6
> frame:2450371 pts:1411413167 pts_time:64009.7
> lavfi.silence_end=64009.7
> lavfi.silence_duration=4.10082
> 
> Eventually after it passes 10 seconds:
> 
> frame:4738029 pts:2729104175 pts_time:123769
> lavfi.silence_start=123765
> frame:4738055 pts:2729119151 pts_time:123770
> lavfi.silence_end=123770
> lavfi.silence_duration=4.17918
> 
> The start and end times are now in whole integers (seconds).
> 
> After making this patch and building the code myself, I now get this
> output near the end:
> 
> frame:4738029 pts:2729104175 pts_time:123768.897
> lavfi.silence_start=123765.411
> frame:4738055 pts:2729119151 pts_time:123769.576
> lavfi.silence_end=123769.584
> lavfi.silence_duration=4.173
> 
> This gives me the output I want.
> 
> Thank you,
> 
> Allan Cady
> Seattle WA

>  timestamp.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> a997e2f7d02d14a3761cf389b8096e55f3670fb5  
> 0001-Fix-loss-of-precision-for-silencedetect-on-large-fil.patch
> From 59b82d49516926173ab03944a73fd7fc9e5d7bcc Mon Sep 17 00:00:00 2001
> From: Allan Cady 
> Date: Tue, 26 Mar 2019 14:11:03 -0700
> Subject: [PATCH] Fix loss of precision for silencedetect on large files


On Wednesday, March 27, 2019, 11:19:23 AM PDT, Michael Niedermayer 
 wrote:

this breaks make fate

also if fate is updated it should be ensured it still checks enough precission
and that it does produce the same results (fate passes) on all relevant
platforms. This change may bring non significant differences into significance

thanks

[...]
-- 
Michael    GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thank you Michael for moving this forward. I've been able to reproduce the 
failure for myself and I'm starting to look into how big a deal it will be. 
First glance it looks like there are pre-built reference output files in the 
tests that may need to be re-generated, and that may be all that's required. 
I'll continue digging to try to understand what's going on.

I'm brand new here and not very experienced with open source collaboration... 
any hints how to proceed or corrections if I break protocol would be 
appreciated. So far so good though it seems.
  
___
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/4] lavc/qsvenc: fix hevc vps extradata issues

[Mark Thompson]

On 26/03/2019 19:46, Zhong Li wrote:
> cbs trace qsv vps header failed due to some reasons:
> 1. vps_temporal_id_nesting_flag is not set but spec required it must to
>be 1 when vps_max_sub_layers_minus1 is equal to 0.
> 2. vps_num_hrd_parameters is not set and written.
> 3. other issues in ff_hevc_encode_nal_vps() (have fixed in pervious commit).
> 
> Reproduce: ffmpeg -hwaccel qsv -v verbose -c:v h264_qsv -i 
> bbb_sunflower_1080p_30fps_normal.mp4 -vframes 1
> -c:v hevc_qsv  -bsf:v trace_headers -f null -
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsvenc_hevc.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)

I had a patch sitting around for a long time for this - see 
.  It 
just deletes all of the ad-hoc writing code and uses the tested CBS paths 
instead, which have the additional advantage of correctly preserving various 
things which the existing code doesn't cover at all (e.g. newer PTL flags which 
didn't exist when this was written).

The main problem with it was that I didn't have enough libmfx platforms at the 
time to be confident in testing of it, so it got stalled.

Would it be useful to resurrect that?

- Mark
___
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 Adding ff_v210_planar_unpack AVX2

[James Darnley]

On 2019-03-26 21:22, Mike Stoner via ffmpeg-devel wrote:
> Hello,
> I’ve accounted for all feedback on this so far, I’m wondering if it is ready 
> to be pushed upstream?
> 
> Here are my results from ‘checkasm’ (lower is better):
> 
> v210_unpack_c: 1636
> v210_unpack_ssse3: 611
> v210_unpack_avx: 601
> v210_unpack_avx2: 423
> 
> I ran it 5 times and averaged the middle 3 results for each CPU target 
> (ignoring the highest and lowest time).
> 
> https://patchwork.ffmpeg.org/patch/12325/
> 
> 
> Thanks… -Mike

Sorry that I keep forgetting about this.  I will try to make some time
tomorrow to give this another look over.

I'm not sure what order this and my checkasm patch should be applied in,
which I also forgot about.

Did anyone else make comments on either patch?




signature.asc
Description: OpenPGP digital 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] avcodec/videotoolbox: add support for full range and 10bit pixel formats

[der richter]

apparently the first patch didn't make it through



0001-avcodec-videotoolbox-add-support-for-10bit-pixel-for.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] avcodec/videotoolbox: add support for full range and 10bit pixel formats

[der richter]

the second patch



0002-avcodec-videotoolbox-add-support-for-full-range-deco.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] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size

[Alexander Strasser]

Hi Stephan!

On 2019-03-25 20:32 +0100, Stephan Hilb wrote:
> Alexander Strasser wrote on 21.03.2019 at 23:34:
>
> > 3. Return zero-sized packets => This works and is consistent with how
> >we handle frames flagged to be corrupted (V4L2_BUF_FLAG_ERROR).
> >See commit 28f20d2ff487aa589643d8f70eaf614b78839685 .
>
> I posted a patch for this on Sat, 25 Aug 2018. It seems to have been
> forgotten, attached again.

I didn't know you sent that patch.


> From 0af8515acca4d598570d03450656adc0ed7ac2d7 Mon Sep 17 00:00:00 2001
> From: Stephan Hilb 
> Date: Sun, 10 Jun 2018 21:07:52 +0200
> Subject: [PATCH] lavd/v4l2: skip buffers not matching frame_size
>
> By adopting the same behaviour as if there was corrupted data in the
> buffer (see the check for V4L2_BUF_FLAG_ERROR) the resulting rawvideo
> now at least contains valid data (the previous frame being duplicated).
> Fixes video capturing for some stk1160 devices.
> ---
>  libavdevice/v4l2.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
> index 10a0ff0dd6..ab903bbcee 100644
> --- a/libavdevice/v4l2.c
> +++ b/libavdevice/v4l2.c
> @@ -534,11 +534,10 @@ static int mmap_read_frame(AVFormatContext *ctx, 
> AVPacket *pkt)
>  s->frame_size = buf.bytesused;
>
>  if (s->frame_size > 0 && buf.bytesused != s->frame_size) {
> -av_log(ctx, AV_LOG_ERROR,
> +av_log(ctx, AV_LOG_WARNING,
> "Dequeued v4l2 buffer contains %d bytes, but %d were 
> expected. Flags: 0x%08X.\n",
> buf.bytesused, s->frame_size, buf.flags);
> -enqueue_buffer(s, );
> -return AVERROR_INVALIDDATA;
> +buf.bytesused = 0;
>  }
>  }

It is exactly the same as mine except for degrading the log message
from AV_LOG_ERROR to AV_LOG_WARNING which should be fine.

As I stated before I am in favor of this solution and I am fine with
applying your version. Let's wait a little while longer if there are
objections.


  Alexander
___
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 v9 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Mark Thompson]

On 27/03/2019 17:13, Vittorio Giovara wrote:
> On Tue, Mar 26, 2019 at 10:47 PM Jing Sun  wrote:
> 
>> Signed-off-by: Zhengxu Huang 
>> Signed-off-by: Hassene Tmar 
>> Signed-off-by: Jun Zhao 
>> Signed-off-by: Jing Sun 
>> ---
>>  configure|   4 +
>>  libavcodec/Makefile  |   1 +
>>  libavcodec/allcodecs.c   |   1 +
>>  libavcodec/libsvt_hevc.c | 502
>> +++
>>  4 files changed, 508 insertions(+)
>>  create mode 100644 libavcodec/libsvt_hevc.c
>>
>> ...
>> +if (svt_enc->hdr) {
>> +svt_enc->vui_info = 1;
>> +param->highDynamicRangeInput = svt_enc->hdr;
>> +}
>>
> 
> Where is the warning that notifies the lack of color properties support?

Looking at what the highDynamicRangeInput field actually does 
,
 I don't think it makes sense for this external "hdr" option at exist at all.

From the point of view of a user looking at the external options, they might 
expect that on setting this option some conversion takes place to actually 
create an HDR output.  In fact, that's not what it does - it just marks the 
output with some very specific colour properties, and any stream which doesn't 
actually have exactly those properties will then have incorrect metadata for 
display (possibly conflicting with container metadata, if the container has 
better support for colour properties than this encoder).

Perhaps to avoid confusion about what is actually happening the option could be 
removed and this check replaced with something like:

if (avctx->colorspace == AVCOL_SPC_BT2020_NCL &&
avctx->color_primaries == AVCOL_PRI_BT2020 &&
avctx->color_trc == AVCOL_TRC_SMPTE2084 &&
avctx->color_range == AVCOL_RANGE_MPEG &&
avctx->chroma_sample_location == AVCHROMA_LOC_TOPLEFT) {
param->highDynamicRangeInput = 1;
} else {
param->highDynamicRangeInput = 0;
// Maybe also a warning here in some cases?
}

That would then do the right thing for all streams which actually have the 
given properties, while not forcing incorrect display of anything else.

- Mark
___
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] avcodec/videotoolbox: add support for full range and 10bit pixel formats

[der richter]

these additions consist of two patches.

the first one is a slight modified version of a patch from issue #7704 that 
adds a 10bit pixel format.
i basically just added the pixel format availability checks.

the second patch adds full range pixel formats. the issue arose on the mpv 
issue tracker.
https://github.com/mpv-player/mpv/issues/6546 


___
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] Check if we do have also a filter_complex filter.

[Thierry Foucu]

Right now, the code check for no filter description, but if we use a
filter_complex, the code will use the AVFrame.duration which could be
wrong in case of using fps filter.

How to reproduce the problem:
ffmpeg -f lavfi -i testsrc=duration=1 -vf fps=fps=50 -vsync 1 -f null -
output 50 frames

ffmpeg -f lavfi -i testsrc=duration=1 -filter_complex fps=fps=50 -vsync 1 -f 
null -
output 51 frames

With the patch, the same command will always output 50 frames.

---
 fftools/ffmpeg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 544f1a1cef..0f157d67d8 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1079,6 +1079,7 @@ static void do_video_out(OutputFile *of,
 
 if (!ost->filters_script &&
 !ost->filters &&
+(nb_filtergraphs == 0 || !filtergraphs[0]->graph_desc) &&
 next_picture &&
 ist &&
 lrintf(next_picture->pkt_duration * av_q2d(ist->st->time_base) / 
av_q2d(enc->time_base)) > 0) {
-- 
2.21.0.392.gf8f6787159e-goog

___
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] avformat/bink: properly mark packets that are key frames

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/bink.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavformat/bink.c b/libavformat/bink.c
index 631b8c4d7d..44eb04362e 100644
--- a/libavformat/bink.c
+++ b/libavformat/bink.c
@@ -56,6 +56,7 @@ typedef struct BinkDemuxContext {
 int64_t audio_pts[BINK_MAX_AUDIO_TRACKS];
 
 uint32_t remain_packet_size;
+int flags;
 int smush_size;
 } BinkDemuxContext;
 
@@ -90,6 +91,7 @@ static int read_header(AVFormatContext *s)
 unsigned int i;
 uint32_t pos, next_pos;
 uint16_t flags;
+int next_keyframe = 1;
 int keyframe;
 int ret;
 uint32_t signature;
@@ -203,12 +205,13 @@ static int read_header(AVFormatContext *s)
 next_pos = avio_rl32(pb);
 for (i = 0; i < vst->duration; i++) {
 pos = next_pos;
+keyframe = next_keyframe;
 if (i == vst->duration - 1) {
 next_pos = bink->file_size;
-keyframe = 0;
+next_keyframe = 0;
 } else {
 next_pos = avio_rl32(pb);
-keyframe = pos & 1;
+next_keyframe = next_pos & 1;
 }
 pos &= ~1;
 next_pos &= ~1;
@@ -254,6 +257,7 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
 }
 
 bink->remain_packet_size = st->index_entries[index_entry].size;
+bink->flags = st->index_entries[index_entry].flags;
 bink->current_track = 0;
 }
 
@@ -290,7 +294,8 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
 return ret;
 pkt->stream_index = 0;
 pkt->pts = bink->video_pts++;
-pkt->flags |= AV_PKT_FLAG_KEY;
+if (bink->flags & AVINDEX_KEYFRAME)
+pkt->flags |= AV_PKT_FLAG_KEY;
 
 /* -1 instructs the next call to read_packet() to read the next frame */
 bink->current_track = -1;
-- 
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] Fix loss of precision for silencedetect on large files

[Michael Niedermayer]

On Tue, Mar 26, 2019 at 10:07:10PM +, Allan Cady via ffmpeg-devel wrote:
> When the silencedetect filter is run against very large files, the
> output timestamps gradually lose precision as the scan proceeds
> further into the file. This is because the output is formatted (in
> libavutil/timestamp.h) as "%.6g", which limits the total field length.
> Eventually, for offsets greater than 10 seconds (about 28 hours),
> fractions of a second disappear altogether, and the timestamps
> are logged as whole integers. This is insufficient precision for
> my purposes.
> 
> I propose changing the format to "%.3f", which will give millisecond
> precision for all timestamps regardless of offset.
> 
> Patch file is attached.
> 
> EXAMPLE
> 
> For a sample scan on a file that's about 35 hours (126000 seconds) length:
> 
> $ ffmpeg -i input.mp3 -filter_complex 
> silencedetect=n=-30dB:d=3,ametadata=mode=print:file=silence-out.txt -f null -
> 
> The output looks like this near the beginning:
> 
> frame:83085 pts:47856431 pts_time:2170.36
> lavfi.silence_start=2166.86
> frame:83139 pts:47887535 pts_time:2171.77
> lavfi.silence_end=2171.77
> lavfi.silence_duration=4.91061
> 
> Further on we get this:
> 
> frame:2450348 pts:1411399919 pts_time:64009.1
> lavfi.silence_start=64005.6
> frame:2450371 pts:1411413167 pts_time:64009.7
> lavfi.silence_end=64009.7
> lavfi.silence_duration=4.10082
> 
> Eventually after it passes 10 seconds:
> 
> frame:4738029 pts:2729104175 pts_time:123769
> lavfi.silence_start=123765
> frame:4738055 pts:2729119151 pts_time:123770
> lavfi.silence_end=123770
> lavfi.silence_duration=4.17918
> 
> The start and end times are now in whole integers (seconds).
> 
> After making this patch and building the code myself, I now get this
> output near the end:
> 
> frame:4738029 pts:2729104175 pts_time:123768.897
> lavfi.silence_start=123765.411
> frame:4738055 pts:2729119151 pts_time:123769.576
> lavfi.silence_end=123769.584
> lavfi.silence_duration=4.173
> 
> This gives me the output I want.
> 
> Thank you,
> 
> Allan Cady
> Seattle WA

>  timestamp.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> a997e2f7d02d14a3761cf389b8096e55f3670fb5  
> 0001-Fix-loss-of-precision-for-silencedetect-on-large-fil.patch
> From 59b82d49516926173ab03944a73fd7fc9e5d7bcc Mon Sep 17 00:00:00 2001
> From: Allan Cady 
> Date: Tue, 26 Mar 2019 14:11:03 -0700
> Subject: [PATCH] Fix loss of precision for silencedetect on large files

this breaks make fate

also if fate is updated it should be ensured it still checks enough precission
and that it does produce the same results (fate passes) on all relevant
platforms. This change may bring non significant differences into significance

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand


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 v9 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Vittorio Giovara]

On Tue, Mar 26, 2019 at 10:47 PM Jing Sun  wrote:

> Signed-off-by: Zhengxu Huang 
> Signed-off-by: Hassene Tmar 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Jing Sun 
> ---
>  configure|   4 +
>  libavcodec/Makefile  |   1 +
>  libavcodec/allcodecs.c   |   1 +
>  libavcodec/libsvt_hevc.c | 502
> +++
>  4 files changed, 508 insertions(+)
>  create mode 100644 libavcodec/libsvt_hevc.c
>
> +
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV420P10LE) {
> +av_log(avctx, AV_LOG_DEBUG , "Encoder 10 bits depth input\n");
> +
> +// SVT-HEVC's compressed 10-bit format is to supported,
> +// without which it works well functionally but with a
> +// slight performance penalty caused by the extra conv
> +// step from yuv420p10le to that format.
> +
> +param->compressedTenBitFormat = 0;
> +param->encoderBitDepth= 10;
> +}
>

So what is happening in this case? The encoder is slower because it
converts from 10 to 8 bit internally? And then the output encode is 8 bit
right now? If that is the case, I'd rather have this functionality removed
since the conversion can happen directly within ffmpeg. Having the
conversion performed by the encoder is guaranteed to be slower and less
precise, and if the output is not 10 bit it is very surprising too.

At the same time the comment in the code is useless because users will
never read something buried deep in the code, I'd suggest printing
something at the warning level so that it will be shown during the
conversion (and please have it proofread by a native English-speaking
person).


> +param->encoderColorFormat = EB_YUV420;
> +
> +// Update param from options
> +param->hierarchicalLevels = svt_enc->hierarchical_level - 1;
> +param->encMode= svt_enc->enc_mode;
> +param->profile= svt_enc->profile;
> +param->tier   = svt_enc->tier;
> +param->level  = svt_enc->level;
> +param->rateControlMode= svt_enc->rc_mode;
> +param->sceneChangeDetection   = svt_enc->scd;
> +param->tune   = svt_enc->tune;
> +param->baseLayerSwitchMode= svt_enc->base_layer_switch_mode;
> +param->qp = svt_enc->qp;
> +param->accessUnitDelimiter= svt_enc->aud;
> +
> +param->targetBitRate  = avctx->bit_rate;
> +if (avctx->gop_size > 0)
> +param->intraPeriodLength  = avctx->gop_size - 1;
> +
> +if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
> +param->frameRateNumerator = avctx->framerate.num;
> +param->frameRateDenominator   = avctx->framerate.den *
> avctx->ticks_per_frame;
> +} else {
> +param->frameRateNumerator = avctx->time_base.den;
> +param->frameRateDenominator   = avctx->time_base.num *
> avctx->ticks_per_frame;
> +}
> +
> +if (param->rateControlMode) {
> +param->maxQpAllowed   = avctx->qmax;
> +param->minQpAllowed   = avctx->qmin;
> +}
> +
> +param->intraRefreshType   =
> +!!(avctx->flags & AV_CODEC_FLAG_CLOSED_GOP) + 1;
> +
> +// is it repeat headers for MP4 or Annex-b
> +if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)
> +param->codeVpsSpsPps  = 0;
> +else
> +param->codeVpsSpsPps  = 1;
> +
> +param->codeEosNal = 1;
>

nit: excessive whitespace alignment

+
> +if (svt_enc->hdr) {
> +svt_enc->vui_info = 1;
> +param->highDynamicRangeInput = svt_enc->hdr;
> +}
>

Where is the warning that notifies the lack of color properties support?


> +
> +avctx->extradata_size = header_ptr->nFilledLen;
> +avctx->extradata = av_mallocz(avctx->extradata_size +
> AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!avctx->extradata) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Cannot allocate HEVC header of size %d.\n",
> avctx->extradata_size);
> +svt_ret = EB_ErrorInsufficientResources;
> +goto failed_init_enc;
> +}
>

initialize extradata_size only in case of success, some code may rely on it

+#define OFFSET(x) offsetof(SvtContext, x)
> +#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
> +static const AVOption options[] = {
> +{ "vui", "Enable vui info", OFFSET(vui_info),
> +  AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE },
> +
> +{ "aud", "Include AUD", OFFSET(aud),
> +  AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>

IMO these options help text could be improved.

-- 
Vittorio
___
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] scaling option

[Dennis Mungai]

On Wed, 27 Mar 2019 at 17:51, Yufei He  wrote:

> On 03/26/2019 02:36 PM, Dennis Mungai wrote:
>
>
>
> On Tue, Mar 26, 2019, 21:20 Yufei He  wrote:
>
>> On 03/26/2019 11:31 AM, Dennis Mungai wrote:
>> > On Tue, 26 Mar 2019 at 18:21, Yufei He  wrote:
>> >
>> >> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
>> >> On 26/03/2019 13:47, Yufei He wrote:
>> >> Hi
>> >>
>> >> Is there option for scaling on transcoding ?
>> >>
>> >> e.g. transcoding from a quadhd file to 640 * 480.
>> >>
>> >> Thanks.
>> >>
>> >> Yufei.
>> >>
>> >>
>> >> Yes there is, but this is ffmpeg-devel, so not the place to ask user
>> >> questions.
>> >>
>> >> Yes, I see the option of -vf scale=width:height
>> >> We can do scaling on decoding or encoding, my question was to check if
>> >> there is scaling option for codec.
>> >> I'll add special scaling option to our codec.
>> >>
>> >>
>> > Hello there,
>> >
>> > Scaling comes in two forms (correct me if I'm wrong):
>> >
>> > 1. Specific video filters, such as the scale filters, and other
>> > hardware-accelerated implementations, such as scale_npp, scale_cuda,
>> > scale_vaapi, etc.
>> > 2. Decoders (Not too sure if equating the private -resize option
>> provided
>> > by these decoders is equivalent to "scaling"):
>> >
>> > See the example provided by the likes of the cuvid implementations,
>> such as
>> > h264_cuvid, etc:
>> >
>> > ffmpeg -h decoder=h264_cuvid
>> >
>> > The -resize option therein acts as a scaler.
>> >
>> > Are you planning to implement a codec-specific hardware (or
>> software-based)
>> > scaler (implemented as a video filter or a decoder), with similar
>> > functionality?
>> Hi Dennis
>> Our hardware m264 supports scaling and encoding or decoding at the same
>> time, this saves memory copy time between host and card if it's scaled
>> in host or in other separate filter.
>> I'm trying to make it work in FFmpeg.
>>
>> Yufei.
>>
>
>
> Here's what you'll need to implement:
>
> 1. A hwaccel of the type equivalent to the accelerator backend you're
> creating, and
>
> 2. The actual hwaccel implementation. This will be an encoder (or set of
> encoders) targeting the codecs you're after.
>
> 3. Based on the two above, create video filters that can take advantage of
> hwupload, hwdownload, etc to create filter chains that will allow to move
> (and map) textures, etc from system to device memory . Take a look at how
> CUDA based hwaccels are implemented. That's a good crash course on what
> needs to be done.
>
> 4. Understand how the FFmpeg development process works. Patches are
> welcome, but the review process and adherence to coding standards matters
> even more. See the wikis on what's expected regarding the development
> process. I'd suggest being aware of the subsystem maintainers and the roles
> they play.
>
> 5. On vendor specific libraries: I'd suggest releasing this as an open
> implementation such that it can be hosted in a manner similar to how the
> ffnvcodec headers are handled. Trust me, you'll greatly lower the
> maintainance overhead on time.
>
> Hope that helps.
>
> Hi Dennis
>
> We will talk about your suggestion and schedule it later.
>
> Thanks for your help.
>
> Yufei.
>

And I'll issue a warning, before it blocks this patch from going anywhere:
Do *NOT* link to a library bundled within the device driver.
There's no (justifiable) reason for that. Also see the note on maintainer
overhead above.
Avail the shim (intermediate library) as recommended above such that it can
be enabled at ./configure as an option.
The end user should be able to compile and install the aforementioned
library to a pre-configured prefix, such that when building FFmpeg, the
same facility can pick up that library and enable the requested
component(s) as per the directive(s) in ./configure.
What your (now rejected) patch in the mailing list does shifts the burden
of maintaining ABI compatibility to a *device driver component* and until
that's resolved, it will go nowhere.
___
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 4/4] lavc/qsvenc_h264: remove the privite option trellis

[Carl Eugen Hoyos]

2019-03-27 15:51 GMT+01:00, Moritz Barsnick :
> On Wed, Mar 27, 2019 at 20:51:47 +0800, Zhong Li wrote:
>> Just simply remove the private option, and switch to the AVCodecContext
>> definition. Compatibility should not a big problem (expect can't exact
>> map)
>> since the option name is same as AVCodecContext.
>
> You should probably bump libavcodec's micro version if the option
> mapping changes.

+1

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

[Carl Eugen Hoyos]

2019-03-27 16:30 GMT+01:00, Yufei He :

> Here is the fixed patch for a new H.264 codec with Matrox
> M264 card.

Please do not send another version of this patch that doesn't
add the non-free requirement in configure (or open-source
your library).

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

[Nicolas George]

Yufei He (12019-03-27):
> Here is the fixed patch for a new H.264 codec with Matrox M264 card.
> 
> It calls the default library from the card's driver installation.
> Please review.

You are still using programmatic dynamic linking instead of normal
dynamic linking, and you have not given a good reason for that. Please
fix.

Regards,

-- 
  Nicolas George


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 for a new H.264 codec with Matrox m264 card.

[Yufei He]

Hi

Here is the fixed patch for a new H.264 codec with Matrox M264 card.

It calls the default library from the card's driver installation.
Please review.

Thanks.

Yufei.
  

From da521d4e1315199a5fb781adf8a56efdc64c2b42 Mon Sep 17 00:00:00 2001
From: yhe 
Date: Wed, 27 Mar 2019 11:05:41 -0400
Subject: [PATCH] h.264 decoder and encoder support with M264

---
 Changelog  |   1 +
 configure  |   2 +
 libavcodec/Makefile|   2 +
 libavcodec/allcodecs.c |   2 +
 libavcodec/m264dec.c   | 357 +
 libavcodec/m264dec.h   |  40 ++
 libavcodec/m264enc.c   | 335 ++
 libavcodec/m264enc.h   |  38 ++
 8 files changed, 777 insertions(+)
 create mode 100644 libavcodec/m264dec.c
 create mode 100644 libavcodec/m264dec.h
 create mode 100644 libavcodec/m264enc.c
 create mode 100644 libavcodec/m264enc.h

diff --git a/Changelog b/Changelog
index 4d80e5b..ce0daf8 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
 - ARBC decoder
 - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
 - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
+- Support h.264 encoding and decoding with Matrox M264 card.
 
 
 version 4.1:
diff --git a/configure b/configure
index dcead3a..3be416e 100755
--- a/configure
+++ b/configure
@@ -2697,6 +2697,8 @@ h263p_decoder_select="h263_decoder"
 h263p_encoder_select="h263_encoder"
 h264_decoder_select="cabac golomb h264chroma h264dsp h264parse h264pred h264qpel videodsp"
 h264_decoder_suggest="error_resilience"
+h264_m264_decoder_deps_any="libdl"
+h264_m264_encoder_deps_any="libdl libswscale"
 hap_decoder_select="snappy texturedsp"
 hap_encoder_deps="libsnappy"
 hap_encoder_select="texturedspenc"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8..8e8f9ab 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -348,6 +348,8 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o h264_cabac.o h264_cavlc.o \
   h264_slice.o h264data.o
 OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
 OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
+OBJS-$(CONFIG_H264_M264_DECODER)   += m264dec.o
+OBJS-$(CONFIG_H264_M264_ENCODER)   += m264enc.o
 OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
 OBJS-$(CONFIG_H264_NVENC_ENCODER)  += nvenc_h264.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b26aeca..c03a5a3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -737,6 +737,8 @@ extern AVCodec ff_libopenh264_encoder;
 extern AVCodec ff_libopenh264_decoder;
 extern AVCodec ff_h264_amf_encoder;
 extern AVCodec ff_h264_cuvid_decoder;
+extern AVCodec ff_h264_m264_decoder;
+extern AVCodec ff_h264_m264_encoder;
 extern AVCodec ff_h264_nvenc_encoder;
 extern AVCodec ff_h264_omx_encoder;
 extern AVCodec ff_h264_qsv_encoder;
diff --git a/libavcodec/m264dec.c b/libavcodec/m264dec.c
new file mode 100644
index 000..f6cc65f
--- /dev/null
+++ b/libavcodec/m264dec.c
@@ -0,0 +1,357 @@
+/*
+ * M264 H.264 video decoder
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Matrox M264 card supports h.264 encoding and decoding.
+ */
+
+#include "decode.h"
+#include "cabac.h"
+#include "error_resilience.h"
+#include "h264_parse.h"
+#include "h264_ps.h"
+#include "h264_sei.h"
+#include "h2645_parse.h"
+#include "h264chroma.h"
+#include "h264dsp.h"
+#include "h264pred.h"
+#include "h264qpel.h"
+#include "internal.h"
+#include "mpegutils.h"
+#include "parser.h"
+#include "qpeldsp.h"
+#include "rectangle.h"
+#include "videodsp.h"
+#include "config.h"
+#include "libswscale/swscale.h"
+#include "libavutil/opt.h"
+#include "m264dec.h"
+#ifdef _WIN32
+#include "compat/w32dlfcn.h"
+#else
+#include 
+#endif
+
+typedef struct {
+   uint16_t input_width;
+   uint16_t input_height;
+   uint16_t output_width;
+   uint16_t output_height;
+   uint16_t scale;
+   uint16_t rate;
+   uint16_t gop_size;
+   uint32_t bitrate;
+   uint8_t  field_order;
+} M264DecoderInfo;
+
+typedef struct {
+AVClass *class;
+int (*init_m264_decoder)(void *decoder_info, void **m264_decoder_object);

Re: [FFmpeg-devel] [PATCH 4/4] lavc/qsvenc_h264: remove the privite option trellis

[Moritz Barsnick]

On Wed, Mar 27, 2019 at 20:51:47 +0800, Zhong Li wrote:
> Just simply remove the private option, and switch to the AVCodecContext
> definition. Compatibility should not a big problem (expect can't exact map)
> since the option name is same as AVCodecContext.

You should probably bump libavcodec's micro version if the option
mapping changes.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffmpeg: add -drop_deviant_frames option

[Gyan]

Weird. Attached corrected patch.

Thanks.

On 27-03-2019 08:19 PM, Moritz Barsnick wrote:

On Wed, Mar 27, 2019 at 18:05:32 +0530, Gyan wrote:

+@item -drop_deviant_frames (@emph{input,per-stream})
+Allows discarding decoded frames whose parameters differ from initialized
+stream parameters. May be useful in
+

It looks like this was truncated.

Moritz
Cheers,
___
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".


From f39e3d44e1cb8108592d2241e2251d8e1506e031 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 25 Mar 2019 22:01:07 +0530
Subject: [PATCH] ffmpeg: add -drop_deviant_frames option

Decoded frames with changed parameters in inputs expected to be uniform
may indicate malformed/corrupted packets. Demuxer with flag discardcorrupt
set may not catch all such packets and neither may decoders with err_detect
flags set.

Upon parameter change, AVFilterLink of any filters receiving such frames has
to be reconfigured, destroying existing filter context. In case of a
change in audio sample rate, timestamps can go haywire, potentially
leaving the output stream to be "truncated".

Added option allows users to avoid sending such deviant frames onwards.
Default behaviour remains unchanged.
---
 doc/ffmpeg.texi  |  5 +
 fftools/ffmpeg.c | 47 ++--
 fftools/ffmpeg.h |  3 +++
 fftools/ffmpeg_opt.c |  5 +
 4 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index cd35eb49c8..b388942859 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1664,6 +1664,11 @@ Discard all frames excepts keyframes.
 Discard all frames.
 @end table
 
+@item -drop_deviant_frames (@emph{input,per-stream})
+Allows discarding decoded frames whose parameters differ from initialized
+stream parameters. May be useful when an input with uniform frames is received
+over unreliable transport.
+
 @item -abort_on @var{flags} (@emph{global})
 Stop and abort on various conditions. The following flags are available:
 
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 544f1a1cef..5da75306e3 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2283,7 +2283,7 @@ static int decode_audio(InputStream *ist, AVPacket *pkt, 
int *got_output,
 {
 AVFrame *decoded_frame;
 AVCodecContext *avctx = ist->dec_ctx;
-int ret, err = 0;
+int ret, err = 0, deviant = 0;
 AVRational decoded_frame_tb;
 
 if (!ist->decoded_frame && !(ist->decoded_frame = av_frame_alloc()))
@@ -2303,12 +2303,36 @@ static int decode_audio(InputStream *ist, AVPacket 
*pkt, int *got_output,
 ret = AVERROR_INVALIDDATA;
 }
 
+if (*got_output && ret >= 0 && ist->frames_decoded && ist->nb_filters &&
+(ist->filters[0]->sample_rate!= decoded_frame->sample_rate ||
+ ist->filters[0]->channels   != decoded_frame->channels ||
+ ist->filters[0]->channel_layout != decoded_frame->channel_layout ||
+ ist->filters[0]->format != decoded_frame->format ||
+ ist->filters[0]->sample_rate!= avctx->sample_rate)) {
+av_log(NULL, ist->drop_deviant_frames ? AV_LOG_INFO : AV_LOG_VERBOSE,
+   "Parameter change in decoded audio frame from stream %d.%d pts 
%s \n"
+   "filter rate:%d fmt:%s ch:%d layout:%"PRIX64" != frame rate:%d 
fmt:%s ch:%d layout:%"PRIX64", decoder context rate: %d \n",
+   ist->file_index, ist->st->index, 
av_ts2timestr(decoded_frame->pts, >st->time_base),
+   ist->filters[0]->sample_rate, 
av_get_sample_fmt_name(ist->filters[0]->format),
+   ist->filters[0]->channels, ist->filters[0]->channel_layout,
+   decoded_frame->sample_rate, 
av_get_sample_fmt_name(decoded_frame->format),
+   decoded_frame->channels, decoded_frame->channel_layout,
+   avctx->sample_rate);
+if (ist->drop_deviant_frames) {
+deviant = 1;
+av_log(NULL, AV_LOG_WARNING, "Dropping frame.\n");
+}
+}
+
 if (ret != AVERROR_EOF)
 check_decode_result(ist, got_output, ret);
 
 if (!*got_output || ret < 0)
 return ret;
 
+if (deviant)
+goto fail;
+
 ist->samples_decoded += decoded_frame->nb_samples;
 ist->frames_decoded++;
 
@@ -2335,6 +2359,7 @@ static int decode_audio(InputStream *ist, AVPacket *pkt, 
int *got_output,
 ist->nb_samples = decoded_frame->nb_samples;
 err = send_frame_to_filters(ist, decoded_frame);
 
+fail:
 av_frame_unref(ist->filter_frame);
 av_frame_unref(decoded_frame);
 return err < 0 ? err : ret;
@@ -2344,7 +2369,7 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
 int *decode_failed)
 {
 AVFrame *decoded_frame;
-int i, ret = 0, err = 0;

Re: [FFmpeg-devel] scaling option

[Yufei He]

On 03/26/2019 02:36 PM, Dennis Mungai wrote:


On Tue, Mar 26, 2019, 21:20 Yufei He mailto:y...@matrox.com>> 
wrote:
On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> On Tue, 26 Mar 2019 at 18:21, Yufei He 
> mailto:y...@matrox.com>> wrote:
>
>> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
>> On 26/03/2019 13:47, Yufei He wrote:
>> Hi
>>
>> Is there option for scaling on transcoding ?
>>
>> e.g. transcoding from a quadhd file to 640 * 480.
>>
>> Thanks.
>>
>> Yufei.
>>
>>
>> Yes there is, but this is ffmpeg-devel, so not the place to ask user
>> questions.
>>
>> Yes, I see the option of -vf scale=width:height
>> We can do scaling on decoding or encoding, my question was to check if
>> there is scaling option for codec.
>> I'll add special scaling option to our codec.
>>
>>
> Hello there,
>
> Scaling comes in two forms (correct me if I'm wrong):
>
> 1. Specific video filters, such as the scale filters, and other
> hardware-accelerated implementations, such as scale_npp, scale_cuda,
> scale_vaapi, etc.
> 2. Decoders (Not too sure if equating the private -resize option provided
> by these decoders is equivalent to "scaling"):
>
> See the example provided by the likes of the cuvid implementations, such as
> h264_cuvid, etc:
>
> ffmpeg -h decoder=h264_cuvid
>
> The -resize option therein acts as a scaler.
>
> Are you planning to implement a codec-specific hardware (or software-based)
> scaler (implemented as a video filter or a decoder), with similar
> functionality?
Hi Dennis
Our hardware m264 supports scaling and encoding or decoding at the same
time, this saves memory copy time between host and card if it's scaled
in host or in other separate filter.
I'm trying to make it work in FFmpeg.

Yufei.


Here's what you'll need to implement:

1. A hwaccel of the type equivalent to the accelerator backend you're creating, 
and

2. The actual hwaccel implementation. This will be an encoder (or set of 
encoders) targeting the codecs you're after.

3. Based on the two above, create video filters that can take advantage of 
hwupload, hwdownload, etc to create filter chains that will allow to move (and 
map) textures, etc from system to device memory . Take a look at how CUDA based 
hwaccels are implemented. That's a good crash course on what needs to be done.

4. Understand how the FFmpeg development process works. Patches are welcome, 
but the review process and adherence to coding standards matters even more. See 
the wikis on what's expected regarding the development process. I'd suggest 
being aware of the subsystem maintainers and the roles they play.

5. On vendor specific libraries: I'd suggest releasing this as an open 
implementation such that it can be hosted in a manner similar to how the 
ffnvcodec headers are handled. Trust me, you'll greatly lower the maintainance 
overhead on time.

Hope that helps.
Hi Dennis

We will talk about your suggestion and schedule it later.

Thanks for your help.

Yufei.
___
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] ffmpeg: add -drop_deviant_frames option

[Moritz Barsnick]

On Wed, Mar 27, 2019 at 18:05:32 +0530, Gyan wrote:
> +@item -drop_deviant_frames (@emph{input,per-stream})
> +Allows discarding decoded frames whose parameters differ from initialized
> +stream parameters. May be useful in
> +

It looks like this was truncated.

Moritz
Cheers,
___
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 00/21] New Version

[Pedro Arthur]

Em qua, 27 de mar de 2019 às 09:23, Andreas Rheinhardt via
ffmpeg-devel  escreveu:
>
> Carl Eugen Hoyos:
> > 2019-03-27 12:18 GMT+01:00, Andreas Rheinhardt:
> >
> >> I have cced Steve for this (I didn't the first time,
> >> because I thought that he (as a maintainer) would
> >> also be a subscriber to this list).
> >
> > Everybody welcomes reviews by Steve but I don't
> > think he maintains anything within FFmpeg.
> >
> He is listed as maintainer for dxva2 and d3d11va in the maintainers
> file. But this could be wrong/outdated.
> >> Oh, and I did not check with Valgrind that the new
> >> lacing code doesn't read uninitialized data. I don't
> >> even know how to use Valgrind. I just read the
> >> code. If someone more knowledgeable than I
> >> could please test it...
> >
> > Just use "valgrind ./ffmpeg_g ..."
> >
> Thanks for the help, but unfortunately I can't use Valgrind on Windows.
If you're using win10 you can test it using the windows linux subsystem.


>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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]configure: Use -Wno-gnu-variable-sized-type-not-at-end with clang

[Carl Eugen Hoyos]

Hi!

Attached patch fixes many warnings when compiling vaapi with clang.
Also tested with clang-3.4.

Please comment, Carl Eugen
From 0df0773aaf6fa3b920ad078c534f4e1b4e203413 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 27 Mar 2019 15:15:54 +0100
Subject: [PATCH] configure: Use -Wno-gnu-variable-sized-type-not-at-end with
 clang.

Fixes many warnings like the following:
libavcodec/vaapi_encode.h:253:34: warning: field 'misc' with variable sized type 'VAEncMiscParameterBuffer'
  (aka 'struct _VAEncMiscParameterBuffer') not at the end of a struct or class is a GNU extension
  [-Wgnu-variable-sized-type-not-at-end]
VAEncMiscParameterBuffer misc;
 ^
---
 configure |1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 331393f..867bb21 100755
--- a/configure
+++ b/configure
@@ -6760,6 +6760,7 @@ elif enabled clang; then
 check_cflags -Werror=implicit-function-declaration
 check_cflags -Werror=missing-prototypes
 check_cflags -Werror=return-type
+check_cflags -Wno-gnu-variable-sized-type-not-at-end
 elif enabled cparser; then
 add_cflags -Wno-missing-variable-declarations
 add_cflags -Wno-empty-statement
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH]lavc/vaapi_h264: Do not set unused deprecated fields

[Carl Eugen Hoyos]

Hi!

I don't think setting vaapi fields that are deprecated makes sense, this
also silences a warning when compiling with clang.

Please comment, Carl Eugen
From b1f4e64e577ffecd1eab7b95d8d6f90e261cdd74 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 27 Mar 2019 14:58:51 +0100
Subject: [PATCH] lavc/vaapi_264: Do not set deprecated unused fields.

Fixes the following warnings:
libavcodec/vaapi_h264.c:259:10: warning: 'num_slice_groups_minus1' is deprecated [-Wdeprecated-declarations]
.num_slice_groups_minus1= pps->slice_group_count - 1,
 ^
libavcodec/vaapi_h264.c:260:10: warning: 'slice_group_map_type' is deprecated [-Wdeprecated-declarations]
.slice_group_map_type   = pps->mb_slice_group_map_type,
 ^
libavcodec/vaapi_h264.c:261:10: warning: 'slice_group_change_rate_minus1' is deprecated [-Wdeprecated-declarations]
.slice_group_change_rate_minus1 = 0, /* FMO is not implemented */
 ^
---
 libavcodec/vaapi_h264.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index 5854587..dd2a657 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -256,9 +256,6 @@ static int vaapi_h264_start_frame(AVCodecContext  *avctx,
 .log2_max_pic_order_cnt_lsb_minus4  = sps->log2_max_poc_lsb - 4,
 .delta_pic_order_always_zero_flag   = sps->delta_pic_order_always_zero_flag,
 },
-.num_slice_groups_minus1= pps->slice_group_count - 1,
-.slice_group_map_type   = pps->mb_slice_group_map_type,
-.slice_group_change_rate_minus1 = 0, /* FMO is not implemented */
 .pic_init_qp_minus26= pps->init_qp - 26,
 .pic_init_qs_minus26= pps->init_qs - 26,
 .chroma_qp_index_offset = pps->chroma_qp_index_offset[0],
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH]lavc/vaap_hevc: Do not initialize fields twice

[Carl Eugen Hoyos]

Hi!

Attached patch fixes a warning when compiling vaapi with clang.

Please comment, Carl Eugen
From 6463a3cf5730be9e9e6003f4aaf6c9fab7f68407 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 27 Mar 2019 14:52:35 +0100
Subject: [PATCH] lavc/vaapi_hevc: Do not initialize fields twice.

Fixes the following compilation warnings:
libavcodec/vaapi_hevc.c:155:21: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
.pic_fields.bits = {
   ~^~~~
libavcodec/vaapi_hevc.c:125:57: note: previous initialization is here
.pic_fields.value = 0,
^
libavcodec/vaapi_hevc.c:175:31: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
.slice_parsing_fields.bits = {
 ~^~~~
libavcodec/vaapi_hevc.c:126:57: note: previous initialization is here
.slice_parsing_fields.value   = 0,
---
 libavcodec/vaapi_hevc.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index 19aabcd..c69d63d 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -122,8 +122,6 @@ static int vaapi_hevc_start_frame(AVCodecContext  *avctx,
 pic->pic.output_surface = ff_vaapi_get_surface_id(h->ref->frame);
 
 pic->pic_param = (VAPictureParameterBufferHEVC) {
-.pic_fields.value = 0,
-.slice_parsing_fields.value   = 0,
 .pic_width_in_luma_samples= sps->width,
 .pic_height_in_luma_samples   = sps->height,
 .log2_min_luma_coding_block_size_minus3   = sps->log2_min_cb_size - 3,
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/latmenc: Error out for unsupported codecs.

[Carl Eugen Hoyos]

2019-03-21 10:06 GMT+01:00, Nicolas George :
> Carl Eugen Hoyos (12019-03-20):
>> +if (par->codec_id != AV_CODEC_ID_AAC && par->codec_id !=
>> AV_CODEC_ID_MP4ALS) {
>> +av_log(ctx, AV_LOG_ERROR, "Only AAC, LATM and ALS are
>> supported\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>
> I think EINVAL is more correct in this kind of case: EINVAL for invalid
> parameters from the application, INVALIDDATA for invalid data from the
> files. A quick grep shows it is not the only place this is done like
> that. I do not think it is urgent to fix it, just keep it in mind for
> later if you agree.

Should be fixed.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Avoid MPEG-TS 1-cycle delay

[Paolo Pr]

Hello,

looking at the code of libavformat/mpegtsenc.c I experienced a 1-cycle
delay with the mpegts muxer that could be avoided (at least for Opus codec)
by putting the following lines:
( https://ffmpeg.org/doxygen/4.1/mpegtsenc_8c_source.html#l01777 )

memcpy(ts_st->payload + ts_st->payload_size, buf, size);
ts_st->payload_size += size;
ts_st->opus_queued_samples += opus_samples;

... just above this line (
https://ffmpeg.org/doxygen/4.1/mpegtsenc_8c_source.html#l01734 ):

if (pkt->dts != AV_NOPTS_VALUE) {

Otherwise, at the first muxing cycle, none of the blocks with
mpegts_write_pes() function is executed.
I did not write a patch for that because I don't know if it works with
other codecs as well and I'm not sure if there could be other consequent
issues, but given that Opus can be used with low-latency, it would be good
to consider this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/4] lavc/qsvenc: use the common option "trellis" of AVCodecContext

[Zhong Li]

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c   | 5 -
 libavcodec/qsvenc_h264.c  | 2 +-
 libavcodec/qsvenc_hevc.c  | 2 +-
 libavcodec/qsvenc_mpeg2.c | 2 +-
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 2e98de93f1..914b9479c0 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -693,7 +693,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
 #if QSV_HAVE_TRELLIS
-q->extco2.Trellis = q->trellis;
+if (avctx->trellis >= 0)
+q->extco2.Trellis = (avctx->trellis == 0) ? MFX_TRELLIS_OFF : 
(MFX_TRELLIS_I | MFX_TRELLIS_P | MFX_TRELLIS_B);
+else
+q->extco2.Trellis = MFX_TRELLIS_UNKNOWN;
 #endif
 
 #if QSV_VERSION_ATLEAST(1, 8)
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index f458137848..4fea69fb2c 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -181,7 +181,7 @@ static const AVCodecDefault qsv_enc_defaults[] = {
 #if FF_API_CODER_TYPE
 { "coder", "-1"},
 #endif
-
+{ "trellis",   "-1"},
 { "flags", "+cgop" },
 #if FF_API_PRIVATE_OPT
 { "b_strategy", "-1"   },
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index 1e822efece..94a81d8c74 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -260,7 +260,7 @@ static const AVCodecDefault qsv_enc_defaults[] = {
 // same as the x264 default
 { "g", "248"   },
 { "bf","8" },
-
+{ "trellis",   "-1"},
 { "flags", "+cgop" },
 #if FF_API_PRIVATE_OPT
 { "b_strategy", "-1"   },
diff --git a/libavcodec/qsvenc_mpeg2.c b/libavcodec/qsvenc_mpeg2.c
index a7427d8109..e4ade56d62 100644
--- a/libavcodec/qsvenc_mpeg2.c
+++ b/libavcodec/qsvenc_mpeg2.c
@@ -87,7 +87,7 @@ static const AVCodecDefault qsv_enc_defaults[] = {
 // same as the x264 default
 { "g", "250"   },
 { "bf","3" },
-
+{ "trellis",   "-1"},
 { "flags", "+cgop" },
 #if FF_API_PRIVATE_OPT
 { "b_strategy", "-1"   },
-- 
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/4] lavc/qsvenc: enable hevc gpb option

[Zhong Li]

GPB is the default type, just contains forward references but the
slice_type is B slice.
Add this option to allow user to set regular P slice.

Fix ticket#6870

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c  | 7 +++
 libavcodec/qsvenc.h  | 4 
 libavcodec/qsvenc_hevc.c | 2 ++
 3 files changed, 13 insertions(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 1d9893efbf..2e98de93f1 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -270,6 +270,10 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
 #if QSV_HAVE_CO3
 av_log(avctx, AV_LOG_VERBOSE,"WinBRCMaxAvgKbps: %"PRIu32"; WinBRCSize: 
%"PRId32"\n",
co3->WinBRCMaxAvgKbps, co3->WinBRCSize);
+#if QSV_HAVE_GPB
+av_log(avctx, AV_LOG_VERBOSE,"GPB: %s\n", print_threestate(co3->GPB));
+#endif
+
 #endif
 
 if (avctx->codec_id == AV_CODEC_ID_H264) {
@@ -743,6 +747,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 q->extco3.Header.BufferSz  = sizeof(q->extco3);
 q->extco3.WinBRCMaxAvgKbps = q->win_brc_max_avg_kbps;
 q->extco3.WinBRCSize   = q->win_brc_size;
+#if QSV_HAVE_GPB
+q->extco3.GPB  = q->gpb_off ? MFX_CODINGOPTION_OFF : 
MFX_CODINGOPTION_UNKNOWN;
+#endif
 q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer 
*)>extco3;
 #else
 if (q->win_brc_max_avg_kbps || q->win_brc_size) {
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index f01453e67f..3030e4413f 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -47,6 +47,8 @@
 #define QSV_HAVE_LA_HRD QSV_VERSION_ATLEAST(1, 11)
 #define QSV_HAVE_VDENC  QSV_VERSION_ATLEAST(1, 15)
 
+#define QSV_HAVE_GPBQSV_VERSION_ATLEAST(1, 18)
+
 #if defined(_WIN32) || defined(__CYGWIN__)
 #define QSV_HAVE_AVBR   QSV_VERSION_ATLEAST(1, 3)
 #define QSV_HAVE_ICQQSV_VERSION_ATLEAST(1, 8)
@@ -179,6 +181,8 @@ typedef struct QSVEncContext {
 int win_brc_max_avg_kbps;
 int win_brc_size;
 
+int gpb_off;
+
 int a53_cc;
 
 #if QSV_HAVE_MF
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index df6ef24b72..1e822efece 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -242,6 +242,8 @@ static const AVOption options[] = {
 { "main10",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_MAIN10  
}, INT_MIN, INT_MAX, VE, "profile" },
 { "mainsp",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_MAINSP  
}, INT_MIN, INT_MAX, VE, "profile" },
 
+{ "gpb_off", "turn off GPB (generalized P/B frame) and use regular P 
frame", OFFSET(qsv.gpb_off), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE},
+
 { NULL },
 };
 
-- 
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 4/4] lavc/qsvenc_h264: remove the privite option trellis

[Zhong Li]

There are many problems of current qsv trellis option:
1. Duplicated with AVCodecContext definition
2. MFX_TRELLIS_XXX is introduced by MSDK API 1.17
   Currently Without MSDK API checking thus may cause compilation issue.
3. user is inclined to enable trellis when set "-trellis 1", but
   actually it is to disable since MFX_TRELLIS_OFF is equal to 1.
4. It is too complex for user to enable trellis for every frame(I/P/B).

Just simply remove the private option, and switch to the AVCodecContext
definition. Compatibility should not a big problem (expect can't exact map)
since the option name is same as AVCodecContext.

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.h  | 1 -
 libavcodec/qsvenc_h264.c | 6 --
 2 files changed, 7 deletions(-)

diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 3030e4413f..6e50baa783 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -160,7 +160,6 @@ typedef struct QSVEncContext {
 
 int single_sei_nal_unit;
 int max_dec_frame_buffering;
-int trellis;
 
 int bitrate_limit;
 int mbbrc;
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 4fea69fb2c..2bf3419d27 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -132,12 +132,6 @@ static const AVOption options[] = {
 { "int_ref_qp_delta",   "QP difference for the refresh MBs",   
  OFFSET(qsv.int_ref_qp_delta),AV_OPT_TYPE_INT, { .i64 = INT16_MIN }, 
INT16_MIN,  INT16_MAX, VE },
 { "recovery_point_sei", "Insert recovery point SEI messages",  
  OFFSET(qsv.recovery_point_sei),  AV_OPT_TYPE_INT, { .i64 = -1 },  
 -1,  1, VE },
 
-{ "trellis", "Trellis quantization",   
  OFFSET(qsv.trellis), AV_OPT_TYPE_FLAGS, { .i64 = 0 }, 0, 
UINT_MAX, VE, "trellis" },
-{ "off", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_TRELLIS_OFF }, 
.flags = VE, "trellis" },
-{ "I",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_TRELLIS_I },   
.flags = VE, "trellis" },
-{ "P",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_TRELLIS_P },   
.flags = VE, "trellis" },
-{ "B",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_TRELLIS_B },   
.flags = VE, "trellis" },
-
 { "profile", NULL, OFFSET(qsv.profile), AV_OPT_TYPE_INT, { .i64 = 
MFX_PROFILE_UNKNOWN }, 0, INT_MAX, VE, "profile" },
 { "unknown" , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_UNKNOWN 
 }, INT_MIN, INT_MAX, VE, "profile" },
 { "baseline", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
MFX_PROFILE_AVC_BASELINE }, INT_MIN, INT_MAX, VE, "profile" },
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/4] lavc/qsvenc: enable hevc coding options configuration

[Zhong Li]

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 2f128597db..1d9893efbf 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -625,9 +625,10 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 #endif
 }
 
-// the HEVC encoder plugin currently fails if coding options
-// are provided
-if (avctx->codec_id != AV_CODEC_ID_HEVC) {
+// The HEVC encoder plugin currently fails with some old libmfx version if 
coding options
+// are provided. Can't find the extract libmfx version which fixed it, 
just enable it from
+// V1.28 in order to keep compatibility security.
+if ((avctx->codec_id != AV_CODEC_ID_HEVC) || 
QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 28)) {
 q->extco.Header.BufferId  = MFX_EXTBUFF_CODING_OPTION;
 q->extco.Header.BufferSz  = sizeof(q->extco);
 
-- 
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] ffmpeg: add -drop_deviant_frames option

[Gyan]

Essential in avoiding loss of output streams (audio) for me, when input 
has unreliable transport.

Tested with software decoding (h264, aac, mp1, mp2) pipeline.

Gyan
From ca04af063ee4a9406b6f09e12126827728aff875 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 25 Mar 2019 22:01:07 +0530
Subject: [PATCH] ffmpeg: add -drop_deviant_frames option

Decoded frames with changed parameters in inputs expected to be uniform
may indicate malformed/corrupted packets. Demuxer with flag discardcorrupt
set may not catch all such packets and neither may decoders with err_detect
flags set.

Upon parameter change, AVFilterLink of any filters receiving such frames has
to be reconfigured, destroying existing filter context. In case of a
change in audio sample rate, timestamps can go haywire, potentially
leaving the output stream to be "truncated".

Added option allows users to avoid sending such deviant frames onwards.
Default behaviour remains unchanged.
---
 doc/ffmpeg.texi  |  4 
 fftools/ffmpeg.c | 47 ++--
 fftools/ffmpeg.h |  3 +++
 fftools/ffmpeg_opt.c |  5 +
 4 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index cd35eb49c8..338f98ecdf 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1664,6 +1664,10 @@ Discard all frames excepts keyframes.
 Discard all frames.
 @end table
 
+@item -drop_deviant_frames (@emph{input,per-stream})
+Allows discarding decoded frames whose parameters differ from initialized
+stream parameters. May be useful in  
+
 @item -abort_on @var{flags} (@emph{global})
 Stop and abort on various conditions. The following flags are available:
 
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 544f1a1cef..5da75306e3 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2283,7 +2283,7 @@ static int decode_audio(InputStream *ist, AVPacket *pkt, 
int *got_output,
 {
 AVFrame *decoded_frame;
 AVCodecContext *avctx = ist->dec_ctx;
-int ret, err = 0;
+int ret, err = 0, deviant = 0;
 AVRational decoded_frame_tb;
 
 if (!ist->decoded_frame && !(ist->decoded_frame = av_frame_alloc()))
@@ -2303,12 +2303,36 @@ static int decode_audio(InputStream *ist, AVPacket 
*pkt, int *got_output,
 ret = AVERROR_INVALIDDATA;
 }
 
+if (*got_output && ret >= 0 && ist->frames_decoded && ist->nb_filters &&
+(ist->filters[0]->sample_rate!= decoded_frame->sample_rate ||
+ ist->filters[0]->channels   != decoded_frame->channels ||
+ ist->filters[0]->channel_layout != decoded_frame->channel_layout ||
+ ist->filters[0]->format != decoded_frame->format ||
+ ist->filters[0]->sample_rate!= avctx->sample_rate)) {
+av_log(NULL, ist->drop_deviant_frames ? AV_LOG_INFO : AV_LOG_VERBOSE,
+   "Parameter change in decoded audio frame from stream %d.%d pts 
%s \n"
+   "filter rate:%d fmt:%s ch:%d layout:%"PRIX64" != frame rate:%d 
fmt:%s ch:%d layout:%"PRIX64", decoder context rate: %d \n",
+   ist->file_index, ist->st->index, 
av_ts2timestr(decoded_frame->pts, >st->time_base),
+   ist->filters[0]->sample_rate, 
av_get_sample_fmt_name(ist->filters[0]->format),
+   ist->filters[0]->channels, ist->filters[0]->channel_layout,
+   decoded_frame->sample_rate, 
av_get_sample_fmt_name(decoded_frame->format),
+   decoded_frame->channels, decoded_frame->channel_layout,
+   avctx->sample_rate);
+if (ist->drop_deviant_frames) {
+deviant = 1;
+av_log(NULL, AV_LOG_WARNING, "Dropping frame.\n");
+}
+}
+
 if (ret != AVERROR_EOF)
 check_decode_result(ist, got_output, ret);
 
 if (!*got_output || ret < 0)
 return ret;
 
+if (deviant)
+goto fail;
+
 ist->samples_decoded += decoded_frame->nb_samples;
 ist->frames_decoded++;
 
@@ -2335,6 +2359,7 @@ static int decode_audio(InputStream *ist, AVPacket *pkt, 
int *got_output,
 ist->nb_samples = decoded_frame->nb_samples;
 err = send_frame_to_filters(ist, decoded_frame);
 
+fail:
 av_frame_unref(ist->filter_frame);
 av_frame_unref(decoded_frame);
 return err < 0 ? err : ret;
@@ -2344,7 +2369,7 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
 int *decode_failed)
 {
 AVFrame *decoded_frame;
-int i, ret = 0, err = 0;
+int i, ret = 0, err = 0, deviant = 0;
 int64_t best_effort_timestamp;
 int64_t dts = AV_NOPTS_VALUE;
 AVPacket avpkt;
@@ -2413,11 +2438,29 @@ static int decode_video(InputStream *ist, AVPacket 
*pkt, int *got_output, int64_
 ist->dec_ctx->height,
 ist->dec_ctx->pix_fmt);
 }
+if (ist->nb_filters && ist->frames_decoded &&
+(ist->filters[0]->width!= decoded_frame->width ||
+ ist->filters[0]->height   != decoded_frame->height 

Re: [FFmpeg-devel] [PATCH 00/21] New Version

[Andreas Rheinhardt via ffmpeg-devel]

Carl Eugen Hoyos:
> 2019-03-27 12:18 GMT+01:00, Andreas Rheinhardt:
> 
>> I have cced Steve for this (I didn't the first time,
>> because I thought that he (as a maintainer) would
>> also be a subscriber to this list).
> 
> Everybody welcomes reviews by Steve but I don't
> think he maintains anything within FFmpeg.
> 
He is listed as maintainer for dxva2 and d3d11va in the maintainers
file. But this could be wrong/outdated.
>> Oh, and I did not check with Valgrind that the new
>> lacing code doesn't read uninitialized data. I don't
>> even know how to use Valgrind. I just read the
>> code. If someone more knowledgeable than I
>> could please test it...
> 
> Just use "valgrind ./ffmpeg_g ..."
> 
Thanks for the help, but unfortunately I can't use Valgrind on Windows.

- 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] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 17:12 schrieb Carl Eugen Hoyos:
> I was under the impression that we exchanged all
> these emails today only because you still hadn't
> found a way to measure the performance of your
> patch.

As I had written, I found a way with "-vf
loop=loop=1024:size=1:start=0", but I was curious how I could use the
shorter options -loop or -stream_loop from your suggestion of 19.03.19,
17:31 CET.
This does not mean, that I unlike your new suggestion with "-f rawvideo
".

> I hoped you had already tested the functional correctness.

Until this state of changes yes. But it is more convenient in my IDE
configuration to have only 1 script for both purposes.

Thanks for all your help

-Ulf

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavf/tls_gnutls: retry gnutls_handshake on non fatal errors

[Remita Amine]

fixes #7801

Signed-off-by: Remita Amine 
---
 libavformat/tls_gnutls.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index e3c43683be..f32bc2821b 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -182,11 +182,13 @@ static int tls_open(URLContext *h, const char *uri, int 
flags, AVDictionary **op
 gnutls_transport_set_push_function(p->session, gnutls_url_push);
 gnutls_transport_set_ptr(p->session, c->tcp);
 gnutls_priority_set_direct(p->session, "NORMAL", NULL);
-ret = gnutls_handshake(p->session);
-if (ret) {
-ret = print_tls_error(h, ret);
-goto fail;
-}
+do {
+ret = gnutls_handshake(p->session);
+if (gnutls_error_is_fatal(ret)) {
+ret = print_tls_error(h, ret);
+goto fail;
+}
+} while (ret);
 p->need_shutdown = 1;
 if (c->verify) {
 unsigned int status, cert_list_size;
-- 
2.21.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 00/21] New Version

[Carl Eugen Hoyos]

2019-03-27 12:18 GMT+01:00, Andreas Rheinhardt:

> I have cced Steve for this (I didn't the first time,
> because I thought that he (as a maintainer) would
> also be a subscriber to this list).

Everybody welcomes reviews by Steve but I don't
think he maintains anything within FFmpeg.

> Oh, and I did not check with Valgrind that the new
> lacing code doesn't read uninitialized data. I don't
> even know how to use Valgrind. I just read the
> code. If someone more knowledgeable than I
> could please test it...

Just use "valgrind ./ffmpeg_g ..."

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 06/21] avformat/matroskadec: Don't copy attached pictures

[Andreas Rheinhardt via ffmpeg-devel]

This commit replaces copying attached pictures by using references to
the already existing buffers.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index f9811b54a1..f1cfc09a5f 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2695,15 +2695,19 @@ static int matroska_read_header(AVFormatContext *s)
 attachments[j].stream = st;
 
 if (st->codecpar->codec_id != AV_CODEC_ID_NONE) {
+AVPacket *pkt = >attached_pic;
+
 st->disposition |= AV_DISPOSITION_ATTACHED_PIC;
 st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
 
-av_init_packet(>attached_pic);
-if ((res = av_new_packet(>attached_pic, 
attachments[j].bin.size)) < 0)
-return res;
-memcpy(st->attached_pic.data, attachments[j].bin.data, 
attachments[j].bin.size);
-st->attached_pic.stream_index = st->index;
-st->attached_pic.flags   |= AV_PKT_FLAG_KEY;
+av_init_packet(pkt);
+pkt->buf = av_buffer_ref(attachments[j].bin.buf);
+if (!pkt->buf)
+return AVERROR(ENOMEM);
+pkt->data = attachments[j].bin.data;
+pkt->size = attachments[j].bin.size;
+pkt->stream_index = st->index;
+pkt->flags   |= AV_PKT_FLAG_KEY;
 } else {
 st->codecpar->codec_type = AVMEDIA_TYPE_ATTACHMENT;
 if (ff_alloc_extradata(st->codecpar, attachments[j].bin.size))
-- 
2.19.2

___
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 21/21] avformat/matroskadec: Typos and cosmetics

[Andreas Rheinhardt via ffmpeg-devel]

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index bd0dfee4db..8243b858da 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1645,7 +1645,7 @@ static void matroska_convert_tags(AVFormatContext *s)
 static int matroska_parse_seekhead_entry(MatroskaDemuxContext *matroska,
  uint64_t pos)
 {
-uint32_t saved_id   = matroska->current_id;
+uint32_t saved_id  = matroska->current_id;
 int64_t before_pos = avio_tell(matroska->ctx->pb);
 MatroskaLevel level;
 int64_t offset;
@@ -2693,7 +2693,7 @@ static int matroska_read_header(AVFormatContext *s)
 /* The next thing is a segment. */
 pos = avio_tell(matroska->ctx->pb);
 res = ebml_parse(matroska, matroska_segments, matroska);
-// try resyncing until we find a EBML_STOP type element.
+// try resyncing until we find an EBML_STOP type element.
 while (res != 1) {
 res = matroska_resync(matroska, pos);
 if (res < 0)
@@ -3544,8 +3544,8 @@ static int matroska_parse_cluster(MatroskaDemuxContext 
*matroska)
block->discard_padding);
 }
 
-ebml_free(matroska_blockgroup, block);
-memset(block, 0, sizeof(*block));
+ebml_free(matroska_blockgroup, block);
+memset(block, 0, sizeof(*block));
 } else if (!matroska->num_levels) {
 if (!avio_feof(matroska->ctx->pb)) {
 avio_r8(matroska->ctx->pb);
@@ -3951,7 +3951,7 @@ static int webm_dash_manifest_cues(AVFormatContext *s, 
int64_t init_range)
 // cues end
 av_dict_set_int(>streams[0]->metadata, CUES_END, cues_end, 0);
 
-// if the file has cues at the start, fix up the init range so tht
+// if the file has cues at the start, fix up the init range so that
 // it does not include it
 if (cues_start <= init_range)
 av_dict_set_int(>streams[0]->metadata, INITIALIZATION_RANGE, 
cues_start - 1, 0);
-- 
2.19.2

___
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 20/21] avformat/matroskadec: Redo EOF handling

[Andreas Rheinhardt via ffmpeg-devel]

This commit adds a check and a corresponding warning whether there
is data beyond the Matroska segment (only reasonable for finite-sized
segments). If everything looks alright, then parsing is stopped as soon
as EOF is reached (in contrast, the current code would always call
matroska_resync at the end).

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index c1feb3f0a1..bd0dfee4db 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3547,6 +3547,14 @@ static int matroska_parse_cluster(MatroskaDemuxContext 
*matroska)
 ebml_free(matroska_blockgroup, block);
 memset(block, 0, sizeof(*block));
 } else if (!matroska->num_levels) {
+if (!avio_feof(matroska->ctx->pb)) {
+avio_r8(matroska->ctx->pb);
+if (!avio_feof(matroska->ctx->pb)) {
+av_log(matroska->ctx, AV_LOG_WARNING, "File extends beyond "
+   "end of segment.\n");
+return AVERROR_INVALIDDATA;
+}
+}
 matroska->done = 1;
 return AVERROR_EOF;
 }
@@ -3560,10 +3568,11 @@ static int matroska_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 int ret = 0;
 
 while (matroska_deliver_packet(matroska, pkt)) {
-int64_t pos = avio_tell(matroska->ctx->pb);
+int64_t pos;
 if (matroska->done)
 return (ret < 0) ? ret : AVERROR_EOF;
-if (matroska_parse_cluster(matroska) < 0)
+pos = avio_tell(matroska->ctx->pb);
+if ((matroska_parse_cluster(matroska) < 0) && !matroska->done)
 ret = matroska_resync(matroska, pos);
 }
 
-- 
2.19.2

___
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 18/21] avformat/matroskadec: Combine two arrays

[Andreas Rheinhardt via ffmpeg-devel]

By including SimpleBlocks and Blocksgroups twice in the same EbmlSyntax
array (with different semantics), one can reduce the duplication of the
other values.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 3adcb3e86d..60f58cefa9 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -704,25 +704,18 @@ static const EbmlSyntax matroska_blockgroup[] = {
 };
 
 static const EbmlSyntax matroska_cluster_parsing[] = {
-{ MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, offsetof(MatroskaCluster, 
timecode) },
-{ MATROSKA_ID_BLOCKGROUP,  EBML_NEST, 0, 0, { .n = matroska_blockgroup 
} },
 { MATROSKA_ID_SIMPLEBLOCK, EBML_BIN,  0, offsetof(MatroskaBlock, bin) 
},
-{ MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
-{ MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
-{ 0 }
-};
-
-static const EbmlSyntax matroska_cluster_initial[] = {
+{ MATROSKA_ID_BLOCKGROUP,  EBML_NEST, 0, 0, { .n = matroska_blockgroup 
} },
 { MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, offsetof(MatroskaCluster, 
timecode) },
-{ MATROSKA_ID_BLOCKGROUP,  EBML_STOP },
 { MATROSKA_ID_SIMPLEBLOCK, EBML_STOP },
+{ MATROSKA_ID_BLOCKGROUP,  EBML_STOP },
 { MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
 { MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
 { 0 }
 };
 
 static const EbmlSyntax matroska_cluster_enter[] = {
-{ MATROSKA_ID_CLUSTER, EBML_NEST, 0, 0, { .n = 
matroska_cluster_initial } },
+{ MATROSKA_ID_CLUSTER, EBML_NEST, 0, 0, { .n = 
_cluster_parsing[2] } },
 { 0 }
 };
 
-- 
2.19.2

___
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 19/21] avformat/matroskadec: Add SilentTracks to cluster syntax

[Andreas Rheinhardt via ffmpeg-devel]

This is important as unknown-sized elements end upon encountering an
unknown EBML ID.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroska.h| 1 +
 libavformat/matroskadec.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 86968a8de1..43fea595b6 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -224,6 +224,7 @@
 #define MATROSKA_ID_CLUSTERTIMECODE 0xE7
 #define MATROSKA_ID_CLUSTERPOSITION 0xA7
 #define MATROSKA_ID_CLUSTERPREVSIZE 0xAB
+#define MATROSKA_ID_SILENTTRACKS 0x5854
 #define MATROSKA_ID_BLOCKGROUP 0xA0
 #define MATROSKA_ID_BLOCKADDITIONS 0x75A1
 #define MATROSKA_ID_BLOCKMORE 0xA6
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 60f58cefa9..c1feb3f0a1 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -711,6 +711,7 @@ static const EbmlSyntax matroska_cluster_parsing[] = {
 { MATROSKA_ID_BLOCKGROUP,  EBML_STOP },
 { MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
 { MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
+{ MATROSKA_ID_SILENTTRACKS,EBML_NONE },
 { 0 }
 };
 
-- 
2.19.2

___
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 17/21] avformat/matroskadec: Don't reset cluster position

[Andreas Rheinhardt via ffmpeg-devel]

The new code does not rely on whether the cluster's position is set or
not to infer whether a cluster needs to be closed or not (instead, the
levels are closed during ebml_parse), so there is no need to reset the
cluster's position at all any more. It will be automatically set to the
correct value when a cluster is entered.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index fc8c3f936c..3adcb3e86d 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -747,7 +747,6 @@ static int matroska_reset_status(MatroskaDemuxContext 
*matroska,
 {
 matroska->current_id = id;
 matroska->num_levels = 1;
-matroska->current_cluster.pos = 0;
 
 if (position >= 0)
 return avio_seek(matroska->ctx->pb, position, SEEK_SET);
@@ -1679,8 +1678,8 @@ static int 
matroska_parse_seekhead_entry(MatroskaDemuxContext *matroska,
 }
 }
 
-/* Seek back - notice that in all instances where this is used it is safe
- * to set the level to 1 and unset the position of the current cluster. */
+/* Seek back - notice that in all instances where this is used
+ * it is safe to set the level to 1. */
 matroska_reset_status(matroska, saved_id, before_pos);
 
 return ret;
@@ -3535,7 +3534,6 @@ static int matroska_parse_cluster(MatroskaDemuxContext 
*matroska)
 }
 
 if (matroska->num_levels == 2) {
-int err = 0;
 /* We are inside a cluster. */
 res = ebml_parse(matroska, matroska_cluster_parsing, cluster);
 
@@ -3544,7 +3542,7 @@ static int matroska_parse_cluster(MatroskaDemuxContext 
*matroska)
 uint8_t* additional = block->additional.size > 0 ?
 block->additional.data : NULL;
 
-err = matroska_parse_block(matroska, block->bin.buf, 
block->bin.data,
+res = matroska_parse_block(matroska, block->bin.buf, 
block->bin.data,
block->bin.size, block->bin.pos,
cluster->timecode, block->duration,
is_keyframe, additional, 
block->additional_id,
@@ -3552,14 +3550,8 @@ static int matroska_parse_cluster(MatroskaDemuxContext 
*matroska)
block->discard_padding);
 }
 
-if (res == LEVEL_ENDED)
-cluster->pos = 0;
-
 ebml_free(matroska_blockgroup, block);
 memset(block, 0, sizeof(*block));
-
-if (err < 0)
-return err;
 } else if (!matroska->num_levels) {
 matroska->done = 1;
 return AVERROR_EOF;
-- 
2.19.2

___
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 14/21] avformat/matroskadec: Use proper levels after discontínuity

[Andreas Rheinhardt via ffmpeg-devel]

The earlier code set the level to zero upon seeking and after a
discontinuity although in both cases parsing (re)starts at a level 1
element.

Also set the segment's length to unkown if an error occured in order not
to drop any valid data that happens to be beyond the designated end of
the segment.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 59 +++
 1 file changed, 35 insertions(+), 24 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 0179e5426e..42f1c21042 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -737,13 +737,24 @@ static const char *const matroska_doctypes[] = { 
"matroska", "webm" };
 
 static int matroska_read_close(AVFormatContext *s);
 
+static int matroska_reset_status(MatroskaDemuxContext *matroska,
+ uint32_t id, int64_t position)
+{
+matroska->current_id = id;
+matroska->num_levels = 1;
+matroska->current_cluster.pos = 0;
+
+if (position >= 0)
+return avio_seek(matroska->ctx->pb, position, SEEK_SET);
+
+return 0;
+}
+
 static int matroska_resync(MatroskaDemuxContext *matroska, int64_t last_pos)
 {
 AVIOContext *pb = matroska->ctx->pb;
 int64_t ret;
 uint32_t id;
-matroska->current_id = 0;
-matroska->num_levels = 0;
 
 /* seek to next position to resync from */
 if ((ret = avio_seek(pb, last_pos + 1, SEEK_SET)) < 0) {
@@ -759,7 +770,14 @@ static int matroska_resync(MatroskaDemuxContext *matroska, 
int64_t last_pos)
 id == MATROSKA_ID_CUES || id == MATROSKA_ID_TAGS||
 id == MATROSKA_ID_SEEKHEAD || id == MATROSKA_ID_ATTACHMENTS ||
 id == MATROSKA_ID_CLUSTER  || id == MATROSKA_ID_CHAPTERS) {
-matroska->current_id = id;
+/* Prepare the context for further parsing of a level 1 element. */
+matroska_reset_status(matroska, id, -1);
+
+/* Given that we are here means that an error has occured,
+ * so treat the segment as unknown length in order not to
+ * discard valid data that happens to be beyond the designated
+ * end of the segment. */
+matroska->levels[0].length = EBML_UNKNOWN_LENGTH;
 return 0;
 }
 id = (id << 8) | avio_r8(pb);
@@ -1610,18 +1628,12 @@ static int 
matroska_parse_seekhead_entry(MatroskaDemuxContext *matroska,
 matroska->current_id   = 0;
 
 ret = ebml_parse(matroska, matroska_segment, matroska);
-
-/* remove dummy level */
-while (matroska->num_levels) {
-uint64_t length = 
matroska->levels[--matroska->num_levels].length;
-if (length == EBML_UNKNOWN_LENGTH)
-break;
-}
 }
 }
-/* seek back */
-avio_seek(matroska->ctx->pb, before_pos, SEEK_SET);
-matroska->current_id = saved_id;
+
+/* Seek back - notice that in all instances where this is used it is safe
+ * to set the level to 1 and unset the position of the current cluster. */
+matroska_reset_status(matroska, saved_id, before_pos);
 
 return ret;
 }
@@ -3535,9 +3547,7 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 timestamp = FFMAX(timestamp, st->index_entries[0].timestamp);
 
 if ((index = av_index_search_timestamp(st, timestamp, flags)) < 0 || index 
== st->nb_index_entries - 1) {
-avio_seek(s->pb, st->index_entries[st->nb_index_entries - 1].pos,
-  SEEK_SET);
-matroska->current_id = 0;
+matroska_reset_status(matroska, 0, 
st->index_entries[st->nb_index_entries - 1].pos);
 while ((index = av_index_search_timestamp(st, timestamp, flags)) < 0 
|| index == st->nb_index_entries - 1) {
 matroska_clear_queue(matroska);
 if (matroska_parse_cluster(matroska) < 0)
@@ -3557,8 +3567,8 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 tracks[i].end_timecode = 0;
 }
 
-avio_seek(s->pb, st->index_entries[index].pos, SEEK_SET);
-matroska->current_id   = 0;
+/* We seek to a level 1 element, so set the appropriate status. */
+matroska_reset_status(matroska, 0, st->index_entries[index].pos);
 if (flags & AVSEEK_FLAG_ANY) {
 st->skip_to_keyframe = 0;
 matroska->skip_to_timecode = timestamp;
@@ -3568,18 +3578,16 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 }
 matroska->skip_to_keyframe = 1;
 matroska->done = 0;
-matroska->num_levels   = 0;
 ff_update_cur_dts(s, st, st->index_entries[index].timestamp);
 return 0;
 err:
 // slightly hackish but allows proper fallback to
 // the generic seeking code.
+matroska_reset_status(matroska, 0, -1);
 matroska_clear_queue(matroska);
-matroska->current_id = 0;
 st->skip_to_keyframe =
 

[FFmpeg-devel] [PATCH 15/21] avformat/matroskadec: Redo level handling

[Andreas Rheinhardt via ffmpeg-devel]

This commit changes how levels are handled: If the level used for
ebml_parse ends directly after an element that has been consumed, then
ebml_parse ends the level itself (and any finite-sized levels that end
there as well) and informs the caller via the return value; if the
current level is unknown-sized, then the level is ended as soon as
an element that is not valid on the current level is encountered.

This is designed for situations where one wants to parse master elements
incrementally, i.e. not in one go via ebml_parse_nest.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 104 +++---
 1 file changed, 85 insertions(+), 19 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 42f1c21042..32cf57685f 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -69,6 +69,8 @@
 #include "qtpalette.h"
 
 #define EBML_UNKNOWN_LENGTH  UINT64_MAX /* EBML unknown length, in uint64_t */
+#define LEVEL_ENDED   2 /* return value of ebml_parse when the
+ * syntax level used for parsing 
ended. */
 
 typedef enum {
 EBML_NONE,
@@ -1041,16 +1043,32 @@ static int ebml_parse_id(MatroskaDemuxContext 
*matroska, EbmlSyntax *syntax,
  uint32_t id, void *data)
 {
 int i;
+
 for (i = 0; syntax[i].id; i++)
 if (id == syntax[i].id)
 break;
-if (!syntax[i].id && id == MATROSKA_ID_CLUSTER &&
-matroska->num_levels > 0   &&
-matroska->levels[matroska->num_levels - 1].length == 
EBML_UNKNOWN_LENGTH)
-return 0;  // we reached the end of an unknown size cluster
+
 if (!syntax[i].id && id != EBML_ID_VOID && id != EBML_ID_CRC32) {
-av_log(matroska->ctx, AV_LOG_DEBUG, "Unknown entry 0x%"PRIX32"\n", id);
+if (!matroska->num_levels || matroska->levels[matroska->num_levels - 
1].length
+!= 
EBML_UNKNOWN_LENGTH) {
+av_log(matroska->ctx, AV_LOG_DEBUG, "Unknown entry 0x%"PRIX32"\n", 
id);
+} else if (matroska->num_levels > 1) {
+// Unknown-sized master elements (except root elements) end
+// when an id not known to be allowed in them is encountered.
+matroska->num_levels--;
+return LEVEL_ENDED;
+} else if (matroska->num_levels == 1) {
+AVIOContext *pb = matroska->ctx->pb;
+int64_t pos = avio_tell(pb);
+// An unkown level 1 element inside an unknown-sized segment
+// is considered an error.
+av_log(matroska->ctx, AV_LOG_ERROR, "Found unknown element id 
0x%"PRIX32
+   " at pos. %"PRIu64" (0x%"PRIx64") in an unknown-sized 
segment. "
+   "Will be treated as error.\n", id, pos, pos);
+return AVERROR_INVALIDDATA;
+}
 }
+
 return ebml_parse_elem(matroska, [i], data);
 }
 
@@ -1061,9 +1079,24 @@ static int ebml_parse(MatroskaDemuxContext *matroska, 
EbmlSyntax *syntax,
 uint64_t id;
 int res = ebml_read_num(matroska, matroska->ctx->pb, 4, , 0);
 if (res < 0) {
-// in live mode, finish parsing if EOF is reached.
-return (matroska->is_live && matroska->ctx->pb->eof_reached &&
-res == AVERROR_EOF) ? 1 : res;
+if (matroska->ctx->pb->eof_reached && res == AVERROR_EOF) {
+if (matroska->is_live)
+// in live mode, finish parsing if EOF is reached.
+return 1;
+if (matroska->num_levels) {
+MatroskaLevel *level = 
>levels[matroska->num_levels - 1];
+
+if (level->length == EBML_UNKNOWN_LENGTH) {
+// Unknown-sized elements automatically end at EOF.
+matroska->num_levels = 0;
+return LEVEL_ENDED;
+} else if (avio_tell(matroska->ctx->pb) < level->start + 
level->length) {
+av_log(matroska->ctx, AV_LOG_ERROR, "File ended before 
"
+   "its declared end\n");
+}
+}
+}
+return res;
 }
 matroska->current_id = id | 1 << 7 * res;
 }
@@ -1098,10 +1131,15 @@ static int ebml_parse_nest(MatroskaDemuxContext 
*matroska, EbmlSyntax *syntax,
 break;
 }
 
-while (!res && !ebml_level_end(matroska))
+if (!matroska->levels[matroska->num_levels - 1].length) {
+matroska->num_levels--;
+return 0;
+}
+
+while (!res)
 res = ebml_parse(matroska, syntax, data);
 
-return res;
+return res == LEVEL_ENDED ? 0 : res;
 }
 
 static int is_ebml_id_valid(uint32_t id)
@@ -1169,7 +1207,7 @@ static int ebml_parse_elem(MatroskaDemuxContext *matroska,
 AVIOContext *pb = matroska->ctx->pb;

[FFmpeg-devel] [PATCH 16/21] avformat/matroskadec: Make cluster parsing level compatible

[Andreas Rheinhardt via ffmpeg-devel]

Before this commit, the parsing of clusters mixed EBML levels by
allowing elements from different levels in a EbmlSyntax (namely
matroska_cluster_parsing). This has been changed. The level is now
explicitly used to determine how to parse.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 102 +-
 1 file changed, 46 insertions(+), 56 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 32cf57685f..fc8c3f936c 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -709,15 +709,10 @@ static const EbmlSyntax matroska_cluster_parsing[] = {
 { MATROSKA_ID_SIMPLEBLOCK, EBML_BIN,  0, offsetof(MatroskaBlock, bin) 
},
 { MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
 { MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
-{ MATROSKA_ID_INFO,EBML_NONE },
-{ MATROSKA_ID_CUES,EBML_NONE },
-{ MATROSKA_ID_TAGS,EBML_NONE },
-{ MATROSKA_ID_SEEKHEAD,EBML_NONE },
-{ MATROSKA_ID_CLUSTER, EBML_STOP },
 { 0 }
 };
 
-static const EbmlSyntax matroska_cluster[] = {
+static const EbmlSyntax matroska_cluster_initial[] = {
 { MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, offsetof(MatroskaCluster, 
timecode) },
 { MATROSKA_ID_BLOCKGROUP,  EBML_STOP },
 { MATROSKA_ID_SIMPLEBLOCK, EBML_STOP },
@@ -726,12 +721,20 @@ static const EbmlSyntax matroska_cluster[] = {
 { 0 }
 };
 
+static const EbmlSyntax matroska_cluster_enter[] = {
+{ MATROSKA_ID_CLUSTER, EBML_NEST, 0, 0, { .n = 
matroska_cluster_initial } },
+{ 0 }
+};
+
 static const EbmlSyntax matroska_clusters[] = {
-{ MATROSKA_ID_CLUSTER,  EBML_NEST, 0, 0, { .n = matroska_cluster } },
-{ MATROSKA_ID_INFO, EBML_NONE },
-{ MATROSKA_ID_CUES, EBML_NONE },
-{ MATROSKA_ID_TAGS, EBML_NONE },
-{ MATROSKA_ID_SEEKHEAD, EBML_NONE },
+{ MATROSKA_ID_CLUSTER, EBML_STOP },
+{ MATROSKA_ID_CUES,EBML_NONE },
+{ MATROSKA_ID_TAGS,EBML_NONE },
+{ MATROSKA_ID_INFO,EBML_NONE },
+{ MATROSKA_ID_TRACKS,  EBML_NONE },
+{ MATROSKA_ID_ATTACHMENTS, EBML_NONE },
+{ MATROSKA_ID_CHAPTERS,EBML_NONE },
+{ MATROSKA_ID_SEEKHEAD,EBML_NONE },
 { 0 }
 };
 
@@ -789,24 +792,6 @@ static int matroska_resync(MatroskaDemuxContext *matroska, 
int64_t last_pos)
 return AVERROR_EOF;
 }
 
-/*
- * Return: Whether we reached the end of a level in the hierarchy or not.
- */
-static int ebml_level_end(MatroskaDemuxContext *matroska)
-{
-AVIOContext *pb = matroska->ctx->pb;
-int64_t pos = avio_tell(pb);
-
-if (matroska->num_levels > 0) {
-MatroskaLevel *level = >levels[matroska->num_levels - 1];
-if (pos - level->start >= level->length || matroska->current_id) {
-matroska->num_levels--;
-return 1;
-}
-}
-return (matroska->is_live && matroska->ctx->pb->eof_reached) ? 1 : 0;
-}
-
 /*
  * Read: an "EBML number", which is defined as a variable-length
  * array of bytes. The first byte indicates the length by giving a
@@ -3533,41 +3518,39 @@ static int matroska_parse_cluster(MatroskaDemuxContext 
*matroska)
 MatroskaCluster *cluster = >current_cluster;
 MatroskaBlock *block = >block;
 int res;
-res = ebml_parse(matroska,
- matroska_cluster_parsing,
- cluster);
-if (res == 1) {
-/* New Cluster */
-if (cluster->pos)
-ebml_level_end(matroska);
-cluster->pos = avio_tell(matroska->ctx->pb);
-/* sizeof the ID which was already read */
-if (matroska->current_id)
-cluster->pos -= 4;
-res = ebml_parse(matroska,
- matroska_clusters,
- cluster);
-/* Try parsing the block again. */
-if (res == 1)
-res = ebml_parse(matroska,
- matroska_cluster_parsing,
- cluster);
+
+av_assert0(matroska->num_levels <= 2);
+
+if (matroska->num_levels == 1) {
+res = ebml_parse(matroska, matroska_clusters, NULL);
+
+if (res == 1) {
+/* Found a cluster: subtract the size of the ID already read. */
+cluster->pos = avio_tell(matroska->ctx->pb) - 4;
+
+res = ebml_parse(matroska, matroska_cluster_enter, cluster);
+if (res < 0)
+return res;
+}
 }
 
-if ((!res || res == LEVEL_ENDED) && block->bin.size > 0) {
+if (matroska->num_levels == 2) {
+int err = 0;
+/* We are inside a cluster. */
+res = ebml_parse(matroska, matroska_cluster_parsing, cluster);
+
+if ((!res || res == LEVEL_ENDED) && block->bin.size > 0) {
 int is_keyframe = block->non_simple ? block->reference == 
INT64_MIN : -1;
 uint8_t* additional = block->additional.size > 0 ?
 

[FFmpeg-devel] [PATCH 12/21] avformat/matroskadec: Remove redundant variable declaration

[Andreas Rheinhardt via ffmpeg-devel]

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index b98e690f01..6fa324c0cc 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1179,7 +1179,6 @@ static int ebml_parse_elem(MatroskaDemuxContext *matroska,
 }
 if (matroska->num_levels > 0) {
 MatroskaLevel *level = >levels[matroska->num_levels - 1];
-AVIOContext *pb = matroska->ctx->pb;
 int64_t pos = avio_tell(pb);
 if (level->length != EBML_UNKNOWN_LENGTH &&
 (pos + length) > (level->start + level->length)) {
-- 
2.19.2

___
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 13/21] avformat/matroskadec: Improve length check

[Andreas Rheinhardt via ffmpeg-devel]

The earlier code had three flaws:

1. The case of an unknown-sized element inside a finite-sized element
(which is against the specifications) was not caught.

2. The error message wasn't helpful: It compared the length of the child
with the offset of the end of the parent and claimed that the first
exceeds the latter, although that is not necessarily true.

3. Unknown-sized elements that are not parsed can't be skipped. Given
that according to the Matroska specifications only the segment and the
clusters can be of unknown-size, this is handled by not allowing any
other units to have infinite size whereas the earlier code would seek
back by 1 byte upon encountering an infinite-size element that ought
to be skipped.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 6fa324c0cc..0179e5426e 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1180,11 +1180,29 @@ static int ebml_parse_elem(MatroskaDemuxContext 
*matroska,
 if (matroska->num_levels > 0) {
 MatroskaLevel *level = >levels[matroska->num_levels - 1];
 int64_t pos = avio_tell(pb);
-if (level->length != EBML_UNKNOWN_LENGTH &&
-(pos + length) > (level->start + level->length)) {
+
+if (length != EBML_UNKNOWN_LENGTH &&
+level->length != EBML_UNKNOWN_LENGTH) {
+uint64_t elem_end = pos + length,
+level_end = level->start + level->length;
+
+if (level_end < elem_end) {
+av_log(matroska->ctx, AV_LOG_ERROR,
+   "Element at 0x%"PRIx64" ending at 0x%"PRIx64" 
exceeds "
+   "containing master element ending at 0x%"PRIx64"\n",
+   pos, elem_end, level_end);
+return AVERROR_INVALIDDATA;
+}
+} else if (level->length != EBML_UNKNOWN_LENGTH) {
+av_log(matroska->ctx, AV_LOG_ERROR, "Unknown-sized element "
+   "at 0x%"PRIx64" inside parent with finite size\n", pos);
+return AVERROR_INVALIDDATA;
+} else if (length == EBML_UNKNOWN_LENGTH && id != 
MATROSKA_ID_CLUSTER) {
+// According to the specifications only clusters and segments
+// are allowed to be unknown-sized.
 av_log(matroska->ctx, AV_LOG_ERROR,
-   "Invalid length 0x%"PRIx64" > 0x%"PRIx64" in parent\n",
-   length, level->start + level->length);
+   "Found unknown-sized element other than a cluster at "
+   "0x%"PRIx64". Dropping the invalid element.\n", pos);
 return AVERROR_INVALIDDATA;
 }
 }
-- 
2.19.2

___
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 11/21] avformat/matroskadec: Treat SimpleBlock as EBML_BIN

[Andreas Rheinhardt via ffmpeg-devel]

Up until now, the SimpleBlock was treated specially: It basically had
its own EBML category and it was also included in the BlockGroup EBML
syntax (although a SimpleBlock must not exist in a BlockGroup according
to the Matroska specifications). The latter fact also meant that
a MatroskaBlock's buffer was always unreferenced twice.
This has been changed: The type of a SimpleBlock is now an EBML_BIN.
The only way in which SimpleBlocks are still different is that they
share their associated structure with another unit (namely BlockGroup).
This is also used to unref the block: It is always unreferenced via the
BlockGroup syntax.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 997c96d78f..b98e690f01 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -79,7 +79,6 @@ typedef enum {
 EBML_BIN,
 EBML_NEST,
 EBML_LEVEL1,
-EBML_PASS,
 EBML_STOP,
 EBML_SINT,
 EBML_TYPE_COUNT
@@ -694,7 +693,6 @@ static const EbmlSyntax matroska_blockadditions[] = {
 static const EbmlSyntax matroska_blockgroup[] = {
 { MATROSKA_ID_BLOCK,  EBML_BIN,  0, offsetof(MatroskaBlock, bin) },
 { MATROSKA_ID_BLOCKADDITIONS, EBML_NEST, 0, 0, { .n = 
matroska_blockadditions} },
-{ MATROSKA_ID_SIMPLEBLOCK,EBML_BIN,  0, offsetof(MatroskaBlock, bin) },
 { MATROSKA_ID_BLOCKDURATION,  EBML_UINT, 0, offsetof(MatroskaBlock, 
duration) },
 { MATROSKA_ID_DISCARDPADDING, EBML_SINT, 0, offsetof(MatroskaBlock, 
discard_padding) },
 { MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0, offsetof(MatroskaBlock, 
reference), { .i = INT64_MIN } },
@@ -706,7 +704,7 @@ static const EbmlSyntax matroska_blockgroup[] = {
 static const EbmlSyntax matroska_cluster_parsing[] = {
 { MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, offsetof(MatroskaCluster, 
timecode) },
 { MATROSKA_ID_BLOCKGROUP,  EBML_NEST, 0, 0, { .n = matroska_blockgroup 
} },
-{ MATROSKA_ID_SIMPLEBLOCK, EBML_PASS, 0, 0, { .n = matroska_blockgroup 
} },
+{ MATROSKA_ID_SIMPLEBLOCK, EBML_BIN,  0, offsetof(MatroskaBlock, bin) 
},
 { MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
 { MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
 { MATROSKA_ID_INFO,EBML_NONE },
@@ -1169,7 +1167,7 @@ static int ebml_parse_elem(MatroskaDemuxContext *matroska,
 list->nb_elem++;
 }
 
-if (syntax->type != EBML_PASS && syntax->type != EBML_STOP) {
+if (syntax->type != EBML_STOP) {
 matroska->current_id = 0;
 if ((res = ebml_read_length(matroska, pb, )) < 0)
 return res;
@@ -1225,8 +1223,6 @@ static int ebml_parse_elem(MatroskaDemuxContext *matroska,
 level1_elem->parsed = 1;
 }
 return ebml_parse_nest(matroska, syntax->def.n, data);
-case EBML_PASS:
-return ebml_parse_id(matroska, syntax->def.n, id, data);
 case EBML_STOP:
 return 1;
 default:
-- 
2.19.2

___
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 08/21] avformat/matroskadec: Improve error messages

[Andreas Rheinhardt via ffmpeg-devel]

ebml_read_num had a number of flaws:

1. The check for read errors/EOF was totally wrong. E.g. an EBML number
beginning with the invalid 0x00 would be considered a read error,
although it is just invalid data.
2. The check for read errors/EOF was done just once, after reading the
first byte of the EBML number. But errors/EOF can happen inbetween, of
course, and this wasn't checked.
3. There was no way to distinguish when EOF should be an error (because
the data has to be there) for which an error message should be emitted
and when it is not necessarily an error (namely during parsing of EBML
IDs). Such a possibility has been added and used.

Some useless initializations were also fixed.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 61 ++-
 1 file changed, 34 insertions(+), 27 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index a6617a607b..aa2266384a 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -820,29 +820,19 @@ static int ebml_level_end(MatroskaDemuxContext *matroska)
  * Returns: number of bytes read, < 0 on error
  */
 static int ebml_read_num(MatroskaDemuxContext *matroska, AVIOContext *pb,
- int max_size, uint64_t *number)
+ int max_size, uint64_t *number, int eof_forbidden)
 {
-int read = 1, n = 1;
-uint64_t total = 0;
+int read, n = 1;
+uint64_t total;
+int64_t pos;
 
-/* The first byte tells us the length in bytes - avio_r8() can normally
- * return 0, but since that's not a valid first ebmlID byte, we can
- * use it safely here to catch EOS. */
-if (!(total = avio_r8(pb))) {
-/* we might encounter EOS here */
-if (!avio_feof(pb)) {
-int64_t pos = avio_tell(pb);
-av_log(matroska->ctx, AV_LOG_ERROR,
-   "Read error at pos. %"PRIu64" (0x%"PRIx64")\n",
-   pos, pos);
-return pb->error ? pb->error : AVERROR(EIO);
-}
-return AVERROR_EOF;
-}
+/* The first byte tells us the length in bytes - except when it is zero. */
+total = avio_r8(pb);
+if (avio_feof(pb))
+goto err;
 
 /* get the length of the EBML number */
-read = 8 - ff_log2_tab[total];
-if (read > max_size) {
+if (!total || (read = 8 - ff_log2_tab[total]) > max_size) {
 int64_t pos = avio_tell(pb) - 1;
 av_log(matroska->ctx, AV_LOG_ERROR,
"Invalid EBML number size tag 0x%02x at pos %"PRIu64" 
(0x%"PRIx64")\n",
@@ -855,9 +845,27 @@ static int ebml_read_num(MatroskaDemuxContext *matroska, 
AVIOContext *pb,
 while (n++ < read)
 total = (total << 8) | avio_r8(pb);
 
+if (avio_feof(pb)) {
+eof_forbidden = 1;
+goto err;
+}
+
 *number = total;
 
 return read;
+
+err:
+pos = avio_tell(pb);
+if (pb->error) {
+av_log(matroska->ctx, AV_LOG_ERROR,
+   "Read error at pos. %"PRIu64" (0x%"PRIx64")\n",
+   pos, pos);
+return pb->error;
+}
+if (eof_forbidden)
+av_log(matroska->ctx, AV_LOG_ERROR, "File ended prematurely "
+   "at pos. %"PRIu64" (0x%"PRIx64")\n", pos, pos);
+return AVERROR_EOF;
 }
 
 /**
@@ -868,7 +876,7 @@ static int ebml_read_num(MatroskaDemuxContext *matroska, 
AVIOContext *pb,
 static int ebml_read_length(MatroskaDemuxContext *matroska, AVIOContext *pb,
 uint64_t *number)
 {
-int res = ebml_read_num(matroska, pb, 8, number);
+int res = ebml_read_num(matroska, pb, 8, number, 1);
 if (res > 0 && *number + 1 == 1ULL << (7 * res))
 *number = EBML_UNKNOWN_LENGTH;
 return res;
@@ -1010,7 +1018,7 @@ static int matroska_ebmlnum_uint(MatroskaDemuxContext 
*matroska,
 {
 AVIOContext pb;
 ffio_init_context(, data, size, 0, NULL, NULL, NULL, NULL);
-return ebml_read_num(matroska, , FFMIN(size, 8), num);
+return ebml_read_num(matroska, , FFMIN(size, 8), num, 1);
 }
 
 /*
@@ -1057,7 +1065,7 @@ static int ebml_parse(MatroskaDemuxContext *matroska, 
EbmlSyntax *syntax,
 {
 if (!matroska->current_id) {
 uint64_t id;
-int res = ebml_read_num(matroska, matroska->ctx->pb, 4, );
+int res = ebml_read_num(matroska, matroska->ctx->pb, 4, , 0);
 if (res < 0) {
 // in live mode, finish parsing if EOF is reached.
 return (matroska->is_live && matroska->ctx->pb->eof_reached &&
@@ -3335,10 +3343,9 @@ static int matroska_parse_block(MatroskaDemuxContext 
*matroska, AVBufferRef *buf
 uint64_t num;
 int trust_default_duration = 1;
 
-if ((n = matroska_ebmlnum_uint(matroska, data, size, )) < 0) {
-av_log(matroska->ctx, AV_LOG_ERROR, "EBML block data error\n");
+if ((n = matroska_ebmlnum_uint(matroska, data, size, )) < 0)
 return n;
-}
+
 data += n;
 size -= n;
 
@@ -3699,7 +3706,7 @@ static int 

[FFmpeg-devel] [PATCH 09/21] avformat/matroskadec: Remove non-incremental parsing of clusters

[Andreas Rheinhardt via ffmpeg-devel]

When the new incremental parser was introduced, the old parser was
kept, because the new parser was unable to handle the way SSA packets
are put into Matroska. But since 2014 (since
c7d8dbad14ed5fa3c217a4fc1790021d6c0b6416) this is no longer needed, so
that the old parser can be completely removed.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 72 ++-
 1 file changed, 10 insertions(+), 62 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index aa2266384a..9198fa1bea 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -360,9 +360,6 @@ typedef struct MatroskaDemuxContext {
 int64_t current_cluster_pos;
 MatroskaCluster current_cluster;
 
-/* File has SSA subtitles which prevent incremental cluster parsing. */
-int contains_ssa;
-
 /* WebM DASH Manifest live flag */
 int is_live;
 
@@ -707,25 +704,7 @@ static const EbmlSyntax matroska_blockgroup[] = {
 { 0 }
 };
 
-static const EbmlSyntax matroska_cluster[] = {
-{ MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, 
offsetof(MatroskaCluster, timecode) },
-{ MATROSKA_ID_BLOCKGROUP,  EBML_NEST, sizeof(MatroskaBlock), 
offsetof(MatroskaCluster, blocks), { .n = matroska_blockgroup } },
-{ MATROSKA_ID_SIMPLEBLOCK, EBML_PASS, sizeof(MatroskaBlock), 
offsetof(MatroskaCluster, blocks), { .n = matroska_blockgroup } },
-{ MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
-{ MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
-{ 0 }
-};
-
-static const EbmlSyntax matroska_clusters[] = {
-{ MATROSKA_ID_CLUSTER,  EBML_NEST, 0, 0, { .n = matroska_cluster } },
-{ MATROSKA_ID_INFO, EBML_NONE },
-{ MATROSKA_ID_CUES, EBML_NONE },
-{ MATROSKA_ID_TAGS, EBML_NONE },
-{ MATROSKA_ID_SEEKHEAD, EBML_NONE },
-{ 0 }
-};
-
-static const EbmlSyntax matroska_cluster_incremental_parsing[] = {
+static const EbmlSyntax matroska_cluster_parsing[] = {
 { MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, 
offsetof(MatroskaCluster, timecode) },
 { MATROSKA_ID_BLOCKGROUP,  EBML_NEST, sizeof(MatroskaBlock), 
offsetof(MatroskaCluster, blocks), { .n = matroska_blockgroup } },
 { MATROSKA_ID_SIMPLEBLOCK, EBML_PASS, sizeof(MatroskaBlock), 
offsetof(MatroskaCluster, blocks), { .n = matroska_blockgroup } },
@@ -739,7 +718,7 @@ static const EbmlSyntax 
matroska_cluster_incremental_parsing[] = {
 { 0 }
 };
 
-static const EbmlSyntax matroska_cluster_incremental[] = {
+static const EbmlSyntax matroska_cluster[] = {
 { MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, offsetof(MatroskaCluster, 
timecode) },
 { MATROSKA_ID_BLOCKGROUP,  EBML_STOP },
 { MATROSKA_ID_SIMPLEBLOCK, EBML_STOP },
@@ -748,8 +727,8 @@ static const EbmlSyntax matroska_cluster_incremental[] = {
 { 0 }
 };
 
-static const EbmlSyntax matroska_clusters_incremental[] = {
-{ MATROSKA_ID_CLUSTER,  EBML_NEST, 0, 0, { .n = 
matroska_cluster_incremental } },
+static const EbmlSyntax matroska_clusters[] = {
+{ MATROSKA_ID_CLUSTER,  EBML_NEST, 0, 0, { .n = matroska_cluster } },
 { MATROSKA_ID_INFO, EBML_NONE },
 { MATROSKA_ID_CUES, EBML_NONE },
 { MATROSKA_ID_TAGS, EBML_NONE },
@@ -2592,8 +2571,6 @@ static int matroska_parse_tracks(AVFormatContext *s)
 }
 } else if (track->type == MATROSKA_TRACK_TYPE_SUBTITLE) {
 st->codecpar->codec_type = AVMEDIA_TYPE_SUBTITLE;
-if (st->codecpar->codec_id == AV_CODEC_ID_ASS)
-matroska->contains_ssa = 1;
 }
 }
 
@@ -3464,19 +3441,19 @@ end:
 return res;
 }
 
-static int matroska_parse_cluster_incremental(MatroskaDemuxContext *matroska)
+static int matroska_parse_cluster(MatroskaDemuxContext *matroska)
 {
 EbmlList *blocks_list;
 MatroskaBlock *blocks;
 int i, res;
 res = ebml_parse(matroska,
- matroska_cluster_incremental_parsing,
+ matroska_cluster_parsing,
  >current_cluster);
 if (res == 1) {
 /* New Cluster */
 if (matroska->current_cluster_pos)
 ebml_level_end(matroska);
-ebml_free(matroska_cluster, >current_cluster);
+ebml_free(matroska_cluster_parsing, >current_cluster);
 memset(>current_cluster, 0, sizeof(MatroskaCluster));
 matroska->current_cluster_num_blocks = 0;
 matroska->current_cluster_pos= avio_tell(matroska->ctx->pb);
@@ -3484,12 +3461,12 @@ static int 
matroska_parse_cluster_incremental(MatroskaDemuxContext *matroska)
 if (matroska->current_id)
 matroska->current_cluster_pos -= 4;
 res = ebml_parse(matroska,
- matroska_clusters_incremental,
+ matroska_clusters,
  >current_cluster);
 /* Try parsing the block again. */
 if (res == 1)
 res = ebml_parse(matroska,
-  

[FFmpeg-devel] [PATCH 10/21] avformat/matroskadec: Don't keep old blocks

[Andreas Rheinhardt via ffmpeg-devel]

Before this commit, the Matroska muxer would read a block when required
to do so, parse the block, create and return the necessary AVPackets and
yet keep the blocks (in a dynamically allocated list), although they
aren't used at all any more. This has been changed. There is no list any
more and the block is immediately discarded after parsing.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 87 +--
 1 file changed, 38 insertions(+), 49 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 9198fa1bea..997c96d78f 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -304,9 +304,20 @@ typedef struct MatroskaLevel {
 uint64_t length;
 } MatroskaLevel;
 
+typedef struct MatroskaBlock {
+uint64_t duration;
+int64_t  reference;
+uint64_t non_simple;
+EbmlBin  bin;
+uint64_t additional_id;
+EbmlBin  additional;
+int64_t discard_padding;
+} MatroskaBlock;
+
 typedef struct MatroskaCluster {
+MatroskaBlock block;
 uint64_t timecode;
-EbmlList blocks;
+int64_t pos;
 } MatroskaCluster;
 
 typedef struct MatroskaLevel1Element {
@@ -356,8 +367,6 @@ typedef struct MatroskaDemuxContext {
 MatroskaLevel1Element level1_elems[64];
 int num_level1_elems;
 
-int current_cluster_num_blocks;
-int64_t current_cluster_pos;
 MatroskaCluster current_cluster;
 
 /* WebM DASH Manifest live flag */
@@ -367,16 +376,6 @@ typedef struct MatroskaDemuxContext {
 int bandwidth;
 } MatroskaDemuxContext;
 
-typedef struct MatroskaBlock {
-uint64_t duration;
-int64_t  reference;
-uint64_t non_simple;
-EbmlBin  bin;
-uint64_t additional_id;
-EbmlBin  additional;
-int64_t discard_padding;
-} MatroskaBlock;
-
 static const EbmlSyntax ebml_header[] = {
 { EBML_ID_EBMLREADVERSION,EBML_UINT, 0, offsetof(Ebml, version),   
  { .u = EBML_VERSION } },
 { EBML_ID_EBMLMAXSIZELENGTH,  EBML_UINT, 0, offsetof(Ebml, max_size),  
  { .u = 8 } },
@@ -705,9 +704,9 @@ static const EbmlSyntax matroska_blockgroup[] = {
 };
 
 static const EbmlSyntax matroska_cluster_parsing[] = {
-{ MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, 
offsetof(MatroskaCluster, timecode) },
-{ MATROSKA_ID_BLOCKGROUP,  EBML_NEST, sizeof(MatroskaBlock), 
offsetof(MatroskaCluster, blocks), { .n = matroska_blockgroup } },
-{ MATROSKA_ID_SIMPLEBLOCK, EBML_PASS, sizeof(MatroskaBlock), 
offsetof(MatroskaCluster, blocks), { .n = matroska_blockgroup } },
+{ MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, offsetof(MatroskaCluster, 
timecode) },
+{ MATROSKA_ID_BLOCKGROUP,  EBML_NEST, 0, 0, { .n = matroska_blockgroup 
} },
+{ MATROSKA_ID_SIMPLEBLOCK, EBML_PASS, 0, 0, { .n = matroska_blockgroup 
} },
 { MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
 { MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
 { MATROSKA_ID_INFO,EBML_NONE },
@@ -3443,57 +3442,48 @@ end:
 
 static int matroska_parse_cluster(MatroskaDemuxContext *matroska)
 {
-EbmlList *blocks_list;
-MatroskaBlock *blocks;
-int i, res;
+MatroskaCluster *cluster = >current_cluster;
+MatroskaBlock *block = >block;
+int res;
 res = ebml_parse(matroska,
  matroska_cluster_parsing,
- >current_cluster);
+ cluster);
 if (res == 1) {
 /* New Cluster */
-if (matroska->current_cluster_pos)
+if (cluster->pos)
 ebml_level_end(matroska);
-ebml_free(matroska_cluster_parsing, >current_cluster);
-memset(>current_cluster, 0, sizeof(MatroskaCluster));
-matroska->current_cluster_num_blocks = 0;
-matroska->current_cluster_pos= avio_tell(matroska->ctx->pb);
+cluster->pos = avio_tell(matroska->ctx->pb);
 /* sizeof the ID which was already read */
 if (matroska->current_id)
-matroska->current_cluster_pos -= 4;
+cluster->pos -= 4;
 res = ebml_parse(matroska,
  matroska_clusters,
- >current_cluster);
+ cluster);
 /* Try parsing the block again. */
 if (res == 1)
 res = ebml_parse(matroska,
  matroska_cluster_parsing,
- >current_cluster);
+ cluster);
 }
 
-if (!res &&
-matroska->current_cluster_num_blocks <
-matroska->current_cluster.blocks.nb_elem) {
-blocks_list = >current_cluster.blocks;
-blocks  = blocks_list->elem;
+if (!res && block->bin.size > 0) {
+int is_keyframe = block->non_simple ? block->reference == 
INT64_MIN : -1;
+uint8_t* additional = block->additional.size > 0 ?
+block->additional.data : NULL;
 
-matroska->current_cluster_num_blocks = 

[FFmpeg-devel] [PATCH 05/21] avformat/matroskadec: Set offset of first cluster

[Andreas Rheinhardt via ffmpeg-devel]

By default, the data_offset member of the AVFormatInternal of the
AVFormatContext associated with the MatroskaDemuxContext has not been
initialized explicitly by any Matroska-specific function, so that it was
initialized by default to the offset at the end of matroska_read_header,
i.e. usually to the offset of the length field of the first encountered
cluster. This meant that in case that the Matroska-specific seek-code
fails because there are no index entries for the target track a seek to
data_offset would be performed and ordinary parsing would start from
there which is nonsense: The length field would be treated as EBML ID and
(if the length field is not longer than four bytes (EBML numbers that
long are rejected as invalid EBML IDs)) and whatever comes next would be
treated as its EBML size although it simply isn't.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 49f8ff4082..f9811b54a1 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2651,6 +2651,9 @@ static int matroska_read_header(AVFormatContext *s)
 pos = avio_tell(matroska->ctx->pb);
 res = ebml_parse(matroska, matroska_segment, matroska);
 }
+/* Set data_offset as it might be needed later by seek_frame_generic. */
+if (matroska->current_id)
+s->internal->data_offset = avio_tell(matroska->ctx->pb) - 4;
 matroska_execute_seekhead(matroska);
 
 if (!matroska->time_scale)
-- 
2.19.2

___
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 07/21] avformat/matroskadec: Remove redundant initialization

[Andreas Rheinhardt via ffmpeg-devel]

Every new element of an EbmlList is zeroed initially in
ebml_parse_elem, so that in particular a SimpleBlock's duration is
initialized to zero. Therefore it is unnecessary to initialize this
field again (for SimpleBlocks) in matroska_parse_cluster_incremental.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index f1cfc09a5f..a6617a607b 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3498,8 +3498,7 @@ static int 
matroska_parse_cluster_incremental(MatroskaDemuxContext *matroska)
 int is_keyframe = blocks[i].non_simple ? blocks[i].reference == 
INT64_MIN : -1;
 uint8_t* additional = blocks[i].additional.size > 0 ?
 blocks[i].additional.data : NULL;
-if (!blocks[i].non_simple)
-blocks[i].duration = 0;
+
 res = matroska_parse_block(matroska, blocks[i].bin.buf, 
blocks[i].bin.data,
blocks[i].bin.size, blocks[i].bin.pos,
matroska->current_cluster.timecode,
-- 
2.19.2

___
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 04/21] avformat/matroskadec: Use generic size check for signed integers

[Andreas Rheinhardt via ffmpeg-devel]

and drop the redundant checks contained in ebml_read_uint and
ebml_read_sint.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index f3bc792728..49f8ff4082 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -882,9 +882,6 @@ static int ebml_read_uint(AVIOContext *pb, int size, 
uint64_t *num)
 {
 int n = 0;
 
-if (size > 8)
-return AVERROR_INVALIDDATA;
-
 /* big-endian ordering; build up number */
 *num = 0;
 while (n++ < size)
@@ -901,9 +898,6 @@ static int ebml_read_sint(AVIOContext *pb, int size, 
int64_t *num)
 {
 int n = 1;
 
-if (size > 8)
-return AVERROR_INVALIDDATA;
-
 if (size == 0) {
 *num = 0;
 } else {
@@ -1161,6 +1155,7 @@ static int ebml_parse_elem(MatroskaDemuxContext *matroska,
 {
 static const uint64_t max_lengths[EBML_TYPE_COUNT] = {
 [EBML_UINT]  = 8,
+[EBML_SINT]  = 8,
 [EBML_FLOAT] = 8,
 // max. 16 MB for strings
 [EBML_STR]   = 0x100,
-- 
2.19.2

___
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 02/21] avformat/matroskadec: Don't zero unnecessarily

[Andreas Rheinhardt via ffmpeg-devel]

It is only necessary to zero the initial allocated memory used to store
the size of laced frames if the block used Xiph lacing. Otherwise no
unintialized data was ever used, so use av_malloc instead of av_mallocz.

Also use the correct type for the allocations.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 48b1ba3872..7a96e53bdd 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2796,7 +2796,7 @@ static int matroska_parse_laces(MatroskaDemuxContext 
*matroska, uint8_t **buf,
 
 if (!type) {
 *laces= 1;
-*lace_buf = av_mallocz(sizeof(int));
+*lace_buf = av_malloc(sizeof(**lace_buf));
 if (!*lace_buf)
 return AVERROR(ENOMEM);
 
@@ -2808,7 +2808,7 @@ static int matroska_parse_laces(MatroskaDemuxContext 
*matroska, uint8_t **buf,
 *laces= *data + 1;
 data += 1;
 size -= 1;
-lace_size = av_mallocz(*laces * sizeof(int));
+lace_size = av_malloc(*laces * sizeof(*lace_size));
 if (!lace_size)
 return AVERROR(ENOMEM);
 
@@ -2818,6 +2818,8 @@ static int matroska_parse_laces(MatroskaDemuxContext 
*matroska, uint8_t **buf,
 uint8_t temp;
 uint32_t total = 0;
 for (n = 0; res == 0 && n < *laces - 1; n++) {
+lace_size[n] = 0;
+
 while (1) {
 if (size <= total) {
 res = AVERROR_INVALIDDATA;
-- 
2.19.2

___
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 01/21] avformat/matroskadec: Remove unused variables

[Andreas Rheinhardt via ffmpeg-devel]

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 81e9bb9bff..48b1ba3872 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -322,7 +322,6 @@ typedef struct MatroskaDemuxContext {
 /* EBML stuff */
 int num_levels;
 MatroskaLevel levels[EBML_MAX_DEPTH];
-int level_up;
 uint32_t current_id;
 
 uint64_t time_scale;
@@ -1593,7 +1592,6 @@ static void matroska_convert_tags(AVFormatContext *s)
 static int matroska_parse_seekhead_entry(MatroskaDemuxContext *matroska,
  uint64_t pos)
 {
-uint32_t level_up   = matroska->level_up;
 uint32_t saved_id   = matroska->current_id;
 int64_t before_pos = avio_tell(matroska->ctx->pb);
 MatroskaLevel level;
@@ -1629,7 +1627,6 @@ static int 
matroska_parse_seekhead_entry(MatroskaDemuxContext *matroska,
 }
 /* seek back */
 avio_seek(matroska->ctx->pb, before_pos, SEEK_SET);
-matroska->level_up   = level_up;
 matroska->current_id = saved_id;
 
 return ret;
@@ -3564,7 +3561,7 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 MatroskaDemuxContext *matroska = s->priv_data;
 MatroskaTrack *tracks = NULL;
 AVStream *st = s->streams[stream_index];
-int i, index, index_min;
+int i, index;
 
 /* Parse the CUES now since we need the index data to seek. */
 if (matroska->cues_parsing_deferred > 0) {
@@ -3591,7 +3588,6 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 if (index < 0 || (matroska->cues_parsing_deferred < 0 && index == 
st->nb_index_entries - 1))
 goto err;
 
-index_min = index;
 tracks = matroska->tracks.elem;
 for (i = 0; i < matroska->tracks.nb_elem; i++) {
 tracks[i].audio.pkt_cnt= 0;
@@ -3600,7 +3596,7 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 tracks[i].end_timecode = 0;
 }
 
-avio_seek(s->pb, st->index_entries[index_min].pos, SEEK_SET);
+avio_seek(s->pb, st->index_entries[index].pos, SEEK_SET);
 matroska->current_id   = 0;
 if (flags & AVSEEK_FLAG_ANY) {
 st->skip_to_keyframe = 0;
-- 
2.19.2

___
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 03/21] avformat/matroskadec: Get rid of cluster size field assumption

[Andreas Rheinhardt via ffmpeg-devel]

The earlier code relied on the length of clusters always being coded on
eight bytes (as is current Matroska muxer behaviour). But there is no
need to rely on this and this commit changes it.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskadec.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 7a96e53bdd..f3bc792728 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3694,14 +3694,16 @@ static int 
webm_clusters_start_with_keyframe(AVFormatContext *s)
 before_pos = avio_tell(s->pb);
 while (1) {
 int64_t cluster_id = 0, cluster_length = 0;
+int read;
 AVPacket *pkt;
 avio_seek(s->pb, cluster_pos, SEEK_SET);
 // read cluster id and length
-ebml_read_num(matroska, matroska->ctx->pb, 4, _id);
-ebml_read_length(matroska, matroska->ctx->pb, _length);
-if (cluster_id != 0xF43B675) { // done with all clusters
+read = ebml_read_num(matroska, matroska->ctx->pb, 4, _id);
+if (read < 0 || cluster_id != 0xF43B675) // done with all clusters
+break;
+read = ebml_read_length(matroska, matroska->ctx->pb, _length);
+if (read < 0)
 break;
-}
 avio_seek(s->pb, cluster_pos, SEEK_SET);
 matroska->current_id = 0;
 matroska_clear_queue(matroska);
@@ -3710,7 +3712,8 @@ static int 
webm_clusters_start_with_keyframe(AVFormatContext *s)
 break;
 }
 pkt = >queue->pkt;
-cluster_pos += cluster_length + 12; // 12 is the offset of the cluster 
id and length.
+// 4 + read is the length of the cluster id and the cluster length 
field.
+cluster_pos += 4 + read + cluster_length;
 if (!(pkt->flags & AV_PKT_FLAG_KEY)) {
 rv = 0;
 break;
-- 
2.19.2

___
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 00/21] New Version

[Andreas Rheinhardt via ffmpeg-devel]

Here is a new version. Some of the already sent patches were slightly
modified: The first patch now removes two unused variables and "Improve
length check" has been rewritten. Furthermore, some new patches not
directly needed in order to fix the garbage error message have been
added:

1. The generic seeking code sometimes relies on the data_offset to seek
to in order to begin parsing from this point on. For the Matroska
demuxer, this field has usually been set to the beginning of the size
field of the first cluster. This is wrong, instead it should be set to
the beginning of the first cluster. This fixes a "Truncating packet of
size 21061679 to 17740959" error that one gets when using Michael's
sample with the commandline he provided.
2. Attachments are already read into a suitably padded refcounted AVBuffer,
so that one can directly reuse this AVBuffer in case this attachment
contains an attached picture.
3. The error messages in ebml_read_num were quite suboptimal and have
been fixed.

My idea to make the incremental parsing of clusters level compliant is
that levels are an EBML concept and so this should be handled internally
by the EBML functions, not the Matroska functions. So ebml_parse itself
takes care of correctly opening/closing the levels. This has been
coupled with the length checks that are done before reading an element's
payload in order to reduce the amount of checks needed. Furthermore, a
special return value is returned whenever a level is ended so that one
can use this to determine whether to perform whatever action is necessary
at the end of a level. (In the end, the actual parsing of clusters
turned out not to need this.)

This also changed the handling of unknown-sized elements: They are now
ended whenever an element not known to be allowed in them is
encountered. If we are already on level 1 and encounter an element not
known to be allowed in an unknown-sized segment, this is treated as an
indication that an error might have occured. I hope this is fine.

Dale's sample "bear-320x240-live.webm" btw has cues at the end that use
unknown-sized elements (wastefully coded on eight bytes) for CuePoints and
CueTrackPositions which is spec-incompliant. They are not referenced by
a SeekHead and so can't be used for seeking, but if they were, neither
current FFmpeg nor FFmpeg with my patches applied would be able to use
them. Are such files common (this is the first such file I ever saw)?
If so, I could probably make it work.

I have cced Steve for this (I didn't the first time, because I
thought that he (as a maintainer) would also be a subscriber to this
list).

Oh, and I did not check with Valgrind that the new lacing code doesn't
read uninitialized data. I don't even know how to use Valgrind. I just
read the code. If someone more knowledgeable than I could please test
it...

- Andreas

Andreas Rheinhardt (21):
  avformat/matroskadec: Remove unused variables
  avformat/matroskadec: Don't zero unnecessarily
  avformat/matroskadec: Get rid of cluster size field assumption
  avformat/matroskadec: Use generic size check for signed integers
  avformat/matroskadec: Set offset of first cluster
  avformat/matroskadec: Don't copy attached pictures
  avformat/matroskadec: Remove redundant initialization
  avformat/matroskadec: Improve error messages
  avformat/matroskadec: Remove non-incremental parsing of clusters
  avformat/matroskadec: Don't keep old blocks
  avformat/matroskadec: Treat SimpleBlock as EBML_BIN
  avformat/matroskadec: Remove redundant variable declaration
  avformat/matroskadec: Improve length check
  avformat/matroskadec: Use proper levels after discontínuity
  avformat/matroskadec: Redo level handling
  avformat/matroskadec: Make cluster parsing level compatible
  avformat/matroskadec: Don't reset cluster position
  avformat/matroskadec: Combine two arrays
  avformat/matroskadec: Add SilentTracks to cluster syntax
  avformat/matroskadec: Redo EOF handling
  avformat/matroskadec: Typos and cosmetics

 libavformat/matroska.h|   1 +
 libavformat/matroskadec.c | 537 --
 2 files changed, 280 insertions(+), 258 deletions(-)

-- 
2.19.2

___
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] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Wang, Shaofei]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: Tuesday, March 26, 2019 6:36 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode +
> N filter graphs and adaptive bitrate.
> 
> 2019-03-26 23:07 GMT+01:00, Shaofei Wang :
> > It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above
> > about 4%~20% improvement in some 1:N scenarios by CPU or GPU
> > acceleration
> 
> Which version of the patch did you test to get this numbers?
> 
The current one got it. It may move depend on different platform, density and 
case
___
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 v2] lavc/qsvenc: get vps extradata from MSDK

[Zhong Li]

Signed-off-by: Zhong Li 
---
V2: Fix the regression of qsv h264 encoding since no VPS for h264

 libavcodec/qsvenc.c  | 53 ++--
 libavcodec/qsvenc.h  |  3 +++
 libavcodec/qsvenc_hevc.c | 10 +---
 3 files changed, 54 insertions(+), 12 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 576d88c259..2f128597db 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -810,6 +810,16 @@ static int qsv_retrieve_enc_params(AVCodecContext *avctx, 
QSVEncContext *q)
 };
 #endif
 
+#if QSV_HAVE_CO_VPS
+uint8_t vps_buf[128];
+mfxExtCodingOptionVPS extradata_vps = {
+.Header.BufferId = MFX_EXTBUFF_CODING_OPTION_VPS,
+.Header.BufferSz = sizeof(extradata_vps),
+.VPSBuffer   = vps_buf,
+.VPSBufSize  = sizeof(vps_buf),
+};
+#endif
+
 mfxExtBuffer *ext_buffers[] = {
 (mfxExtBuffer*),
 (mfxExtBuffer*),
@@ -818,14 +828,24 @@ static int qsv_retrieve_enc_params(AVCodecContext *avctx, 
QSVEncContext *q)
 #endif
 #if QSV_HAVE_CO3
 (mfxExtBuffer*),
+#endif
+#if QSV_HAVE_CO_VPS
+(mfxExtBuffer*)_vps,
 #endif
 };
 
 int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
-int ret;
+int ret, extradata_offset = 0;
 
 q->param.ExtParam= ext_buffers;
+
+#if QSV_HAVE_CO_VPS
+q->hevc_vps = ((avctx->codec_id == AV_CODEC_ID_HEVC) && 
QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 17));
+q->param.NumExtParam = FF_ARRAY_ELEMS(ext_buffers) - 1 + q->hevc_vps;
+#else
+q->hevc_vps = 0;
 q->param.NumExtParam = FF_ARRAY_ELEMS(ext_buffers);
+#endif
 
 ret = MFXVideoENCODE_GetVideoParam(q->session, >param);
 if (ret < 0)
@@ -834,20 +854,37 @@ static int qsv_retrieve_enc_params(AVCodecContext *avctx, 
QSVEncContext *q)
 
 q->packet_size = q->param.mfx.BufferSizeInKB * 
q->param.mfx.BRCParamMultiplier * 1000;
 
-if (!extradata.SPSBufSize || (need_pps && !extradata.PPSBufSize)) {
+if (!extradata.SPSBufSize || (need_pps && !extradata.PPSBufSize)
+#if QSV_HAVE_CO_VPS
+|| (q->hevc_vps && !extradata_vps.VPSBufSize)
+#endif
+) {
 av_log(avctx, AV_LOG_ERROR, "No extradata returned from libmfx.\n");
 return AVERROR_UNKNOWN;
 }
 
-avctx->extradata = av_malloc(extradata.SPSBufSize + need_pps * 
extradata.PPSBufSize +
- AV_INPUT_BUFFER_PADDING_SIZE);
+avctx->extradata_size = extradata.SPSBufSize + need_pps * 
extradata.PPSBufSize;
+#if QSV_HAVE_CO_VPS
+avctx->extradata_size += q->hevc_vps * extradata_vps.VPSBufSize;
+#endif
+
+avctx->extradata = av_malloc(avctx->extradata_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (!avctx->extradata)
 return AVERROR(ENOMEM);
 
-memcpy(avctx->extradata,sps_buf, 
extradata.SPSBufSize);
-if (need_pps)
-memcpy(avctx->extradata + extradata.SPSBufSize, pps_buf, 
extradata.PPSBufSize);
-avctx->extradata_size = extradata.SPSBufSize + need_pps * 
extradata.PPSBufSize;
+#if QSV_HAVE_CO_VPS
+if (q->hevc_vps) {
+memcpy(avctx->extradata, vps_buf, extradata_vps.VPSBufSize);
+extradata_offset += extradata_vps.VPSBufSize;
+}
+#endif
+
+memcpy(avctx->extradata + extradata_offset, sps_buf, extradata.SPSBufSize);
+extradata_offset += extradata.SPSBufSize;
+if (need_pps) {
+memcpy(avctx->extradata + extradata_offset, pps_buf, 
extradata.PPSBufSize);
+extradata_offset += extradata.PPSBufSize;
+}
 memset(avctx->extradata + avctx->extradata_size, 0, 
AV_INPUT_BUFFER_PADDING_SIZE);
 
 cpb_props = ff_add_cpb_side_data(avctx);
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 25105894f2..f01453e67f 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -36,6 +36,7 @@
 
 #define QSV_HAVE_CO2 QSV_VERSION_ATLEAST(1, 6)
 #define QSV_HAVE_CO3 QSV_VERSION_ATLEAST(1, 11)
+#define QSV_HAVE_CO_VPS  QSV_VERSION_ATLEAST(1, 17)
 
 #define QSV_HAVE_TRELLIS QSV_VERSION_ATLEAST(1, 8)
 #define QSV_HAVE_MAX_SLICE_SIZE QSV_VERSION_ATLEAST(1, 9)
@@ -135,6 +136,8 @@ typedef struct QSVEncContext {
 
 mfxVersion  ver;
 
+int hevc_vps;
+
 // options set by the caller
 int async_depth;
 int idr_interval;
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index 9e15d3ce6b..df6ef24b72 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -195,10 +195,12 @@ static av_cold int qsv_enc_init(AVCodecContext *avctx)
 if (ret < 0)
 return ret;
 
-ret = generate_fake_vps(>qsv, avctx);
-if (ret < 0) {
-ff_qsv_enc_close(avctx, >qsv);
-return ret;
+if (!q->qsv.hevc_vps) {
+ret = generate_fake_vps(>qsv, avctx);
+if (ret < 0) {
+ff_qsv_enc_close(avctx, >qsv);
+return ret;
+}
 }
 
 return 0;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [PATCH] qsv: fix the dangerous macro definitions

[Zhong Li]

Signed-off-by: Zhong Li 
---
 libavcodec/qsv_internal.h | 8 
 libavfilter/qsvvpp.h  | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index 394c558883..86a5dbad98 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -35,12 +35,12 @@
 #define QSV_MAX_ENC_PAYLOAD 2   // # of mfxEncodeCtrl payloads supported
 
 #define QSV_VERSION_ATLEAST(MAJOR, MINOR)   \
-(MFX_VERSION_MAJOR > (MAJOR) || \
- MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR))
+((MFX_VERSION_MAJOR > (MAJOR) || \
+ MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR)))
 
 #define QSV_RUNTIME_VERSION_ATLEAST(MFX_VERSION, MAJOR, MINOR) \
-(MFX_VERSION.Major > (MAJOR)) ||   \
-(MFX_VERSION.Major == (MAJOR) && MFX_VERSION.Minor >= (MINOR))
+((MFX_VERSION.Major > (MAJOR)) ||   \
+(MFX_VERSION.Major == (MAJOR) && MFX_VERSION.Minor >= (MINOR)))
 
 typedef struct QSVMid {
 AVBufferRef *hw_frames_ref;
diff --git a/libavfilter/qsvvpp.h b/libavfilter/qsvvpp.h
index ff02b64c41..a02de6321a 100644
--- a/libavfilter/qsvvpp.h
+++ b/libavfilter/qsvvpp.h
@@ -32,12 +32,12 @@
 #define FF_OUTLINK_IDX(link) ((int)((link)->srcpad - (link)->src->output_pads))
 
 #define QSV_VERSION_ATLEAST(MAJOR, MINOR)   \
-(MFX_VERSION_MAJOR > (MAJOR) || \
- MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR))
+((MFX_VERSION_MAJOR > (MAJOR) || \
+ MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR)))
 
 #define QSV_RUNTIME_VERSION_ATLEAST(MFX_VERSION, MAJOR, MINOR) \
-(MFX_VERSION.Major > (MAJOR)) ||   \
-(MFX_VERSION.Major == (MAJOR) && MFX_VERSION.Minor >= (MINOR))
+((MFX_VERSION.Major > (MAJOR)) ||   \
+(MFX_VERSION.Major == (MAJOR) && MFX_VERSION.Minor >= (MINOR)))
 
 typedef struct QSVVPPContext QSVVPPContext;
 
-- 
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 v1 1/1] swscale/swscale_unscaled: fixed the issue that when width/height is not 2-multiple, transition of nv12 to u/v planes is not completed.

[Decai Lin]

From: "Dong, Jerry" 

Signed-off-by: Dong, Jerry 
Signed-off-by: Decai Lin 
---
 libswscale/swscale_unscaled.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 058f2b9..2ba2907 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -150,10 +150,10 @@ static int planarToNv12Wrapper(SwsContext *c, const 
uint8_t *src[],
   dstParam[0], dstStride[0]);
 
 if (c->dstFormat == AV_PIX_FMT_NV12)
-interleaveBytes(src[1], src[2], dst, c->srcW / 2, srcSliceH / 2,
+interleaveBytes(src[1], src[2], dst, (c->srcW + 1) / 2, (srcSliceH + 
1) / 2,
 srcStride[1], srcStride[2], dstStride[1]);
 else
-interleaveBytes(src[2], src[1], dst, c->srcW / 2, srcSliceH / 2,
+interleaveBytes(src[2], src[1], dst, (c->srcW + 1) / 2, (srcSliceH + 
1) / 2,
 srcStride[2], srcStride[1], dstStride[1]);
 
 return srcSliceH;
@@ -171,10 +171,10 @@ static int nv12ToPlanarWrapper(SwsContext *c, const 
uint8_t *src[],
   dstParam[0], dstStride[0]);
 
 if (c->srcFormat == AV_PIX_FMT_NV12)
-deinterleaveBytes(src[1], dst1, dst2,c->srcW / 2, srcSliceH / 2,
+deinterleaveBytes(src[1], dst1, dst2, (c->srcW + 1) / 2, (srcSliceH + 
1) / 2,
   srcStride[1], dstStride[1], dstStride[2]);
 else
-deinterleaveBytes(src[1], dst2, dst1, c->srcW / 2, srcSliceH / 2,
+deinterleaveBytes(src[1], dst2, dst1, (c->srcW + 1) / 2, (srcSliceH + 
1) / 2,
   srcStride[1], dstStride[2], dstStride[1]);
 
 return srcSliceH;
-- 
1.8.3.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] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Wang, Shaofei]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Michael Niedermayer
> Sent: Wednesday, March 27, 2019 5:24 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode +
> N filter graphs and adaptive bitrate.
 
> this still fails with some (fuzzed) samples valgrind does not seem to produce
> much usefull though ...
Still the join issue, will fix them in next version, thanks
> Error while decoding stream #0:0: Invalid data found when processing input
> [rv40 @ 0x25829f40] marking unfished frame as finished
> [rv40 @ 0x25829f40] concealing 27 DC, 27 AC, 27 MV errors in B frame
> [rv40 @ 0x2584f000] Slice indicates MB offset 142, got 140
> [rv40 @ 0x2584f000] Dquant for P-frame
> [rv40 @ 0x2584f000] concealing 2 DC, 2 AC, 2 MV errors in P frame Error
> while decoding stream #0:0: Invalid data found when processing input
> [rv40 @ 0x256dfb40] Slice indicates MB offset 140, got 135
> [rv40 @ 0x256dfb40] concealing 5 DC, 5 AC, 5 MV errors in B frame
> [rv40 @ 0x25701940] concealing 112 DC, 112 AC, 112 MV errors in P frame
> Error while decoding stream #0:0: Invalid data found when processing
> input=N/A
> Last message repeated 1 times
> [rv40 @ 0x25804e80] First slice header is incorrect
> [rv40 @ 0x256dfb40] Slice indicates MB offset 187, got 140
> [rv40 @ 0x256dfb40] Dquant for P-frame
> [rv40 @ 0x256dfb40] concealing 47 DC, 47 AC, 47 MV errors in P frame
> [rv40 @ 0x25726a00] Dquant for B-frame
> [rv40 @ 0x25770b80] concealing 115 DC, 115 AC, 115 MV errors in P frame
> Error while decoding stream #0:0: Invalid data found when processing
> input=N/A
> [rv40 @ 0x25804e80] Dquant for P-frame
> [rv40 @ 0x257dfdc0] Dquant for P-framee=-577014:32:22.77 bitrate=N/A
> speed=N/A
> [rv40 @ 0x25804e80] Dquant for B-frame
> Too many packets buffered for output stream 0:0.
> pthread_join failed with error: Resource deadlock avoided
> 
> gdb output:
> pthread_join failed with error: Resource deadlock avoided
> 
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fffe4def700 (LWP 13350)]
> 0x7fffefeaec37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> Python Exception  No module named
> gdb.frames:
> #0  0x7fffefeaec37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7fffefeb2028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x0042bea1 in strict_pthread_join (thread=140737033205504,
> value_ptr=0x0) at ./libavutil/thread.h:55
> #3  0x0042d342 in ffmpeg_cleanup (ret=1) at fftools/ffmpeg.c:526
> #4  0x004250d8 in exit_program (ret=1) at fftools/cmdutils.c:139
> #5  0x0042dfd4 in write_packet (of=0x231b780,
> pkt=0x7fffe4dee680, ost=0x237f680, unqueue=0) at fftools/ffmpeg.c:738
> #6  0x0042eb39 in output_packet (of=0x231b780,
> pkt=0x7fffe4dee680, ost=0x237f680, eof=0) at fftools/ffmpeg.c:903
> #7  0x00430c30 in do_video_out (of=0x231b780, ost=0x237f680,
> next_picture=0x7fffa4005200, sync_ipts=98940.800010681152) at
> fftools/ffmpeg.c:1337
> #8  0x00431986 in reap_filters (flush=1, ifilter=0x22d2c00) at
> fftools/ffmpeg.c:1533
> #9  0x00434dc8 in filter_pipeline (arg=0x22d2c00) at
> fftools/ffmpeg.c:2318
> #10 0x70249184 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #11 0x7fffeff7603d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> 
> 
> [...]
> --
> Michael GnuPG fingerprint:
> 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Those who are too smart to engage in politics are punished by being governed
> by those who are dumber. -- Plato
___
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] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Wang, Shaofei]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Wednesday, March 27, 2019 6:44 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode +
> N filter graphs and adaptive bitrate.
>
It will always without an ending to work out a perfect solution, that' also the
current situation of the parallelism issue in ffmpeg.
No matter how users would like to resolved the "well-known" serial
limitation by them self in their app, but why not do some positive thing in
the big amount user used ffmpeg tool? Although it's codebase was not
designed with parallelism mind, it can also be paralleled at some key part
of pipeline as the patch shows with lightly modification. Otherwise, a brand
new parallel designed ffmpeg can be delivered by extra big effort, and
concerns, behaviour problems will no less than the current one.
Some thoughts:
- Provide the option -abr_pipeline to enable this multiple simple filter graph
parallel optimization instead of by default, which means users who enable
it knows what they are doing and performance pursuing. The feature/
optimization shouldn't cover all the situations in ffmpeg which is a cool box
provides huge amount of different features. And some cases need parallel,
some not.
- To fix those already known parallel problems such as -benchmark_all.
Those consideration are good to improve and refine the feature/solution,
, even some hidden/not easy triggered issue found in future, they can be
fixed by dedicated patch.

Thanks

> On further thought, I don't think this patch should continue in its present
> form.
> 
> The fundamental problem is that the bolted-on parallelism renders it pretty
> much unreviewable - the codebase here was not designed with any
> parallelism in mind, so it does not follow the usual rules expected of such
> code.  In particular, there are global variables in many places accessed
> without regard for data races, and that becomes fatal undefined behaviour
> once parallelism is added.  While in theory every one of those can be fixed
> (by adding more locks, or one big lock covering many instances together), it
> will be very hard to verify that all cases have been covered and the code will
> suffer significantly in readability/maintainability for the change.
> 
> To give an explicit example of the sort of problems you are hitting, the
> -benchmark_all option is entirely broken in the current proposed version.  It
> invokes undefined behaviour by writing to the current_time global in every
> thread.  Even if that were avoided by moving the value to a thread-local
> structure, it also gives wrong results - getrusage(RUSAGE_SELF) returns values
> for the whole process, so it won't say anything useful once there are multiple
> threads looking at the value in parallel.  Perhaps that is fixable by using 
> some
> sort of per-thread storage and RUSAGE_THREAD (and some equivalent on
> Windows), but whatever that is certainly requires more investigation and
> probably a separate patch.
> 
> Three possible thoughts on where to go from here:
> 
> * Start by refactoring the code to make it easier to verify.  This would 
> entail
> something like removing all global variable accesses from parallel paths, and
> then ensuring that each thread only ever writes to its own local working set
> (e.g. OutputStream structure) while marking all other structures as const.
> After such refactoring has happened, a new version of the present patch
> would then be possible to assess.
> 
> * Run exhaustively in tsan/valgrind/other race detectors and fix every
> problem it finds, then provide evidence from that to help with review.  Since
> these issues can be hidden behind specific option combinations (as the
> benchmark one is), this would need a lot of care to ensure full coverage, and
> some parts (like the benchmark one) would need rewriting anyway.  As
> noted above I'm not sure this would be very good for the code, but we could
> at least have some amount of confidence that the result was correct.
For the existing code, already got lots of issues detected by valgrind/tsan.
We can provide evidence to prove the problem have been covered.
> 
> * Reconsider whether the patch is worth pursuing.  While I agree that a
> correct implementation of this would help in the specific use-cases you
> describe, I'm not sure that the set of users who gain from it is actually
> particularly large - most people wanting to maximise throughput in the way
> this change can help with already run multiple FFmpeg instances (or their own
> programs using the libraries) because the serial limitations of FFmpeg are
> well-known.
To run multiple FFmpeg instances couldn't stand for 1:N cases. And of course
users can use their own program to call the libraries, but we also see a lot of
users who use ffmpeg tool to build up their solution, demo, App and etc.

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/zmbvenc: add support for 24-bit encoding, using pix_fmt BGR24.

[Tomas Härdin]

tis 2019-03-26 klockan 22:13 + skrev Matthew Fearnley:
> Support is #ifdef'd out at this stage, using ZMBV_ENABLE_24BPP (like in
> the zmbv.c decoder)
> ---
>  libavcodec/zmbvenc.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
> index 98029de5f6..48871758e0 100644
> --- a/libavcodec/zmbvenc.c
> +++ b/libavcodec/zmbvenc.c
> @@ -340,6 +340,12 @@ static av_cold int encode_init(AVCodecContext *avctx)
>  c->fmt = ZMBV_FMT_16BPP;
>  c->bypp = 2;
>  break;
> +#ifdef ZMBV_ENABLE_24BPP
> +case AV_PIX_FMT_BGR24:
> +c->fmt = ZMBV_FMT_24BPP;
> +c->bypp = 3;
> +break;
> +#endif //ZMBV_ENABLE_24BPP

Should be fine, since our encoder is byte-oriented rather than word-
oriented like the DosBox encoder

/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 1/2] libavcodec/zmbv: change 24-bit decoder channel order, from RGB24 to BGR24

[Tomas Härdin]

tis 2019-03-26 klockan 22:13 + skrev Matthew Fearnley:
> This brings the channel order in line with that used in 32-bit mode (BGR0).
> 
> 24-bit decoding is disabled by default (#ifdef ZMBV_ENABLE_24BPP), and no
> prior encoders or sample videos are known to exist for this bit depth, so
> I consider this change in implementation is unlikely to affect anyone.
> 
> The decision has been made in agreement with the DOSBox Development Team
> > (dosbox.c...@gmail.com), specifically with harekiet, who wrote the original
> codec.

I can confirm this

> Additional minor fix: use PTRDIFF_SPECIFIER for `src - c->decomp_buf`.
> Other bit depths saw this change in ced0d6c14d, but this instance was
> missed, presumably because of the #ifdef block.

I think it'd be best to split this off into its own patch, even if it's
trivial

/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]lavc/bmp: Avoid a heap buffer overwrite for 1bpp

[Tomas Härdin]

tis 2019-03-26 klockan 13:38 +0100 skrev Carl Eugen Hoyos:
> Hi!
> 
> Attached patch intends to fix a buffer overwrite reported today.

Funny, I was looking at this code a few weeks ago as a good candidate
for some static analysis/formal verification

> ptr[avctx->width - (avctx->width & 7) + j] = buf[avctx->width >> 3] >> (7 - 
> j) & 1;

An extra pair of parenthesis around the right-hand side would be
prudent:

  (buf[avctx->width >> 3] >> (7 - j)) & 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 3/3] doc/examples: add QSV decode GPU copy sample

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Li, Zhong
> Sent: Wednesday, March 27, 2019 11:17
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] doc/examples: add QSV decode
> GPU copy sample
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Michael Niedermayer
> > Sent: Wednesday, March 27, 2019 12:05 AM
> > To: FFmpeg development discussions and patches
> > 
> > Subject: Re: [FFmpeg-devel] [PATCH 3/3] doc/examples: add QSV decode
> > GPU copy sample
> >
> > On Tue, Mar 26, 2019 at 01:39:49PM +0800, Linjie Fu wrote:
> > > Usage is:
> > >   ./qsvdec_gpucopy on/off input_stream output_stream
> > >
> > > For example:
> > >  - enable/disable gpu copy:
> > >   ./qsvdec_gpucopy on input.h264 output.yuv
> > >   ./qsvdec_gpucopy off input.h264 output.yuv
> > >
> > > Generate fps per second.
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  configure |   2 +
> > >  doc/examples/Makefile |   1 +
> > >  doc/examples/qsvdec_gpucopy.c | 276
> > > ++
> > >  3 files changed, 279 insertions(+)
> > >  create mode 100644 doc/examples/qsvdec_gpucopy.c
> >
> > breaks examples build on arm
> >
> > In file included from src/doc/examples/qsvdec_gpucopy.c:43:0:
> > src/libavcodec/qsv.h:24:26: fatal error: mfx/mfxvideo.h: No such file or
> > directory compilation terminated.
> > make: *** [doc/examples/qsvdec_gpucopy.o] Error 1
> > make: *** Waiting for unfinished jobs
> 
> It is caused by libmfx is not checked to configure this example in configure
> file.
> It is checked for doc/examples/qsvdec.c: qsvdec_example_deps="avcodec
> avutil libmfx h264_qsv_decoder"
> Similar checking is needed for this example.

Thanks, will update and check.

> However, I would like to suggestion to add gpu_copy option based on
> current qsvdec.c example (working in system memory path should be added
> too).

I'm not quite sure whether the example of qsvdec.c can enable the system memory 
path
without hwdownload.
___
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] avcodec/hevcdec: Avoid only partly skiping duplicate first slices

[Michael Niedermayer]

On Tue, Mar 26, 2019 at 10:19:44PM -0300, James Almer wrote:
> On 3/26/2019 9:17 PM, Michael Niedermayer wrote:
> > Fixes: NULL pointer dereference and out of array access
> > Fixes: 
> > 13871/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5746167087890432
> > Fixes: 
> > 13845/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5650370728034304
> > 
> > This also fixes the return code for explode mode
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/hevcdec.c | 14 ++
> >  1 file changed, 10 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index 86adab0ae1..857c10dd12 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -488,6 +488,11 @@ static int hls_slice_header(HEVCContext *s)
> >  
> >  // Coded parameters
> >  sh->first_slice_in_pic_flag = get_bits1(gb);
> > +if (s->ref && sh->first_slice_in_pic_flag) {
> > +av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the 
> > first in the same frame.\n");
> > +return 1; // This slice will be skiped later, do not corrupt state
> > +}
> > +
> >  if ((IS_IDR(s) || IS_BLA(s)) && sh->first_slice_in_pic_flag) {
> >  s->seq_decode = (s->seq_decode + 1) & 0xff;
> >  s->max_ra = INT_MAX;
> > @@ -2918,6 +2923,11 @@ static int decode_nal_unit(HEVCContext *s, const 
> > H2645NAL *nal)
> >  ret = hls_slice_header(s);
> >  if (ret < 0)
> >  return ret;
> > +if (ret == 1) {
> > +ret = AVERROR_INVALIDDATA;
> > +goto fail;
> > +}
> > +
> >  
> >  if (
> >  (s->avctx->skip_frame >= AVDISCARD_BIDIR && s->sh.slice_type 
> > == HEVC_SLICE_B) ||
> > @@ -2927,10 +2937,6 @@ static int decode_nal_unit(HEVCContext *s, const 
> > H2645NAL *nal)
> >  }
> >  
> >  if (s->sh.first_slice_in_pic_flag) {
> > -if (s->ref) {
> > -av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being 
> > the first in the same frame.\n");
> > -goto fail;
> > -}
> >  if (s->max_ra == INT_MAX) {
> >  if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
> >  s->max_ra = s->poc;
> 
> LGTM. Please also backport it. Thanks.

applied

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 resend] swscale/ppc: VSX-optimize yuv2rgb_full

[Lauri Kasanen]

On Thu, 21 Mar 2019 09:54:17 +0200
Lauri Kasanen  wrote:

> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
> -s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> This uses 32-bit mul, so POWER8 only.
>
> The following output formats get about 4.5x speedup:
>
> rgb24
>   39980 UNITS in yuv2packed1,   32768 runs,  0 skips
>8774 UNITS in yuv2packed1,   32768 runs,  0 skips
> bgr24
>   40069 UNITS in yuv2packed1,   32768 runs,  0 skips
>8772 UNITS in yuv2packed1,   32766 runs,  2 skips
> rgba
>   39759 UNITS in yuv2packed1,   32768 runs,  0 skips
>8681 UNITS in yuv2packed1,   32767 runs,  1 skips
> bgra
>   39729 UNITS in yuv2packed1,   32768 runs,  0 skips
>8696 UNITS in yuv2packed1,   32766 runs,  2 skips
> argb
>   39766 UNITS in yuv2packed1,   32768 runs,  0 skips
>8672 UNITS in yuv2packed1,   32766 runs,  2 skips
> bgra
>   39784 UNITS in yuv2packed1,   32768 runs,  0 skips
>8659 UNITS in yuv2packed1,   32767 runs,  1 skips
>
> Signed-off-by: Lauri Kasanen 
> ---
>  libswscale/ppc/swscale_vsx.c | 291 
> +++
>  1 file changed, 291 insertions(+)
>
> v2: HAVE_POWER8 from ifdef to if
> Resending due to mail client troubles

Applying.

- Lauri
___
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] swscale: Remove duplicated code

[Lauri Kasanen]

On Tue, 26 Mar 2019 22:00:54 +0100
Michael Niedermayer  wrote:

> On Tue, Mar 26, 2019 at 08:58:34AM +0200, Lauri Kasanen wrote:
> > In this function, the exact same clamping happens both in the if and 
> > unconditionally.
> >
> > Signed-off-by: Lauri Kasanen 
> > ---
> >  libswscale/output.c | 10 --
> >  1 file changed, 10 deletions(-)
> >
> > v2: Remove the unconditional instead of the if'd clipping.
> > I'll leave changing the bit pattern to others, there's so many funcs using 
> > 0x100.
> >
> > diff --git a/libswscale/output.c b/libswscale/output.c
> > index d7c53e6..d3401f0 100644
> > --- a/libswscale/output.c
> > +++ b/libswscale/output.c
>
> should be ok
>
> thanks

Applying.

- Lauri
___
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".