Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

[Werner Robitza]

On Wed, Feb 20, 2019 at 11:36 PM Carl Eugen Hoyos  wrote:
>
> 2019-02-20 20:56 GMT+01:00, Lou Logan :
> > On Wed, Feb 6, 2019, at 11:48 AM, Werner Robitza wrote:
> >>
> >> I propose that FFmpeg maintains its own ffmpeg formula under its
> >> GitHub organization at github.com/ffmpeg/homebrew-ffmpeg (or similar).
> >> This will ensure that there's one formula users will discover when
> >> they look for an alternative tap, thus improving discoverability and
> >> avoiding fragmentation. We could use the above link as a starting
> >> point.
> >
> > The alternative tap originally proposed by Werner went ahead independently
> > and has been implemented at:
> > https://github.com/varenc/homebrew-ffmpeg
>
> Great!
> Should we add this link to the download page?

I'd wait until we have a proper CI pipeline in place. Right now we're
testing manually. I wouldn't want to directly link to a build script
that has not fully been automatically tested on macOS/Linux. Once that
is done, I'll provide a patch to add the link.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT

[Hendrik Leppkes]

On Thu, Feb 21, 2019 at 3:28 PM Carl Eugen Hoyos  wrote:
>
> 2019-02-21 10:40 GMT+01:00, Hendrik Leppkes :
>
> > https://files.1f0.de/samples/incredibles2-truehd-bitstreaming.thd
> > (TrueHD stream)
> > https://files.1f0.de/samples/incredibles2-truehd-bitstreaming.pcm.xz
> > (bitstreaming output, xz compressed)
>
> 404 =-(
>

Sorry about that, fixed the files, should work now.

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

Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT

[Carl Eugen Hoyos]

2019-02-21 10:40 GMT+01:00, Hendrik Leppkes :

> https://files.1f0.de/samples/incredibles2-truehd-bitstreaming.thd
> (TrueHD stream)
> https://files.1f0.de/samples/incredibles2-truehd-bitstreaming.pcm.xz
> (bitstreaming output, xz compressed)

404 =-(

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

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Carl Eugen Hoyos]

2019-02-21 11:26 GMT+01:00, Tomas Härdin :
> ons 2019-02-20 klockan 23:33 +0100 skrev Carl Eugen Hoyos:
>> > 2019-02-10 16:42 GMT+01:00, Tomas Härdin :
>> > lör 2019-02-09 klockan 13:10 + skrev Matthew Fearnley:
>> > > - Improve block choices by counting 0-bytes in the entropy score
>> > > - Make histogram use uint16_t type, to allow byte counts from 16*16
>> > > (current block size) up to 255*255 (maximum allowed 8bpp block size)
>> > > - Make sure score table is big enough for a full block's worth of
>> > > bytes
>> > > - Calculate *xored without using code in inner loop
>> > > ---
>> > >  libavcodec/zmbvenc.c | 22 --
>> > >  1 file changed, 16 insertions(+), 6 deletions(-)
>> >
>> > Passes FATE, looks good to me
>>
>> I believe you asked on irc about fate tests:
>> Since such a test would depend on the zlib version, you cannot test
>> exact output, you could only test a round-trip (assuming the codec
>> really is lossless).
>
> Right, we'd need to embed a specific version of zlib. But we probably
> don't want to do that, for many reasons.
>
> A dummy DEFLATE implementation that just passes the bytes along could
> be useful. I know there's a mode in the DEFLATE format for blocks that
> fail to compress. That way we could test many encoders that depend on
> zlib, and their output should decode just fine.

What's wrong with a round-trip test?

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

Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT

[Carl Eugen Hoyos]

2019-02-21 15:28 GMT+01:00, Carl Eugen Hoyos :
> 2019-02-21 10:40 GMT+01:00, Hendrik Leppkes :
>
>> https://files.1f0.de/samples/incredibles2-truehd-bitstreaming.thd
>> (TrueHD stream)
>> https://files.1f0.de/samples/incredibles2-truehd-bitstreaming.pcm.xz
>> (bitstreaming output, xz compressed)
>
> 404 =-(

Works fine with the browser, what's wrong with wget?

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

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Carl Eugen Hoyos]

2019-02-21 15:08 GMT+01:00, Matthew Fearnley :

> The question would still remain though, of the best way to incorporate it
> into FFMEG.  That's probably beyond my current knowledge..

It belongs in libavutil, see also the unfinished inflate implementation:
https://github.com/michaelni/FFmpeg/tree/inflate

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

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Matthew Fearnley]

On Thu, 21 Feb 2019 at 10:26, Tomas Härdin  wrote:

> ons 2019-02-20 klockan 23:33 +0100 skrev Carl Eugen Hoyos:
> > > 2019-02-10 16:42 GMT+01:00, Tomas Härdin :
> > > lör 2019-02-09 klockan 13:10 + skrev Matthew Fearnley:
> > > > - Improve block choices by counting 0-bytes in the entropy score
> > > > - Make histogram use uint16_t type, to allow byte counts from 16*16
> > > > (current block size) up to 255*255 (maximum allowed 8bpp block size)
> > > > - Make sure score table is big enough for a full block's worth of
> bytes
> > > > - Calculate *xored without using code in inner loop
> > > > ---
> > > >  libavcodec/zmbvenc.c | 22 --
> > > >  1 file changed, 16 insertions(+), 6 deletions(-)
> > >
> > > Passes FATE, looks good to me
> >
> > I believe you asked on irc about fate tests:
> > Since such a test would depend on the zlib version, you cannot test
> > exact output, you could only test a round-trip (assuming the codec
> > really is lossless).
>
> Right, we'd need to embed a specific version of zlib. But we probably
> don't want to do that, for many reasons.
>
> A dummy DEFLATE implementation that just passes the bytes along could
> be useful. I know there's a mode in the DEFLATE format for blocks that
> fail to compress. That way we could test many encoders that depend on
> zlib, and their output should decode just fine.
>

I know the DEFLATE format fairly well, and a dummy DEFLATE implementation
would certainly be possible.

An uncompressed block can be up to 65535 bytes, and has a simple five-byte
header (subject to some bit alignment issues, but they only come into play
when other block types are also used).

Here's a simple code example, the guts of which fit into <70 lines:
https://gist.github.com/countingpine/602453d330ea055a4bcab90ca2a7ed02

It allows data to be compressed in chunks, allowing a stream to be split
across frames, like in ZMBV.
The first chunk needs the START flag, and the last chunk (if any) needs the
FINISH flag.

It also allows adding an Adler32 checksum - although ZMBV itself doesn't
need this, because it never "finishes" the stream.

The question would still remain though, of the best way to incorporate it
into FFMEG.  That's probably beyond my current knowledge..

Matthew


/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

Re: [FFmpeg-devel] [PATCH] fix trac ticket #7359

[Daniel Oberhoff]

Bump,


Is there any interest in applying this patch? The brokenness of -ss on
hls/ts has caused and keeps on causing us lots of headaches...


Best


Daniel Oberhoff

GameOn Technologies



pEpkey.asc
Description: application/pgp-keys
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Thursday, February 21, 2019 8:26 AM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH v2 3/6] lavc/qsvdec: Replace current
> parser with MFXVideoDECODE_DecodeHeader()
> 
> 2019-02-20 3:58 GMT+01:00, Zhong Li :
> 
> > And it is necessary for adding new qsv decoders such as MJPEG and VP9
> > since current parser can't provide enough information.
> 
> Just curious: What information is missing?
> 
> Carl Eugen

To init MSDK decoder, width/height/pix_fmt/picture_struct/level/profile are 
needed.
But currently, mjpeg_parser.c provides nothing of them. VP9 also provides very 
few information. 

If we want to further discussion about adding the missing information, probably 
we can continue in Mark's thread.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Li, Zhong]

> From: Rogozhkin, Dmitry V
> Sent: Thursday, February 21, 2019 3:14 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: Re: [FFmpeg-devel] [PATCH v2 3/6] lavc/qsvdec: Replace current
> parser with MFXVideoDECODE_DecodeHeader()
> 
> On Wed, 2019-02-20 at 10:58 +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 +
> >  2 files changed, 90 insertions(+), 84 deletions(-)
> >
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> > 4a0be811fb..efe054f5c5 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -120,19 +120,18 @@ 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;
> > +} else
> > +q->orig_pix_fmt = pix_fmts[1];
> 
> You rely on the way how pix_fmts will be declared in some other place.
> This gives issues to understand the code for the beginners and hence
> difficulty in code support. Can we somehow show what is actually going on
> here? For example, declare pix_fmts something like:
> enum qsv_formats {
>   QSV,
>   QSV_NV12,
>   QSV_MAX
> }
> 
> enum AVPixelFormat pix_fmts[QSV_MAX+1] = {
>   [QSV] = AV_PIX_FMT_QSV,
>   [QSV_NV12] = AV_PIX_FMT_NV12,
>   [QSV_MAX] = AV_PIX_FMT_NONE
> }
> 
> After that we could address like:
> q->orig_pix_fmt = pix_fmts[QSV_NV12]; both highlighting what
> we actually want to achieve and making sure that we will have less mistakes
> supporting the list of fmts wish we reorder something.

QSV sw_pix_fmt is not always NV12. For 10bit clips, we just assume it is NV12, 
after decoder_header called, it will be updated as P010.

> >
> >  if (!q->async_fifo) {
> >  q->async_fifo = av_fifo_alloc(q->async_depth *
> > qsv_fifo_item_size()); @@ -170,48 +169,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;
> > -

Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT

[Hendrik Leppkes]

On Fri, Feb 15, 2019 at 1:13 AM Carl Eugen Hoyos  wrote:
>
> > - The distance between frames can be incredibly large in some streams,
> > I've seen it be larger then one whole MAT frame, and the output works
> > reliably (MAT start/middle/end codes need to be placed within the
> > padding space, of course).
>
> That is not supported yet, could you provide such a problematic sample?
> (Including the output if possible)
>

I didn't want to cut it too badly, since that can disrupt how it
works, so its a bit sizeable (the bitrate is also quite high), its the
first ~4 minutes from the start of the Incredibles 2 UHD Blu-ray

https://files.1f0.de/samples/incredibles2-truehd-bitstreaming.thd
(TrueHD stream)
https://files.1f0.de/samples/incredibles2-truehd-bitstreaming.pcm.xz
(bitstreaming output, xz compressed)

There should be a few occurances of this particular case, its the same
stream I used to look into these problems in the first place after it
was reported to me by users.

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

Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added

[Nicolas George]

Uwe Freese (12019-01-25):
> may I ask again what the next step is to integrate my delogo patch?
> 
> It was some effort to change the implementation in the way as discussed here
> and I really would like that the patch is finally added to the repository.
> 
> Are there any problems, questions, or other points blocking it?
> 
> Please let me know, or please find some time to submit the patch to the repo
> (which I can't do). As already written, I'd continue with the discussed
> indentation patch right after that.

I am sorry, I do not have time to work on this personally. I made a
short review earlier because I had more time. I may have time to look at
it later, it still seems useful, but I cannot make any promise.

Also, I might add that an important prerequisite for working with this
project is to respect all its conventions, including the one about
top-posting.

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, RFC] lavf/deinterlace_qsv: set TFF or BFF together with progressive

[Li, Zhong]

> > > Currently, BFF or TFF will not be set if the frame is progressive.
> > > This will break the Input PicStruct check in MSDK because of absence
> > > of the specific PicStruct check for:
> > > MFX_PICSTRUCT_PROGRESSIVE | MFX_PICSTRUCT_FIELD_REPEATED
> > >
> > > Set PicStruct to MFX_PICSTRUCT_FIELD_TFF or
> > MFX_PICSTRUCT_FIELD_BFF
> > > to match the CheckInputPicStruct in MSDK.
> > >
> > > Fix #7701.
> >
> > After checking this ticket, I believe this is not a MSDK issue, and
> > current fix in this patch is not correct.
> > If I understand correctly, this issue only happens when H264
> > pic_struct = 5 or 6.
> > In this case, MFX_PICSTRUCT_FIELD_TFF or MFX_PICSTRUCT_FIELD_BFF
> > should be set, else we don't know which filed should be repeated.
> >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > > Is it acceptable to add the TFF or BFF to PicStruct according to the
> > > attribute of the input frames, even if it's not interlaced?
> > > Or it should be fixed in MSDK level to support more PicStruct?
> > >
> > >  libavfilter/vf_deinterlace_qsv.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_deinterlace_qsv.c
> > b/libavfilter/vf_deinterlace_qsv.c
> > > index d6b02e98c5..f03d65f029 100644
> > > --- a/libavfilter/vf_deinterlace_qsv.c
> > > +++ b/libavfilter/vf_deinterlace_qsv.c
> > > @@ -417,8 +417,9 @@ static int submit_frame(AVFilterContext *ctx,
> > > AVFrame *frame,
> > >  qf->surface.Info.CropH  = qf->frame->height;
> > >
> > >  qf->surface.Info.PicStruct = !qf->frame->interlaced_frame ?
> > > MFX_PICSTRUCT_PROGRESSIVE :
> > > - (qf->frame->top_field_first ?
> > > MFX_PICSTRUCT_FIELD_TFF :
> > > -
> > > MFX_PICSTRUCT_FIELD_BFF);
> > > +
> > > MFX_PICSTRUCT_UNKNOWN;
> > > +qf->surface.Info.PicStruct |= qf->frame->top_field_first ?
> > > MFX_PICSTRUCT_FIELD_TFF :
> > > +
> > > + MFX_PICSTRUCT_FIELD_BFF;
> > >  if (qf->frame->repeat_pict == 1)
> > >  qf->surface.Info.PicStruct |=
> MFX_PICSTRUCT_FIELD_REPEATED;
> >
> > I believe the correct fix should be here (previous code change is not
> > needed and should be removed):
> > if (qf->frame->repeat_pict == 1) {
> >   qf->surface.Info.PicStruct |= MFX_PICSTRUCT_FIELD_REPEATED;
> >   qf->surface.Info.PicStruct |= qf->frame->top_field_first ?
> > MFX_PICSTRUCT_FIELD_TFF : MFX_PICSTRUCT_FIELD_BFF; }
> >
> > >  else if (qf->frame->repeat_pict == 2)
> 
> Thanks, it seems more reasonable in the repeated_first_field cases in #7701.
> 
> But I still have concerns:
> Progressive| TFF or Progressive | BFF frames will never be set after the
> modification.
> 
> A discussion on " Is progresive TFF or BFF in mpeg2" :
> https://forum.doom9.org/showthread.php?t=165176
> 
> I think it is a more common way to suit all probable cases (not only in
> #7701):
> Allow FFmpeg qsv to set all attributes got from each frame, and pass down
> to MSDK/driver.
> It depends on MSDK/driver to decide whether the TFF and BFF flag is valid
> and useful in progressive mode.
> 
> --
> Linjie

top_field_first is meaningless as ffmpeg decoder documentation and AVFrame 
comments. 
Thus means probably you are change MFX_PICSTRUCT_PROGRESSIVE to 
MFX_PICSTRUCT_PROGRESSIVE| MFX_PICSTRUCT_FIELD_BFF for all cases, is it as 
expectation? 

For MFX_PICSTRUCT_FIELD_REPEATED case, it is a different story, you must tell 
which filed should be repeated.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Tomas Härdin]

ons 2019-02-20 klockan 22:12 +0100 skrev Michael Niedermayer:
> On Sat, Feb 09, 2019 at 01:10:20PM +, Matthew Fearnley wrote:
> > - Improve block choices by counting 0-bytes in the entropy score
> > - Make histogram use uint16_t type, to allow byte counts from 16*16
> > (current block size) up to 255*255 (maximum allowed 8bpp block size)
> > - Make sure score table is big enough for a full block's worth of bytes
> > - Calculate *xored without using code in inner loop
> 
> This should have been split into multiple changes

Alas

> compression seems to become slightly worse from this change
> 
> ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y test-old.avi
> ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y test-new.avi
> 
> -rw-r- 1 michael michael 1175466 Feb 20 22:06 test-new.avi
> -rw-r- 1 michael michael 1174832 Feb 20 22:07 test-old.avi

A whopping 0.05% change, with an MPEG source rather than the intended
PAL8..

The flip side here is that we can now use larger block sizes and higher
me_range without crashing the encoder. We can add a slower mode that
tests a few different block sizes to see which one results in the
smallest output.

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

[FFmpeg-devel] [PATCH] ffmpeg_filter: initialize sub2video.end_pts together with last_pts

[Jan Ekström]

This fixes buffering of samples which causes sudden ballooning of
memory usage in case of no subtitle samples coming in for a while if
the filter chain had been re-initialized.

You can also see messages a la:
"Error while add the frame to buffer source(Invalid argument)."
disappearing after filter chain re-initializations.

Passes fate-sub2video.

Example (memory usage before patch around 700+ MiB, after around 150MiB) :
/usr/bin/time -v ffmpeg -v verbose \
  -i 
"https://megumin.fushizen.eu/samples/2019-01-18-audio_reconfig_causes_buffer_growth.ts;
\
  -filter_complex
'[0:v:0]yadif=deint=interlaced[yadif_out];[yadif_out][0:s:0]overlay=eof_action=pass:repeatlast=0[overlay_out];[overlay_out]scale=1024:-2[video_out];[0:a:0]aresample=48000:async=1,aformat=channel_layouts=stereo[filtered_audio]'
\
  -map "[video_out]" \
-c:v mpeg4 \
-b:v 750k \
  -map "[filtered_audio]" \
-c:a aac \
-b:a 192k \
  "test.mp4"

Best regards,
Jan
From 9c824c36c972aca19f2747437c8edc71b6c0886c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20Ekstr=C3=B6m?= 
Date: Thu, 20 Feb 2019 20:54:11 +0200
Subject: [PATCH] ffmpeg_filter: initialize sub2video.end_pts together with
 last_pts

This way re-initializations properly update end_pts, enabling
sub2video_heartbeat to call sub2video_update as expected to re-init
the sub2video AVFrame's contents and to feed a frame into the filter
chain.

This then fixes memory usage ballooning due to framesync waiting
for secondary input in case of no actual subtitle samples being present
for a while in source after a re-init occurs.
---
 fftools/ffmpeg_filter.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 8c0ff99dd9..72838de1e2 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -739,6 +739,7 @@ static int sub2video_prepare(InputStream *ist, InputFilter *ifilter)
 if (!ist->sub2video.frame)
 return AVERROR(ENOMEM);
 ist->sub2video.last_pts = INT64_MIN;
+ist->sub2video.end_pts  = INT64_MIN;
 return 0;
 }
 
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Tomas Härdin]

ons 2019-02-20 klockan 23:33 +0100 skrev Carl Eugen Hoyos:
> > 2019-02-10 16:42 GMT+01:00, Tomas Härdin :
> > lör 2019-02-09 klockan 13:10 + skrev Matthew Fearnley:
> > > - Improve block choices by counting 0-bytes in the entropy score
> > > - Make histogram use uint16_t type, to allow byte counts from 16*16
> > > (current block size) up to 255*255 (maximum allowed 8bpp block size)
> > > - Make sure score table is big enough for a full block's worth of bytes
> > > - Calculate *xored without using code in inner loop
> > > ---
> > >  libavcodec/zmbvenc.c | 22 --
> > >  1 file changed, 16 insertions(+), 6 deletions(-)
> > 
> > Passes FATE, looks good to me
> 
> I believe you asked on irc about fate tests:
> Since such a test would depend on the zlib version, you cannot test
> exact output, you could only test a round-trip (assuming the codec
> really is lossless).

Right, we'd need to embed a specific version of zlib. But we probably
don't want to do that, for many reasons.

A dummy DEFLATE implementation that just passes the bytes along could
be useful. I know there's a mode in the DEFLATE format for blocks that
fail to compress. That way we could test many encoders that depend on
zlib, and their output should decode just fine.

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

Re: [FFmpeg-devel] [PATCH] ffmpeg_filter: initialize sub2video.end_pts together with last_pts

[Nicolas George]

Jan Ekström (12019-02-21):
> This fixes buffering of samples which causes sudden ballooning of
> memory usage in case of no subtitle samples coming in for a while if
> the filter chain had been re-initialized.
> 
> You can also see messages a la:
> "Error while add the frame to buffer source(Invalid argument)."
> disappearing after filter chain re-initializations.
> 
> Passes fate-sub2video.
> 
> Example (memory usage before patch around 700+ MiB, after around 150MiB) :
> /usr/bin/time -v ffmpeg -v verbose \
>   -i 
> "https://megumin.fushizen.eu/samples/2019-01-18-audio_reconfig_causes_buffer_growth.ts;
> \
>   -filter_complex
> '[0:v:0]yadif=deint=interlaced[yadif_out];[yadif_out][0:s:0]overlay=eof_action=pass:repeatlast=0[overlay_out];[overlay_out]scale=1024:-2[video_out];[0:a:0]aresample=48000:async=1,aformat=channel_layouts=stereo[filtered_audio]'
> \
>   -map "[video_out]" \
> -c:v mpeg4 \
> -b:v 750k \
>   -map "[filtered_audio]" \
> -c:a aac \
> -b:a 192k \
>   "test.mp4"

Looks good, thanks.

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 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Tomas Härdin]

tor 2019-02-21 klockan 11:26 +0100 skrev Tomas Härdin:
> ons 2019-02-20 klockan 23:33 +0100 skrev Carl Eugen Hoyos:
> > > > > > 2019-02-10 16:42 GMT+01:00, Tomas Härdin :
> > > lör 2019-02-09 klockan 13:10 + skrev Matthew Fearnley:
> > > > - Improve block choices by counting 0-bytes in the entropy score
> > > > - Make histogram use uint16_t type, to allow byte counts from 16*16
> > > > (current block size) up to 255*255 (maximum allowed 8bpp block size)
> > > > - Make sure score table is big enough for a full block's worth of bytes
> > > > - Calculate *xored without using code in inner loop
> > > > ---
> > > >  libavcodec/zmbvenc.c | 22 --
> > > >  1 file changed, 16 insertions(+), 6 deletions(-)
> > > 
> > > Passes FATE, looks good to me
> > 
> > I believe you asked on irc about fate tests:
> > Since such a test would depend on the zlib version, you cannot test
> > exact output, you could only test a round-trip (assuming the codec
> > really is lossless).
> 
> Right, we'd need to embed a specific version of zlib. But we probably
> don't want to do that, for many reasons.
> 
> A dummy DEFLATE implementation that just passes the bytes along could
> be useful. I know there's a mode in the DEFLATE format for blocks that
> fail to compress. That way we could test many encoders that depend on
> zlib, and their output should decode just fine.

.. or just -compression_level 0 upon further inspection. Not likely to
change between zlib version, but of course not guaranteed not to

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

Re: [FFmpeg-devel] [PATCH] avcodec/jvdec: Check available input space before decode8x8()

[Paul B Mahol]

On 2/21/19, Michael Niedermayer  wrote:
> Fixes: Timeout (78 sec -> 15 millisec)
> Fixes:
> 13147/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JV_fuzzer-5727107827630080
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/jvdec.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/jvdec.c b/libavcodec/jvdec.c
> index cbe83d3c10..bf8a55cbad 100644
> --- a/libavcodec/jvdec.c
> +++ b/libavcodec/jvdec.c
> @@ -170,6 +170,11 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
>  GetBitContext gb;
>  init_get_bits(, buf, 8 * video_size);
>
> +if ( avctx->height/8 * (avctx->width/8) > 4 * video_size) {
> +av_log(avctx, AV_LOG_ERROR, "Insuffient input data for
> dimensions\n");

Typo

> +return AVERROR_INVALIDDATA;
> +}
> +
>  for (j = 0; j < avctx->height; j += 8)
>  for (i = 0; i < avctx->width; i += 8)
>  decode8x8(,
> --
> 2.20.1
>
> ___
> 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/jvdec: Check available input space before decode8x8()

[Michael Niedermayer]

Fixes: Timeout (78 sec -> 15 millisec)
Fixes: 
13147/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JV_fuzzer-5727107827630080

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/jvdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/jvdec.c b/libavcodec/jvdec.c
index cbe83d3c10..bf8a55cbad 100644
--- a/libavcodec/jvdec.c
+++ b/libavcodec/jvdec.c
@@ -170,6 +170,11 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 GetBitContext gb;
 init_get_bits(, buf, 8 * video_size);
 
+if ( avctx->height/8 * (avctx->width/8) > 4 * video_size) {
+av_log(avctx, AV_LOG_ERROR, "Insuffient input data for 
dimensions\n");
+return AVERROR_INVALIDDATA;
+}
+
 for (j = 0; j < avctx->height; j += 8)
 for (i = 0; i < avctx->width; i += 8)
 decode8x8(,
-- 
2.20.1

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

[FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] mmi optimizations for VP9 put and avg functions

[gxw]

VP9 decoding speed improved about 60.5%(from 38fps to 61fps, tested on loongson 
3A3000).
---
 libavcodec/mips/Makefile   |   1 +
 libavcodec/mips/vp9_mc_mmi.c   | 692 +
 libavcodec/mips/vp9dsp_init_mips.c |  42 +++
 libavcodec/mips/vp9dsp_mips.h  |  50 +++
 libavutil/mips/mmiutils.h  |  15 +
 5 files changed, 800 insertions(+)
 create mode 100644 libavcodec/mips/vp9_mc_mmi.c

diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index c827649..c5b54d5 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -88,3 +88,4 @@ MMI-OBJS-$(CONFIG_VC1_DECODER)+= mips/vc1dsp_mmi.o
 MMI-OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_mmi.o
 MMI-OBJS-$(CONFIG_HEVC_DECODER)   += mips/hevcdsp_mmi.o
 MMI-OBJS-$(CONFIG_VP3DSP) += mips/vp3dsp_idct_mmi.o
+MMI-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_mmi.o
diff --git a/libavcodec/mips/vp9_mc_mmi.c b/libavcodec/mips/vp9_mc_mmi.c
new file mode 100644
index 000..58a920b
--- /dev/null
+++ b/libavcodec/mips/vp9_mc_mmi.c
@@ -0,0 +1,692 @@
+/*
+ * Copyright (c) 2019 gxw 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavcodec/vp9dsp.h"
+#include "libavutil/mips/mmiutils.h"
+#include "vp9dsp_mips.h"
+
+#define GET_DATA_H_MMI   \
+"pmaddhw%[ftmp4],%[ftmp4],   %[filter1]\n\t" \
+"pmaddhw%[ftmp5],%[ftmp5],   %[filter2]\n\t" \
+"paddw  %[ftmp4],%[ftmp4],   %[ftmp5]  \n\t" \
+"punpckhwd  %[ftmp5],%[ftmp4],   %[ftmp0]  \n\t" \
+"paddw  %[ftmp4],%[ftmp4],   %[ftmp5]  \n\t" \
+"pmaddhw%[ftmp6],%[ftmp6],   %[filter1]\n\t" \
+"pmaddhw%[ftmp7],%[ftmp7],   %[filter2]\n\t" \
+"paddw  %[ftmp6],%[ftmp6],   %[ftmp7]  \n\t" \
+"punpckhwd  %[ftmp7],%[ftmp6],   %[ftmp0]  \n\t" \
+"paddw  %[ftmp6],%[ftmp6],   %[ftmp7]  \n\t" \
+"punpcklwd  %[srcl], %[ftmp4],   %[ftmp6]  \n\t" \
+"pmaddhw%[ftmp8],%[ftmp8],   %[filter1]\n\t" \
+"pmaddhw%[ftmp9],%[ftmp9],   %[filter2]\n\t" \
+"paddw  %[ftmp8],%[ftmp8],   %[ftmp9]  \n\t" \
+"punpckhwd  %[ftmp9],%[ftmp8],   %[ftmp0]  \n\t" \
+"paddw  %[ftmp8],%[ftmp8],   %[ftmp9]  \n\t" \
+"pmaddhw%[ftmp10],   %[ftmp10],  %[filter1]\n\t" \
+"pmaddhw%[ftmp11],   %[ftmp11],  %[filter2]\n\t" \
+"paddw  %[ftmp10],   %[ftmp10],  %[ftmp11] \n\t" \
+"punpckhwd  %[ftmp11],   %[ftmp10],  %[ftmp0]  \n\t" \
+"paddw  %[ftmp10],   %[ftmp10],  %[ftmp11] \n\t" \
+"punpcklwd  %[srch], %[ftmp8],   %[ftmp10] \n\t"
+
+#define GET_DATA_V_MMI   \
+"punpcklhw  %[srcl], %[ftmp4],   %[ftmp5]  \n\t" \
+"pmaddhw%[srcl], %[srcl],%[filter10]   \n\t" \
+"punpcklhw  %[ftmp12],   %[ftmp6],   %[ftmp7]  \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter32]   \n\t" \
+"paddw  %[srcl], %[srcl],%[ftmp12] \n\t" \
+"punpcklhw  %[ftmp12],   %[ftmp8],   %[ftmp9]  \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter54]   \n\t" \
+"paddw  %[srcl], %[srcl],%[ftmp12] \n\t" \
+"punpcklhw  %[ftmp12],   %[ftmp10],  %[ftmp11] \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter76]   \n\t" \
+"paddw  %[srcl], %[srcl],%[ftmp12] \n\t" \
+"punpckhhw  %[srch], %[ftmp4],   %[ftmp5]  \n\t" \
+"pmaddhw%[srch], %[srch],%[filter10]   \n\t" \
+"punpckhhw  %[ftmp12],   %[ftmp6],   %[ftmp7]  \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter32]   \n\t" \
+"paddw  %[srch], %[srch],%[ftmp12] \n\t" \
+"punpckhhw  %[ftmp12],   %[ftmp8],   %[ftmp9]  \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter54]   \n\t" \
+"paddw  %[srch], %[srch],%[ftmp12] \n\t" \
+"punpckhhw  %[ftmp12],   %[ftmp10],  %[ftmp11] \n\t" \
+"pmaddhw%[ftmp12],   %[ftmp12],  %[filter76]   \n\t" \
+"paddw  %[srch], %[srch],%[ftmp12] \n\t"
+
+static void 

Re: [FFmpeg-devel] [PATCH] ffmpeg_filter: initialize sub2video.end_pts together with last_pts

[Jan Ekström]

On Thu, Feb 21, 2019 at 1:30 PM Nicolas George  wrote:
>
> Jan Ekström (12019-02-21):
> > This fixes buffering of samples which causes sudden ballooning of
> > memory usage in case of no subtitle samples coming in for a while if
> > the filter chain had been re-initialized.
> >
> > You can also see messages a la:
> > "Error while add the frame to buffer source(Invalid argument)."
> > disappearing after filter chain re-initializations.
> >
> > Passes fate-sub2video.
> >
> > Example (memory usage before patch around 700+ MiB, after around 150MiB) :
> > /usr/bin/time -v ffmpeg -v verbose \
> >   -i 
> > "https://megumin.fushizen.eu/samples/2019-01-18-audio_reconfig_causes_buffer_growth.ts;
> > \
> >   -filter_complex
> > '[0:v:0]yadif=deint=interlaced[yadif_out];[yadif_out][0:s:0]overlay=eof_action=pass:repeatlast=0[overlay_out];[overlay_out]scale=1024:-2[video_out];[0:a:0]aresample=48000:async=1,aformat=channel_layouts=stereo[filtered_audio]'
> > \
> >   -map "[video_out]" \
> > -c:v mpeg4 \
> > -b:v 750k \
> >   -map "[filtered_audio]" \
> > -c:a aac \
> > -b:a 192k \
> >   "test.mp4"
>
> Looks good, thanks.
>
> Regards,

Applied. Thanks for the review.

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

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Matthew Fearnley]

On Thu, 21 Feb 2019 at 19:28, Michael Niedermayer 
wrote:

> On Thu, Feb 21, 2019 at 11:19:08AM +0100, Tomas Härdin wrote:
> > ons 2019-02-20 klockan 22:12 +0100 skrev Michael Niedermayer:
> > > On Sat, Feb 09, 2019 at 01:10:20PM +, Matthew Fearnley wrote:
> > > > - Improve block choices by counting 0-bytes in the entropy score
> > > > - Make histogram use uint16_t type, to allow byte counts from 16*16
> > > > (current block size) up to 255*255 (maximum allowed 8bpp block size)
> > > > - Make sure score table is big enough for a full block's worth of
> bytes
> > > > - Calculate *xored without using code in inner loop
> > >
> > > This should have been split into multiple changes
> >
> > Alas
> >
>
> > > compression seems to become slightly worse from this change
> > >
> > > ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y
> test-old.avi
> > > ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y
> test-new.avi
> > >
> > > -rw-r- 1 michael michael 1175466 Feb 20 22:06 test-new.avi
> > > -rw-r- 1 michael michael 1174832 Feb 20 22:07 test-old.avi
> >
> > A whopping 0.05% change,
>
> no its just a tiny difference but i think it still would make sense to
> understand it.
> Generally a patch doing 4 improvments would be expected to improve things.
> This was not a hand picked case. I mean its not as if I saw 10 cases
> improving things and i picked the 11th. i looked at one case and that was
> worse
>
> Also either way the patch should have been split, dont you agree ?
> it also would make it much easier to within seconds identify which
> change actually caused the 0.05% difference. (maybe avoiding this
> discussion as it maybe would be obvious from that if this is a
> ommision in the commit message a bug a rare outlier ...)
>
> Hi Michael.  First, let me say thanks for your feedback on this patch.
Let me address some of this..

- Yes: in retrospect, I think I should have split the patch.
I struggled here to work out how to split up my changes, and spent too long
staring too closely at the code to see this.
I still perhaps have some way to go before I would be able to get a proper
feel for the general FFmpeg development ecosystem.

- To clear up the effects: the change from 'i=1' to 'i=0' was the only
change that should make any difference in the output.
The rest of the changes were to improve the speed of an inner loop, and to
fix two bugs that happily cancelled each other out, but would have broken
if the code were changed to emit larger blocks.  These should not lead to
changes in the blocks chosen or the final compression size.

- Regarding the worse compression: let me start by stating that scoring on
byte frequency alone will not always predict well how Deflate will work,
since Deflate also uses pattern matching as well.
Frequency-based block scoring will only ever be a heuristic.  There may be
scope for improving the scoring, but it would add a lot of complexity, and
I think it would be easy to make things worse rather than better.  (I found
this in my brief experiments with including the frequencies from the
previous block.)

I think the main thing that persuaded me to make this particular change
from 1 to 0 was that it gave a pure entropy-based score, and allowed me,
mathematically, to use the same scoring table on both full and partial
blocks, without having to worry about the effects of omitting the 0-bytes
in the score in each case.

I focused my testing on the available ZMBV samples, which were likely all
generated by DOSBox, and my findings were that while not all movies were
smaller, overall the gains outweighed the losses.
I'm slightly sad to hear it didn't improve this real-world movie sample.
But I think this level in this case is acceptable, and not outside the
expected range of size difference that I've seen.  And the improvements to
the motion estimation range (from the other patch) should tend to lead to a
compression improvement overall.

Maybe I should have been clearer though, that the scoring changes won't
bring universal improvements.  And if someone looks into this and finds on
average results are worsened by the change, I won't complain if it gets
reverted.

Thanks for your feedback, I appreciate it.
Matthew


> > with an MPEG source rather than the intended
> > PAL8..
>
> The input to the encoder is always PAL8. so i assume you mean
> "old computer game material" vs. "realistic video".
>
>
> >
> > The flip side here is that we can now use larger block sizes and higher
> > me_range without crashing the encoder. We can add a slower mode that
> > tests a few different block sizes to see which one results in the
> > smallest output.
> >
> > /Tomas
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Complexity theory is the science of finding the exact 

Re: [FFmpeg-devel] [PATCHv2 3/3] avformat/mpegtsenc: add support for service and provider names with utf8 encoding

[Marton Balint]

On Tue, 19 Feb 2019, Marton Balint wrote:




On Tue, 12 Feb 2019, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
libavformat/mpegtsenc.c | 88 

+

1 file changed, 53 insertions(+), 35 deletions(-)


Ping, will push soon.



Pushed.

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

[FFmpeg-devel] [PATCH 0/1] avformat/dashenc: Added #EXT-X-PROGRAM-DATE-TIME to HLS playlists

[joepadmiraal]

This patch adds the #EXT-X-PROGRAM-DATE-TIME tag to HLS playlists when using 
the Dash muxer.

joepadmiraal (1):
  avformat/dashenc: Added #EXT-X-PROGRAM-DATE-TIME to HLS playlists

 libavformat/dashenc.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

-- 
2.17.0

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

[FFmpeg-devel] [PATCH 1/1] avformat/dashenc: Added #EXT-X-PROGRAM-DATE-TIME to HLS playlists

[joepadmiraal]

From: joepadmiraal 

---
 libavformat/dashenc.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 37a7547b12..d0d0d6f030 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -122,6 +122,7 @@ typedef struct DASHContext {
 int64_t last_duration;
 int64_t total_duration;
 char availability_start_time[100];
+int64_t start_time_ms;
 char dirname[1024];
 const char *single_file_name;  /* file names as specified in options */
 const char *init_seg_name;
@@ -432,6 +433,8 @@ static void write_hls_media_playlist(OutputStream *os, 
AVFormatContext *s,
 const char *proto = avio_find_protocol_name(c->dirname);
 int use_rename = proto && !strcmp(proto, "file");
 int i, start_index, start_number;
+time_t start_time_s = c->start_time_ms / 1000;
+double prog_date_time = start_time_s;
 
 get_start_index_number(os, c, _index, _number);
 
@@ -464,16 +467,21 @@ static void write_hls_media_playlist(OutputStream *os, 
AVFormatContext *s,
 ff_hls_write_init_file(c->m3u8_out, os->initfile, c->single_file,
os->init_range_length, os->init_start_pos);
 
-for (i = start_index; i < os->nb_segments; i++) {
+for (i = 0; i < os->nb_segments; i++) {
 Segment *seg = os->segments[i];
-ret = ff_hls_write_file_entry(c->m3u8_out, 0, c->single_file,
-(double) seg->duration / timescale, 0,
-seg->range_length, seg->start_pos, NULL,
-c->single_file ? os->initfile : seg->file,
-NULL);
-if (ret < 0) {
-av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get 
error\n");
+double duration = (double) seg->duration / timescale;
+if (i >= start_index) {
+double prog_date_time_copy = prog_date_time;
+ret = ff_hls_write_file_entry(c->m3u8_out, 0, c->single_file,
+duration, 0,
+seg->range_length, seg->start_pos, NULL,
+c->single_file ? os->initfile : seg->file,
+_date_time_copy);
+if (ret < 0) {
+av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get 
error\n");
+}
 }
+prog_date_time += duration;
 }
 
 if (prefetch_url)
@@ -1583,9 +1591,12 @@ static int dash_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 os->first_pts = pkt->pts;
 os->last_pts = pkt->pts;
 
-if (!c->availability_start_time[0])
+if (!c->availability_start_time[0]) {
+int64_t start_time_us = av_gettime();
+c->start_time_ms = start_time_us / 1000;
 format_date_now(c->availability_start_time,
 sizeof(c->availability_start_time));
+}
 
 if (!os->availability_time_offset && pkt->duration) {
 int64_t frame_duration = av_rescale_q(pkt->duration, st->time_base,
-- 
2.17.0

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

[FFmpeg-devel] [PATCH] libavfilter/vf_subtitles: add options offset set subtitles time offset

[qq2225936589]

From: qq2225936589 

---
 doc/filters.texi   | 3 +++
 libavfilter/vf_subtitles.c | 5 -
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 0ef6f56d5d..5dee472837 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -16307,6 +16307,9 @@ useful if not UTF-8.
 @item stream_index, si
 Set subtitles stream index. @code{subtitles} filter only.
 
+@item offset
+Set subtitles time offset. @code{subtitles} filter only.
+
 @item force_style
 Override default style or script info parameters of the subtitles. It accepts a
 string containing ASS style format @code{KEY=VALUE} couples separated by ",".
diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
index a7b02461f2..ba6f03e385 100644
--- a/libavfilter/vf_subtitles.c
+++ b/libavfilter/vf_subtitles.c
@@ -27,6 +27,7 @@
  * @see{http://www.matroska.org/technical/specs/subtitles/ssa.html}
  */
 
+#include 
 #include 
 
 #include "config.h"
@@ -52,6 +53,7 @@ typedef struct AssContext {
 char *filename;
 char *fontsdir;
 char *charenc;
+float offset;
 char *force_style;
 int stream_index;
 int alpha;
@@ -266,6 +268,7 @@ static const AVOption subtitles_options[] = {
 {"charenc",  "set input character encoding", OFFSET(charenc),  
AV_OPT_TYPE_STRING, {.str = NULL}, CHAR_MIN, CHAR_MAX, FLAGS},
 {"stream_index", "set stream index", OFFSET(stream_index), 
AV_OPT_TYPE_INT,{ .i64 = -1 }, -1,   INT_MAX,  FLAGS},
 {"si",   "set stream index", OFFSET(stream_index), 
AV_OPT_TYPE_INT,{ .i64 = -1 }, -1,   INT_MAX,  FLAGS},
+{"offset",   "set subtitles time offset",OFFSET(offset),   
AV_OPT_TYPE_FLOAT,  { .dbl = 0.0}, -600.0,   600.0,FLAGS},
 {"force_style",  "force subtitle style", OFFSET(force_style),  
AV_OPT_TYPE_STRING, {.str = NULL}, CHAR_MIN, CHAR_MAX, FLAGS},
 {NULL},
 };
@@ -458,7 +461,7 @@ static av_cold int init_subtitles(AVFilterContext *ctx)
 av_log(ctx, AV_LOG_WARNING, "Error decoding: %s (ignored)\n",
av_err2str(ret));
 } else if (got_subtitle) {
-const int64_t start_time = av_rescale_q(sub.pts, 
AV_TIME_BASE_Q, av_make_q(1, 1000));
+const int64_t start_time = av_rescale_q(sub.pts, 
AV_TIME_BASE_Q, av_make_q(1, 1000)) + ass->offset*1000;
 const int64_t duration   = sub.end_display_time;
 for (i = 0; i < sub.num_rects; i++) {
 char *ass_line = sub.rects[i]->ass;
-- 
2.13.0.windows.1


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

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Michael Niedermayer]

On Thu, Feb 21, 2019 at 11:19:08AM +0100, Tomas Härdin wrote:
> ons 2019-02-20 klockan 22:12 +0100 skrev Michael Niedermayer:
> > On Sat, Feb 09, 2019 at 01:10:20PM +, Matthew Fearnley wrote:
> > > - Improve block choices by counting 0-bytes in the entropy score
> > > - Make histogram use uint16_t type, to allow byte counts from 16*16
> > > (current block size) up to 255*255 (maximum allowed 8bpp block size)
> > > - Make sure score table is big enough for a full block's worth of bytes
> > > - Calculate *xored without using code in inner loop
> > 
> > This should have been split into multiple changes
> 
> Alas
> 

> > compression seems to become slightly worse from this change
> > 
> > ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y 
> > test-old.avi
> > ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y 
> > test-new.avi
> > 
> > -rw-r- 1 michael michael 1175466 Feb 20 22:06 test-new.avi
> > -rw-r- 1 michael michael 1174832 Feb 20 22:07 test-old.avi
> 
> A whopping 0.05% change,

no its just a tiny difference but i think it still would make sense to
understand it.
Generally a patch doing 4 improvments would be expected to improve things.
This was not a hand picked case. I mean its not as if I saw 10 cases
improving things and i picked the 11th. i looked at one case and that was
worse

Also either way the patch should have been split, dont you agree ?
it also would make it much easier to within seconds identify which
change actually caused the 0.05% difference. (maybe avoiding this
discussion as it maybe would be obvious from that if this is a
ommision in the commit message a bug a rare outlier ...)


> with an MPEG source rather than the intended
> PAL8..

The input to the encoder is always PAL8. so i assume you mean
"old computer game material" vs. "realistic video".


> 
> The flip side here is that we can now use larger block sizes and higher
> me_range without crashing the encoder. We can add a slower mode that
> tests a few different block sizes to see which one results in the
> smallest output.
> 
> /Tomas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

[FFmpeg-devel] [PATCH 1/2] avcodec/zmbv: obtain frame later

[Michael Niedermayer]

The frame is not needed that early so obtaining it later avoids
the costly operation in case other checks fail.

Fixes: Timeout (14sec -> 4sec)
Fixes: 
13140/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ZMBV_fuzzer-5738330308739072

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/zmbv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/zmbv.c b/libavcodec/zmbv.c
index 79e0892070..e07009d0fb 100644
--- a/libavcodec/zmbv.c
+++ b/libavcodec/zmbv.c
@@ -525,9 +525,6 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame, AVPac
 return AVERROR_INVALIDDATA;
 }
 
-if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
-return ret;
-
 if (c->comp == 0) { // uncompressed data
 if (c->decomp_size < len) {
 av_log(avctx, AV_LOG_ERROR, "Buffer too small\n");
@@ -553,6 +550,9 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame, AVPac
 av_log(avctx, AV_LOG_ERROR, "decompressed size %d is incorrect, 
expected %d\n", c->decomp_len, expected_size);
 return AVERROR_INVALIDDATA;
 }
+if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
+return ret;
+
 if (c->flags & ZMBV_KEYFRAME) {
 frame->key_frame = 1;
 frame->pict_type = AV_PICTURE_TYPE_I;
-- 
2.20.1

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

[FFmpeg-devel] [PATCH 2/2] avcodec/pnm: Avoid structure pointer dereferences in inner loop in pnm_get()

[Michael Niedermayer]

Improves speed from 5.4 to 4.2 seconds
Fixes: 
13149/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGM_fuzzer-5760833622114304

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/pnm.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c
index b06a6e81b5..17926f256f 100644
--- a/libavcodec/pnm.c
+++ b/libavcodec/pnm.c
@@ -36,13 +36,15 @@ static void pnm_get(PNMContext *sc, char *str, int buf_size)
 {
 char *s;
 int c;
+uint8_t *bs  = sc->bytestream;
+const uint8_t *end = sc->bytestream_end;
 
 /* skip spaces and comments */
-while (sc->bytestream < sc->bytestream_end) {
-c = *sc->bytestream++;
+while (bs < end) {
+c = *bs++;
 if (c == '#')  {
-while (c != '\n' && sc->bytestream < sc->bytestream_end) {
-c = *sc->bytestream++;
+while (c != '\n' && bs < end) {
+c = *bs++;
 }
 } else if (!pnm_space(c)) {
 break;
@@ -50,12 +52,13 @@ static void pnm_get(PNMContext *sc, char *str, int buf_size)
 }
 
 s = str;
-while (sc->bytestream < sc->bytestream_end && !pnm_space(c)) {
+while (bs < end && !pnm_space(c)) {
 if ((s - str)  < buf_size - 1)
 *s++ = c;
-c = *sc->bytestream++;
+c = *bs++;
 }
 *s = '\0';
+sc->bytestream = bs;
 }
 
 int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext * const s)
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH 1/4] doc/formats: add reference to ffmpeg(1) stream specifiers as that docs is more complete

[Marton Balint]

On Mon, 18 Feb 2019, Lou Logan wrote:


On Sun, Feb 17, 2019, at 10:58 AM, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 doc/formats.texi | 24 ++--


LGTM


Applied, thanks.

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

[FFmpeg-devel] [PATCH 0/1] avformat/dashenc: Added #EXT-X-PROGRAM-DATE-TIME to HLS playlists

[joepadmiraal]

This patch adds the #EXT-X-PROGRAM-DATE-TIME tag to HLS playlists when using 
the Dash muxer.

joepadmiraal (1):
  avformat/dashenc: Added #EXT-X-PROGRAM-DATE-TIME to HLS playlists

 libavformat/dashenc.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

-- 
2.17.0

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

[FFmpeg-devel] [PATCH 1/1] avformat/dashenc: Added #EXT-X-PROGRAM-DATE-TIME to HLS playlists

[joepadmiraal]

From: joepadmiraal 

---
 libavformat/dashenc.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 37a7547b12..d0d0d6f030 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -122,6 +122,7 @@ typedef struct DASHContext {
 int64_t last_duration;
 int64_t total_duration;
 char availability_start_time[100];
+int64_t start_time_ms;
 char dirname[1024];
 const char *single_file_name;  /* file names as specified in options */
 const char *init_seg_name;
@@ -432,6 +433,8 @@ static void write_hls_media_playlist(OutputStream *os, 
AVFormatContext *s,
 const char *proto = avio_find_protocol_name(c->dirname);
 int use_rename = proto && !strcmp(proto, "file");
 int i, start_index, start_number;
+time_t start_time_s = c->start_time_ms / 1000;
+double prog_date_time = start_time_s;
 
 get_start_index_number(os, c, _index, _number);
 
@@ -464,16 +467,21 @@ static void write_hls_media_playlist(OutputStream *os, 
AVFormatContext *s,
 ff_hls_write_init_file(c->m3u8_out, os->initfile, c->single_file,
os->init_range_length, os->init_start_pos);
 
-for (i = start_index; i < os->nb_segments; i++) {
+for (i = 0; i < os->nb_segments; i++) {
 Segment *seg = os->segments[i];
-ret = ff_hls_write_file_entry(c->m3u8_out, 0, c->single_file,
-(double) seg->duration / timescale, 0,
-seg->range_length, seg->start_pos, NULL,
-c->single_file ? os->initfile : seg->file,
-NULL);
-if (ret < 0) {
-av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get 
error\n");
+double duration = (double) seg->duration / timescale;
+if (i >= start_index) {
+double prog_date_time_copy = prog_date_time;
+ret = ff_hls_write_file_entry(c->m3u8_out, 0, c->single_file,
+duration, 0,
+seg->range_length, seg->start_pos, NULL,
+c->single_file ? os->initfile : seg->file,
+_date_time_copy);
+if (ret < 0) {
+av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get 
error\n");
+}
 }
+prog_date_time += duration;
 }
 
 if (prefetch_url)
@@ -1583,9 +1591,12 @@ static int dash_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 os->first_pts = pkt->pts;
 os->last_pts = pkt->pts;
 
-if (!c->availability_start_time[0])
+if (!c->availability_start_time[0]) {
+int64_t start_time_us = av_gettime();
+c->start_time_ms = start_time_us / 1000;
 format_date_now(c->availability_start_time,
 sizeof(c->availability_start_time));
+}
 
 if (!os->availability_time_offset && pkt->duration) {
 int64_t frame_duration = av_rescale_q(pkt->duration, st->time_base,
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/pnm: Avoid structure pointer dereferences in inner loop in pnm_get()

[Lauri Kasanen]

On Thu, 21 Feb 2019 20:34:29 +0100
Michael Niedermayer  wrote:

> Improves speed from 5.4 to 4.2 seconds
> Fixes: 
> 13149/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGM_fuzzer-5760833622114304

LGTM

Though, I really would expect the compiler to detect and optimize that.
I wonder if "PNMContext * const sc" would help it any.

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.

[Michael Niedermayer]

On Wed, Feb 20, 2019 at 11:54:56PM +0800, Charles Liu wrote:
> 1. organize fragmented information according to the tracks.
> 2. do NOT skip the last boxes of fragmented info.
> 
> ticket #7572
> 
> Signed-off-by: Charles Liu 
> ---
>  libavformat/isom.h |  10 +-
>  libavformat/mov.c  | 375 ++---
>  2 files changed, 185 insertions(+), 200 deletions(-)

this causes OOM and crashes

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] stream 0, timescale not set
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] stream 1, timescale not set
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] error reading header
*** Error in `./ffmpeg': double free or corruption (fasttop): 
0x0379b100 ***
Aborted (core dumped)


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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Check parents remaining length

[Dale Curtis]

One of our test clips is behaving differently after this patch:
https://cs.chromium.org/chromium/src/media/test/data/bear-320x240-live.webm

The printed log message is:
[matroska,webm @ 0x1516c84f4e00] Invalid length 0xff >
0x12f in parent

Looking through the code I'm unsure which of the mixed usage "(uint64_t)-1"
and "2**56-1" as marker values is correct. Changing the code to:
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 9b706ab4e0..3015a0b230 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1205,7 +1205,7 @@ static int ebml_parse_elem(MatroskaDemuxContext
*matroska,
 MatroskaLevel *level = >levels[matroska->num_levels
- 1];
 AVIOContext *pb = matroska->ctx->pb;
 int64_t pos = avio_tell(pb);
-if (level->length != (uint64_t) -1 &&
+if (level->length != 0xffULL &&
 (pos + length) > (level->start + level->length)) {
 av_log(matroska->ctx, AV_LOG_ERROR,
"Invalid length 0x%"PRIx64" > 0x%"PRIx64" in
parent\n",

Resolves our issues. Should all other length tests be done the same way?

- dale

On Sun, Feb 17, 2019 at 12:45 AM Michael Niedermayer 
wrote:

> On Wed, Feb 13, 2019 at 01:41:31PM +0100, Michael Niedermayer wrote:
> > Reported-by: Steve Lhomme
> > This was found through the Hacker One program on VLC but is not a
> security issue in libavformat
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/matroskadec.c | 21 +
> >  1 file changed, 21 insertions(+)
>
> will apply an equivalent variant from steve
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Asymptotically faster algorithms should always be preferred if you have
> asymptotical amounts of data
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSoC mentored project: derain filter

[Michael Niedermayer]

On Wed, Feb 20, 2019 at 06:35:22PM +0800, 孟学苇 wrote:
> Hi Dev-Community,
> 
> 
> 
> 
> I am Iris Meng from China. I’m a PhD student in Institute of Digital Media, 
> Peking University. I wish to contribute as a GSoC applicant this year.
> 
> I am interested in Deep Learning. I want to add a derain filter in ffmpeg. If 
> you have any suggestion or question, we can contact by email. My motivation 
> and plans are as follows.
> 
> 
> 
> 
>Motivation
> 
> Rain and fog are very common weather in actual life. However, it can affect 
> the visibility. Especially in heavy rain, rain streaks from various 
> directions accumulate and make the background scene misty, which will 
> seriously influence the accuracy of many computer vision systems, including 
> video surveillance, object detection and tracking in autonomous driving, etc. 
> Therefore, it is an important task to remove the rain and fog, and recover 
> the background from rain images. It can be used for image and video 
> processing to make them clearer and it can be a preprocessing method for many 
> computer vision systems.
> 
> 
> 
> 
>Proposed Idea
> 
> We propose to implement this technology in ffmpeg. For video [1][2], we can 
> utilize the relationship between frames to remove rain and fog. For single 
> image [3], we can use traditional methods, such as discriminative sparse 
> coding, low rank representation and the Gaussian mixture model. We can also 
> use some deep learning methods. We should investigate these methods, and 
> ultimately consider the effect of rain/fog removal and the complexity of the 
> algorithm, and choose the optimal scheme.
> 
> 
> 
> 
>Practical application
> 
> The derain and dehaze method can improve the subjective quality of videos and 
> images.
> 
> 
> 
> 
>   Development plan
> 

> I would like to start working on my qualification task and try to solve my 
> problems. Overall, I will follow the following steps to complete the project.
> 
> (1)Literature and algorithm investigation
> 
> (2)Data sets preparation
> 
> (3)Coding: Implement network, training code, inference code and so on
> 
> (4)Select the best method and transplantation it into ffmpeg

I would suggest to do the coding within FFmpeg from as early as possible, not
to implement things outside and transplant later. This should be less work and
avoids underestimating the work to transplant the code

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar

[Chris Cunningham]

I'm fine to do either. James, do you still prefer to skip the later headers
if this breaks some old ogm files?

On Sat, Feb 16, 2019 at 4:52 PM Michael Niedermayer 
wrote:

> On Fri, Feb 15, 2019 at 02:56:18PM -0800, Chris Cunningham wrote:
> > On Mon, Feb 11, 2019 at 1:55 PM Chris Cunningham <
> chcunning...@chromium.org>
> > wrote:
> >
> > > On Fri, Feb 8, 2019 at 2:37 PM Michael Niedermayer 
> > > wrote:
> > >
> > >> ogg allows chaining streams when they have differing serial numbers
> > >> https://xiph.org/ogg/doc/oggstream.html
> > >>
> > >> i think ive seen actual files doing this
> > >>
> > >> ogg_replace_stream() might assign these into existing avstreams i
> think
> > >>
> > >
> > > If I'm reading this correctly, I think that should always happen at the
> > > boundary of a new ogg page, meaning it wouldn't rely on this multiple
> > > headers logic?
> > >
> > > I found the commit where this was introduced
> > >
> > >
> https://github.com/FFmpeg/FFmpeg/commit/81b743eb1026547270b88ac6a5cb451a3907ee94?diff=split
> > >
> > > With the description:
> > > This fixes some old ogm files that had the 3rd vorbis header after a
> data
> > > packet in another stream. This is invalid in ogg, but this change
> shouldn't
> > > affect the behaviour of any valid file.
> > >
> > > So, I don't think we're going to find spec text for this. No spec for
> OGM
> > > and committer indicates its not valid Ogg. I'm guessing we want to
> still
> > > support these ogm files?
> > >
> > >
> > Hey friends, just checking in on this discussion. Pls advise on findings
> > above.
>
> I have no real oppinion on which solution to pick. If disallowing these
> changes in OGM works, thats fine with me as is updating values
>
> thanks
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 2
> "100% positive feedback" - "All either got their money back or didnt
> complain"
> "Best seller ever, very honest" - "Seller refunded buyer after failed scam"
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://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 4/5] avfilter/vf_thumbnail_cuda: Switch to using ffnvcodec

[Soft Works]

> Subject: [FFmpeg-devel] [PATCH 4/5] avfilter/vf_thumbnail_cuda: Switch to 
> using ffnvcodec
>
> This change switches the vf_thumbnail_cuda filter from using the
> full cuda sdk to using the ffnvcodec headers and loader.
>
> Most of the change is a direct mapping, but I also switched from
> using texture references to using texture objects. This is supposed
> to be the preferred way of using textures, and the texture object API
> is the one I added to ffnvcodec.
>
> Signed-off-by: Philip Langdale 
> ---
>  configure|   2 +-
>  libavfilter/vf_thumbnail_cuda.c  | 147 +--
>  libavfilter/vf_thumbnail_cuda.cu |  25 +++---
>  3 files changed, 93 insertions(+), 81 deletions(-)

> -CHECK_CU(cuMemsetD8(s->data, 0, HIST_SIZE * sizeof(int)));
> +CHECK_CU(cu->cuMemsetD8Async(s->data, 0, HIST_SIZE * sizeof(int), 
> s->cu_stream));
Hi Phil,

the only problem I encountered was the cuMemsetD8Async function
which needs yet to be added to the ffnvcodec headers.

The other filters are building fine (MSYS2/Win).

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

[FFmpeg-devel] [PATCH 2/2] tools/target_dec_fate.list: Add testcases for #2000 to #4000

[Michael Niedermayer]

Testcases which return 403 currently are commented out

Signed-off-by: Michael Niedermayer 
---
 tools/target_dec_fate.list | 196 +
 1 file changed, 196 insertions(+)

diff --git a/tools/target_dec_fate.list b/tools/target_dec_fate.list
index f6f131569e..5ad1e940c6 100644
--- a/tools/target_dec_fate.list
+++ b/tools/target_dec_fate.list
@@ -391,6 +391,202 @@
 1948/clusterfuzz-testcase-minimized-6601933810827264   
 target_dec_rv40_fuzzer
 1949/clusterfuzz-testcase-minimized-6645980176842752   
 target_dec_svq3_fuzzer
 1967/clusterfuzz-testcase-minimized-5757031199801344   
 target_dec_wavpack_fuzzer
+2001/clusterfuzz-testcase-minimized-6187599389523968   
 target_dec_asv2_fuzzer
+2004/clusterfuzz-testcase-minimized-5533262866808832   
 target_dec_snow_fuzzer
+2005/clusterfuzz-testcase-minimized-5744226438479872   
 target_dec_aac_fixed_fuzzer
+2006/clusterfuzz-testcase-minimized-5766515037044736   
 target_dec_dxv_fuzzer
+2010/clusterfuzz-testcase-minimized-6209288450080768   
 target_dec_hevc_fuzzer
+2014/clusterfuzz-testcase-minimized-5186337030275072   
 target_dec_aac_fixed_fuzzer
+2038/clusterfuzz-testcase-minimized-4521466148159488   
 target_dec_wavpack_fuzzer
+2045/clusterfuzz-testcase-minimized-6751255865065472   
 target_dec_aac_fixed_fuzzer
+2065/clusterfuzz-testcase-minimized-6298930457346048   
 target_dec_qdraw_fuzzer
+2067/clusterfuzz-testcase-minimized-5578430902960128   
 target_dec_cavs_fuzzer
+2071/clusterfuzz-testcase-minimized-6036414271586304   
 target_dec_aac_fixed_fuzzer
+2076/clusterfuzz-testcase-minimized-6542640243802112   
 target_dec_tiff_fuzzer
+2079/clusterfuzz-testcase-minimized-5345861779324928   
 target_dec_tak_fuzzer
+2096/clusterfuzz-testcase-minimized-4901566068817920   
 target_dec_aac_fixed_fuzzer
+2097/clusterfuzz-testcase-minimized-5036861833609216   
 target_dec_mxpeg_fuzzer
+2100/clusterfuzz-testcase-minimized-4522961547558912   
 target_dec_paf_video_fuzzer
+2106/clusterfuzz-testcase-minimized-6136503639998464   
 target_dec_mpeg4_fuzzer
+2113/clusterfuzz-testcase-minimized-6510704959946752   
 target_dec_ac3_fixed_fuzzer
+2115/clusterfuzz-testcase-minimized-6594111748440064   
 target_dec_indeo4_fuzzer
+2127/clusterfuzz-testcase-minimized-6595787859427328   
 target_dec_subrip_fuzzer
+2131/clusterfuzz-testcase-minimized-4718045157130240   
 target_dec_shorten_fuzzer
+2134/clusterfuzz-testcase-minimized-4619258405322752   
 target_dec_wavpack_fuzzer
+2143/clusterfuzz-testcase-minimized-5482288060039168   
 target_dec_dvbsub_fuzzer
+2145/clusterfuzz-testcase-minimized-5866217724182528   
 target_dec_h264_fuzzer
+2154/clusterfuzz-testcase-minimized-4879971375906816   
 target_dec_hevc_fuzzer
+2159/clusterfuzz-testcase-minimized-5267945972301824   
 target_dec_h264_fuzzer
+2164/clusterfuzz-testcase-minimized-4715936172998656   
 target_dec_aac_fixed_fuzzer
+2169/clusterfuzz-testcase-minimized-5688641642823680   
 target_dec_cfhd_fuzzer
+2174/clusterfuzz-testcase-minimized-5739234533048320   
 target_dec_flic_fuzzer
+2175/clusterfuzz-testcase-minimized-5809657849315328   
 target_dec_ra_144_fuzzer
+2176/clusterfuzz-testcase-minimized-5908197216878592   
 target_dec_tiff_fuzzer
+2181/clusterfuzz-testcase-minimized-6314784322486272   
 target_dec_wavpack_fuzzer
+2192/clusterfuzz-testcase-minimized-5370387988742144   
 target_dec_mpeg4_fuzzer
+2195/clusterfuzz-testcase-minimized-4736721533009920   
 target_dec_aac_fixed_fuzzer
+2197/clusterfuzz-testcase-minimized-6010716676947968  

[FFmpeg-devel] [PATCH 1/2] tools/target_dec_fate.sh: Add support for lines that are comments

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 tools/target_dec_fate.sh | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/target_dec_fate.sh b/tools/target_dec_fate.sh
index 1fdfdcaaea..1377b6b4e8 100755
--- a/tools/target_dec_fate.sh
+++ b/tools/target_dec_fate.sh
@@ -50,6 +50,8 @@ while read -r LINE; do
 FILE=`echo $LINE | sed 's# .*##'`
 if test -f "$1/$FILE" ; then
 echo exists   $FILE
+elif echo "$ISSUE_NUM" | grep '#' >/dev/null ; then
+echo disabled $FILE
 else
 echo downloading  $FILE
 mkdir -p "$1/$ISSUE_NUM"
@@ -72,6 +74,9 @@ make -j4 $TOOLS
 while read -r LINE; do
 TOOL_ID=`echo $LINE | sed 's#[^ ]* ##'`
 FILE=`echo $LINE | sed 's# .*##'`
+if ! test -f "$1/$FILE" ; then
+continue
+fi
 tools/$TOOL_ID $1/$FILE
 done < "tools/$LIST"
 
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Michael Niedermayer]

On Thu, Feb 21, 2019 at 09:26:44PM +, Matthew Fearnley wrote:
> On Thu, 21 Feb 2019 at 19:28, Michael Niedermayer 
> wrote:
> 
> > On Thu, Feb 21, 2019 at 11:19:08AM +0100, Tomas Härdin wrote:
> > > ons 2019-02-20 klockan 22:12 +0100 skrev Michael Niedermayer:
> > > > On Sat, Feb 09, 2019 at 01:10:20PM +, Matthew Fearnley wrote:
> > > > > - Improve block choices by counting 0-bytes in the entropy score
> > > > > - Make histogram use uint16_t type, to allow byte counts from 16*16
> > > > > (current block size) up to 255*255 (maximum allowed 8bpp block size)
> > > > > - Make sure score table is big enough for a full block's worth of
> > bytes
> > > > > - Calculate *xored without using code in inner loop
> > > >
> > > > This should have been split into multiple changes
> > >
> > > Alas
> > >
> >
> > > > compression seems to become slightly worse from this change
> > > >
> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y
> > test-old.avi
> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y
> > test-new.avi
> > > >
> > > > -rw-r- 1 michael michael 1175466 Feb 20 22:06 test-new.avi
> > > > -rw-r- 1 michael michael 1174832 Feb 20 22:07 test-old.avi
> > >
> > > A whopping 0.05% change,
> >
> > no its just a tiny difference but i think it still would make sense to
> > understand it.
> > Generally a patch doing 4 improvments would be expected to improve things.
> > This was not a hand picked case. I mean its not as if I saw 10 cases
> > improving things and i picked the 11th. i looked at one case and that was
> > worse
> >
> > Also either way the patch should have been split, dont you agree ?
> > it also would make it much easier to within seconds identify which
> > change actually caused the 0.05% difference. (maybe avoiding this
> > discussion as it maybe would be obvious from that if this is a
> > ommision in the commit message a bug a rare outlier ...)
> >
> > Hi Michael.  First, let me say thanks for your feedback on this patch.
> Let me address some of this..
> 

> - Yes: in retrospect, I think I should have split the patch.
> I struggled here to work out how to split up my changes, and spent too long
> staring too closely at the code to see this.
> I still perhaps have some way to go before I would be able to get a proper
> feel for the general FFmpeg development ecosystem.

if something is unclear, ask, yes i know this is often not so simple but
especially in case of for example spliting patches, if you dont know how
its easy to ask 


> 
> - To clear up the effects: the change from 'i=1' to 'i=0' was the only
> change that should make any difference in the output.
> The rest of the changes were to improve the speed of an inner loop, and to
> fix two bugs that happily cancelled each other out, but would have broken
> if the code were changed to emit larger blocks.  These should not lead to
> changes in the blocks chosen or the final compression size.
> 

> - Regarding the worse compression: let me start by stating that scoring on
> byte frequency alone will not always predict well how Deflate will work,
> since Deflate also uses pattern matching as well.
> Frequency-based block scoring will only ever be a heuristic.  There may be
> scope for improving the scoring, but it would add a lot of complexity, and
> I think it would be easy to make things worse rather than better.  (I found
> this in my brief experiments with including the frequencies from the
> previous block.)

implementing the exact scoring by using Deflate itself would allow us to
understand how much there is between the heuristic and what is achievable.
If there is a gap that is significant then it may be interresting to
look at improving the heuristic if the gap is small than the whole
heuristic improvment path can be discarded.
The obvious improvment for the heuristic would be to move to higher
order entropy estimation. ATM IIUC this uses a 0th order. 1st order could
be tried or any fast compression algorithm could also be used to estimate
entropy.
It also would be interresting to see how a higher order heuristic or
some simple fast LZ like compressor would perform with the previous block.
That is if the issue you saw with the previous block inclusion was because
of the very simplistic entropy estimation.


> 
> I think the main thing that persuaded me to make this particular change
> from 1 to 0 was that it gave a pure entropy-based score, and allowed me,
> mathematically, to use the same scoring table on both full and partial
> blocks, without having to worry about the effects of omitting the 0-bytes
> in the score in each case.
> 
> I focused my testing on the available ZMBV samples, which were likely all
> generated by DOSBox, and my findings were that while not all movies were
> smaller, overall the gains outweighed the losses.
> I'm slightly sad to hear it didn't improve this real-world movie sample.
> But I think this level in this case is acceptable, and not outside the
> 

Re: [FFmpeg-devel] [PATCH] fix trac ticket #7359

[Michael Niedermayer]

On Wed, Oct 24, 2018 at 01:50:15PM +0100, Nick Ryan wrote:
> Signed-off-by: Nick Ryan 
> ---
>  libavformat/hls.c |  6 --
>  libavformat/mov.c | 36 +---
>  2 files changed, 37 insertions(+), 5 deletions(-)

this is lacking a commit message that explains what this does, why it does it
and how it does it
also if the 2 changes are not each dependant on the other then spliting
it in 2 patches may make sense

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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

Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution changes little

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Thursday, February 21, 2019 17:53
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution
> changes little
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Wednesday, February 13, 2019 6:00 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution
> changes
> > little
> >
> > Currently, resolution change detection is based on 16 alignment, small
> > resolution changes (same after FFALIGN 16) in coded width or coded height
> > will not trigger the reinit and will lead to a decode failure.
> >
> > Modify to use last_coded_width and last_coded_height to detect the small
> > resolution change.
> >
> > Signed-off-by: Linjie Fu 
> 
> Is it still needed if https://patchwork.ffmpeg.org/patch/12112/ applied?

Garbage still exists after applying the patch set. 
Will comment under patch 12112.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/vaapi_encode: add frame-skip func

[Sun, Jing A]

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
Thompson
Sent: Thursday, February 21, 2019 5:35 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/vaapi_encode: add frame-skip 
func

On 20/02/2019 10:33, Jing SUN wrote:
> This implements app controlled frame skipping in vaapi encoding. To 
> make a frame skipped, allocate its frame side data of the newly added 
> AV_FRAME_DATA_SKIP_FRAME type and set its value to 1.
> 
> Signed-off-by: Jing SUN 
> ---
>  libavcodec/vaapi_encode.c | 112 
> --
>  libavcodec/vaapi_encode.h |   5 +++
>  libavutil/frame.c |   1 +
>  libavutil/frame.h |   5 +++
>  4 files changed, 119 insertions(+), 4 deletions(-)

Have a look at 
, 
which tries to implement this feature in a more general way without adding any 
ad-hoc API.

- Mark
-Original Message-

Hi Mark,

I think the 239989 patch is quite a good one to implement VFR by adapting VAAPI 
frame-skip feature, but it does not fulfill the feature requirement that we 
have been asked to achieve, which is to skip the frames that are selected by 
apps, and the purpose to skip any frames is not just to control frame-rate, but 
also to skip duplicated ones, or to skip abandoned ones due to some changes 
just made, etc. Could we please keep both and let users decide which way they 
want to use?

Regards,
SUN, Jing
___
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 v2 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Zhong Li
> Sent: Wednesday, February 20, 2019 10:58
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [FFmpeg-devel] [PATCH v2 3/6] lavc/qsvdec: Replace current parser
> with MFXVideoDECODE_DecodeHeader()
> 
> 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 +
>  2 files changed, 90 insertions(+), 84 deletions(-)
> 
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 4a0be811fb..efe054f5c5 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -120,19 +120,18 @@ 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;
> +} else
> +q->orig_pix_fmt = pix_fmts[1];
> 
>  if (!q->async_fifo) {
>  q->async_fifo = av_fifo_alloc(q->async_depth * qsv_fifo_item_size());
> @@ -170,48 +169,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;
> + }
> +
> +static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q,
> mfxVideoParam *param)
> +{
> +int ret;
> 
> -param.IOPattern   = q->iopattern;
> -param.AsyncDepth  = q->async_depth;
> -param.ExtParam= q->ext_buffers;
> -param.NumExtParam = q->nb_ext_buffers;
> +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-
> >mfx.FrameInfo.PicStruct);
> +avctx->pix_fmt  = ff_qsv_map_fourcc(param->mfx.FrameInfo.FourCC);
> 
> -ret = MFXVideoDECODE_Init(q->session, );
> +ret = MFXVideoDECODE_Init(q->session, param);
>  if (ret < 0)
>  return ff_qsv_print_error(avctx, ret,
>"Error