Re: [FFmpeg-devel] [PATCH 05/10] avformat/matroskadec: Remove non-incremental parsing of clusters

[Andreas Rheinhardt]

Michael Niedermayer:
> On Sun, Mar 10, 2019 at 11:03:00PM +, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Fri, Mar 08, 2019 at 10:25:59AM +0100, Andreas Rheinhardt wrote:
 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(-)
>>>
>>> This affects seeking:
>>>
>>> libavformat/tests/seek 
>>> issues/388/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv
>>>  -duration 400 >oldseek
>>>
>>> The file appears to be available here:
>>> https://samples.ffmpeg.org/Matroska/matrix/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv
>>>
>>> --- oldseek 2019-03-08 23:08:21.380042329 +0100
>>> +++ newseek 2019-03-08 23:08:02.048041745 +0100
>>> @@ -8,7 +8,7 @@
>>>  ret: 0 st:13 flags:1 dts: 86.75 pts: 86.75 pos: -1 
>>> size: 50436
>>>  ret:-1 st: 1 flags:0  ts: 250.577000
>>>  ret: 0 st: 1 flags:1  ts: 13.471000
>>> -ret: 0 st:13 flags:1 dts: 1.776000 pts: 1.776000 pos: -1 size: 
>>> 50436
>>> +ret: 0 st:13 flags:1 dts: 0.00 pts: 0.00 pos: -1 size: 
>>> 50436
>>>  ret:-1 st: 2 flags:0  ts: 176.365000
>>>  ret: 0 st: 2 flags:1  ts: 339.259000
>>>  ret: 0 st:13 flags:1 dts: 145.08 pts: 145.08 pos: -1 
>>> size: 50436
>>>
>> This is not unexpected. The reason is that the old parser always
>> parses a whole cluster at once while the new parser parses clusters
>> incrementally, i.e. one block (I use block as a general term for
>> SimpleBlock or BlockGroup) at a time. The goal of incremental parsing
>> was reduced latency (and with my patch #6 one also achieves a
>> reduction of memory used and an increase in performance as well).
>>
>> With the old parser, the very first cluster gets parsed during
>> avformat_find_stream_info() and index entries were created for all the
>> keyframes contained therein (the cues only contain entries for the
>> main video track, so this only affects the other tracks). The 1.776
>> pts corresponds to the block with the highest timestamp for track #1
>> (or track #2 in Matroska's counting) in the first cluster (with a
>> timestamp of 1776ms).
>>
>> With the incremental parser, only one block of the audio track gets
>> parsed during avformat_find_stream_info() (it has a timestamp of 0)
>> and so only one index entry gets created for it.
>>
>> So when the seek based upon the audio track is performed, the used
>> index point has a timestamp of either 0ms or 1776ms. Then the
>> current_dts is updated based upon this timestamp.
>>
>> Now this file has an attached picture which gets translated into its
>> own track and upon every seek this picture will be put into the
>> raw_packet_buffer from which it will be read by ff_read_packet as the
>> first packet after each seek. Given that this packet doesn't have
>> timestamps, the timestamp will be set equal to current_dts (in
>> compute_pkt_fields()). Hence the discrepancy.
>>
>> Btw: Because of things like this, a fate test had to be changed during
>> the initial introduction of incremental parsing (in
>> 8336eb6f85e4b94b9c198b16bd0ac4178f4dba86).
> 
> Sounds like undesirable behavior if not a bug
> 
> The seek request is to 13.471000 and the result should not depend on
> what has been parsed or not prior to the seek request.
> also if a packet can be produced for 1.776000 which adequatly fullfills
> the seek reuest that is better than a more distant one as that would
> increase latency experienced by the user
> 
If all one cares about is that the returned packet is near to the
desired timestamp, then matroska_read_seek succeeds in two cases:
a) The currently available index entries for the desired track are so
fine-grained that one can use this index to seek accurately. This
includes the standard case that one seeks according to a video track
for which the file provides cues (for the keyframes).
b) The desired timestamp is so big that it is beyond the last index
entry or the returned index entry is the last index entry. In this
case the file is read from the last index entry onward, so that a very
precise timestamp can be found.

If one only seeks wrt the same track and if said track either has a
good index or no index, then this works well: It's clear that it works
in case there is a good index and if there is no index at all (because
in this case the index that is being built up in the background is
good for a whole initial portion of the file and said portion won't
have "holes").

But if one changes the track wrt to one seeks, problems can arise.
Think 

Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

[Rogozhkin, Dmitry V]

pix_fmts[1] is misleading. And I think it can be quite easily
avoided.

If I understand the code correctly, qsv_decode_preinit is the place
(and the only place) where you need an array of pix_fmts. You actually
request ffmpeg to select one of the formats and program it into avctx.
Is that right?

If so, could we try to define the array exactly in this function and
avoid passing the whole array around? See comments below for
suggestions...


On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > -Original Message-
> > From: Rogozhkin, Dmitry V
> > Sent: Saturday, March 9, 2019 8:48 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Li, Zhong 
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > current
> > parser with MFXVideoDECODE_DecodeHeader()
> > 
> > On Fri, 2019-03-08 at 15:40 +0800, Zhong Li wrote:
> > > Using MSDK parser can improve qsv decoder pass rate in some cases
> > > (E.g:
> > > sps declares a wrong level_idc, smaller than it should be).
> > > And it is necessary for adding new qsv decoders such as MJPEG and
> > > VP9
> > > since current parser can't provide enough information.
> > > Actually using MFXVideoDECODE_DecodeHeader() was disscussed at
> > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175734.html
> > > and
> > > merged as commit 1acb19d, but was overwritten when merged libav
> > > patches (commit: 1f26a23) without any explain.
> > > 
> > > v2: split decode header from decode_init, and call it for
> > > everyframe
> > > to detect format/resoultion change. It can fix some regression
> > > issues
> > > such as hevc 10bits decoding.
> > > 
> > > Signed-off-by: Zhong Li 
> > > ---
> > >  libavcodec/qsvdec.c   | 172 --
> > > 
> > > 
> > >  libavcodec/qsvdec.h   |   2 +
> > >  libavcodec/qsvdec_h2645.c |   1 +
> > >  libavcodec/qsvdec_other.c |   1 +
> > >  4 files changed, 93 insertions(+), 83 deletions(-)
> > > 
> > > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> > > 4a0be811fb..b78026e14d 100644
> > > --- a/libavcodec/qsvdec.c
> > > +++ b/libavcodec/qsvdec.c
> > > @@ -120,19 +120,17 @@ static inline unsigned int
> > > qsv_fifo_size(const
> > > AVFifoBuffer* fifo)
> > >  return av_fifo_size(fifo) / qsv_fifo_item_size();
> > >  }
> > > 
> > > -static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > > +static int qsv_decode_preinit(AVCodecContext *avctx, QSVContext
> > > *q,
> > > enum AVPixelFormat *pix_fmts, mfxVideoParam *param)

Just: enum AVPixelFormat pix_fmt. Single one we need.

> > >  {
> > > -const AVPixFmtDescriptor *desc;
> > >  mfxSession session = NULL;
> > >  int iopattern = 0;
> > > -mfxVideoParam param = { 0 };
> > > -int frame_width  = avctx->coded_width;
> > > -int frame_height = avctx->coded_height;
> > >  int ret;
> > > 
> > > -desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > > -if (!desc)
> > > -return AVERROR_BUG;

enum AVPixelFormat pix_fmts[3] = { AV_PIX_FMT_QSV,
   pix_fmt,  // <<< use the one we got
in function call
   AV_PIX_FMT_NONE };

> > > +ret = ff_get_format(avctx, pix_fmts);
> > > +if (ret < 0) {
> > > +q->orig_pix_fmt = avctx->pix_fmt = AV_PIX_FMT_NONE;
> > > +return ret;
> > > +}
> > > 
> > >  if (!q->async_fifo) {
> > >  q->async_fifo = av_fifo_alloc(q->async_depth *
> > > qsv_fifo_item_size()); @@ -170,48 +168,72 @@ static int
> > > qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > >  return ret;
> > >  }
> > > 
> > > -ret = ff_qsv_codec_id_to_mfx(avctx->codec_id);
> > > -if (ret < 0)
> > > -return ret;
> > > +param->IOPattern   = q->iopattern;
> > > +param->AsyncDepth  = q->async_depth;
> > > +param->ExtParam= q->ext_buffers;
> > > +param->NumExtParam = q->nb_ext_buffers;
> > > 
> > > -param.mfx.CodecId  = ret;
> > > -param.mfx.CodecProfile = ff_qsv_profile_to_mfx(avctx-
> > > >codec_id,
> > > avctx->profile);
> > > -param.mfx.CodecLevel   = avctx->level ==
> > 
> > FF_LEVEL_UNKNOWN ?
> > > MFX_LEVEL_UNKNOWN : avctx->level;
> > > -
> > > -param.mfx.FrameInfo.BitDepthLuma   = desc->comp[0].depth;
> > > -param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
> > > -param.mfx.FrameInfo.Shift  = desc->comp[0].depth >
> > 
> > 8;
> > > -param.mfx.FrameInfo.FourCC = q->fourcc;
> > > -param.mfx.FrameInfo.Width  = frame_width;
> > > -param.mfx.FrameInfo.Height = frame_height;
> > > -param.mfx.FrameInfo.ChromaFormat   =
> > 
> > MFX_CHROMAFORMAT_YUV420;
> > > -
> > > -switch (avctx->field_order) {
> > > -case AV_FIELD_PROGRESSIVE:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_PROGRESSIVE;
> > > -break;
> > > -case AV_FIELD_TT:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_FIELD_TFF;
> > > -break;
> 

Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

[Rogozhkin, Dmitry V]

On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > -Original Message-
> > From: Rogozhkin, Dmitry V
> > Sent: Saturday, March 9, 2019 8:48 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Li, Zhong 
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > current
> > parser with MFXVideoDECODE_DecodeHeader()
> > 
> > On Fri, 2019-03-08 at 15:40 +0800, Zhong Li wrote:
> > > Using MSDK parser can improve qsv decoder pass rate in some cases
> > > (E.g:
> > > sps declares a wrong level_idc, smaller than it should be).
> > > And it is necessary for adding new qsv decoders such as MJPEG and
> > > VP9
> > > since current parser can't provide enough information.
> > > Actually using MFXVideoDECODE_DecodeHeader() was disscussed at
> > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175734.html
> > > and
> > > merged as commit 1acb19d, but was overwritten when merged libav
> > > patches (commit: 1f26a23) without any explain.
> > > 
> > > v2: split decode header from decode_init, and call it for
> > > everyframe
> > > to detect format/resoultion change. It can fix some regression
> > > issues
> > > such as hevc 10bits decoding.
> > > 
> > > Signed-off-by: Zhong Li 
> > > ---
> > >  libavcodec/qsvdec.c   | 172 --
> > > 
> > > 
> > >  libavcodec/qsvdec.h   |   2 +
> > >  libavcodec/qsvdec_h2645.c |   1 +
> > >  libavcodec/qsvdec_other.c |   1 +
> > >  4 files changed, 93 insertions(+), 83 deletions(-)
> > > 
> > > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> > > 4a0be811fb..b78026e14d 100644
> > > --- a/libavcodec/qsvdec.c
> > > +++ b/libavcodec/qsvdec.c
> > > @@ -120,19 +120,17 @@ static inline unsigned int
> > > qsv_fifo_size(const
> > > AVFifoBuffer* fifo)
> > >  return av_fifo_size(fifo) / qsv_fifo_item_size();
> > >  }
> > > 
> > > -static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > > +static int qsv_decode_preinit(AVCodecContext *avctx, QSVContext
> > > *q,
> > > enum AVPixelFormat *pix_fmts, mfxVideoParam *param)
> > >  {
> > > -const AVPixFmtDescriptor *desc;
> > >  mfxSession session = NULL;
> > >  int iopattern = 0;
> > > -mfxVideoParam param = { 0 };
> > > -int frame_width  = avctx->coded_width;
> > > -int frame_height = avctx->coded_height;
> > >  int ret;
> > > 
> > > -desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > > -if (!desc)
> > > -return AVERROR_BUG;
> > > +ret = ff_get_format(avctx, pix_fmts);
> > > +if (ret < 0) {
> > > +q->orig_pix_fmt = avctx->pix_fmt = AV_PIX_FMT_NONE;
> > > +return ret;
> > > +}
> > > 
> > >  if (!q->async_fifo) {
> > >  q->async_fifo = av_fifo_alloc(q->async_depth *
> > > qsv_fifo_item_size()); @@ -170,48 +168,72 @@ static int
> > > qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > >  return ret;
> > >  }
> > > 
> > > -ret = ff_qsv_codec_id_to_mfx(avctx->codec_id);
> > > -if (ret < 0)
> > > -return ret;
> > > +param->IOPattern   = q->iopattern;
> > > +param->AsyncDepth  = q->async_depth;
> > > +param->ExtParam= q->ext_buffers;
> > > +param->NumExtParam = q->nb_ext_buffers;
> > > 
> > > -param.mfx.CodecId  = ret;
> > > -param.mfx.CodecProfile = ff_qsv_profile_to_mfx(avctx-
> > > >codec_id,
> > > avctx->profile);
> > > -param.mfx.CodecLevel   = avctx->level ==
> > 
> > FF_LEVEL_UNKNOWN ?
> > > MFX_LEVEL_UNKNOWN : avctx->level;
> > > -
> > > -param.mfx.FrameInfo.BitDepthLuma   = desc->comp[0].depth;
> > > -param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
> > > -param.mfx.FrameInfo.Shift  = desc->comp[0].depth >
> > 
> > 8;
> > > -param.mfx.FrameInfo.FourCC = q->fourcc;
> > > -param.mfx.FrameInfo.Width  = frame_width;
> > > -param.mfx.FrameInfo.Height = frame_height;
> > > -param.mfx.FrameInfo.ChromaFormat   =
> > 
> > MFX_CHROMAFORMAT_YUV420;
> > > -
> > > -switch (avctx->field_order) {
> > > -case AV_FIELD_PROGRESSIVE:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_PROGRESSIVE;
> > > -break;
> > > -case AV_FIELD_TT:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_FIELD_TFF;
> > > -break;
> > > -case AV_FIELD_BB:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_FIELD_BFF;
> > > -break;
> > > -default:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_UNKNOWN;
> > > -break;
> > > -}
> > > +return 0;
> > > + }
> > > 
> > > -param.IOPattern   = q->iopattern;
> > > -param.AsyncDepth  = q->async_depth;
> > > -param.ExtParam= q->ext_buffers;
> > > -param.NumExtParam = q->nb_ext_buffers;
> > > +static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q,
> > > mfxVideoParam *param)
> > > +{
> > > +int ret;
> > > 
> > > -ret = MFXVideoDECODE_Init(q->session, );
> > > +

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-12 0:25 GMT+01:00, Moritz Barsnick :
> On Mon, Mar 11, 2019 at 23:23:15 +0100, Ulf Zibis wrote:
>> >> I believe, it's faster because of:
>> > Please post some numbers if your patch is supposed to
>> > speed up the filter.
>>
>> Hm, I have no clue how to do this. I thing the listed arguments speak
>> for themselves. Is there a kind of harness, template or framework for
>> this?
>
> Well, belief is not enough. ;-) In the simplest case, you show command
> lines of some examples using the filter (with various inputs,
> parameters) and their filtering/encoding performance before and after
> the patch.

> Ideally, you use the START_TIMER/STOP_TIMER macros to
> profile the actual functions you changed. (Check this mailing list's
> archives for some examples, and play with the code.)

But this should not be needed if time (the command) and / or
benchmark (the FFmpeg option) show clear improvements.

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

Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

[Rogozhkin, Dmitry V]

On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > -Original Message-
> > From: Rogozhkin, Dmitry V
> > Sent: Saturday, March 9, 2019 8:48 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Li, Zhong 
> > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > current
> > parser with MFXVideoDECODE_DecodeHeader()
> > 
> > On Fri, 2019-03-08 at 15:40 +0800, Zhong Li wrote:
> > > Using MSDK parser can improve qsv decoder pass rate in some cases
> > > (E.g:
> > > sps declares a wrong level_idc, smaller than it should be).
> > > And it is necessary for adding new qsv decoders such as MJPEG and
> > > VP9
> > > since current parser can't provide enough information.
> > > Actually using MFXVideoDECODE_DecodeHeader() was disscussed at
> > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175734.html
> > > and
> > > merged as commit 1acb19d, but was overwritten when merged libav
> > > patches (commit: 1f26a23) without any explain.
> > > 
> > > v2: split decode header from decode_init, and call it for
> > > everyframe
> > > to detect format/resoultion change. It can fix some regression
> > > issues
> > > such as hevc 10bits decoding.
> > > 
> > > Signed-off-by: Zhong Li 
> > > ---
> > >  libavcodec/qsvdec.c   | 172 --
> > > 
> > > 
> > >  libavcodec/qsvdec.h   |   2 +
> > >  libavcodec/qsvdec_h2645.c |   1 +
> > >  libavcodec/qsvdec_other.c |   1 +
> > >  4 files changed, 93 insertions(+), 83 deletions(-)
> > > 
> > > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> > > 4a0be811fb..b78026e14d 100644
> > > --- a/libavcodec/qsvdec.c
> > > +++ b/libavcodec/qsvdec.c
> > > @@ -120,19 +120,17 @@ static inline unsigned int
> > > qsv_fifo_size(const
> > > AVFifoBuffer* fifo)
> > >  return av_fifo_size(fifo) / qsv_fifo_item_size();
> > >  }
> > > 
> > > -static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > > +static int qsv_decode_preinit(AVCodecContext *avctx, QSVContext
> > > *q,
> > > enum AVPixelFormat *pix_fmts, mfxVideoParam *param)
> > >  {
> > > -const AVPixFmtDescriptor *desc;
> > >  mfxSession session = NULL;
> > >  int iopattern = 0;
> > > -mfxVideoParam param = { 0 };
> > > -int frame_width  = avctx->coded_width;
> > > -int frame_height = avctx->coded_height;
> > >  int ret;
> > > 
> > > -desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > > -if (!desc)
> > > -return AVERROR_BUG;
> > > +ret = ff_get_format(avctx, pix_fmts);
> > > +if (ret < 0) {
> > > +q->orig_pix_fmt = avctx->pix_fmt = AV_PIX_FMT_NONE;
> > > +return ret;
> > > +}
> > > 
> > >  if (!q->async_fifo) {
> > >  q->async_fifo = av_fifo_alloc(q->async_depth *
> > > qsv_fifo_item_size()); @@ -170,48 +168,72 @@ static int
> > > qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > >  return ret;
> > >  }
> > > 
> > > -ret = ff_qsv_codec_id_to_mfx(avctx->codec_id);
> > > -if (ret < 0)
> > > -return ret;
> > > +param->IOPattern   = q->iopattern;
> > > +param->AsyncDepth  = q->async_depth;
> > > +param->ExtParam= q->ext_buffers;
> > > +param->NumExtParam = q->nb_ext_buffers;
> > > 
> > > -param.mfx.CodecId  = ret;
> > > -param.mfx.CodecProfile = ff_qsv_profile_to_mfx(avctx-
> > > >codec_id,
> > > avctx->profile);
> > > -param.mfx.CodecLevel   = avctx->level ==
> > 
> > FF_LEVEL_UNKNOWN ?
> > > MFX_LEVEL_UNKNOWN : avctx->level;
> > > -
> > > -param.mfx.FrameInfo.BitDepthLuma   = desc->comp[0].depth;
> > > -param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
> > > -param.mfx.FrameInfo.Shift  = desc->comp[0].depth >
> > 
> > 8;
> > > -param.mfx.FrameInfo.FourCC = q->fourcc;
> > > -param.mfx.FrameInfo.Width  = frame_width;
> > > -param.mfx.FrameInfo.Height = frame_height;
> > > -param.mfx.FrameInfo.ChromaFormat   =
> > 
> > MFX_CHROMAFORMAT_YUV420;
> > > -
> > > -switch (avctx->field_order) {
> > > -case AV_FIELD_PROGRESSIVE:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_PROGRESSIVE;
> > > -break;
> > > -case AV_FIELD_TT:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_FIELD_TFF;
> > > -break;
> > > -case AV_FIELD_BB:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_FIELD_BFF;
> > > -break;
> > > -default:
> > > -param.mfx.FrameInfo.PicStruct =
> > 
> > MFX_PICSTRUCT_UNKNOWN;
> > > -break;
> > > -}
> > > +return 0;
> > > + }
> > > 
> > > -param.IOPattern   = q->iopattern;
> > > -param.AsyncDepth  = q->async_depth;
> > > -param.ExtParam= q->ext_buffers;
> > > -param.NumExtParam = q->nb_ext_buffers;
> > > +static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q,
> > > mfxVideoParam *param)
> > > +{
> > > +int ret;
> > > 
> > > -ret = MFXVideoDECODE_Init(q->session, );
> > > +

[FFmpeg-devel] [PATCH]lavf/matroska: Also support WebVTT in Matroska

[Carl Eugen Hoyos]

Hi!

Attached patch is supposed to fix HandBrake issue 1964, FFmpeg
currently fails to identify WebVTT in Matroska (only webm is supported
as container). I don't have the original sample to test though.

Please comment, Carl Eugen
From d4cdbc94e4adf8ee4b1f576b60c0e743f9f8928f Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 12 Mar 2019 00:32:59 +0100
Subject: [PATCH] lavf/matroska: Also support WebVTT in Matroska.

Fixes HandBrake issue #1964.
---
 libavformat/matroska.c|1 +
 libavformat/matroskadec.c |3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index 4d18d14..adcd67c 100644
--- a/libavformat/matroska.c
+++ b/libavformat/matroska.c
@@ -68,6 +68,7 @@ const CodecTags ff_mkv_codec_tags[]={
 {"S_TEXT/UTF8"  , AV_CODEC_ID_SUBRIP},
 {"S_TEXT/UTF8"  , AV_CODEC_ID_TEXT},
 {"S_TEXT/ASCII" , AV_CODEC_ID_TEXT},
+{"S_TEXT/WEBVTT", AV_CODEC_ID_WEBVTT},
 {"S_TEXT/ASS"   , AV_CODEC_ID_ASS},
 {"S_TEXT/SSA"   , AV_CODEC_ID_ASS},
 {"S_ASS", AV_CODEC_ID_ASS},
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 0e3a689..0d7b0bd 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3428,7 +3428,8 @@ static int matroska_parse_block(MatroskaDemuxContext *matroska, AVBufferRef *buf
 if (res)
 goto end;
 
-} else if (st->codecpar->codec_id == AV_CODEC_ID_WEBVTT) {
+} else if (   st->codecpar->codec_id == AV_CODEC_ID_WEBVTT
+   && strcmp(track->codec_id, "S_TEXT/WEBVTT")) {
 res = matroska_parse_webvtt(matroska, track, st,
 data, lace_size[n],
 timecode, lace_duration,
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Moritz Barsnick]

On Mon, Mar 11, 2019 at 23:23:15 +0100, Ulf Zibis wrote:
> >> I believe, it's faster because of:
> > Please post some numbers if your patch is supposed to
> > speed up the filter.
> 
> Hm, I have no clue how to do this. I thing the listed arguments speak
> for themselves. Is there a kind of harness, template or framework for this?

Well, belief is not enough. ;-) In the simplest case, you show command
lines of some examples using the filter (with various inputs,
parameters) and their filtering/encoding performance before and after
the patch. Ideally, you use the START_TIMER/STOP_TIMER macros to
profile the actual functions you changed. (Check this mailing list's
archives for some examples, and play with the code.)

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

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg4_unpack_bframes_bsf: Improve DivX userdata check

[Andreas Rheinhardt]

Michael Niedermayer:
> On Mon, Mar 11, 2019 at 12:36:08PM +0100, Andreas Rheinhardt wrote:
>> The earlier version didn't really check that the 'p' of a "p\0" is
>> actually part of a user_data section, instead it treated the first
>> "p\0" after the start of a user_data section as end of a user_data
>> section if it is close enough to the beginning of the user_data section;
>> it actually needn't be part of a user_data section at all.
>>
>> Furthermore, the code worked under the assumption that there is a 0x00
>> after the 'p' although this might not be true for extradata if the
>> user_data unit is at the end of the extradata.
>>
>> Both of these flaws have been fixed.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> The earlier version was inspired by the check for packed bitstreams in
>> decode_user_data() in mpeg4videodec.c where the "DivX" is mandatory,
>> too.
> 
>> Note that this new version relies on there being no binary zero inside
>> the user data.
> 
> Is this based on anything from the spec ?

No. According to the spec, a user_data ends upon the next occurence of
a byte-aligned 0x01 (and it may not contain a non-byte-aligned
0x01), so it is allowed to have a binary zero in there. But I
thought that a user_data for indicating a packed bitstream is a
string, so shouldn't contain a binary zero. I can modify this if
desired. (If so, does a "p\0" where the 'p' is part of the user_data
be taken to indicate a packed bitstream or does the 'p' have to be the
last nonzero character of the user_data?)

(And shouldn't the same logic also be applied to the decoder (that
currently requires the "DivX" to conclude that a stream is a packed
bitstream)?)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Lou Logan]

On Mon, 11 Mar 2019 23:07:37 +0100
Ulf Zibis  wrote:

> From 74dda304bf7a0a31873518187438815d08533934 Mon Sep 17 00:00:00 2001
> From: Ulf Zibis 
> Date: 11.03.2019, 23:04:15
> 
> Beautified + accelerated

Commit message title prefix for filter patches are usually in the form
of:

avfilter/fillborders:
or
lavfi/fillborders: 

The commit message body ideally should have a concise but informative
summary that describes the patch.

See 'git log' for examples.

> diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c
> index 1344587..a7a074b 100644
> --- a/libavfilter/vf_fillborders.c
> +++ b/libavfilter/vf_fillborders.c
> @@ -1,5 +1,7 @@
>  /*
>   * Copyright (c) 2017 Paul B Mahol
> + * 

Trailing whitespace. This should always be avoided.

> + * Contributors: Ulf Zibis

We don't add a "Contributors" line. The git log covers that.

[...]
>  static void fixed_borders16(FillBordersContext *s, AVFrame *frame)
>  {
> -int p, y, x;
> +for (int p = 0; p < s->nb_planes; p++) {
> +uint16_t *data = (uint16_t *)frame->data[p];
> +int lz = frame->linesize[p] / sizeof(uint16_t);
> +int width = s->planewidth[p];
> +int height = s->planeheight[p] * lz;
> +int left = s->borders[p].left;
> +int right = width - s->borders[p].right;
> +int top = s->borders[p].top * lz;
> +int bottom = height - s->borders[p].bottom * lz;
> +int fill_sz = MAX(MAX(left, right), top!=0 || height-bottom!=0 ? 
> width : 0);
> +uint16_t *fill = malloc(fill_sz * sizeof(uint16_t));

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

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg4_unpack_bframes_bsf: Improve DivX userdata check

[Michael Niedermayer]

On Mon, Mar 11, 2019 at 12:36:08PM +0100, Andreas Rheinhardt wrote:
> The earlier version didn't really check that the 'p' of a "p\0" is
> actually part of a user_data section, instead it treated the first
> "p\0" after the start of a user_data section as end of a user_data
> section if it is close enough to the beginning of the user_data section;
> it actually needn't be part of a user_data section at all.
> 
> Furthermore, the code worked under the assumption that there is a 0x00
> after the 'p' although this might not be true for extradata if the
> user_data unit is at the end of the extradata.
> 
> Both of these flaws have been fixed.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> The earlier version was inspired by the check for packed bitstreams in
> decode_user_data() in mpeg4videodec.c where the "DivX" is mandatory,
> too.

> Note that this new version relies on there being no binary zero inside
> the user data.

Is this based on anything from the spec ?


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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg4videodec: Fix nonsense warning

[Michael Niedermayer]

On Mon, Mar 11, 2019 at 11:32:05AM +0100, Andreas Rheinhardt wrote:
> Since db772308941a2a338c7809f90d347219a6a93074 parsing of
> mpeg4-extradata lead to a "Failed to parse extradata" warning, because
> ff_mpeg4_decode_picture_header returns AVERROR_INVALIDDATA in case that
> no VOP was found. This patch adds a parameter to signify whether a
> header (where the absence of a VOP does not raise an error) or not is
> parsed. The first mode is of course used for parsing headers.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/h263dec.c   |  4 ++--
>  libavcodec/mpeg4video.h|  2 +-
>  libavcodec/mpeg4video_parser.c |  6 +++---
>  libavcodec/mpeg4videodec.c | 10 +++---
>  4 files changed, 13 insertions(+), 9 deletions(-)

will apply

thx

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 11.03.19 um 23:08 schrieb Carl Eugen Hoyos:
> You are not supposed to mix cosmetic changes
> like removing braces or moving variable declarations
> with actual code changes.

Hm difficult, because the code changes are dependent from different
variables.

But I'll give it a try to make some separated patches.

>> I believe, it's faster because of:
> Please post some numbers if your patch is supposed to
> speed up the filter.

Hm, I have no clue how to do this. I thing the listed arguments speak
for themselves. Is there a kind of harness, template or framework for this?

Thanks for your first review.

-Ulf

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-11 22:59 GMT+01:00, Ulf Zibis :

> I have made some refactoring to vf_fillborders.c.

You are not supposed to mix cosmetic changes
like removing braces or moving variable declarations
with actual code changes.

> My motivation came from using this filter as a template
> for a new filter. Refactoring the code was a good exercise
> to understand FFmpeg's data models.
>
> I think, the code is now much better readable and

> I believe, it's faster because of:

Please post some numbers if your patch is supposed to
speed up the filter.

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Here is attached the "commit" patch, if you like this more.

-Ulf

Am 11.03.19 um 22:59 schrieb Ulf Zibis:
> Hi,
>
> I have made some refactoring to vf_fillborders.c.
>
> My motivation came from using this filter as a template for a new
> filter. Refactoring the code was a good exercise to understand FFmpeg's
> data models.
>
> I think, the code is now much better readable and I believe, it's faster
> because of:
> - more use of memset() and memcpy()
> - less calculations in the inner for loops
> - skip the looping for right/left filling when there is nothing to do
>
> I would be appreciated, if one would review my proposed changes.
>
> Hopefully I've used the right format for the patch. Please honour, that
> I'm new in FFmpeg development.
>
> -Ulf
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 74dda304bf7a0a31873518187438815d08533934 Mon Sep 17 00:00:00 2001
From: Ulf Zibis 
Date: 11.03.2019, 23:04:15

Beautified + accelerated

diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c
index 1344587..a7a074b 100644
--- a/libavfilter/vf_fillborders.c
+++ b/libavfilter/vf_fillborders.c
@@ -1,5 +1,7 @@
 /*
  * Copyright (c) 2017 Paul B Mahol
+ * 
+ * Contributors: Ulf Zibis
  *
  * This file is part of FFmpeg.
  *
@@ -18,6 +20,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include 
 #include "libavutil/colorspace.h"
 #include "libavutil/common.h"
 #include "libavutil/opt.h"
@@ -84,187 +87,176 @@
 
 static void smear_borders8(FillBordersContext *s, AVFrame *frame)
 {
-int p, y;
+for (int p = 0; p < s->nb_planes; p++) {
+uint8_t *data = frame->data[p];
+int lz = frame->linesize[p];
+int width = s->planewidth[p];
+int height = s->planeheight[p] * lz;
+int left = s->borders[p].left;
+int right = width - s->borders[p].right;
+int top = s->borders[p].top * lz;
+int bottom = height - s->borders[p].bottom * lz;
 
-for (p = 0; p < s->nb_planes; p++) {
-uint8_t *ptr = frame->data[p];
-int linesize = frame->linesize[p];
+/* fill left and right borders from top to bottom border */
+if (left != 0 || right != width) // in case skip for performance
+for (int y = top; y < bottom; y += lz) {
+memset(data + y, *(data + y + left), left);
+memset(data + y + right, *(data + y + right - 1), width - right);
+}
 
-for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-memset(ptr + y * linesize,
-   *(ptr + y * linesize + s->borders[p].left),
-   s->borders[p].left);
-memset(ptr + y * linesize + s->planewidth[p] - s->borders[p].right,
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
-   s->borders[p].right);
-}
-
-for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p]);
-}
-
-for (y = s->planeheight[p] - s->borders[p].bottom; y < s->planeheight[p]; y++) {
-memcpy(ptr + y * linesize,
-   ptr + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
-   s->planewidth[p]);
-}
+/* fill top and bottom borders */
+for (uint8_t *y = data + top; y > data; )
+memcpy(y -= lz, data + top, width);
+for (uint8_t *y = data + bottom; y < data + height; y += lz)
+memcpy(y, data + bottom - lz, width);
 }
 }
 
 static void smear_borders16(FillBordersContext *s, AVFrame *frame)
 {
-int p, y, x;
+for (int p = 0; p < s->nb_planes; p++) {
+uint16_t *data = (uint16_t *)frame->data[p];
+int lz = frame->linesize[p] / sizeof(uint16_t);
+int width = s->planewidth[p];
+int height = s->planeheight[p] * lz;
+int left = s->borders[p].left;
+int right = width - s->borders[p].right;
+int top = s->borders[p].top * lz;
+int bottom = height - s->borders[p].bottom * lz;
 
-for (p = 0; p < s->nb_planes; p++) {
-uint16_t *ptr = (uint16_t *)frame->data[p];
-int linesize = frame->linesize[p] / 2;
-
-for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-for (x = 0; x < s->borders[p].left; x++) {
-ptr[y * linesize + x] =  *(ptr + y * linesize + s->borders[p].left);
+/* fill left and right borders from top to bottom border */
+if (left != 0 || right != width) // in case skip for performance
+for (int y = top; y < bottom; y += lz) {
+for (int x = left; x >= 0; x--)
+data[y + x] =  data[y + left];
+for (int x = right; x < width; 

[FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Hi,

I have made some refactoring to vf_fillborders.c.

My motivation came from using this filter as a template for a new
filter. Refactoring the code was a good exercise to understand FFmpeg's
data models.

I think, the code is now much better readable and I believe, it's faster
because of:
- more use of memset() and memcpy()
- less calculations in the inner for loops
- skip the looping for right/left filling when there is nothing to do

I would be appreciated, if one would review my proposed changes.

Hopefully I've used the right format for the patch. Please honour, that
I'm new in FFmpeg development.

-Ulf

diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c
index 1344587..a7a074b 100644
--- a/libavfilter/vf_fillborders.c
+++ b/libavfilter/vf_fillborders.c
@@ -1,5 +1,7 @@
 /*
  * Copyright (c) 2017 Paul B Mahol
+ * 
+ * Contributors: Ulf Zibis
  *
  * This file is part of FFmpeg.
  *
@@ -18,6 +20,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include 
 #include "libavutil/colorspace.h"
 #include "libavutil/common.h"
 #include "libavutil/opt.h"
@@ -84,187 +87,176 @@
 
 static void smear_borders8(FillBordersContext *s, AVFrame *frame)
 {
-int p, y;
+for (int p = 0; p < s->nb_planes; p++) {
+uint8_t *data = frame->data[p];
+int lz = frame->linesize[p];
+int width = s->planewidth[p];
+int height = s->planeheight[p] * lz;
+int left = s->borders[p].left;
+int right = width - s->borders[p].right;
+int top = s->borders[p].top * lz;
+int bottom = height - s->borders[p].bottom * lz;
 
-for (p = 0; p < s->nb_planes; p++) {
-uint8_t *ptr = frame->data[p];
-int linesize = frame->linesize[p];
+/* fill left and right borders from top to bottom border */
+if (left != 0 || right != width) // in case skip for performance
+for (int y = top; y < bottom; y += lz) {
+memset(data + y, *(data + y + left), left);
+memset(data + y + right, *(data + y + right - 1), width - right);
+}
 
-for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-memset(ptr + y * linesize,
-   *(ptr + y * linesize + s->borders[p].left),
-   s->borders[p].left);
-memset(ptr + y * linesize + s->planewidth[p] - s->borders[p].right,
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
-   s->borders[p].right);
-}
-
-for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p]);
-}
-
-for (y = s->planeheight[p] - s->borders[p].bottom; y < s->planeheight[p]; y++) {
-memcpy(ptr + y * linesize,
-   ptr + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
-   s->planewidth[p]);
-}
+/* fill top and bottom borders */
+for (uint8_t *y = data + top; y > data; )
+memcpy(y -= lz, data + top, width);
+for (uint8_t *y = data + bottom; y < data + height; y += lz)
+memcpy(y, data + bottom - lz, width);
 }
 }
 
 static void smear_borders16(FillBordersContext *s, AVFrame *frame)
 {
-int p, y, x;
+for (int p = 0; p < s->nb_planes; p++) {
+uint16_t *data = (uint16_t *)frame->data[p];
+int lz = frame->linesize[p] / sizeof(uint16_t);
+int width = s->planewidth[p];
+int height = s->planeheight[p] * lz;
+int left = s->borders[p].left;
+int right = width - s->borders[p].right;
+int top = s->borders[p].top * lz;
+int bottom = height - s->borders[p].bottom * lz;
 
-for (p = 0; p < s->nb_planes; p++) {
-uint16_t *ptr = (uint16_t *)frame->data[p];
-int linesize = frame->linesize[p] / 2;
-
-for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-for (x = 0; x < s->borders[p].left; x++) {
-ptr[y * linesize + x] =  *(ptr + y * linesize + s->borders[p].left);
+/* fill left and right borders from top to bottom border */
+if (left != 0 || right != width) // in case skip for performance
+for (int y = top; y < bottom; y += lz) {
+for (int x = left; x >= 0; x--)
+data[y + x] =  data[y + left];
+for (int x = right; x < width; x++)
+data[y + x] = data[y + right - 1];
 }
 
-for (x = 0; x < s->borders[p].right; x++) {
-ptr[y * linesize + s->planewidth[p] - s->borders[p].right + x] =
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1);
-}
-}
-
-for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   

Re: [FFmpeg-devel] [PATCH v2 2/2] fate/mxf: add mxf user comments tests

[Tomas Härdin]

mån 2019-03-11 klockan 13:22 -0700 skrev mindm...@gmail.com:
> From: Mark Reid 
> 
> ---
>  tests/fate/mxf.mak  | 15 ++-
>  tests/ref/fate/mxf-d10-user-comments|  1 +
>  tests/ref/fate/mxf-opatom-user-comments |  1 +
>  tests/ref/fate/mxf-user-comments|  1 +
>  4 files changed, 17 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/fate/mxf-d10-user-comments
>  create mode 100644 tests/ref/fate/mxf-opatom-user-comments
>  create mode 100644 tests/ref/fate/mxf-user-comments
> 
> diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak
> index dce23d522e..62e4ec01cb 100644
> --- a/tests/fate/mxf.mak
> +++ b/tests/fate/mxf.mak
> @@ -37,9 +37,22 @@ FATE_MXF_REEL_NAME-$(call ENCDEC2, MPEG2VIDEO,
> PCM_S16LE, MXF) += fate-mxf-reel_
>  fate-mxf-reel_name: $(TARGET_SAMPLES)/mxf/Sony-1.mxf
>  fate-mxf-reel_name: CMD = md5 -y -i $(TARGET_SAMPLES)/mxf/Sony-
> 1.mxf  -c copy -timecode 00:00:00:00 -metadata
> "reel_name=test_reel" -fflags +bitexact -f mxf
>  
> +FATE_MXF_USER_COMMENTS-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF)
> += fate-mxf-user-comments
> +fate-mxf-user-comments: $(TARGET_SAMPLES)/mxf/Sony-1.mxf
> +fate-mxf-user-comments: CMD = md5 -y -i $(TARGET_SAMPLES)/mxf/Sony-
> 1.mxf -c copy -metadata "comment_test=value" -fflags +bitexact -f
> mxf

For a while I thought we could maybe make these tests faster by not
muxing any essence, but the opatom case wouldn't work, and maybe not
the others either. In short: looks OK to me.

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/mxfenc: allow user comments for opatom muxer

[Tomas Härdin]

mån 2019-03-11 klockan 13:22 -0700 skrev mindm...@gmail.com:
> From: Mark Reid 
> 
> ---
>  doc/muxers.texi  | 4 ++--
>  libavformat/mxfenc.c | 2 ++
>  2 files changed, 4 insertions(+), 2 deletions(-)

Looks OK

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: allow user comments for opatom muxer

[Mark Reid]

On Mon, Mar 11, 2019 at 2:55 AM Tomas Härdin  wrote:

> sön 2019-03-10 klockan 19:03 -0700 skrev mindm...@gmail.com:
> > > From: Mark Reid 
> >
> > This patch restores the ability to add user comments for the opatom_mxf
> muxer.
> > The ability seems to have been disabled in d9726893f31.
>
> Seems the intent was to only disable them for D-10, so this is probably
> fine. You should change this too:
>
>   IRT D-10 does not allow user comments. The default is thus to write
>   them for mxf but not for mxf_d10
>
> to
>
>   IRT D-10 does not allow user comments. The default is thus to write
>   them for mxf and mxf_opatom but not for mxf_d10
>
> oops missed the line.


> The comment from Michael in d9726893f31 about comments causing problems
> for "users" has me worried. We *need* functional tests for stuff like
> that..
>
>
I'll try and add a fate test with the next version of the patch. Thanks for
the review.


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

[FFmpeg-devel] [PATCH v2 2/2] fate/mxf: add mxf user comments tests

[mindmark]

From: Mark Reid 

---
 tests/fate/mxf.mak  | 15 ++-
 tests/ref/fate/mxf-d10-user-comments|  1 +
 tests/ref/fate/mxf-opatom-user-comments |  1 +
 tests/ref/fate/mxf-user-comments|  1 +
 4 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/mxf-d10-user-comments
 create mode 100644 tests/ref/fate/mxf-opatom-user-comments
 create mode 100644 tests/ref/fate/mxf-user-comments

diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak
index dce23d522e..62e4ec01cb 100644
--- a/tests/fate/mxf.mak
+++ b/tests/fate/mxf.mak
@@ -37,9 +37,22 @@ FATE_MXF_REEL_NAME-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, 
MXF) += fate-mxf-reel_
 fate-mxf-reel_name: $(TARGET_SAMPLES)/mxf/Sony-1.mxf
 fate-mxf-reel_name: CMD = md5 -y -i $(TARGET_SAMPLES)/mxf/Sony-1.mxf  -c 
copy -timecode 00:00:00:00 -metadata "reel_name=test_reel" -fflags +bitexact -f 
mxf
 
+FATE_MXF_USER_COMMENTS-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += 
fate-mxf-user-comments
+fate-mxf-user-comments: $(TARGET_SAMPLES)/mxf/Sony-1.mxf
+fate-mxf-user-comments: CMD = md5 -y -i $(TARGET_SAMPLES)/mxf/Sony-1.mxf 
-c copy -metadata "comment_test=value" -fflags +bitexact -f mxf
+
+FATE_MXF_D10_USER_COMMENTS-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += 
fate-mxf-d10-user-comments
+fate-mxf-d10-user-comments: $(TARGET_SAMPLES)/mxf/Sony-1.mxf
+fate-mxf-d10-user-comments: CMD = md5 -y -i 
$(TARGET_SAMPLES)/mxf/Sony-1.mxf -c copy -metadata "comment_test=value" 
-store_user_comments 1 -fflags +bitexact -f mxf_d10
+
+FATE_MXF_OPATOM_USER_COMMENTS-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += 
fate-mxf-opatom-user-comments
+fate-mxf-opatom-user-comments: $(TARGET_SAMPLES)/mxf/Sony-1.mxf
+fate-mxf-opatom-user-comments: CMD = md5 -y -i 
$(TARGET_SAMPLES)/mxf/Sony-1.mxf -an -vcodec copy -metadata 
"comment_test=value" -fflags +bitexact -f mxf_opatom
+
 FATE_MXF-$(CONFIG_MXF_DEMUXER) += $(FATE_MXF)
 
 FATE_SAMPLES_AVCONV += $(FATE_MXF-yes) $(FATE_MXF_REEL_NAME-yes)
+FATE_SAMPLES_AVCONV += $(FATE_MXF_USER_COMMENTS-yes) 
$(FATE_MXF_D10_USER_COMMENTS-yes) $(FATE_MXF_OPATOM_USER_COMMENTS-yes)
 FATE_SAMPLES_FFPROBE += $(FATE_MXF_PROBE-yes)
 
-fate-mxf: $(FATE_MXF-yes) $(FATE_MXF_PROBE-yes) $(FATE_MXF_REEL_NAME-yes)
+fate-mxf: $(FATE_MXF-yes) $(FATE_MXF_PROBE-yes) $(FATE_MXF_REEL_NAME-yes) 
$(FATE_MXF_USER_COMMENTS-yes) $(FATE_MXF_D10_USER_COMMENTS-yes) 
$(FATE_MXF_OPATOM_USER_COMMENTS-yes)
diff --git a/tests/ref/fate/mxf-d10-user-comments 
b/tests/ref/fate/mxf-d10-user-comments
new file mode 100644
index 00..e78765020c
--- /dev/null
+++ b/tests/ref/fate/mxf-d10-user-comments
@@ -0,0 +1 @@
+b659c1204f8d04e2a5607af083590dca
diff --git a/tests/ref/fate/mxf-opatom-user-comments 
b/tests/ref/fate/mxf-opatom-user-comments
new file mode 100644
index 00..1834b9e074
--- /dev/null
+++ b/tests/ref/fate/mxf-opatom-user-comments
@@ -0,0 +1 @@
+892cf02e44bf7d61b6d6f01e41db9375
diff --git a/tests/ref/fate/mxf-user-comments b/tests/ref/fate/mxf-user-comments
new file mode 100644
index 00..4b734a0f85
--- /dev/null
+++ b/tests/ref/fate/mxf-user-comments
@@ -0,0 +1 @@
+683bacb0105e5bc5bbf46aa430c644d1
-- 
2.21.0

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

[FFmpeg-devel] [PATCH v2 1/2] avformat/mxfenc: allow user comments for opatom muxer

[mindmark]

From: Mark Reid 

---
 doc/muxers.texi  | 4 ++--
 libavformat/mxfenc.c | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 372fab2f92..aac7d94edf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1629,7 +1629,7 @@ ffmpeg -i file.mpg -c copy \
  out.ts
 @end example
 
-@section mxf, mxf_d10
+@section mxf, mxf_d10, mxf_opatom
 
 MXF muxer.
 
@@ -1641,7 +1641,7 @@ The muxer options are:
 @item store_user_comments @var{bool}
 Set if user comments should be stored if available or never.
 IRT D-10 does not allow user comments. The default is thus to write them for
-mxf but not for mxf_d10
+mxf and mxf_opatom but not for mxf_d10
 @end table
 
 @section null
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 032ee3bf3d..8c6db94865 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -3095,6 +3095,8 @@ static const AVOption opatom_options[] = {
 { "mxf_audio_edit_rate", "Audio edit rate for timecode",
 offsetof(MXFContext, audio_edit_rate), AV_OPT_TYPE_RATIONAL, 
{.dbl=25}, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
 MXF_COMMON_OPTIONS
+{ "store_user_comments", "",
+  offsetof(MXFContext, store_user_comments), AV_OPT_TYPE_BOOL, {.i64 = 1}, 
0, 1, AV_OPT_FLAG_ENCODING_PARAM},
 { NULL },
 };
 
-- 
2.21.0

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpeg4videodec: Check idx in mpeg4_decode_studio_block()

[Michael Niedermayer]

On Mon, Mar 11, 2019 at 10:39:20AM +0400, Kieran Kunhya wrote:
> On Sun, 10 Mar 2019 at 04:43 Michael Niedermayer 
> wrote:
> 
> > Fixes: Out of array access
> > Fixes:
> > 13500/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5769760178962432
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by
> > :
> > Michael Niedermayer 
> >
> 
> Ok.

will apply 

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] patch for a new H.264 codec

[Michael Niedermayer]

On Mon, Mar 11, 2019 at 01:28:18PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Mar 11, 2019 at 12:21 PM Soft Works  wrote:
> 
> > > From: Nicolas George
> > >
> > > Yufei He (12019-03-11):
> > > > Matrox M264 is similar to other hardware codecs.
> > > >
> > > > I saw amf_load_library and nvenc_load_library in ffmpeg.
> > >
> > > Past practices do not constitute precedents.
> > >
> > > > We got a lot customers using ffmpeg and they want to use Matrox M264
> > to do transcoding.
> > >
> > > If you make the driver GPL-compatible, there will be no problem at all.
> > >
> > > Regards,
> > >
> > > --
> > >   Nicolas George
> >
> > While I don’t care much about Matrox, I’m a bit surprised about the
> > recent sounds here. Should  we expect ffmpeg to drop most hw
> > accelerations, then?
> >
> > IANAL, but aren’t drivers clearly considered to be system components?
> > In this case they would  be exempted from the GPL afaic?
> >
> 
> Getting very legal here for someone who's not a lawyer :), but my reading
> of the GPL is not that it says "something that acts at system level" (e.g.
> hardware), but something that is provided by the base system (i.e. you can
> assume it to be installed in some way shape or form regardless of the exact
> license that it is accompanied by). For example, you can assume your system
> has a libc, even though it might not be a GPL libc.
> 

> However, my objection is not legal, it is philosophical. 

> I would prefer
> that we (FFmpeg) as a project do not encourage the use of closed-source
> software or endorse particular closed-source software 

I agree


> (by including support
> for it in FFmpeg). We are an open source project, and thus (again: in my
> personal opinion) we should only endorse other open source software. That
> does not mean closed source software is bad or should not be used. It
> merely means we do not endorse it by including support for it.

I disagree that giving users the choice is encouraging a specific choice. Or
That including an option is endorsing it.
I also disagree that closed source software is not bad. It is in my
personal oppinion bad. In fact IMHO its bad for everyone both for the
authors as well as the users.
I agree though that using it if thats what one needs to get something done
is perfectly fine.

And the last useless comment from me today :)
It seems many in these recent threads assume that supporting some interfaces
to non free software harms open source. This sounds logic but iam not so sure
here this is actually true and maybe this is why iam disagreeing a bit.

and btw i do not understand why hw companies are not just making their
software free This might actually increase their hw sales and decrease
their sw maintaince expenses ...

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

Re: [FFmpeg-devel] [PATCH 05/10] avformat/matroskadec: Remove non-incremental parsing of clusters

[Michael Niedermayer]

On Sun, Mar 10, 2019 at 11:03:00PM +, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Fri, Mar 08, 2019 at 10:25:59AM +0100, Andreas Rheinhardt wrote:
> >> 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(-)
> > 
> > This affects seeking:
> > 
> > libavformat/tests/seek 
> > issues/388/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv
> >  -duration 400 >oldseek
> > 
> > The file appears to be available here:
> > https://samples.ffmpeg.org/Matroska/matrix/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv
> > 
> > --- oldseek 2019-03-08 23:08:21.380042329 +0100
> > +++ newseek 2019-03-08 23:08:02.048041745 +0100
> > @@ -8,7 +8,7 @@
> >  ret: 0 st:13 flags:1 dts: 86.75 pts: 86.75 pos: -1 
> > size: 50436
> >  ret:-1 st: 1 flags:0  ts: 250.577000
> >  ret: 0 st: 1 flags:1  ts: 13.471000
> > -ret: 0 st:13 flags:1 dts: 1.776000 pts: 1.776000 pos: -1 size: 
> > 50436
> > +ret: 0 st:13 flags:1 dts: 0.00 pts: 0.00 pos: -1 size: 
> > 50436
> >  ret:-1 st: 2 flags:0  ts: 176.365000
> >  ret: 0 st: 2 flags:1  ts: 339.259000
> >  ret: 0 st:13 flags:1 dts: 145.08 pts: 145.08 pos: -1 
> > size: 50436
> > 
> This is not unexpected. The reason is that the old parser always
> parses a whole cluster at once while the new parser parses clusters
> incrementally, i.e. one block (I use block as a general term for
> SimpleBlock or BlockGroup) at a time. The goal of incremental parsing
> was reduced latency (and with my patch #6 one also achieves a
> reduction of memory used and an increase in performance as well).
> 
> With the old parser, the very first cluster gets parsed during
> avformat_find_stream_info() and index entries were created for all the
> keyframes contained therein (the cues only contain entries for the
> main video track, so this only affects the other tracks). The 1.776
> pts corresponds to the block with the highest timestamp for track #1
> (or track #2 in Matroska's counting) in the first cluster (with a
> timestamp of 1776ms).
> 
> With the incremental parser, only one block of the audio track gets
> parsed during avformat_find_stream_info() (it has a timestamp of 0)
> and so only one index entry gets created for it.
> 
> So when the seek based upon the audio track is performed, the used
> index point has a timestamp of either 0ms or 1776ms. Then the
> current_dts is updated based upon this timestamp.
> 
> Now this file has an attached picture which gets translated into its
> own track and upon every seek this picture will be put into the
> raw_packet_buffer from which it will be read by ff_read_packet as the
> first packet after each seek. Given that this packet doesn't have
> timestamps, the timestamp will be set equal to current_dts (in
> compute_pkt_fields()). Hence the discrepancy.
> 
> Btw: Because of things like this, a fate test had to be changed during
> the initial introduction of incremental parsing (in
> 8336eb6f85e4b94b9c198b16bd0ac4178f4dba86).

Sounds like undesirable behavior if not a bug

The seek request is to 13.471000 and the result should not depend on
what has been parsed or not prior to the seek request.
also if a packet can be produced for 1.776000 which adequatly fullfills
the seek reuest that is better than a more distant one as that would
increase latency experienced by the user

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

Re: [FFmpeg-devel] [PATCH v2] avformat/smoothstreamingenc:add bitrate calculate

[Carl Eugen Hoyos]

2019-03-11 18:58 GMT+01:00, Jun Li :

> Smooth is not the only one need bitrate for manifest, Dash also need this
> value for "Bandwidth" field:
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L730
> Although there is some difference, both the calculation are based on
> fragment size, which is the result after muxing.

Thank you for the explanation!

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

Re: [FFmpeg-devel] [PATCH v2] avformat/smoothstreamingenc:add bitrate calculate

[Jun Li]

Thanks Carl for review.
Smooth is not the only one need bitrate for manifest, Dash also need this
value for "Bandwidth" field:
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L730
Although there is some difference, both the calculation are based on
fragment size, which is the result after muxing. So it might be very hard
to do it outside of Muxer.

Thanks. Regards
-Jun

On Mon, Mar 11, 2019 at 2:03 AM Carl Eugen Hoyos  wrote:

> 2019-03-07 20:55 GMT+01:00, Jun Li :
> > From: jun 
> >
> > Calculate bitrate based on fragment size, only applied when
> > bitrate is not set, for example rtsp source.
>
> Could this also be done on a higher level?
> Or is smoothstreaming the only thing that needs this information?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for a new H.264 codec

[Ronald S. Bultje]

Hi,

On Mon, Mar 11, 2019 at 12:21 PM Soft Works  wrote:

> > From: Nicolas George
> >
> > Yufei He (12019-03-11):
> > > Matrox M264 is similar to other hardware codecs.
> > >
> > > I saw amf_load_library and nvenc_load_library in ffmpeg.
> >
> > Past practices do not constitute precedents.
> >
> > > We got a lot customers using ffmpeg and they want to use Matrox M264
> to do transcoding.
> >
> > If you make the driver GPL-compatible, there will be no problem at all.
> >
> > Regards,
> >
> > --
> >   Nicolas George
>
> While I don’t care much about Matrox, I’m a bit surprised about the
> recent sounds here. Should  we expect ffmpeg to drop most hw
> accelerations, then?
>
> IANAL, but aren’t drivers clearly considered to be system components?
> In this case they would  be exempted from the GPL afaic?
>

Getting very legal here for someone who's not a lawyer :), but my reading
of the GPL is not that it says "something that acts at system level" (e.g.
hardware), but something that is provided by the base system (i.e. you can
assume it to be installed in some way shape or form regardless of the exact
license that it is accompanied by). For example, you can assume your system
has a libc, even though it might not be a GPL libc.

However, my objection is not legal, it is philosophical. I would prefer
that we (FFmpeg) as a project do not encourage the use of closed-source
software or endorse particular closed-source software (by including support
for it in FFmpeg). We are an open source project, and thus (again: in my
personal opinion) we should only endorse other open source software. That
does not mean closed source software is bad or should not be used. It
merely means we do not endorse it by including support for it.

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

Re: [FFmpeg-devel] patch for a new H.264 codec

[Jean-Baptiste Kempf]

On Mon, 11 Mar 2019, at 17:46, Soft Works wrote:
> I still wonder why recent discussions are often referring to GPL even 
> though ffmpeg is released under LGPL.

Because LGPL is a derivative of the GPL, unfortunately.
And there are a lot more jurisprudence on the GPL, than on the LGPL.
And LGPL has an upgradability clause to GPL.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for a new H.264 codec

[Soft Works]

> From: Jean-Baptiste Kempf
>
> On Mon, 11 Mar 2019, at 17:21, Soft Works wrote:
> > While I don’t care much about Matrox, I’m a bit surprised about the
> > recent sounds here. Should  we expect ffmpeg to drop most hw
> > accelerations, then?
>
> Absolutely not.

I very glad to hear that :-)

> > IANAL, but aren’t drivers clearly considered to be system components?
>
> Sure, but here, it does not seem to call a driver, but a specific library 
> called libmvM264Ffmpeg that is being called.
>
> Maybe this is just a mis-communication, though.

Well, it probably was then, thanks for the clarification.

I came to think that it's hardware related because:

> Nicolas wrote:
>> If you make the driver GPL-compatible, there will be no problem at all.


I still wonder why recent discussions are often referring to GPL even though 
ffmpeg is released under LGPL.


Best regards,
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for a new H.264 codec

[Jean-Baptiste Kempf]

On Mon, 11 Mar 2019, at 17:21, Soft Works wrote:
> While I don’t care much about Matrox, I’m a bit surprised about the
> recent sounds here. Should  we expect ffmpeg to drop most hw
> accelerations, then?

Absolutely not.

> IANAL, but aren’t drivers clearly considered to be system components?

Sure, but here, it does not seem to call a driver, but a specific library 
called libmvM264Ffmpeg that is being called.

Maybe this is just a mis-communication, though.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for a new H.264 codec

[Soft Works]

> From: Nicolas George
>
> Yufei He (12019-03-11):
> > Matrox M264 is similar to other hardware codecs.
> >
> > I saw amf_load_library and nvenc_load_library in ffmpeg.
>
> Past practices do not constitute precedents.
>
> > We got a lot customers using ffmpeg and they want to use Matrox M264 to do 
> > transcoding.
>
> If you make the driver GPL-compatible, there will be no problem at all.
>
> Regards,
>
> --
>   Nicolas George

While I don’t care much about Matrox, I’m a bit surprised about the
recent sounds here. Should  we expect ffmpeg to drop most hw
accelerations, then?

IANAL, but aren’t drivers clearly considered to be system components?
In this case they would  be exempted from the GPL afaic?

Anyway, I thought that ffmpeg is LGPL, not GPL. It only becomes GPL
as soon as someone is including GPL libraries, right?

And in that case: wouldn’t it be true that only the owners of
such an included GPL component could pursue and make demands
against a potential violator (violating GPL but not LGPL terms)?

Since ffmpeg code is LGPL, my understanding is that ffmpeg could only
pursue violations of the license under which it is publishing its code,
and that would be LGPL but not GPL.


I’m just wondering – are those assumptions incorrect?

Regards,
softworkz



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

Re: [FFmpeg-devel] extradata on h.264 encoding for mp4 and mov files.

[Nicolas George]

Yufei He (12019-03-11):
> It seems ffmpeg can only generate AVCC box if I set extradata in my
> encoder's init function, it does not take the extradata if I make it
> in receive_packet function.
> 
> But I don't have sps and pps when the encoder's init function is
> called. I only can get it when I get first encoded frame.

"AVCC box" looks like a muxer thing. It happens after the encoder.
Encode the first frames, and only then open your muxer.

Note: this list is about developing FFmpeg, not developing WITH FFmpeg.
Please see the relevant mailing-list for further comments.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] extradata on h.264 encoding for mp4 and mov files.

[Yufei He]

Hi

It seems ffmpeg can only generate AVCC box if I set extradata in my encoder's 
init function, it does not take the extradata if I make it in receive_packet 
function.

But I don't have sps and pps when the encoder's init function is called. I only 
can get it when I get first encoded frame.

Please help.

Thanks.

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

Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Vittorio Giovara]

On Mon, Mar 11, 2019 at 12:50 AM Sun, Jing A  wrote:

> I just searched my inbox again but failed to find that email of question
> you mentioned.
>

Yeah I often see my mail bounced with this message:
Address not foundYour message wasn't delivered to *jun.z...@intel.com*
because the address couldn't be found, or is unable to receive mail.

For reference this was the message on the mailing list
https://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/240663.html

Could you please elaborate your request? What is the preservation for and
> how is it expected to work?
>

Yes of course, when you encode an HEVC stream you should be able to signal
how the color properties of the video buffers should be rendered. This is
usually conveyed with three parameters, the matrix coefficients, the color
primaries and the transfer characteristics. Without such information, the
data stored in the video may be interpreted differently and often
incorrectly by modern video players, causing image degradation, wrong
rendering and off colors.

For HEVC they are usually expressed in the stream itself, under the VUI,
and it is kinda expected that modern encoder allow to set them to any of
the applicable values.
In ffmpeg-land, they are represented by the colorspace, color_primaries and
color_transfer options in AVCodecContext and carried over through the whole
video processing.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] patch for a new H.264 codec

[Nicolas George]

Yufei He (12019-03-11):
> Matrox M264 is similar to other hardware codecs.
> 
> I saw amf_load_library and nvenc_load_library in ffmpeg.

Past practices do not constitute precedents.

> We got a lot customers using ffmpeg and they want to use Matrox M264 to do 
> transcoding.

If you make the driver GPL-compatible, there will be no problem at all.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] patch for a new H.264 codec

[Yufei He]

Hi Carl

Matrox M264 is similar to other hardware codecs.

I saw amf_load_library and nvenc_load_library in ffmpeg.

Matrox M264 is the same.

We got a lot customers using ffmpeg and they want to use Matrox M264 to do 
transcoding.

Thanks a lot.

Yufei.


static int amf_load_library(AVCodecContext *avctx)
{
AmfContext *ctx = avctx->priv_data;
AMFInit_Fn init_fun;
AMFQueryVersion_Fn version_fun;
AMF_RESULT res;
ctx->delayed_frame = av_frame_alloc();
if (!ctx->delayed_frame) {
return AVERROR(ENOMEM);
}
// hardcoded to current HW queue size - will realloc in 
timestamp_queue_enqueue() if too small
ctx->timestamp_list = av_fifo_alloc((avctx->max_b_frames + 16) * 
sizeof(int64_t));
if (!ctx->timestamp_list) {
return AVERROR(ENOMEM);
}
ctx->dts_delay = 0;
ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW | RTLD_LOCAL);
AMF_RETURN_IF_FALSE(ctx, ctx->library != NULL,
AVERROR_UNKNOWN, "DLL %s failed to open\n", AMF_DLL_NAMEA);
init_fun = (AMFInit_Fn)dlsym(ctx->library, AMF_INIT_FUNCTION_NAME);
AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed to 
find function %s\n", AMF_DLL_NAMEA, AMF_INIT_FUNCTION_NAME);
version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library, 
AMF_QUERY_VERSION_FUNCTION_NAME);
AMF_RETURN_IF_FALSE(ctx, version_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed 
to find function %s\n", AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);


static av_cold int nvenc_load_libraries(AVCodecContext *avctx)
{
NvencContext *ctx = avctx->priv_data;
NvencDynLoadFunctions *dl_fn = >nvenc_dload_funcs;
NVENCSTATUS err;
uint32_t nvenc_max_ver;
int ret;
ret = cuda_load_functions(_fn->cuda_dl, avctx);
if (ret < 0)
return ret;
ret = nvenc_load_functions(_fn->nvenc_dl, avctx);
if (ret < 0) {
nvenc_print_driver_requirement(avctx, AV_LOG_ERROR);
return ret;
}
err = dl_fn->nvenc_dl->NvEncodeAPIGetMaxSupportedVersion(_max_ver);
if (err != NV_ENC_SUCCESS)
return nvenc_print_error(avctx, err, "Failed to query nvenc max version");
av_log(avctx, AV_LOG_VERBOSE, "Loaded Nvenc version %d.%d\n", nvenc_max_ver >> 
4, nvenc_max_ver & 0xf);
if ((NVENCAPI_MAJOR_VERSION << 4 | NVENCAPI_MINOR_VERSION) > nvenc_max_ver) {
av_log(avctx, AV_LOG_ERROR, "Driver does not support the required nvenc API 
version. "
"Required: %d.%d Found: %d.%d\n",
NVENCAPI_MAJOR_VERSION, NVENCAPI_MINOR_VERSION,
nvenc_max_ver >> 4, nvenc_max_ver & 0xf);
On 03/11/2019 07:04 AM, Carl Eugen Hoyos wrote:

2019-03-11 11:57 GMT+01:00, Ronald S. Bultje 
:



- How do we set up a fate station with m264 support?



We do not test any external libraries with fate.

[...]



- How do we test that it still works after we make innocent
changes to some API?



Same as so far: We remove the feature that isn't updated.



- If we add new H264 files to our conformance suite, how
do we confirm that m264dec passes them?



That wouldn't work for any of our external codecs (at least
for some it wouldn't), in some cases the reason is that
the external codec supports things unsupported by FFmpeg,
in some cases there are license issues even with
open-source software.

Sorry, but some of this sounds like a solution in search of a
problem.

No strong opinion here about Matrox but we accepted AMD
in spite of their mails, so I don't see why we can't accept a
non-free Matrox codec (as long as the patch is reasonably
clean).

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


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

[FFmpeg-devel] [PATCH] avcodec/mpeg4_unpack_bframes_bsf: Improve DivX userdata check

[Andreas Rheinhardt]

The earlier version didn't really check that the 'p' of a "p\0" is
actually part of a user_data section, instead it treated the first
"p\0" after the start of a user_data section as end of a user_data
section if it is close enough to the beginning of the user_data section;
it actually needn't be part of a user_data section at all.

Furthermore, the code worked under the assumption that there is a 0x00
after the 'p' although this might not be true for extradata if the
user_data unit is at the end of the extradata.

Both of these flaws have been fixed.

Signed-off-by: Andreas Rheinhardt 
---
The earlier version was inspired by the check for packed bitstreams in
decode_user_data() in mpeg4videodec.c where the "DivX" is mandatory,
too.
Note that this new version relies on there being no binary zero inside
the user data.
 libavcodec/mpeg4_unpack_bframes_bsf.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c 
b/libavcodec/mpeg4_unpack_bframes_bsf.c
index 1daf133ce5..37bb0b20e3 100644
--- a/libavcodec/mpeg4_unpack_bframes_bsf.c
+++ b/libavcodec/mpeg4_unpack_bframes_bsf.c
@@ -41,11 +41,12 @@ static void scan_buffer(const uint8_t *buf, int buf_size,
 
 if (startcode == USER_DATA_STARTCODE && pos_p) {
 /* check if the (DivX) userdata string ends with 'p' (packed) */
-for (int i = 0; i < 255 && pos + i + 1 < end; i++) {
-if (pos[i] == 'p' && pos[i + 1] == '\0') {
+for (int i = 0; i < 255 && pos + i < end; i++) {
+if (pos[i] == 'p' && (pos + i + 1 == end || pos[i + 1] == 
'\0')) {
 *pos_p = pos + i - buf;
 break;
-}
+} else if (pos[i] == 0)
+break;
 }
 } else if (startcode == VOP_STARTCODE && nb_vop) {
 *nb_vop += 1;
-- 
2.19.2

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

Re: [FFmpeg-devel] [PATCH] libavcodec/zmbvenc: Add support for RGB formats

[Carl Eugen Hoyos]

2019-03-11 12:07 GMT+01:00, Tomas Härdin :
> mån 2019-03-11 klockan 11:43 +0100 skrev Carl Eugen Hoyos:
>> > 2019-03-11 11:37 GMT+01:00, Tomas Härdin :
>> > fre 2019-03-08 klockan 21:39 + skrev Matthew Fearnley:
>> > > > On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos 
>> > > > wrote:
>> > > > > > > > 2019-03-08 15:04 GMT+01:00, Tomas Härdin
>> > > > > > > > :
>> > > > >
>> > > > > Maybe we could coordinate 1/2/4/24-bit support with the
>> > > >
>> > > > I believe FFmpeg cannot support 1/2/4 bit for encoding.
>> > >
>> > > As far as I can see, FFmpeg has very limited support for bit depths
>> > > less
>> > > than 8.  I think there are basically two formats (plus variants), with
>> > > fixed "palettes":
>> > > 1bpp: MONO_BLACK / MONO_WHITE (black/white only)
>> > > 4bpp: RGB4[_BYTE], BGR4[_BYTE] (RGB 1:2:1, 16 colours - I presume
>> > > red/blue
>> > > would be 0,255; green would be 0,85,170,255)
>> > >
>> > > If the ZMBV formats were defined, these might be worth encoder adding
>> > > support for.
>> > > (Practically speaking though, it would be a slight pain, because the
>> > > encoder would do the work in 8bpp and pack/unpack as needed.)
>> > > But with PAL8 being the only format allowing a free palette, all
>> > > sub-8bpp
>> > > formats would have to decode to that, so they wouldn't round-trip.
>> >
>> > There's some justification for adding sub-8bpp, like BMP. bmp.c
>> > converts all of them except GRAY8 to PAL8. Bitdepths besides 1, 4 and 8
>> > don't work at all.
>> >
>> > One way to at least allow both the bmp and zmbv encoders to do sub-8bpp
>> > from PAL8 would be to keep track of the maximum number of colors in
>> > some appropriate struct.
>>
>> bits_per_coded_sample
>
> bits_per_raw_sample would seem more appropriate

Of course!

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

Re: [FFmpeg-devel] [PATCH] libavcodec/zmbvenc: Add support for RGB formats

[Tomas Härdin]

mån 2019-03-11 klockan 11:43 +0100 skrev Carl Eugen Hoyos:
> > 2019-03-11 11:37 GMT+01:00, Tomas Härdin :
> > fre 2019-03-08 klockan 21:39 + skrev Matthew Fearnley:
> > > > On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos 
> > > > wrote:
> > > > > > > > 2019-03-08 15:04 GMT+01:00, Tomas Härdin :
> > > > > 
> > > > > Maybe we could coordinate 1/2/4/24-bit support with the
> > > > 
> > > > I believe FFmpeg cannot support 1/2/4 bit for encoding.
> > > 
> > > As far as I can see, FFmpeg has very limited support for bit depths less
> > > than 8.  I think there are basically two formats (plus variants), with
> > > fixed "palettes":
> > > 1bpp: MONO_BLACK / MONO_WHITE (black/white only)
> > > 4bpp: RGB4[_BYTE], BGR4[_BYTE] (RGB 1:2:1, 16 colours - I presume red/blue
> > > would be 0,255; green would be 0,85,170,255)
> > > 
> > > If the ZMBV formats were defined, these might be worth encoder adding
> > > support for.
> > > (Practically speaking though, it would be a slight pain, because the
> > > encoder would do the work in 8bpp and pack/unpack as needed.)
> > > But with PAL8 being the only format allowing a free palette, all sub-8bpp
> > > formats would have to decode to that, so they wouldn't round-trip.
> > 
> > There's some justification for adding sub-8bpp, like BMP. bmp.c
> > converts all of them except GRAY8 to PAL8. Bitdepths besides 1, 4 and 8
> > don't work at all.
> > 
> > One way to at least allow both the bmp and zmbv encoders to do sub-8bpp
> > from PAL8 would be to keep track of the maximum number of colors in
> > some appropriate struct.
> 
> bits_per_coded_sample

bits_per_raw_sample would seem more appropriate, depending on what part
of the documentation you trust. It's unfortunate that AVCodecContext
and AVCodecParameters have different wording, and possibly different
semantics for these fields..

Whichever is used, the wording would need to become more
precise. bits_per_coded_sample documentation mentions ADPCM which packs
samples, whereas 1/2/4-bit-in-PAL8 would not.

I sent an email to the DOSBox crew about bit ordering

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

Re: [FFmpeg-devel] patch for a new H.264 codec

[Carl Eugen Hoyos]

2019-03-11 11:57 GMT+01:00, Ronald S. Bultje :

> - How do we set up a fate station with m264 support?

We do not test any external libraries with fate.

[...]

> - How do we test that it still works after we make innocent
> changes to some API?

Same as so far: We remove the feature that isn't updated.

> - If we add new H264 files to our conformance suite, how
> do we confirm that m264dec passes them?

That wouldn't work for any of our external codecs (at least
for some it wouldn't), in some cases the reason is that
the external codec supports things unsupported by FFmpeg,
in some cases there are license issues even with
open-source software.

Sorry, but some of this sounds like a solution in search of a
problem.

No strong opinion here about Matrox but we accepted AMD
in spite of their mails, so I don't see why we can't accept a
non-free Matrox codec (as long as the patch is reasonably
clean).

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

Re: [FFmpeg-devel] patch for a new H.264 codec

[Ronald S. Bultje]

Hi,

On Mon, Mar 11, 2019 at 4:53 AM Moritz Barsnick  wrote:

> On Mon, Mar 11, 2019 at 01:59:47 +0100, Carl Eugen Hoyos wrote:
> > The library needs non-free in configure and please
> > use dynamic linking, not loading at run-time.
>
> There is also no indication whatsoever where to get mvM264Ffmpeg.dll
> and libmvM264Ffmpeg.so from. No-one can even attempt to run (or - once
> you, Yufei, have fixed it - compile) this functionality without this.
> That's hopeless.
>

I want to reiterate my point from the other thread here that I think it's
time that we set an official project policy w.r.t. closed-source software.

I believe we should either choose that there is no place in FFmpeg for this
sort of things (I support this point of view), or we should set specific
guidelines about the software (I understand some developers lean more
towards this, and I respect that). Right now it's all random and that's not
good.

- How do we set up a fate station with m264 support? Or will matrox provide
one? Or will it be available to FFmpeg developers at no charge?
- How do we test that it still works after we make innocent changes to some
API?
- If we add new H264 files to our conformance suite, how do we confirm that
m264dec passes them?
- If we see particular optimizations or code changes that would make this
wrapper work better, how do we test that it still works? (If we can't, then
is the wrapper truly open source software?)
Etc.

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

Re: [FFmpeg-devel] [PATCH] libavcodec/zmbvenc: Add support for RGB formats

[Carl Eugen Hoyos]

2019-03-11 11:37 GMT+01:00, Tomas Härdin :
> fre 2019-03-08 klockan 21:39 + skrev Matthew Fearnley:
>> > On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos 
>> > wrote:
>> > 2019-03-08 15:04 GMT+01:00, Tomas Härdin :
>> > >
>> > > Maybe we could coordinate 1/2/4/24-bit support with the
>> >
>> > I believe FFmpeg cannot support 1/2/4 bit for encoding.
>>
>> As far as I can see, FFmpeg has very limited support for bit depths less
>> than 8.  I think there are basically two formats (plus variants), with
>> fixed "palettes":
>> 1bpp: MONO_BLACK / MONO_WHITE (black/white only)
>> 4bpp: RGB4[_BYTE], BGR4[_BYTE] (RGB 1:2:1, 16 colours - I presume red/blue
>> would be 0,255; green would be 0,85,170,255)
>>
>> If the ZMBV formats were defined, these might be worth encoder adding
>> support for.
>> (Practically speaking though, it would be a slight pain, because the
>> encoder would do the work in 8bpp and pack/unpack as needed.)
>> But with PAL8 being the only format allowing a free palette, all sub-8bpp
>> formats would have to decode to that, so they wouldn't round-trip.
>
> There's some justification for adding sub-8bpp, like BMP. bmp.c
> converts all of them except GRAY8 to PAL8. Bitdepths besides 1, 4 and 8
> don't work at all.
>
> One way to at least allow both the bmp and zmbv encoders to do sub-8bpp
> from PAL8 would be to keep track of the maximum number of colors in
> some appropriate struct.

bits_per_coded_sample

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

[FFmpeg-devel] [PATCH] avcodec/mpeg4videodec: Fix nonsense warning

[Andreas Rheinhardt]

Since db772308941a2a338c7809f90d347219a6a93074 parsing of
mpeg4-extradata lead to a "Failed to parse extradata" warning, because
ff_mpeg4_decode_picture_header returns AVERROR_INVALIDDATA in case that
no VOP was found. This patch adds a parameter to signify whether a
header (where the absence of a VOP does not raise an error) or not is
parsed. The first mode is of course used for parsing headers.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h263dec.c   |  4 ++--
 libavcodec/mpeg4video.h|  2 +-
 libavcodec/mpeg4video_parser.c |  6 +++---
 libavcodec/mpeg4videodec.c | 10 +++---
 4 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 2cf01e3d98..8385ddfe2e 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -500,9 +500,9 @@ retry:
 GetBitContext gb;
 
 if (init_get_bits8(, s->avctx->extradata, 
s->avctx->extradata_size) >= 0 )
-ff_mpeg4_decode_picture_header(avctx->priv_data, );
+ff_mpeg4_decode_picture_header(avctx->priv_data, , 1);
 }
-ret = ff_mpeg4_decode_picture_header(avctx->priv_data, >gb);
+ret = ff_mpeg4_decode_picture_header(avctx->priv_data, >gb, 0);
 } else if (CONFIG_H263I_DECODER && s->codec_id == AV_CODEC_ID_H263I) {
 ret = ff_intel_h263_decode_picture_header(s);
 } else if (CONFIG_FLV_DECODER && s->h263_flv) {
diff --git a/libavcodec/mpeg4video.h b/libavcodec/mpeg4video.h
index dd0a59038d..1a5da31928 100644
--- a/libavcodec/mpeg4video.h
+++ b/libavcodec/mpeg4video.h
@@ -163,7 +163,7 @@ void ff_mpeg4_pred_ac(MpegEncContext *s, int16_t *block, 
int n,
 void ff_set_mpeg4_time(MpegEncContext *s);
 int ff_mpeg4_encode_picture_header(MpegEncContext *s, int picture_number);
 
-int ff_mpeg4_decode_picture_header(Mpeg4DecContext *ctx, GetBitContext *gb);
+int ff_mpeg4_decode_picture_header(Mpeg4DecContext *ctx, GetBitContext *gb, 
int header);
 void ff_mpeg4_encode_video_packet_header(MpegEncContext *s);
 void ff_mpeg4_clean_buffers(MpegEncContext *s);
 void ff_mpeg4_stuffing(PutBitContext *pbc);
diff --git a/libavcodec/mpeg4video_parser.c b/libavcodec/mpeg4video_parser.c
index 9ebb09a63e..9ca0f14976 100644
--- a/libavcodec/mpeg4video_parser.c
+++ b/libavcodec/mpeg4video_parser.c
@@ -89,13 +89,13 @@ static int mpeg4_decode_header(AVCodecParserContext *s1, 
AVCodecContext *avctx,
 
 if (avctx->extradata_size && pc->first_picture) {
 init_get_bits(gb, avctx->extradata, avctx->extradata_size * 8);
-ret = ff_mpeg4_decode_picture_header(dec_ctx, gb);
-if (ret < -1)
+ret = ff_mpeg4_decode_picture_header(dec_ctx, gb, 1);
+if (ret < 0)
 av_log(avctx, AV_LOG_WARNING, "Failed to parse extradata\n");
 }
 
 init_get_bits(gb, buf, 8 * buf_size);
-ret = ff_mpeg4_decode_picture_header(dec_ctx, gb);
+ret = ff_mpeg4_decode_picture_header(dec_ctx, gb, 0);
 if (s->width && (!avctx->width || !avctx->height ||
  !avctx->coded_width || !avctx->coded_height)) {
 ret = ff_set_dimensions(avctx, s->width, s->height);
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index ecd028a87c..99b1e10620 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -3203,11 +3203,13 @@ static int decode_studio_vol_header(Mpeg4DecContext 
*ctx, GetBitContext *gb)
 
 /**
  * Decode MPEG-4 headers.
- * @return <0 if no VOP found (or a damaged one)
+ *
+ * @param  header If set the absence of a VOP is not treated as error; 
otherwise, it is treated as such.
+ * @return <0 if an error occured
  * FRAME_SKIPPED if a not coded VOP is found
- * 0 if a VOP is found
+ * 0 else
  */
-int ff_mpeg4_decode_picture_header(Mpeg4DecContext *ctx, GetBitContext *gb)
+int ff_mpeg4_decode_picture_header(Mpeg4DecContext *ctx, GetBitContext *gb, 
int header)
 {
 MpegEncContext *s = >m;
 unsigned startcode, v;
@@ -3236,6 +3238,8 @@ int ff_mpeg4_decode_picture_header(Mpeg4DecContext *ctx, 
GetBitContext *gb)
 (ctx->divx_version >= 0 || ctx->xvid_build >= 0) || 
s->codec_tag == AV_RL32("QMP4")) {
 av_log(s->avctx, AV_LOG_VERBOSE, "frame skip %d\n", 
gb->size_in_bits);
 return FRAME_SKIPPED;  // divx bug
+} else if (header && get_bits_count(gb) == gb->size_in_bits) {
+return 0; // ordinary return value for parsing of extradata
 } else
 return AVERROR_INVALIDDATA;  // end of stream
 }
-- 
2.19.2

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

Re: [FFmpeg-devel] [PATCH] libavcodec/zmbvenc: Add support for RGB formats

[Tomas Härdin]

fre 2019-03-08 klockan 21:39 + skrev Matthew Fearnley:
> > On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos  wrote:
> > 2019-03-08 15:04 GMT+01:00, Tomas Härdin :
> > > 
> > > Maybe we could coordinate 1/2/4/24-bit support with the
> > 
> > I believe FFmpeg cannot support 1/2/4 bit for encoding.
> > 
> 
> As far as I can see, FFmpeg has very limited support for bit depths less
> than 8.  I think there are basically two formats (plus variants), with
> fixed "palettes":
> 1bpp: MONO_BLACK / MONO_WHITE (black/white only)
> 4bpp: RGB4[_BYTE], BGR4[_BYTE] (RGB 1:2:1, 16 colours - I presume red/blue
> would be 0,255; green would be 0,85,170,255)
> 
> If the ZMBV formats were defined, these might be worth encoder adding
> support for.
> (Practically speaking though, it would be a slight pain, because the
> encoder would do the work in 8bpp and pack/unpack as needed.)
> But with PAL8 being the only format allowing a free palette, all sub-8bpp
> formats would have to decode to that, so they wouldn't round-trip.

There's some justification for adding sub-8bpp, like BMP. bmp.c
converts all of them except GRAY8 to PAL8. Bitdepths besides 1, 4 and 8
don't work at all.

One way to at least allow both the bmp and zmbv encoders to do sub-8bpp 
from PAL8 would be to keep track of the maximum number of colors in
some appropriate struct.

Adding proper sub-8bpp support would involve a lot of libsws headache I
suspect.

> (It should be possible to implement decoding to pal8 if
> > that doesn't work yet and if samples exist.)
> > 
> 
> No samples or specifications exist that I know of, so I don't plan to
> submit any patches to the decoder unless/until there is something to work
> with there.
> 
> > dosbox devs? And maybe we should do something about
> > > the RGB24 thing in the decoder..
> 
> Yeah, I think talking with the DOSBox devs sounds like a potentially good
> idea.
> 
> > 
> > Do I understand correctly that no existing implementation
> > supports 24bit rgb? If that is correct, I believe FFmpeg
> > shouldn't add it (but this may only be me).
> > 
> 
> I agree that FFmpeg shouldn't add support for any formats that haven't been
> defined.
> As far as I know, the specifics of the 24-bit RGB format havn't been
> discussed anywhere, and there are no samples I know of.
> 
> A likely specification of 24-bit is trivial enough to add support for, that
> I was originally planning to add it with an #ifdef (like in the decoder).
> But it wouldn't do to have contradictory channel orders proposed in the
> decoder and encoder, so I will leave that for now unless DOSBox will commit
> to one.
> 
> I presume that FFmpeg generally doesn't like to set standards in media
> formats, only to implement existing ones.
> My personal feelings in this case would be to provide support that's
> disabled at compile-time if an official specification can be agreed, and to
> have support included by default if an independent implementation - or at
> least independent samples - are available that agree with the specification.

Just a small thing to be clear: ZMBV_ENABLE_24BPP is not defined
anywhere, so we're free to do however we want with it. It's not going
to break anyone's workflow unless they were foolish enough to encode
24-bit ZMBVs outside of the non-existing spec.

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

Re: [FFmpeg-devel] [PATCH] ffnvcodec/compat: Fix CUdeviceptr definition for 64bit CPU

[Timo Rothenpieler]

On 11/03/2019 06:37, Ruta Gadkari wrote:

Hi

Please find the attached patch, it rectifies the definition of cuda device 
pointer for PPC64 architecture.
PPC64 support is present from Video Codec SDK 9.

Thanks
Ruta


Applied and released a new version of ffnvcodec 9.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for ppc64

[Carl Eugen Hoyos]

2019-03-11 11:16 GMT+01:00, Timo Rothenpieler :
> On 11/03/2019 09:40, Carl Eugen Hoyos wrote:
>> 2019-03-11 6:36 GMT+01:00, Ruta Gadkari :
>>
>>> Please find attached the patch, it enables ffnvcodec and
>>> nvenc, nvdec, cuvid for PPC64 architecture.
>>
>> Is it supported on both little and big endian?
>
> Good question.

Assuming it is only supported on little-endian ppc64, the
check should be fixed accordingly.

>>> This email message is for the sole use of the intended
>>> recipient(s) and may contain confidential information.
>>
>> Please remove this nonsense from future emails.
>
> While I agree that it's pointless on mails to public lists, I don't
> think there is anything they can do against their mail server adding it.
> And I prefer having that at the end of every mail over not being able to
> identify patches from @nvidia.com as such as easily.

They could add "nvidia" to their gmail / hotmail / ... account names.

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

Re: [FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for ppc64

[Timo Rothenpieler]

On 11/03/2019 09:40, Carl Eugen Hoyos wrote:

2019-03-11 6:36 GMT+01:00, Ruta Gadkari :


Please find attached the patch, it enables ffnvcodec and
nvenc, nvdec, cuvid for PPC64 architecture.


Is it supported on both little and big endian?


Good question.


This email message is for the sole use of the intended
recipient(s) and may contain confidential information.


Please remove this nonsense from future emails.


While I agree that it's pointless on mails to public lists, I don't 
think there is anything they can do against their mail server adding it.
And I prefer having that at the end of every mail over not being able to 
identify patches from @nvidia.com as such as easily.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: allow user comments for opatom muxer

[Tomas Härdin]

sön 2019-03-10 klockan 19:03 -0700 skrev mindm...@gmail.com:
> > From: Mark Reid 
> 
> This patch restores the ability to add user comments for the opatom_mxf muxer.
> The ability seems to have been disabled in d9726893f31.

Seems the intent was to only disable them for D-10, so this is probably
fine. You should change this too:

  IRT D-10 does not allow user comments. The default is thus to write
  them for mxf but not for mxf_d10

to

  IRT D-10 does not allow user comments. The default is thus to write
  them for mxf and mxf_opatom but not for mxf_d10

The comment from Michael in d9726893f31 about comments causing problems
for "users" has me worried. We *need* functional tests for stuff like
that..

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

[FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Jing SUN]

From: Jing Sun 

base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC

V4: - Fix the build error with new API in PR#52
- Fix the encoding hang issue by API change in PR#52
- Fix the last frame dropping issue
- Fix the invalid parameter causing segmentation fault issue
- Add the support to svt hevc and av1 plugins coexistance
- Add the VMAF optimized mode to "-tune"
- Add the "-hdr" parameter

V3: - Fix the build error with new API

V2: - Change the config options (didn't need to enable-gpl for BSD+Patent,
  it's can compatible with LGPL2+, thanks Xavier correct this part),
  now just need to "--enable-libsvthevc" option
- Add force_idr option
- Remove default GoP size setting in the wrapper, SVT-HEVC will calc
  the the GoP size internal
- Refine the code as the FFmpeg community's comments
  (https://patchwork.ffmpeg.org/patch/11347/)

V1: - base on patch by Huang, Zhengxu, then refine some code.

Change-Id: If0dcc5044ab9effd6847a8f48797b985d02b0816
Signed-off-by: Huang, Zhengxu 
Signed-off-by: hassene 
Signed-off-by: Jun Zhao 
Signed-off-by: Jing Sun 
Signed-off-by: Jing SUN 
---
 configure|   4 +
 libavcodec/Makefile  |   1 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/libsvt_hevc.c | 527 +++
 4 files changed, 533 insertions(+)
 create mode 100644 libavcodec/libsvt_hevc.c

diff --git a/configure b/configure
index dcead3a..36bc8c1 100755
--- a/configure
+++ b/configure
@@ -264,6 +264,7 @@ External library support:
   --enable-libspeexenable Speex de/encoding via libspeex [no]
   --enable-libsrt  enable Haivision SRT protocol via libsrt [no]
   --enable-libssh  enable SFTP protocol via libssh [no]
+  --enable-libsvthevc  enable HEVC encoding via svt [no]
   --enable-libtensorflow   enable TensorFlow as a DNN module backend
for DNN based filters like sr [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
@@ -1784,6 +1785,7 @@ EXTERNAL_LIBRARY_LIST="
 libspeex
 libsrt
 libssh
+libsvthevc
 libtensorflow
 libtesseract
 libtheora
@@ -3173,6 +3175,7 @@ libshine_encoder_select="audio_frame_queue"
 libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
+libsvt_hevc_encoder_deps="libsvthevc"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
@@ -6209,6 +6212,7 @@ enabled libsoxr   && require libsoxr soxr.h 
soxr_create -lsoxr
 enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h 
sftp_init
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0" 
srt/srt.h srt_socket
+enabled libsvthevc&& require_pkg_config libsvthevc SvtHevcEnc 
svt-hevc/EbApi.h EbInitHandle
 enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h 
TF_Version -ltensorflow
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8..c93e545 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -987,6 +987,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o 
libopus.o \
 OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
+OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b26aeca..e93f66f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -703,6 +703,7 @@ extern AVCodec ff_librsvg_decoder;
 extern AVCodec ff_libshine_encoder;
 extern AVCodec ff_libspeex_encoder;
 extern AVCodec ff_libspeex_decoder;
+extern AVCodec ff_libsvt_hevc_encoder;
 extern AVCodec ff_libtheora_encoder;
 extern AVCodec ff_libtwolame_encoder;
 extern AVCodec ff_libvo_amrwbenc_encoder;
diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c
new file mode 100644
index 000..088decf
--- /dev/null
+++ b/libavcodec/libsvt_hevc.c
@@ -0,0 +1,527 @@
+/*
+* Scalable Video Technology for HEVC encoder library plugin
+*
+* Copyright (c) 2018 Intel Corporation
+*
+* 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 

Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Carl Eugen Hoyos]

2019-03-11 11:28 GMT+01:00, Jing SUN :

> +static void free_buffer(SvtContext *svt_enc)
> +{
> +uint8_t *in_data = (EB_H265_ENC_INPUT *)svt_enc->in_buf.pBuffer;
> +
> +av_freep(_data);
> +}

Is the cast necessary?
Does the variable make the code more readable?
Does the function make the code more readable?

No more comments here, sorry, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Sun, Jing A]

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
Eugen Hoyos
Sent: Monday, March 11, 2019 5:01 PM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc 
encoder wrapper.

2019-03-11 9:49 GMT+01:00, Moritz Barsnick :
> On Mon, Mar 11, 2019 at 04:17:21 +, Sun, Jing A wrote:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf 
>> Of Carl Eugen Hoyos
>> > The condition is unnecessary.
>> [SUN, Jing] If av_mallocz fails, free_buffer will be called with 
>> in_data being NULL. Checking it avoids unnecessary calling to 
>> av_freep in that case.
>
> Please read the kind documentation (and the "Note" quzoted below) or 
> the source of said function, and how other uses within ffmpeg are:
>
> https://www.ffmpeg.org/doxygen/4.1/group__lavu__mem__funcs.html#ga0cc8
> 4043ea2167ad005c86e11d0bcdba
>
> void av_freep (void *ptr)
> [...]
> Note
> *ptr = NULL is safe and leads to no action.

> In other words, av_freep() already has this check.

I believe his argumentation was that he knows but that in case of oom, he wants 
to avoid extra indirections.

Carl Eugen

[SUN, Jing] Modified and thanks for the review!

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

[FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Jing SUN]

From: Jing Sun 

base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC

V4: - Fix the build error with new API in PR#52
- Fix the encoding hang issue by API change in PR#52
- Fix the last frame dropping issue
- Fix the invalid parameter causing segmentation fault issue
- Add the support to svt hevc and av1 plugins coexistance
- Add the VMAF optimized mode to "-tune"
- Add the "-hdr" parameter

V3: - Fix the build error with new API

V2: - Change the config options (didn't need to enable-gpl for BSD+Patent,
  it's can compatible with LGPL2+, thanks Xavier correct this part),
  now just need to "--enable-libsvthevc" option
- Add force_idr option
- Remove default GoP size setting in the wrapper, SVT-HEVC will calc
  the the GoP size internal
- Refine the code as the FFmpeg community's comments
  (https://patchwork.ffmpeg.org/patch/11347/)

V1: - base on patch by Huang, Zhengxu, then refine some code.

Change-Id: If0dcc5044ab9effd6847a8f48797b985d02b0816
Signed-off-by: Huang, Zhengxu 
Signed-off-by: hassene 
Signed-off-by: Jun Zhao 
Signed-off-by: Jing Sun 
Signed-off-by: Jing SUN 
---
 configure|   4 +
 libavcodec/Makefile  |   1 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/libsvt_hevc.c | 527 +++
 4 files changed, 533 insertions(+)
 create mode 100644 libavcodec/libsvt_hevc.c

diff --git a/configure b/configure
index dcead3a..36bc8c1 100755
--- a/configure
+++ b/configure
@@ -264,6 +264,7 @@ External library support:
   --enable-libspeexenable Speex de/encoding via libspeex [no]
   --enable-libsrt  enable Haivision SRT protocol via libsrt [no]
   --enable-libssh  enable SFTP protocol via libssh [no]
+  --enable-libsvthevc  enable HEVC encoding via svt [no]
   --enable-libtensorflow   enable TensorFlow as a DNN module backend
for DNN based filters like sr [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
@@ -1784,6 +1785,7 @@ EXTERNAL_LIBRARY_LIST="
 libspeex
 libsrt
 libssh
+libsvthevc
 libtensorflow
 libtesseract
 libtheora
@@ -3173,6 +3175,7 @@ libshine_encoder_select="audio_frame_queue"
 libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
+libsvt_hevc_encoder_deps="libsvthevc"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
@@ -6209,6 +6212,7 @@ enabled libsoxr   && require libsoxr soxr.h 
soxr_create -lsoxr
 enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h 
sftp_init
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0" 
srt/srt.h srt_socket
+enabled libsvthevc&& require_pkg_config libsvthevc SvtHevcEnc 
svt-hevc/EbApi.h EbInitHandle
 enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h 
TF_Version -ltensorflow
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8..c93e545 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -987,6 +987,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o 
libopus.o \
 OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
+OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b26aeca..e93f66f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -703,6 +703,7 @@ extern AVCodec ff_librsvg_decoder;
 extern AVCodec ff_libshine_encoder;
 extern AVCodec ff_libspeex_encoder;
 extern AVCodec ff_libspeex_decoder;
+extern AVCodec ff_libsvt_hevc_encoder;
 extern AVCodec ff_libtheora_encoder;
 extern AVCodec ff_libtwolame_encoder;
 extern AVCodec ff_libvo_amrwbenc_encoder;
diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c
new file mode 100644
index 000..088decf
--- /dev/null
+++ b/libavcodec/libsvt_hevc.c
@@ -0,0 +1,527 @@
+/*
+* Scalable Video Technology for HEVC encoder library plugin
+*
+* Copyright (c) 2018 Intel Corporation
+*
+* 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 

Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

[Li, Zhong]

> -Original Message-
> From: Rogozhkin, Dmitry V
> Sent: Saturday, March 9, 2019 8:48 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current
> parser with MFXVideoDECODE_DecodeHeader()
> 
> On Fri, 2019-03-08 at 15:40 +0800, Zhong Li wrote:
> > Using MSDK parser can improve qsv decoder pass rate in some cases
> > (E.g:
> > sps declares a wrong level_idc, smaller than it should be).
> > And it is necessary for adding new qsv decoders such as MJPEG and VP9
> > since current parser can't provide enough information.
> > Actually using MFXVideoDECODE_DecodeHeader() was disscussed at
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175734.html and
> > merged as commit 1acb19d, but was overwritten when merged libav
> > patches (commit: 1f26a23) without any explain.
> >
> > v2: split decode header from decode_init, and call it for everyframe
> > to detect format/resoultion change. It can fix some regression issues
> > such as hevc 10bits decoding.
> >
> > Signed-off-by: Zhong Li 
> > ---
> >  libavcodec/qsvdec.c   | 172 --
> > 
> >  libavcodec/qsvdec.h   |   2 +
> >  libavcodec/qsvdec_h2645.c |   1 +
> >  libavcodec/qsvdec_other.c |   1 +
> >  4 files changed, 93 insertions(+), 83 deletions(-)
> >
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> > 4a0be811fb..b78026e14d 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -120,19 +120,17 @@ static inline unsigned int qsv_fifo_size(const
> > AVFifoBuffer* fifo)
> >  return av_fifo_size(fifo) / qsv_fifo_item_size();
> >  }
> >
> > -static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > +static int qsv_decode_preinit(AVCodecContext *avctx, QSVContext *q,
> > enum AVPixelFormat *pix_fmts, mfxVideoParam *param)
> >  {
> > -const AVPixFmtDescriptor *desc;
> >  mfxSession session = NULL;
> >  int iopattern = 0;
> > -mfxVideoParam param = { 0 };
> > -int frame_width  = avctx->coded_width;
> > -int frame_height = avctx->coded_height;
> >  int ret;
> >
> > -desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > -if (!desc)
> > -return AVERROR_BUG;
> > +ret = ff_get_format(avctx, pix_fmts);
> > +if (ret < 0) {
> > +q->orig_pix_fmt = avctx->pix_fmt = AV_PIX_FMT_NONE;
> > +return ret;
> > +}
> >
> >  if (!q->async_fifo) {
> >  q->async_fifo = av_fifo_alloc(q->async_depth *
> > qsv_fifo_item_size()); @@ -170,48 +168,72 @@ static int
> > qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> >  return ret;
> >  }
> >
> > -ret = ff_qsv_codec_id_to_mfx(avctx->codec_id);
> > -if (ret < 0)
> > -return ret;
> > +param->IOPattern   = q->iopattern;
> > +param->AsyncDepth  = q->async_depth;
> > +param->ExtParam= q->ext_buffers;
> > +param->NumExtParam = q->nb_ext_buffers;
> >
> > -param.mfx.CodecId  = ret;
> > -param.mfx.CodecProfile = ff_qsv_profile_to_mfx(avctx->codec_id,
> > avctx->profile);
> > -param.mfx.CodecLevel   = avctx->level ==
> FF_LEVEL_UNKNOWN ?
> > MFX_LEVEL_UNKNOWN : avctx->level;
> > -
> > -param.mfx.FrameInfo.BitDepthLuma   = desc->comp[0].depth;
> > -param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
> > -param.mfx.FrameInfo.Shift  = desc->comp[0].depth >
> 8;
> > -param.mfx.FrameInfo.FourCC = q->fourcc;
> > -param.mfx.FrameInfo.Width  = frame_width;
> > -param.mfx.FrameInfo.Height = frame_height;
> > -param.mfx.FrameInfo.ChromaFormat   =
> MFX_CHROMAFORMAT_YUV420;
> > -
> > -switch (avctx->field_order) {
> > -case AV_FIELD_PROGRESSIVE:
> > -param.mfx.FrameInfo.PicStruct =
> MFX_PICSTRUCT_PROGRESSIVE;
> > -break;
> > -case AV_FIELD_TT:
> > -param.mfx.FrameInfo.PicStruct =
> MFX_PICSTRUCT_FIELD_TFF;
> > -break;
> > -case AV_FIELD_BB:
> > -param.mfx.FrameInfo.PicStruct =
> MFX_PICSTRUCT_FIELD_BFF;
> > -break;
> > -default:
> > -param.mfx.FrameInfo.PicStruct =
> MFX_PICSTRUCT_UNKNOWN;
> > -break;
> > -}
> > +return 0;
> > + }
> >
> > -param.IOPattern   = q->iopattern;
> > -param.AsyncDepth  = q->async_depth;
> > -param.ExtParam= q->ext_buffers;
> > -param.NumExtParam = q->nb_ext_buffers;
> > +static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q,
> > mfxVideoParam *param)
> > +{
> > +int ret;
> >
> > -ret = MFXVideoDECODE_Init(q->session, );
> > +avctx->width= param->mfx.FrameInfo.CropW;
> > +avctx->height   = param->mfx.FrameInfo.CropH;
> > +avctx->coded_width  = param->mfx.FrameInfo.Width;
> > +avctx->coded_height = param->mfx.FrameInfo.Height;
> > +avctx->level= param->mfx.CodecLevel;
> > +avctx->profile  = param->mfx.CodecProfile;
> > +avctx->field_order  = ff_qsv_map_picstruct(param-
> > 

Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Carl Eugen Hoyos]

2019-03-11 9:49 GMT+01:00, Moritz Barsnick :
> On Mon, Mar 11, 2019 at 04:17:21 +, Sun, Jing A wrote:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Carl Eugen Hoyos
>> > The condition is unnecessary.
>> [SUN, Jing] If av_mallocz fails, free_buffer will be called with in_data
>> being NULL. Checking it avoids unnecessary calling to av_freep in that
>> case.
>
> Please read the kind documentation (and the "Note" quzoted below) or
> the source of said function, and how other uses within ffmpeg are:
>
> https://www.ffmpeg.org/doxygen/4.1/group__lavu__mem__funcs.html#ga0cc84043ea2167ad005c86e11d0bcdba
>
> void av_freep (void *ptr)
> [...]
> Note
> *ptr = NULL is safe and leads to no action.

> In other words, av_freep() already has this check.

I believe his argumentation was that he knows but that in case
of oom, he wants to avoid extra indirections.

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

Re: [FFmpeg-devel] [PATCH v2] avformat/smoothstreamingenc:add bitrate calculate

[Carl Eugen Hoyos]

2019-03-07 20:55 GMT+01:00, Jun Li :
> From: jun 
>
> Calculate bitrate based on fragment size, only applied when
> bitrate is not set, for example rtsp source.

Could this also be done on a higher level?
Or is smoothstreaming the only thing that needs this information?

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

Re: [FFmpeg-devel] patch for a new H.264 codec

[Moritz Barsnick]

On Mon, Mar 11, 2019 at 01:59:47 +0100, Carl Eugen Hoyos wrote:
> The library needs non-free in configure and please
> use dynamic linking, not loading at run-time.

There is also no indication whatsoever where to get mvM264Ffmpeg.dll
and libmvM264Ffmpeg.so from. No-one can even attempt to run (or - once
you, Yufei, have fixed it - compile) this functionality without this.
That's hopeless.

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

Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Moritz Barsnick]

On Mon, Mar 11, 2019 at 04:17:21 +, Sun, Jing A wrote:
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
> Eugen Hoyos
> > The condition is unnecessary.
> [SUN, Jing] If av_mallocz fails, free_buffer will be called with in_data 
> being NULL. Checking it avoids unnecessary calling to av_freep in that case.

Please read the kind documentation (and the "Note" quzoted below) or
the source of said function, and how other uses within ffmpeg are:

https://www.ffmpeg.org/doxygen/4.1/group__lavu__mem__funcs.html#ga0cc84043ea2167ad005c86e11d0bcdba

void av_freep (void *ptr)
[...]
Note
*ptr = NULL is safe and leads to no action.

In other words, av_freep() already has this check.

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

Re: [FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for ppc64

[Carl Eugen Hoyos]

2019-03-11 6:36 GMT+01:00, Ruta Gadkari :

> Please find attached the patch, it enables ffnvcodec and
> nvenc, nvdec, cuvid for PPC64 architecture.

Is it supported on both little and big endian?

> This email message is for the sole use of the intended
> recipient(s) and may contain confidential information.

Please remove this nonsense from future emails.

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

Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Carl Eugen Hoyos]

2019-03-11 5:17 GMT+01:00, Sun, Jing A :

> 2019-03-08 11:36 GMT+01:00, Jing SUN :
>
>> +static void free_buffer(SvtContext *svt_enc) {
>> +EB_H265_ENC_INPUT *in_data =
>> (EB_H265_ENC_INPUT *)svt_enc->in_buf.pBuffer;
>
> Is the cast necessary?
> Or actually: Can't in_data be whatever doesn't produce a warning?
> [SUN, Jing] Yes, it's necessary, because the type of pBuffer is uint8_t* in
> libsvt_hevc.

You could make in_data uint8_t*.

>> +
>> +if (in_data)
>> +av_freep(_data);
>
> The condition is unnecessary.
> [SUN, Jing] If av_mallocz fails, free_buffer will be called with in_data
> being NULL. Checking it avoids unnecessary calling to av_freep in that
> case.

Please remove the condition (or the function).

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

Re: [FFmpeg-devel] [PATCH v7 2/2] doc: Add libsvt_hevc encoder docs

[Gyan]

On 11-03-2019 12:32 PM, Jing SUN wrote:

Add docs for libsvt_hevc encoder in encoders.texi and general.texi

Signed-off-by: Jun Zhao 
Signed-off-by: Huang, Zhengxu 
Signed-off-by: hassene 
Signed-off-by: Jing SUN 
---
  doc/encoders.texi | 145 ++
  doc/general.texi  |   8 +++
  2 files changed, 153 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 29625ba..0b30776 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1569,6 +1569,151 @@ Set maximum NAL size in bytes.
  Allow skipping frames to hit the target bitrate if set to 1.
  @end table
  
+@section libsvt_hevc

+
+Scalable Video Technology for HEVC encoder (SVT-HEVC encoder) wrapper.


Remove 'encoder' inside the brackets.

+This encoder requires the presence of the headers and
+library during configuration. You need to explicitly configure the
+build with @code{--enable-libsvthevc}. The library is detected using
+@command{pkg-config}.
+
+For more information about the library see
+@url{https://github.com/intel/SVT-HEVC.git}.
+
+@subsection Options
+
+The following FFmpeg global options affect the configurations of the
+libsvt_hevc encoder.

s/configurations/configuration

+@table @option
+@item b  (@emph{bitrate})
+Set the bitrate (as a number of bits per second). Default is 7M.
+
+@item g  / @option{gop_size}
+Set the GOP size. Default is -2 (unspecified).
+
+@item flags +cgop
+Enable closed GOP.
+
+@item qmin (@emph{min-q})
+Defaults 10

"Default is 10."

+@item qmax (@emph{max-q})
+Defaults 48


"Default is 48."

+Set minimum/maximum quantisation values.  Valid range is from 0 to 51

s/quantisation/quantization


+Has to be qmax > = qmin).
"It is required that qmax >= qmin". Ideally, this should be fully 
verbal, but will do.



+@item profile (@emph{profile})
+Set profile restrictions. Can assume one of the following possible values:
+
+Default is 2 (main10).
+
+@table @samp
+@item main
+main profile
+@item main10
+main10 profile
+@end table

Move the default to after the table.


+
+@item level

What are the permissible values? Is the default dynamic or fixed?

+@option{profile} sets the value of @emph{profile}.
+@option{level} sets the value of @emph{level}.


If this refers to the bitstream flags, make that clearer, and use the 
exact labels e.g. profile_idc. Place each sentence after its option entry.



+@item hielevel
+Set hierarchical levels. Can assume one of the following possible values:
+
+Default is 3 (4level).
+
+@table @samp
+@item flat
+none hierarchy level
+@item 2level
+2-level hierarchy
+@item 3level
+3-level hierarchy
+@item 4level
+4-level hierarchy
+@end table


Move the default to after the table.

+@item la_depth
+Set look-ahead depth, depending on bit rate control mode @option{rc}, when
+bit rate control mode is set to vbr it's best to set this parameter to be
+equal to the intra period value (such is the default set by the encoder),
+when cqp is chosen, then a look ahead is recommended. The range is from 
@var{0-256}.


"
Set lookahead depth (in frames). Range is @var{-1 - 256} where -1 
indicates the value is unset. Default is -1.
In rate-control mode @var{vbr}, if unset, the encoder will set this to 
the intra period value. In rate-control mode @var{cqp},

it is recommended that look-ahead depth be set.
"

What does the encoder do in cqp mode if value is unset? Are there 
specific guidelines for optimum la-depth value, in each rc mode?
If there are significant tradeoffs, in terms of latency or resource 
usage, mention those.

+@item preset
+A preset defining the quality vs density tradeoff point that the
+encoding is to be performed at.(e.g. 0 is the highest quality mode,
+12 is the highest density mode). The range is from @var{0-12}. Default is 9.


"
A preset setting the quality vs. density tradeoff that the encoder 
should make.

Range is @var{0-12}. Lower values favour quality over density. Default is 9.
"

+@item tier
+Set @emph{general_tier_flag}.  This may affect the level chosen for the stream
+if it is not explicitly specified. Can assume one of the following possible 
values:
+
+Default is 1 (main).
+
+@table @samp
+@item main
+main tier
+@item high
+high tier
+@end table


Move default to after the table.


+@item rc
+Set bit rate control mode. Can assume one of the following possible values:
+
+Default is 0 (cqp).
+
+@table @samp
+@item cqp
+Constant QP (CQP) mode
+@item vbr
+Variable Bit Rate (VBR) mode
+@end table


Move default to after the table.

+@item tune
+Set quality tuning mode. Can assume one of the following possible values:
+
+Default is 1 (oq).
+
+@table @samp
+@item sq
+Visually optimized mode
+@item oq
+PSNR / SSIM optimized mode
+@item vmaf
+VMAF optimized mode
+@end table


Move default to after the table.

+@item bl_mode
+Enables or disables Random Access Prediction. Default is 0 (disable).
+@end table
Double-check, but I think this end directive is meant to close the table 
for the private options and is 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpeg4videodec: Check idx in mpeg4_decode_studio_block()

[Kieran Kunhya]

On Sun, 10 Mar 2019 at 04:43 Michael Niedermayer 
wrote:

> Fixes: Out of array access
> Fixes:
> 13500/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5769760178962432
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
>

Ok.

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

[FFmpeg-devel] [PATCH v7 2/2] doc: Add libsvt_hevc encoder docs

[Jing SUN]

Add docs for libsvt_hevc encoder in encoders.texi and general.texi

Signed-off-by: Jun Zhao 
Signed-off-by: Huang, Zhengxu 
Signed-off-by: hassene 
Signed-off-by: Jing SUN 
---
 doc/encoders.texi | 145 ++
 doc/general.texi  |   8 +++
 2 files changed, 153 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 29625ba..0b30776 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1569,6 +1569,151 @@ Set maximum NAL size in bytes.
 Allow skipping frames to hit the target bitrate if set to 1.
 @end table
 
+@section libsvt_hevc
+
+Scalable Video Technology for HEVC encoder (SVT-HEVC encoder) wrapper.
+
+This encoder requires the presence of the headers and
+library during configuration. You need to explicitly configure the
+build with @code{--enable-libsvthevc}. The library is detected using
+@command{pkg-config}.
+
+For more information about the library see
+@url{https://github.com/intel/SVT-HEVC.git}.
+
+@subsection Options
+
+The following FFmpeg global options affect the configurations of the
+libsvt_hevc encoder.
+
+@table @option
+@item b  (@emph{bitrate})
+Set the bitrate (as a number of bits per second). Default is 7M.
+
+@item g  / @option{gop_size}
+Set the GOP size. Default is -2 (unspecified).
+
+@item flags +cgop
+Enable closed GOP.
+
+@item qmin (@emph{min-q})
+Defaults 10
+
+@item qmax (@emph{max-q})
+Defaults 48
+
+Set minimum/maximum quantisation values.  Valid range is from 0 to 51
+(Only used when bit rate control mode @option{rc} is set to 1(vbr) mode.
+Has to be qmax > = qmin).
+
+@item profile (@emph{profile})
+Set profile restrictions. Can assume one of the following possible values:
+
+Default is 2 (main10).
+
+@table @samp
+@item main
+main profile
+@item main10
+main10 profile
+@end table
+
+@item level
+
+@option{profile} sets the value of @emph{profile}.
+@option{level} sets the value of @emph{level}.
+
+The encoder also has its own specific options:
+
+@table @option
+@item vui
+Enables or disables the vui structure in the HEVC elementary
+bitstream. 0 = Off, 1 = On. Default is 0 (Off).
+
+@item aud (@emph{aud})
+Enable use of access unit delimiters when set to 1. Default is 0 (Off).
+
+@item hielevel
+Set hierarchical levels. Can assume one of the following possible values:
+
+Default is 3 (4level).
+
+@table @samp
+@item flat
+none hierarchy level
+@item 2level
+2-level hierarchy
+@item 3level
+3-level hierarchy
+@item 4level
+4-level hierarchy
+@end table
+
+@item la_depth
+Set look-ahead depth, depending on bit rate control mode @option{rc}, when
+bit rate control mode is set to vbr it's best to set this parameter to be
+equal to the intra period value (such is the default set by the encoder),
+when cqp is chosen, then a look ahead is recommended. The range is from 
@var{0-256}.
+
+@item preset
+A preset defining the quality vs density tradeoff point that the
+encoding is to be performed at.(e.g. 0 is the highest quality mode,
+12 is the highest density mode). The range is from @var{0-12}. Default is 9.
+
+@item tier
+Set @emph{general_tier_flag}.  This may affect the level chosen for the stream
+if it is not explicitly specified. Can assume one of the following possible 
values:
+
+Default is 1 (main).
+
+@table @samp
+@item main
+main tier
+@item high
+high tier
+@end table
+
+@item rc
+Set bit rate control mode. Can assume one of the following possible values:
+
+Default is 0 (cqp).
+
+@table @samp
+@item cqp
+Constant QP (CQP) mode
+@item vbr
+Variable Bit Rate (VBR) mode
+@end table
+
+@item qp
+Initial quantization parameter for the intra pictures used when
+@option{rc} is cqp mode. The range is from @var{0-51}. Default is 32.
+
+@item sc_detection
+Enables or disables the scene change detection algorithm. Default is 0 
(disable).
+
+@item tune
+Set quality tuning mode. Can assume one of the following possible values:
+
+Default is 1 (oq).
+
+@table @samp
+@item sq
+Visually optimized mode
+@item oq
+PSNR / SSIM optimized mode
+@item vmaf
+VMAF optimized mode
+@end table
+
+@item bl_mode
+Enables or disables Random Access Prediction. Default is 0 (disable).
+@end table
+
+@item hdr
+High dynamic range input. Default is 0 (disable).
+@end table
+
 @section libtheora
 
 libtheora Theora encoder wrapper.
diff --git a/doc/general.texi b/doc/general.texi
index fe94c40..f90e188 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -234,6 +234,14 @@ FFmpeg can use the OpenJPEG libraries for 
decoding/encoding J2K videos.  Go to
 instructions.  To enable using OpenJPEG in FFmpeg, pass 
@code{--enable-libopenjpeg} to
 @file{./configure}.
 
+@section Scalable Video Technology for HEVC
+
+FFmpeg can make use of the SVT-HEVC library for HEVC encoding.
+
+Go to @url{https://github.com/intel/SVT-HEVC.git} and follow the instructions
+for installing the library. Pass @code{--enable-libsvthevc} to configure to
+enable it.
+
 @section TwoLAME
 
 FFmpeg can make use of the TwoLAME library for MP2 encoding.
-- 

Re: [FFmpeg-devel] [PATCH v6 2/2] doc: Add libsvt_hevc encoder docs

[Sun, Jing A]

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
Thompson
Sent: Wednesday, March 6, 2019 6:19 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v6 2/2] doc: Add libsvt_hevc encoder docs

On 05/03/2019 07:43, Jing SUN wrote:
> Add docs for libsvt_hevc encoder in encoders.texi and general.texi
> 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Huang, Zhengxu 
> Signed-off-by: hassene 
> Signed-off-by: Jing SUN 
> ---
>  doc/encoders.texi | 161 
> ++
>  doc/general.texi  |   8 +++
>  2 files changed, 169 insertions(+)
> 
> diff --git a/doc/encoders.texi b/doc/encoders.texi index 
> 29625ba..64ddb2f 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1569,6 +1569,167 @@ Set maximum NAL size in bytes.
>  Allow skipping frames to hit the target bitrate if set to 1.
>  @end table
>  
> +@section libsvt_hevc
> +
> +Scalable Video Technology for HEVC encoder (SVT-HEVC encoder) wrapper.
> +
> +This encoder requires the presence of the headers and library during 
> +configuration. You need to explicitly configure the build with 
> +@code{--enable-libsvthevc}. The library is detected using 
> +@command{pkg-config}.
> +
> +For more information about the library see 
> +@url{https://github.com/intel/SVT-HEVC.git}.
> +
> +@subsection Options
> +
> +The following FFmpeg global options affect the configurations of the 
> +libsvt_hevc encoder.
> +
> +@table @option
> +@item b  (@emph{bitrate})
> +Set the bitrate (as a number of bits per second). Default is 7M.
> +
> +@item refs (@emph{ref})
> +Number of reference frames each P-frame can use. The range is from 
> @var{0-16}.
> +Default is 0(disabled).

Wouldn't 0 mean that P frames can't exist, so the whole stream must be 
intra-only?
[SUN, Jing] To be modified in v7.

> +@item g  / @option{gop_size}
> +Set the GOP size. Default is 64.

This doesn't appear to match what is set in the other patch.
[SUN, Jing] To be modified in v7.

> +
> +@item flags +cgop
> +Enable closed GOP.
> +
> +@item qmin (@emph{min-q})
> +Defaults 10
> +
> +@item qmax (@emph{max-q})
> +Defaults 48
> +
> +Set minimum/maximum quantisation values.  Valid range is from 0 to 51 
> +(Only used when bit rate control mode @option{rc} is set to 0(cqp) mode.
> +Has to be qmax > = qmin).

In the other patch you only set them in VBR mode, not CQP mode.
[SUN, Jing] To be modified in v7.

> +
> +@item profile (@emph{profile})
> +Set profile restrictions. Can assume one of the following possible values:
> +
> +Default is 2 (main10).
> +
> +@table @samp
> +@item main
> +main profile
> +@item main10
> +main10 profile
> +@end table
> +
> +@item level
> +
> +@option{profile} sets the value of @emph{profile_idc} and the 
> @emph{constraint_set*_flag}s.
> +@option{level} sets the value of @emph{level_idc}.

The syntax elements named here exist only in H.264, not H.265.
[SUN, Jing] To be modified in v7.

> +
> +The encoder also has its own specific options:
> +
> +@table @option
> +@item vui
> +Enables or disables the vui structure in the HEVC elementary 
> +bitstream. 0 = Off, 1 = On. Default is 0 (Off).
> +
> +@item aud (@emph{aud})
> +Enable use of access unit delimiters when set to 1. Default is 0 (Off).
> +
> +@item hielevel
> +Set hierarchical levels. Can assume one of the following possible values:
> +
> +Default is 3 (4level).
> +
> +@table @samp
> +@item flat
> +none hierarchy level
> +@item 2level
> +2-level hierarchy
> +@item 3level
> +3-level hierarchy
> +@item 4level
> +4-level hierarchy
> +@end table
> +
> +@item la_depth
> +Set look-ahead depth, depending on bit rate control mode @option{rc}, 
> +when bit rate control mode is set to vbr it's best to set this 
> +parameter to be equal to the intra period value (such is the default 
> +set by the encoder), when cqp is chosen, then a look ahead is recommended. 
> The range is from @var{0-256}.
> +
> +@item intra_ref_type
> +Set intra refesh type. Can assume one of the following possible values:
> +
> +Default is 2 (idr).
> +
> +@table @samp
> +@item cra
> +open group of pictures
> +@item idr
> +closed group of pictures
> +@end table

This option doesn't exist in the other patch.
[SUN, Jing] To be modified in v7.

> +
> +@item preset
> +A preset defining the quality vs density tradeoff point that the 
> +encoding is to be performed at.(e.g. 0 is the highest quality mode,
> +12 is the highest density mode). The range is from @var{0-12}. Default is 9.
> +
> +@item tier
> +Set @emph{general_tier_flag}.  This may affect the level chosen for 
> +the stream if it is not explicitly specified. Can assume one of the 
> following possible values:
> +
> +Default is 1 (main).
> +
> +@table @samp
> +@item main
> +main tier
> +@item high
> +high tier
> +@end table
> +
> +@item rc
> +Set bit rate control mode. Can assume one of the following possible values:
> +
> +Default is 0 (cqp).
> +
> +@table @samp
> +@item cqp
> +Constant QP (CQP) mode