Re: [FFmpeg-devel] [PATCH] mpegaudiodec_template: add ability to check CRC

[Michael Niedermayer]

On Fri, Mar 08, 2019 at 06:48:15PM +0100, Lynne wrote:
> 
> 
> 
> 7 Mar 2019, 21:18 by mich...@niedermayer.cc:
> 
> > On Wed, Mar 06, 2019 at 07:09:52PM +0100, Lynne wrote:
> >
> >> A lot of files have CRC included.
> >> The CRC only covers 34 bytes at most from the frame but it should still be
> >> enough for some amount of error detection.
> >>
> >> mpegaudiodec_template.c |   20 +---
> >>  1 file changed, 17 insertions(+), 3 deletions(-)
> >> e8276f62fa92aa3f78e53b182b4ca7a2a460754c  
> >> 0001-mpegaudiodec_template-add-ability-to-check-CRC.patch
> >> From e1f4410f35d3d7f774a0de59ab72764033d14900 Mon Sep 17 00:00:00 2001
> >> From: Lynne <>> d...@lynne.ee >> >
> >> Date: Wed, 6 Mar 2019 17:04:04 +
> >> Subject: [PATCH] mpegaudiodec_template: add ability to check CRC
> >>
> >> A lot of files have CRC included.
> >> The CRC only covers 34 bytes at most from the frame but it should still be
> >> enough for some amount of error detection.
> >> ---
> >>  libavcodec/mpegaudiodec_template.c | 20 +---
> >>  1 file changed, 17 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavcodec/mpegaudiodec_template.c 
> >> b/libavcodec/mpegaudiodec_template.c
> >> index 9cce88e263..0881b60bf5 100644
> >> --- a/libavcodec/mpegaudiodec_template.c
> >> +++ b/libavcodec/mpegaudiodec_template.c
> >> @@ -27,6 +27,7 @@
> >>  #include "libavutil/attributes.h"
> >>  #include "libavutil/avassert.h"
> >>  #include "libavutil/channel_layout.h"
> >> +#include "libavutil/crc.h"
> >>  #include "libavutil/float_dsp.h"
> >>  #include "libavutil/libm.h"
> >>  #include "avcodec.h"
> >> @@ -1565,9 +1566,22 @@ static int mp_decode_frame(MPADecodeContext *s, 
> >> OUT_INT **samples,
> >>  
> >>  init_get_bits(&s->gb, buf + HEADER_SIZE, (buf_size - HEADER_SIZE) * 8);
> >>  
> >> -/* skip error protection field */
> >> -if (s->error_protection)
> >> -skip_bits(&s->gb, 16);
> >> +if (s->error_protection) {
> >> +uint16_t crc = get_bits(&s->gb, 16);
> >> +if (s->err_recognition & AV_EF_CRCCHECK) {
> >> +const int sec_len = s->lsf ? ((s->nb_channels == 1) ? 9  : 
> >> 17) :
> >> + ((s->nb_channels == 1) ? 17 : 
> >> 32);
> >> +const AVCRC *crc_tab = av_crc_get_table(AV_CRC_16_ANSI);
> >> +uint32_t crc_cal = av_crc(crc_tab, UINT16_MAX, &buf[2], 2);
> >> +crc_cal = av_crc(crc_tab, crc_cal, &buf[6], sec_len);
> >> +
> >> +if (av_bswap16(crc) ^ crc_cal) {
> >> +av_log(s->avctx, AV_LOG_ERROR, "CRC mismatch!\n");
> >> +if (s->err_recognition & AV_EF_EXPLODE)
> >> +return AVERROR_INVALIDDATA;
> >> +}
> >> +}
> >> +}
> >>
> >
> > For files with crcs and with damage, do they sound better with the
> > check and error out or without ?
> >
> > The behavior which provides the best user experience should be the
> > default
> >
> > It also may make sense to add one of AV_EF_CAREFUL / AV_EF_COMPLIANT / 
> > AV_EF_AGGRESSIVE
> > depending on how the check affects actual real world files
> >
> 

> This is just a quick check to verify the files are uncorrupted, it shouldn't

As this CRC does not cover the whole data it cannot achieve that


> make broken files sound better unless the decoder somehow outputs white noise
> when it tries to decode them.
> I corrupted some files with -bsf:a noise=0.5 and couldn't notice an 
> improvement
> with or without -err_detect crccheck+explode even though the outputs looked 
> different. crccheck+explode makes much less errors about incorrect timestamps.

If the check doesnt integrate into error concealment which improves subjective
quality (and also cannot really detect corruption reliably) then it is not
that usefull.
There are no doubt situations outside that for which it could be usefull
like detecting errors in parts that would change to sample rate and such 
otherwise but this check is also not designed to protect that codepath.
(libavcodec/mpegaudio_parser.c)

So i think while checking this crc can be usefull, the implementation here
is missing every usecase a bit at least the ones i can see, which no doubt
are not all usecases ...

Thanks


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

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


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

Re: [FFmpeg-devel] avcodec/vaapi_h264: skip decode if pic has no slices

[Peter F]

Hi Mark,
Am Mi., 13. März 2019 um 02:00 Uhr schrieb Mark Thompson :
[..]
> >>> Date: Sat, 26 Jan 2019 19:48:35 +0100
> >>> Subject: [PATCH] avcodec/vaapi_h264: skip decode if pic has no slices
> >>
> >> Something along the lines of "avcodec/vaapi_h264: skip decoding if no
> >> slices were provided"?
> >>
> >> Also I would prefer if the reasoning for skipping decode on our layer
> >> would be explained in further lines of the commit message, like you
> >> have nicely explained it in the initial e-mail (to work-around a mesa
> >> vaapi driver bug).
> >> I don't remember the specifics of AVC, but are there valid VCL NAL
> >> units without slices (and would such end up in this code path to begin
> >> with)? I would guess that there would be no such valid VCL NAL units
> >> (or if there were, they wouldn't get to this point in the decode
> >> chain) - mostly just noting that this might be something we would like
> >> to check to verify if this should be an error or a "normal" state.
> >>
> >> The general idea I'm OK with since if we already know that there's no
> >> slices to decode, we might as well skip decoding as long as that
> >> doesn't cause issues with the state of the underlying
> >> libraries/drivers. Thus, I would mostly just wait for a reply from one
> >> of the VAAPI wrapper maintainers regarding if this skip should happen
> >> here or earlier in the decode process (where the buffers are being
> >> allocated).
>
> I suspect it would make sense for this to happen earlier in the decoder if it 
> knows it doesn't have any slices (therefore not calling any hwaccel code at 
> all), but I'm not really sure - maybe in this case it doesn't know early 
> enough so you always have the start_frame call.  The current setup is going 
> to allocate a reference frame but then with this change never do anything 
> with it, which seems bad from an uninitialised-data perspective.  On the 
> other hand, I agree that calling into the hardware decoder with no slices 
> seems rather unhelpful, and it probably doesn't write anything useful to the 
> frame either.
>
> Still, all of the other hwaccel APIs (VDPAU, DXVA2, NVDEC) do currently do 
> the same thing too, though, so it would seem nicer if this could be kept 
> consistent across all of them.  If Mesa with VAAPI is the only case where 
> this fails (checking Mesa with VDPAU on the same hardware might be 
> interesting?) then fixing it in the driver would seem the best answer.  I 
> might have a look at that later.
>
> > From 3c4885579e86f6c002e614c4082a3bdb02d8426e Mon Sep 17 00:00:00 2001
> > From: xbmc 
> > Date: Sat, 26 Jan 2019 19:48:35 +0100
> > Subject: [PATCH] avcodec/vaapi_h264: skip decode if pic has no slices
> >
> > This fixes / workarounds 
> > https://bugs.freedesktop.org/show_bug.cgi?id=105368.
> > It was hit frequently when watching h264 channels received via DVB-X.
> > Corresponding kodi bug: https://github.com/xbmc/xbmc/issues/15704
> > ---
> >  libavcodec/vaapi_h264.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> > index 5854587a25..f12fdc457a 100644
> > --- a/libavcodec/vaapi_h264.c
> > +++ b/libavcodec/vaapi_h264.c
> > @@ -317,6 +317,11 @@ static int vaapi_h264_end_frame(AVCodecContext *avctx)
> >  H264SliceContext *sl = &h->slice_ctx[0];
> >  int ret;
> >
> > +if (pic->nb_slices == 0) {
> > +ret = AVERROR_INVALIDDATA;
> > +goto finish;
> > +}
> > +
> >  ret = ff_vaapi_decode_issue(avctx, pic);
> >  if (ret < 0)
> >  goto finish;
> > --
> > 2.20.1
>
> This pastes the parameter buffers you have already sent on to the front of 
> the next frame, which is going to do something pretty weird - I think you 
> want to call ff_vaapi_decode_cancel() before returning.
>
> Have you tried this on the i965 and iHD drivers and made sure it doesn't do 
> anything nasty in the same case there?  (Or if you can provide a sample file 
> I'll have a go myself.)

I tested a provided sample on vaapi (Intel Apollo Lake) with kodi and
the provided ffmpeg patch and it is still working correctly. Sadly it
seems upload.ffmpeg.org does not respond for me correctly (times out
on ipv6 and ipv4) - therefore I cannot upload the sample there. Do you
have another idea where to post the sample?

Best regards
Peter
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel



-- 
   Key-ID: 0x1A995A9B
   keyserver: pgp.mit.edu
==
Fingerprint: 4606 DA19 EC2E 9A0B 0157  C81B DA07 CF63 1A99 5A9B
___
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]

ons 2019-03-13 klockan 17:46 + skrev Matthew Fearnley:
> > > > On 12 Mar 2019, at 11:46, Tomas Härdin  wrote:
> > 
> > tis 2019-03-12 klockan 10:27 + skrev Matthew Fearnley:
> > > > 
> > > It occurs to me that adding sub-8bpp has some implications:
> > > 
> > > My current understanding (I could be wrong) is that FFmpeg tends to
> > > detect the pix_fmt based on the first frame. If FFmpeg detects the
> > > first frame as e.g. PAL4, and chooses that as its output, that means
> > > the rest of the video will have to be encodable as PAL4, otherwise it
> > > (obviously) won’t be encoded properly.
> > > 
> > > So adding a PAL4 format puts a new constraint on encoders (inside and
> > > outside FFmpeg) to not encode frames in a way that looks like PAL4,
> > > unless the whole video will be encodable that way.
> > 
> > Yes, FFmpeg will probe the initial format of the video and audio.
> > Nothing says these are constant. There are FATE samples specifically
> > for files that change resolution. Since ZMBV is a DOS capture codec,
> > and DOS programs frequently change resolution and colordepth, this is
> > indeed something we have to think about. Example: DOS boots into mode
> > 3h, 80x25 16-color text. A recording may start in this mode, then
> > switch to mode 13h (320x200 256 colors graphics), if I understand the
> > format correctly.
> 
> DOSBox actually avoids this issue by outputting to a new file
> whenever it detects a change in colour depth, dimensions or FPS. So
> in practice, these remain constant over a single video.

Ah, convenient

> I’ve tried stitching two AVI files together (palette + RGB, same
> dimensions), and found that if a palette-capable format like ‘png’ is
> chosen, all of the resulting AVI file is encoded with a palette, and
> RGB sections are dithered.  That possibly suggests FFmpeg doesn’t
> like changing format halfway through videos, for AVI at least?

It probably implies AVI can't change palette, or that FFmpeg's support
for changing palettes is spotty at best

> > > Thanks for writing the email to the DOSBox crew.
> > > If they choose a channel order, then we have good grounds for fixing
> > > the encoder (if need be), and implementing the decoder in the same
> > > way.
> > > It occurs to me that they might (in theory) also want to specify 2/4
> > > byte alignment on RGB, like with the MVs.  My gut says there’d be
> > > very little benefit though, and it would only be seen with strange
> > > video / block widths.
> > > 
> > > It also occurs to me this will may warrant a version bump in the
> > > format, to give an easy error case for decoders that don’t expect it.
> > > Particularly if our decoder has to redefine its channel order.
> > 
> > Are there any decoders besides ours and dosbox's?
> 
> I don’t know of any public implementations.
> 
> (That said, I have written a stand-alone tool that encodes/decodes
> ZMBV, but I’ve not published it anywhere. It’s based heavily on the
> DOSBox implementation.)
> > It also turns out the creator of this codec is Harekiet, who hangs
> > out
> > in #revision on IRCnet
> 
> Ah ok, do you know him?
> It sounds like he’s not concerned too much about what direction we
> take the format in. But I guess anything we implement may not get
> made official unless DOSBox adds decoding support.

I suspect he'd be more than happy handing the ZMBV reins to you. Since
24-bit mode isn't official yet I'd say there's room to make
improvements to the format itself, via that flag field. There's also
that unused bit in every MV, which together with the other bit gives
you the possibility of two extra modes beyond copy and XOR. 1-byte MVs
might also be something to investigate, especially for smaller
blocksizes (say 4x4)

> By the way, I’m happy for this patch to be committed as-is (possibly
> without the extra note on unsupported bit depths, if that causes any
> issues). Any new additions outside the existing spec would warrant a
> new patch I think.

Oh yeah, We've gotten a bit sidetracked with this 24-bit business :)
I'll push it once FATE passes. Should be an hour or so.

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

[FFmpeg-devel] 32bit transcoding app running out of memory

[Simone Donadini]

Hi there,
we are developing a transcoder using ffmpeg based on the transcoding example 
https://www.ffmpeg.org/doxygen/4.1/transcoding_8c-example.html and we are 
encountering some problem with memory usage transcoding files with large 
resolutions.
When transcoding 4K files, the memory usage will go up to 3.4GB but then it 
will stay steady for the rest of the conversion, and clean every thing at the 
end. While transcoding video files with larger resolution (8K) the app, which 
is 32bit, will run out of memory (>4GB).
It does not look like a memory leak, as memory usage will grow as long as 
transcoding a certain amount of frames and then it will stay steady. It looks 
like the amount of memory usage depends on the resolution of the frame, but 
even with a 8K frame using >4GB is not expected.
Is this a known behavior?
Is there a way to limit the number of frames loaded on memory or the amount of 
memory while transcoding?
Or building a 64bit version would fix this issue?
Any help would really be appreciated.
Thank you,
Simone.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] 32bit transcoding app running out of memory

[Carl Eugen Hoyos]

2019-03-14 11:28 GMT+01:00, Simone Donadini :
> Hi there,
> we are developing a transcoder using ffmpeg based on the transcoding example
> https://www.ffmpeg.org/doxygen/4.1/transcoding_8c-example.html and we are
> encountering some problem with memory usage transcoding files with large
> resolutions.
> When transcoding 4K files, the memory usage will go up to 3.4GB but then it
> will stay steady for the rest of the conversion, and clean every thing at
> the end.

massif (or an equivalent application) can tell you where the memory
is allocated, some decoders absolutely need these allocations, apart
from that my guess is that (a part of) the allocation does not happen
in FFmpeg.

> While transcoding video files with larger resolution (8K) the app,
> which is 32bit, will run out of memory (>4GB).
> It does not look like a memory leak, as memory usage will grow as long as
> transcoding a certain amount of frames and then it will stay steady. It
> looks like the amount of memory usage depends on the resolution of the

> frame, but even with a 8K frame using >4GB is not expected.

Why do you think so?

> Is this a known behavior?
> Is there a way to limit the number of frames loaded on memory
> or the amount of memory while transcoding?

Yes.
(You did not give enough information about input video and
encoder settings.)

> Or building a 64bit version would fix this issue?

Most likely.

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()

[Li, Zhong]

> From: Rogozhkin, Dmitry V
> Sent: Tuesday, March 12, 2019 7:37 AM
> To: Li, Zhong ; ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current
> parser with MFXVideoDECODE_DecodeHeader()
> 
> 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;
> > > > -  

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

[Li, Zhong]

> From: Rogozhkin, Dmitry V
> Sent: Tuesday, March 12, 2019 8:04 AM
> To: Li, Zhong ; ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current
> parser with MFXVideoDECODE_DecodeHeader()
> 
> 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.

No, it must be array, and the last element of this array must be 
AV_PIX_FMT_NONE (else function ff_get_format() doesn't know how many elements 
contained by this array). 
The first element of pix_fmt[] is HW pixel format, the second element of 
pix_fmt[] is SW pixel format. 
Once again, I would like you to take a look the implementation detail of 
ff_get_format ().

___
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]

tor 2019-03-14 klockan 11:12 +0100 skrev Tomas Härdin:
> ons 2019-03-13 klockan 17:46 + skrev Matthew Fearnley:
> > > > > 
> > By the way, I’m happy for this patch to be committed as-is (possibly
> > without the extra note on unsupported bit depths, if that causes any
> > issues). Any new additions outside the existing spec would warrant a
> > new patch I think.
> 
> Oh yeah, We've gotten a bit sidetracked with this 24-bit business :)
> I'll push it once FATE passes. Should be an hour or so.

Pushed.

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

Re: [FFmpeg-devel] 32bit transcoding app running out of memory

[Simone Donadini]

> 2019-03-14 11:28 GMT+01:00, Simone Donadini :
> > Hi there,
> > we are developing a transcoder using ffmpeg based on the transcoding example
> > https://www.ffmpeg.org/doxygen/4.1/transcoding_8c-example.html and we are
> > encountering some problem with memory usage transcoding files with large
> > resolutions.
> > When transcoding 4K files, the memory usage will go up to 3.4GB but then it
> > will stay steady for the rest of the conversion, and clean every thing at
> > the end.
> 
> massif (or an equivalent application) can tell you where the memory
> is allocated, some decoders absolutely need these allocations, apart
> from that my guess is that (a part of) the allocation does not happen
> in FFmpeg.

ok, i will try with it. But i am not seeing any memory leak with smaller files, 
so i am not sure why there would be any when using a greater resolution.

> 
> > While transcoding video files with larger resolution (8K) the app,
> > which is 32bit, will run out of memory (>4GB).
> > It does not look like a memory leak, as memory usage will grow as long as
> > transcoding a certain amount of frames and then it will stay steady. It
> > looks like the amount of memory usage depends on the resolution of the
> 
> > frame, but even with a 8K frame using >4GB is not expected.
> 
> Why do you think so?
>

With our codec one encoded frame 7680x4320 should be ~100MB.

> > Is this a known behavior?
> > Is there a way to limit the number of frames loaded on memory
> > or the amount of memory while transcoding?
> 
> Yes.
> (You did not give enough information about input video and
> encoder settings.)

At the moment i am testing with a file h264 8K @60fps, and the encoder is using 
the same properties (framerate - size) of the source file. I am using no 
filters.

> 
> > Or building a 64bit version would fix this issue?
> 
> Most likely.
> 
> 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 1/2] avcodec/cdgraphics: Use ff_set_dimensions()

[Michael Niedermayer]

On Tue, Mar 05, 2019 at 08:38:17PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (17 sec -> 65 milli sec)
> Fixes: 
> 13264/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CDGRAPHICS_fuzzer-5711167941509120
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/cdgraphics.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)

will apply patchset

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

It is what and why we do it that matters, not just one of them.


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/gdv: Check fps

[Michael Niedermayer]

On Tue, Mar 05, 2019 at 01:05:46AM +0100, Michael Niedermayer wrote:
> Fixes: Division by 0
> Fixes: ffmpeg_zero_division.bin
> 
> Found-by: Anatoly Trosinenko 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/gdv.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply

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

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

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

[Yufei He]

Hi

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

Please review.

Thanks.

Yufei.


From b1f7779028378f3e0d5360766a8591d0cf5a0a71 Mon Sep 17 00:00:00 2001
From: yhe 
Date: Thu, 14 Mar 2019 10:10:46 -0400
Subject: [PATCH] H.264 encoder and decoder support with Matrox M264.

---
 Changelog   |   1 +
 configure   |   2 +
 libavcodec/Makefile |   2 +
 libavcodec/allcodecs.c  |   2 +
 libavcodec/codec_desc.c |   1 -
 libavcodec/m264dec.c| 315 
 libavcodec/m264dec.h|  39 ++
 libavcodec/m264enc.c| 296 +
 libavcodec/m264enc.h|  38 ++
 9 files changed, 695 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/m264dec.c
 create mode 100644 libavcodec/m264dec.h
 create mode 100644 libavcodec/m264enc.c
 create mode 100644 libavcodec/m264enc.h

diff --git a/Changelog b/Changelog
index 4d80e5b..ce0daf8 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
 - ARBC decoder
 - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
 - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
+- Support h.264 encoding and decoding with Matrox M264 card.
 
 
 version 4.1:
diff --git a/configure b/configure
index dcead3a..5a5d7d5 100755
--- a/configure
+++ b/configure
@@ -2697,6 +2697,8 @@ h263p_decoder_select="h263_decoder"
 h263p_encoder_select="h263_encoder"
 h264_decoder_select="cabac golomb h264chroma h264dsp h264parse h264pred h264qpel videodsp"
 h264_decoder_suggest="error_resilience"
+h264_m264_decoder_deps_any="libdl"
+h264_m264_encoder_deps_any="libdl"
 hap_decoder_select="snappy texturedsp"
 hap_encoder_deps="libsnappy"
 hap_encoder_select="texturedspenc"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8..8e8f9ab 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -348,6 +348,8 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o h264_cabac.o h264_cavlc.o \
   h264_slice.o h264data.o
 OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
 OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
+OBJS-$(CONFIG_H264_M264_DECODER)   += m264dec.o
+OBJS-$(CONFIG_H264_M264_ENCODER)   += m264enc.o
 OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
 OBJS-$(CONFIG_H264_NVENC_ENCODER)  += nvenc_h264.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b26aeca..c03a5a3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -737,6 +737,8 @@ extern AVCodec ff_libopenh264_encoder;
 extern AVCodec ff_libopenh264_decoder;
 extern AVCodec ff_h264_amf_encoder;
 extern AVCodec ff_h264_cuvid_decoder;
+extern AVCodec ff_h264_m264_decoder;
+extern AVCodec ff_h264_m264_encoder;
 extern AVCodec ff_h264_nvenc_encoder;
 extern AVCodec ff_h264_omx_encoder;
 extern AVCodec ff_h264_qsv_encoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index a3de8e1..55c02a8 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1705,7 +1705,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("Gryphon's Anim Compressor"),
 .props = AV_CODEC_PROP_LOSSY,
 },
-
 /* various PCM "codecs" */
 {
 .id= AV_CODEC_ID_PCM_S16LE,
diff --git a/libavcodec/m264dec.c b/libavcodec/m264dec.c
new file mode 100644
index 000..f16716e
--- /dev/null
+++ b/libavcodec/m264dec.c
@@ -0,0 +1,315 @@
+/*
+ * M264 H.264 video decoder
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Matrox M264 card supports h.264 encoding and decoding.
+ */
+
+#include "decode.h"
+#include "cabac.h"
+#include "error_resilience.h"
+#include "h264_parse.h"
+#include "h264_ps.h"
+#include "h264_sei.h"
+#include "h2645_parse.h"
+#include "h264chroma.h"
+#include "h264dsp.h"
+#include "h264pred.h"
+#include "h264qpel.h"
+#include "internal.h"
+#include "mpegutils.h"
+#include "parser.h"
+#include "qpeldsp.h"
+#include "rectangle.h"
+#include "videodsp.h"
+#include "config.h"
+#include "libswscale/swscale.h"
+#include "m264dec.h"
+#ifdef _WIN32
+#include "compat/w32dlfcn.h"
+#else
+#include

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

[Jun Li]

Calculate bitrate based on fragment size, only applied when
bitrate is not set, for example rtsp source.

Signed-off-by: Jun Li 
---
 libavformat/smoothstreamingenc.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/libavformat/smoothstreamingenc.c b/libavformat/smoothstreamingenc.c
index 094712af27..30bb188aa2 100644
--- a/libavformat/smoothstreamingenc.c
+++ b/libavformat/smoothstreamingenc.c
@@ -320,11 +320,13 @@ static int ism_write_header(AVFormatContext *s)
 AVDictionary *opts = NULL;
 
 if (!s->streams[i]->codecpar->bit_rate) {
-av_log(s, AV_LOG_ERROR, "No bit rate set for stream %d\n", i);
-ret = AVERROR(EINVAL);
-goto fail;
+av_log(s, AV_LOG_WARNING, "No bit rate set for stream %d\n", i);
+// create a tmp name for the directory of fragments
+snprintf(os->dirname, sizeof(os->dirname), 
"%s/QualityLevels(Tmp_%"PRId64")", s->url, i);
+} else {
+snprintf(os->dirname, sizeof(os->dirname), 
"%s/QualityLevels(%"PRId64")", s->url, s->streams[i]->codecpar->bit_rate);
 }
-snprintf(os->dirname, sizeof(os->dirname), 
"%s/QualityLevels(%"PRId64")", s->url, s->streams[i]->codecpar->bit_rate);
+
 if (mkdir(os->dirname, 0777) == -1 && errno != EEXIST) {
 ret = AVERROR(errno);
 av_log(s, AV_LOG_ERROR, "mkdir failed\n");
@@ -519,7 +521,7 @@ static int ism_flush(AVFormatContext *s, int final)
 
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = &c->streams[i];
-char filename[1024], target_filename[1024], header_filename[1024];
+char filename[1024], target_filename[1024], header_filename[1024], 
curr_dirname[1024];
 int64_t size;
 int64_t start_ts, duration, moof_size;
 if (!os->packets_written)
@@ -541,6 +543,26 @@ static int ism_flush(AVFormatContext *s, int final)
 size = os->tail_pos - os->cur_start_pos;
 if ((ret = parse_fragment(s, filename, &start_ts, &duration, 
&moof_size, size)) < 0)
 break;
+
+if (!s->streams[i]->codecpar->bit_rate) {
+int64_t bitrate = (int64_t) size * 8 * AV_TIME_BASE / 
av_rescale_q(duration, s->streams[i]->time_base, AV_TIME_BASE_Q);
+if (!bitrate) {
+av_log(s, AV_LOG_ERROR, "calculating bitrate get zero.");
+ret = AVERROR(EINVAL);
+return ret;
+}
+
+av_log(s, AV_LOG_WARNING, "calculated bitrate: %ld\n", bitrate);
+s->streams[i]->codecpar->bit_rate = bitrate;
+memcpy(curr_dirname, os->dirname, sizeof(os->dirname));
+snprintf(os->dirname, sizeof(os->dirname), 
"%s/QualityLevels(%"PRId64")", s->url, s->streams[i]->codecpar->bit_rate);
+snprintf(filename, sizeof(filename), "%s/temp", os->dirname);
+
+// rename the tmp folder back to the correct name since we now 
have the bitrate
+if ((ret = ff_rename((const char*)curr_dirname,  os->dirname, s)) 
< 0)
+return ret;
+}
+
 snprintf(header_filename, sizeof(header_filename), 
"%s/FragmentInfo(%s=%"PRIu64")", os->dirname, os->stream_type_tag, start_ts);
 snprintf(target_filename, sizeof(target_filename), 
"%s/Fragments(%s=%"PRIu64")", os->dirname, os->stream_type_tag, start_ts);
 copy_moof(s, filename, header_filename, moof_size);
-- 
2.17.1

___
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]

On Wed, Mar 13, 2019 at 6:07 PM Jun Li  wrote:

> On Tue, Mar 12, 2019 at 6:24 PM Jun Li  wrote:
>
>> Hi Carl,
>> Thanks for review, is there any more issue I need to take care ?
>> or any process I need to follow before applying the patch? I am new to
>> the community, don't know too much.
>>
>> Thanks
>> -Jun
>>
>> On Mon, Mar 11, 2019 at 11:44 AM Carl Eugen Hoyos 
>> wrote:
>>
>>> 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
>>
>> version 3 is sent out with more comment:
https://patchwork.ffmpeg.org/patch/12307/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/qtrle : improve decoding speed of 24bpp and 32 bpp

[James Almer]

On 3/4/2019 9:06 AM, Martin Vignali wrote:
> Pushed. Thanks
> 
> Martin

This seems to have broken all qtrle tests on sparc64.

See http://fate.ffmpeg.org/history.cgi?slot=sparc64-linux-gcc-4.9 and
others.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/qtrle : improve decoding speed of 24bpp and 32 bpp

[Martin Vignali]

>
> This seems to have broken all qtrle tests on sparc64.
>
> See http://fate.ffmpeg.org/history.cgi?slot=sparc64-linux-gcc-4.9 and
> others.
>

Thanks for reporting this.
Like i can't test on sparc64, doesn't know what line create the bus error.

Patch in attach (untested on sparc64), can probably fix the issue, by
reusing the old way of decoding 32bpp and 24 bpp
on sparc64, and let the new code, for other archs (who seems to doesn't
have the problem)

Martin


0002-avcodec-qtrle-use-the-previous-way-to-decode-rle-and.patch
Description: Binary data


0001-avcodec-qtrle-use-prev-raw-decoding-for-32bpp-on-spa.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v7] mpeg12enc: Use Closed Captions if available

[Mathieu Duponchelle]

Hello, is there anything preventing from merging this patch?

On 2/14/19 10:01 PM, Michael Niedermayer wrote:
> On Wed, Feb 13, 2019 at 11:49:21PM +0100, Mathieu Duponchelle wrote:
>> So, should this go in? :)
> if someone checks it against some spec and or tests it against some
> decoders, probably yes, 
> also might be a good idea to bump the micro version of libavcodec
>
> thanks
>
> [...]
>
> ___
> 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] avcodec/qtrle : improve decoding speed of 24bpp and 32 bpp

[James Almer]

On 3/14/2019 5:27 PM, Martin Vignali wrote:
>>
>> This seems to have broken all qtrle tests on sparc64.
>>
>> See http://fate.ffmpeg.org/history.cgi?slot=sparc64-linux-gcc-4.9 and
>> others.
>>
> 
> Thanks for reporting this.
> Like i can't test on sparc64, doesn't know what line create the bus error.
> 
> Patch in attach (untested on sparc64), can probably fix the issue, by
> reusing the old way of decoding 32bpp and 24 bpp
> on sparc64, and let the new code, for other archs (who seems to doesn't
> have the problem)

No, littering the arch agnostic decoder with arch specific ifdeffery is
not ok.

Someone with a Sparc64 host (or qemu) should try to debug this and find
what's wrong.
Who's "Mik", for that matter? He runs these fate clients.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/qtrle: Do not use aligned writes for odd addresses.

[Carl Eugen Hoyos]

Hi!

Attached patch fixes the qtrle crash on sparc for me.

Please comment, Carl Eugen
From a94d32d63cff248d2eb633b162e9e4d4f7234ee5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 15 Mar 2019 00:02:48 +0100
Subject: [PATCH] lavc/qtrle: Do not used aligned writes for odd addresses.

pixel_ptr can be 3.
Fixes crashes on systems that do not allow unaligned access.
---
 libavcodec/qtrle.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index a744d7b..1351532 100644
--- a/libavcodec/qtrle.c
+++ b/libavcodec/qtrle.c
@@ -325,7 +325,7 @@ static void qtrle_decode_24bpp(QtrleContext *s, int row_ptr, int lines_to_change
 CHECK_PIXEL_PTR(rle_code * 3);
 
 while (rle_code--) {
-AV_WN16A(rgb + pixel_ptr, rg);
+AV_WN16(rgb + pixel_ptr, rg);
 rgb[pixel_ptr + 2] = b;
 pixel_ptr += 3;
 }
@@ -335,13 +335,13 @@ static void qtrle_decode_24bpp(QtrleContext *s, int row_ptr, int lines_to_change
 rle_code_half = rle_code / 2;
 
 while (rle_code_half--) { /* copy 2 raw rgb value at the same time */
-AV_WN32A(rgb + pixel_ptr, bytestream2_get_ne32(&s->g)); /* rgbr */
-AV_WN16A(rgb + pixel_ptr + 4, bytestream2_get_ne16(&s->g)); /* rgbr */
+AV_WN32(rgb + pixel_ptr, bytestream2_get_ne32(&s->g)); /* rgbr */
+AV_WN16(rgb + pixel_ptr + 4, bytestream2_get_ne16(&s->g)); /* rgbr */
 pixel_ptr += 6;
 }
 
 if (rle_code % 2 != 0){ /* not even raw value */
-AV_WN16A(rgb + pixel_ptr, bytestream2_get_ne16(&s->g));
+AV_WN16(rgb + pixel_ptr, bytestream2_get_ne16(&s->g));
 rgb[pixel_ptr + 2] = bytestream2_get_byte(&s->g);
 pixel_ptr += 3;
 }
@@ -379,7 +379,7 @@ static void qtrle_decode_32bpp(QtrleContext *s, int row_ptr, int lines_to_change
 CHECK_PIXEL_PTR(rle_code * 4);
 
 while (rle_code--) {
-AV_WN32A(rgb + pixel_ptr, argb);
+AV_WN32(rgb + pixel_ptr, argb);
 pixel_ptr += 4;
 }
 } else {
@@ -388,12 +388,12 @@ static void qtrle_decode_32bpp(QtrleContext *s, int row_ptr, int lines_to_change
 /* copy pixels directly to output */
 rle_code_half = rle_code / 2;
 while (rle_code_half--) { /* copy 2 argb raw value at the same time */
-AV_WN64A(rgb + pixel_ptr, bytestream2_get_ne64(&s->g));
+AV_WN64(rgb + pixel_ptr, bytestream2_get_ne64(&s->g));
 pixel_ptr += 8;
 }
 
 if (rle_code % 2 != 0){ /* not even raw value */
-AV_WN32A(rgb + pixel_ptr, bytestream2_get_ne32(&s->g));
+AV_WN32(rgb + pixel_ptr, bytestream2_get_ne32(&s->g));
 pixel_ptr += 4;
 }
 }
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavc/qtrle: Do not use aligned writes for odd addresses.

[Hendrik Leppkes]

On Fri, Mar 15, 2019 at 12:05 AM Carl Eugen Hoyos  wrote:
>
> Hi!
>
> Attached patch fixes the qtrle crash on sparc for me.
>

It should be fine in cases where the pointer is being incremented by
an aligned amount, ie. writing 32 and incrementing by 4, or 64 and 8,
etc.
Are all of those required to pass, or only the ones on "odd"
increments like 3 for 24-bit RGB? (In fact, those "odd" ones are the
ones that are new recently)

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

Re: [FFmpeg-devel] [PATCH]lavc/qtrle: Do not use aligned writes for odd addresses.

[Carl Eugen Hoyos]

2019-03-15 0:13 GMT+01:00, Hendrik Leppkes :
> On Fri, Mar 15, 2019 at 12:05 AM Carl Eugen Hoyos 
> wrote:
>>
>> Hi!
>>
>> Attached patch fixes the qtrle crash on sparc for me.
>>
>
> It should be fine in cases where the pointer is being incremented by
> an aligned amount, ie. writing 32 and incrementing by 4, or 64 and 8,
> etc.

Of course, thank you for the review!
New patch attached.

Carl Eugen
From a94d32d63cff248d2eb633b162e9e4d4f7234ee5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 15 Mar 2019 00:02:48 +0100
Subject: [PATCH] lavc/qtrle: Do not used aligned writes for odd addresses.

pixel_ptr can be 3.
Fixes crashes on systems that do not allow unaligned access.
---
 libavcodec/qtrle.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index a744d7b..1351532 100644
--- a/libavcodec/qtrle.c
+++ b/libavcodec/qtrle.c
@@ -325,7 +325,7 @@ static void qtrle_decode_24bpp(QtrleContext *s, int row_ptr, int lines_to_change
 CHECK_PIXEL_PTR(rle_code * 3);
 
 while (rle_code--) {
-AV_WN16A(rgb + pixel_ptr, rg);
+AV_WN16(rgb + pixel_ptr, rg);
 rgb[pixel_ptr + 2] = b;
 pixel_ptr += 3;
 }
@@ -335,13 +335,13 @@ static void qtrle_decode_24bpp(QtrleContext *s, int row_ptr, int lines_to_change
 rle_code_half = rle_code / 2;
 
 while (rle_code_half--) { /* copy 2 raw rgb value at the same time */
-AV_WN32A(rgb + pixel_ptr, bytestream2_get_ne32(&s->g)); /* rgbr */
-AV_WN16A(rgb + pixel_ptr + 4, bytestream2_get_ne16(&s->g)); /* rgbr */
+AV_WN32(rgb + pixel_ptr, bytestream2_get_ne32(&s->g)); /* rgbr */
+AV_WN16(rgb + pixel_ptr + 4, bytestream2_get_ne16(&s->g)); /* rgbr */
 pixel_ptr += 6;
 }
 
 if (rle_code % 2 != 0){ /* not even raw value */
-AV_WN16A(rgb + pixel_ptr, bytestream2_get_ne16(&s->g));
+AV_WN16(rgb + pixel_ptr, bytestream2_get_ne16(&s->g));
 rgb[pixel_ptr + 2] = bytestream2_get_byte(&s->g);
 pixel_ptr += 3;
 }
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH]tests/fate/ffmpeg: Check apng codec for fate-copy-apng

[Carl Eugen Hoyos]

Hi!

Attached patch fixes fate here without zlib.

Please comment, Carl Eugen
From 209fff61a2a680a5adf5df82774f7dd48fc4701c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 15 Mar 2019 00:27:33 +0100
Subject: [PATCH] tests/fate/ffmpeg: Check for apng codec for fate-copy-apng.

The file has to be created first, fixes fate without zlib.
---
 tests/fate/ffmpeg.mak |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index ac68cde..6e9fd28 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -93,7 +93,7 @@ fate-copy-trac2211-avi: $(TARGET_SAMPLES)/h264/bbc2.sample.h264
 fate-copy-trac2211-avi: CMD = transcode "h264 -r 14" $(TARGET_SAMPLES)/h264/bbc2.sample.h264\
   avi "-c:a copy -c:v copy"
 
-FATE_STREAMCOPY-$(call ALLYES, APNG_DEMUXER APNG_MUXER) += fate-copy-apng
+FATE_STREAMCOPY-$(call ALLYES, APNG_DEMUXER APNG_MUXER APNG_DECODER APNG_ENCODER) += fate-copy-apng
 fate-copy-apng: fate-lavf-apng
 fate-copy-apng: CMD = transcode apng "$(TARGET_PATH)/tests/data/lavf/lavf.apng" apng "-c:v copy"
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] 32bit transcoding app running out of memory

[Carl Eugen Hoyos]

2019-03-14 12:51 GMT+01:00, Simone Donadini :
>> 2019-03-14 11:28 GMT+01:00, Simone Donadini
>> :

>> > we are developing a transcoder using ffmpeg based on the
>> > transcoding example
>> > https://www.ffmpeg.org/doxygen/4.1/transcoding_8c-example.html
>> > and we are encountering some problem with memory usage
>> > transcoding files with large resolutions.
>> > When transcoding 4K files, the memory usage will go up to
>> > 3.4GB but then it will stay steady for the rest of the conversion,
>> > and clean every thing at the end.
>>
>> massif (or an equivalent application) can tell you where the memory
>> is allocated, some decoders absolutely need these allocations, apart
>> from that my guess is that (a part of) the allocation does not happen
>> in FFmpeg.
>
> ok, i will try with it. But i am not seeing any memory leak with smaller
> files, so i am not sure why there would be any when using a greater
> resolution.

massif does not detect memory leaks, so I don't understand your
comment.

>> > While transcoding video files with larger resolution (8K) the app,
>> > which is 32bit, will run out of memory (>4GB).
>> > It does not look like a memory leak, as memory usage will grow
>> > as long as transcoding a certain amount of frames and then it
>> > will stay steady. It looks like the amount of memory usage

>> > depends on the resolution of the frame,

I forgot:
Of course it does.

>>> but even with a 8K frame using >4GB is not expected.
>>
>> Why do you think so?
>
> With our codec one encoded frame 7680x4320 should be ~100MB.

No, memory requirements can be >3G (You did not give enough
information about input video and encoder settings, "same
properties" are not valid settings).

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

Re: [FFmpeg-devel] [PATCH]tests/fate/ffmpeg: Check apng codec for fate-copy-apng

[James Almer]

On 3/14/2019 8:29 PM, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes fate here without zlib.
> 
> Please comment, Carl Eugen
> 
> 
> 0001-tests-fate-ffmpeg-Check-for-apng-codec-for-fate-copy.patch
> 
> From 209fff61a2a680a5adf5df82774f7dd48fc4701c Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Fri, 15 Mar 2019 00:27:33 +0100
> Subject: [PATCH] tests/fate/ffmpeg: Check for apng codec for fate-copy-apng.
> 
> The file has to be created first, fixes fate without zlib.
> ---
>  tests/fate/ffmpeg.mak |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
> index ac68cde..6e9fd28 100644
> --- a/tests/fate/ffmpeg.mak
> +++ b/tests/fate/ffmpeg.mak
> @@ -93,7 +93,7 @@ fate-copy-trac2211-avi: 
> $(TARGET_SAMPLES)/h264/bbc2.sample.h264
>  fate-copy-trac2211-avi: CMD = transcode "h264 -r 14" 
> $(TARGET_SAMPLES)/h264/bbc2.sample.h264\
>avi "-c:a copy -c:v copy"
>  
> -FATE_STREAMCOPY-$(call ALLYES, APNG_DEMUXER APNG_MUXER) += fate-copy-apng
> +FATE_STREAMCOPY-$(call ALLYES, APNG_DEMUXER APNG_MUXER APNG_DECODER 
> APNG_ENCODER) += fate-copy-apng
>  fate-copy-apng: fate-lavf-apng
>  fate-copy-apng: CMD = transcode apng 
> "$(TARGET_PATH)/tests/data/lavf/lavf.apng" apng "-c:v copy"

Use $(call ENCDEC, APNG, APNG) instead.

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

Re: [FFmpeg-devel] [PATCH]lavc/qtrle: Do not use aligned writes for odd addresses.

[Hendrik Leppkes]

On Fri, Mar 15, 2019 at 12:26 AM Carl Eugen Hoyos  wrote:
>
> 2019-03-15 0:13 GMT+01:00, Hendrik Leppkes :
> > On Fri, Mar 15, 2019 at 12:05 AM Carl Eugen Hoyos 
> > wrote:
> >>
> >> Hi!
> >>
> >> Attached patch fixes the qtrle crash on sparc for me.
> >>
> >
> > It should be fine in cases where the pointer is being incremented by
> > an aligned amount, ie. writing 32 and incrementing by 4, or 64 and 8,
> > etc.
>
> Of course, thank you for the review!
> New patch attached.
>

LGTM if tested.

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

[FFmpeg-devel] [PATCH]lavf/sdp: Change configuration pointer from char* to uint8_t*.

[Carl Eugen Hoyos]

Hi!

Attached patch silences three warnings with clang and makes the
pointer type equal to what the function called with the pointer
expects.

Please comment, Carl Eugen
From cf06b8cc09acd676ac6fb713168c23342d26e1b8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 15 Mar 2019 00:52:50 +0100
Subject: [PATCH] lavf/sdp: Change pointer to configuration from char* to
 uint8_t*.

This is also what av_base64_encode() expects.
Fixes the following warnings with clang:
libavformat/sdp.c:394:40: warning: implicit conversion from 'int' to 'char' changes value from 254 to -2
libavformat/sdp.c:395:40: warning: implicit conversion from 'int' to 'char' changes value from 205 to -51
libavformat/sdp.c:396:40: warning: implicit conversion from 'int' to 'char' changes value from 186 to -70
---
 libavformat/sdp.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index a5d202e..34e9839 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -347,7 +347,8 @@ static char *extradata2config(AVFormatContext *s, AVCodecParameters *par)
 
 static char *xiph_extradata2config(AVFormatContext *s, AVCodecParameters *par)
 {
-char *config, *encoded_config;
+uint8_t *config;
+char *encoded_config;
 const uint8_t *header_start[3];
 int headers_len, header_len[3], config_len;
 int first_header_size;
-- 
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

[Ulf Zibis]

Am 11.03.19 um 23:29 schrieb Lou Logan:
> Commit message title prefix for filter patches are usually in the form
> of:
>
> avfilter/fillborders:
> or
> lavfi/fillborders: 
>
> Trailing whitespace. This should always be avoided.
>
> Use av_malloc.

I now have separted the changes into 4 patches, and mergerd your hints.

So you can clearly see, which calculations I have skipped or moved out
of inner for loops.
Can you give a rating if a performance win could be expected compaired
to the original code from your experienced knowledge without a benchmark?

-Ulf

>From c51360f3b4be0dca597190da5c2128b45e9ee31b Mon Sep 17 00:00:00 2001
From: Ulf Zibis 
Date: 14.03.2019, 19:34:03

avfilter/fillborders: added comments; named more descriptive; corrected indentations;

diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c
index 1344587..820aa2d 100644
--- a/libavfilter/vf_fillborders.c
+++ b/libavfilter/vf_fillborders.c
@@ -87,26 +87,27 @@
 int p, y;
 
 for (p = 0; p < s->nb_planes; p++) {
-uint8_t *ptr = frame->data[p];
+uint8_t *data = frame->data[p];
 int linesize = frame->linesize[p];
 
+/* fill left and right borders from top to bottom border */
 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),
+memset(data + y * linesize,
+   *(data + 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),
+memset(data + y * linesize + s->planewidth[p] - s->borders[p].right,
+   *(data + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
s->borders[p].right);
 }
 
+/* fill top and bottom borders */
 for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p]);
+memcpy(data + y * linesize,
+   data + 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,
+memcpy(data + y * linesize,
+   data + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
s->planewidth[p]);
 }
 }
@@ -117,29 +118,29 @@
 int p, y, x;
 
 for (p = 0; p < s->nb_planes; p++) {
-uint16_t *ptr = (uint16_t *)frame->data[p];
-int linesize = frame->linesize[p] / 2;
+uint16_t *data = (uint16_t *)frame->data[p];
+int linesize = frame->linesize[p] / sizeof(uint16_t);
 
+/* fill left and right borders from top to bottom border */
 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);
+data[y * linesize + x] =  *(data + y * linesize + s->borders[p].left);
 }
-
 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);
+data[y * linesize + s->planewidth[p] - s->borders[p].right + x] =
+   *(data + y * linesize + s->planewidth[p] - s->borders[p].right - 1);
 }
 }
 
+/* fill top and bottom borders */
 for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p] * 2);
+memcpy(data + y * linesize,
+   data + s->borders[p].top * linesize, s->planewidth[p] * sizeof(uint16_t));
 }
-
 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] * 2);
+memcpy(data + y * linesize,
+   data + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
+   s->planewidth[p] * sizeof(uint16_t));
 }
 }
 }
@@ -149,29 +150,29 @@
 int p, y, x;
 
 for (p = 0; p < s->nb_planes; p++) {
-uint8_t *ptr = frame->data[p];
+uint8_t *data = frame->data[p];
 int linesize = frame->linesize[p];
 
+/* fill left and right borders from top to bottom border */
 for (y = s->borders[p].top; y < s->planeheight[p] - s->b

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

[Carl Eugen Hoyos]

2019-03-15 1:08 GMT+01:00, Ulf Zibis :

> Can you give a rating if a performance win could be expected compaired
> to the original code from your experienced knowledge without a benchmark?

Just post the numbers that your tests produced.

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

Re: [FFmpeg-devel] [PATCH]lavc/qtrle: Do not use aligned writes for odd addresses.

[Carl Eugen Hoyos]

2019-03-15 0:41 GMT+01:00, Hendrik Leppkes :
> On Fri, Mar 15, 2019 at 12:26 AM Carl Eugen Hoyos 
> wrote:
>>
>> 2019-03-15 0:13 GMT+01:00, Hendrik Leppkes :
>> > On Fri, Mar 15, 2019 at 12:05 AM Carl Eugen Hoyos 
>> > wrote:
>> >>
>> >> Hi!
>> >>
>> >> Attached patch fixes the qtrle crash on sparc for me.
>> >>
>> >
>> > It should be fine in cases where the pointer is being incremented by
>> > an aligned amount, ie. writing 32 and incrementing by 4, or 64 and 8,
>> > etc.
>>
>> Of course, thank you for the review!
>> New patch attached.
>>
>
> LGTM if tested.

I pushed the patch that fixed the crash on 32bit sparc
which I had tested first.

Attached patch fixes another fate crash on 64bit sparc, I
don't know if the change is sufficient for all use cases,
it passes fate.

The crash happens with pixel_ptr = 2852, rgb is 16-byte aligned.

Please comment, Carl Eugen
From a7f5fe1d72aef47e46505f94ad247af5486b43de Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 15 Mar 2019 01:14:58 +0100
Subject: [PATCH] lavc/qtrle: Do not use aligned 64bit write.

Fixes a crash on sparc64.
---
 libavcodec/qtrle.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index 1cb3eb0..1613530 100644
--- a/libavcodec/qtrle.c
+++ b/libavcodec/qtrle.c
@@ -388,7 +388,7 @@ static void qtrle_decode_32bpp(QtrleContext *s, int row_ptr, int lines_to_change
 /* copy pixels directly to output */
 rle_code_half = rle_code / 2;
 while (rle_code_half--) { /* copy 2 argb raw value at the same time */
-AV_WN64A(rgb + pixel_ptr, bytestream2_get_ne64(&s->g));
+AV_WN64(rgb + pixel_ptr, bytestream2_get_ne64(&s->g));
 pixel_ptr += 8;
 }
 
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 1/2] avcodec/scpr: Perform frame copy later

[Michael Niedermayer]

Optimization found while looking at 
13442/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-5758293933293568

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/scpr.c  | 8 
 libavcodec/scpr3.c | 4 
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/libavcodec/scpr.c b/libavcodec/scpr.c
index 750cf59fe4..e5d7d13cf0 100644
--- a/libavcodec/scpr.c
+++ b/libavcodec/scpr.c
@@ -409,6 +409,10 @@ static int decompress_p(AVCodecContext *avctx,
 }
 }
 
+ret = av_frame_copy(s->current_frame, s->last_frame);
+if (ret < 0)
+return ret;
+
 for (y = 0; y < s->nby; y++) {
 for (x = 0; x < s->nbx; x++) {
 int sy1 = 0, sy2 = 16, sx1 = 0, sx2 = 16;
@@ -549,10 +553,6 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 } else if (type == 0 || type == 1) {
 frame->key_frame = 0;
 
-ret = av_frame_copy(s->current_frame, s->last_frame);
-if (ret < 0)
-return ret;
-
 if (s->version == 1 || s->version == 2)
 ret = decompress_p(avctx, (uint32_t *)s->current_frame->data[0],
s->current_frame->linesize[0] / 4,
diff --git a/libavcodec/scpr3.c b/libavcodec/scpr3.c
index b59a8cc28f..f92ccfa902 100644
--- a/libavcodec/scpr3.c
+++ b/libavcodec/scpr3.c
@@ -1081,6 +1081,10 @@ static int decompress_p3(AVCodecContext *avctx,
 }
 }
 
+ret = av_frame_copy(s->current_frame, s->last_frame);
+if (ret < 0)
+return ret;
+
 for (y = 0; y < s->nby; y++) {
 for (x = 0; x < s->nbx; x++) {
 int sy1 = 0, sy2 = 16, sx1 = 0, sx2 = 16;
-- 
2.21.0

___
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 issues 4000 to 6000

[Michael Niedermayer]

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

diff --git a/tools/target_dec_fate.list b/tools/target_dec_fate.list
index 5ad1e940c6..13b0721a5e 100644
--- a/tools/target_dec_fate.list
+++ b/tools/target_dec_fate.list
@@ -587,6 +587,70 @@
 3805/clusterfuzz-testcase-minimized-6578427831255040   
 target_dec_h264_fuzzer
 3902/clusterfuzz-testcase-minimized-6081926122176512   
 target_dec_exr_fuzzer
 3984/clusterfuzz-testcase-minimized-5265759929368576   
 target_dec_snow_fuzzer
+4019/clusterfuzz-testcase-minimized-5823336006287360   
 target_dec_h264_fuzzer
+4035/clusterfuzz-testcase-minimized-6479308925173760   
 target_dec_dirac_fuzzer
+4037/clusterfuzz-testcase-minimized-5290998163832832   
 target_dec_hevc_fuzzer
+4074/clusterfuzz-testcase-minimized-4516104123711488   
 target_dec_truehd_fuzzer
+#4086/clusterfuzz-testcase-minimized-5452429861584896  
  target_dec_h264_fuzzer
+4143/clusterfuzz-testcase-minimized-4736864637419520   
 target_dec_zmbv_fuzzer
+4151/clusterfuzz-testcase-minimized-4854089193095168   
 target_dec_libfdk_aac_fuzzer
+4196/clusterfuzz-testcase-minimized-5580648594014208   
 target_dec_h264_fuzzer
+#4271/clusterfuzz-testcase-minimized-4676667768307712  
  target_dec_kgv1_fuzzer
+4326/clusterfuzz-testcase-minimized-5689449645080576   
 target_dec_truehd_fuzzer
+4337/clusterfuzz-testcase-minimized-6192658616680448   
 target_dec_aac_fixed_fuzzer
+4354/clusterfuzz-testcase-minimized-4671122764201984   
 target_dec_dirac_fuzzer
+4397/clusterfuzz-testcase-minimized-4779061080489984   
 target_dec_hevc_fuzzer
+4415/clusterfuzz-testcase-minimized-4677752314658816   
 target_dec_amrwb_fuzzer
+4427/clusterfuzz-testcase-minimized-5106919271301120   
 target_dec_jpeg2000_fuzzer
+4478/clusterfuzz-testcase-minimized-4752113767809024   
 target_dec_dirac_fuzzer
+4479/clusterfuzz-testcase-minimized-6529894147162112   
 target_dec_dirac_fuzzer
+4490/clusterfuzz-testcase-minimized-5210014592532480   
 target_dec_vp9_fuzzer
+4524/clusterfuzz-testcase-minimized-6055590120914944   
 target_dec_hevc_fuzzer
+4525/clusterfuzz-testcase-minimized-6400713073623040   
 target_dec_jpeg2000_fuzzer
+4554/clusterfuzz-testcase-minimized-4843714515042304   
 target_dec_hevc_fuzzer
+4555/clusterfuzz-testcase-minimized-4505532481142784   
 target_dec_hevc_fuzzer
+4563/clusterfuzz-testcase-minimized-5438979567517696   
 target_dec_dirac_fuzzer
+4626/clusterfuzz-testcase-minimized-5647837887987712   
 target_dec_hevc_fuzzer
+4671/clusterfuzz-testcase-minimized-6027464343027712   
 target_dec_dnxhd_fuzzer
+4683/clusterfuzz-testcase-minimized-6152313673613312   
 target_dec_exr_fuzzer
+4688/clusterfuzz-testcase-minimized-6572210748653568   
 target_dec_flac_fuzzer
+4690/clusterfuzz-testcase-minimized-6117482428366848   
 target_dec_hevc_fuzzer
+4698/clusterfuzz-testcase-minimized-5096956322906112   
 target_dec_h264_fuzzer
+4716/clusterfuzz-testcase-minimized-5835915940331520   
 target_dec_flac_fuzzer
+4756/clusterfuzz-testcase-minimized-4812495563784192   
 target_dec_jpeg2000_fuzzer
+4780/clusterfuzz-testcase-minimized-4709066174627840   
 target_dec_h264_fuzzer
+4792/clusterfuzz-testcase-minimized-6322450775146496   
 target_dec_dirac_fuzzer
+4793/clusterfuzz-testcase-minimized-5707366629638144   
 target_dec_exr_fuzzer
+4800/clusterfuzz-testcase-minimized-6110372403609600   
 target_dec_ac3_fixed_fuzzer
+4810/clusterfuzz-testca

Re: [FFmpeg-devel] [PATCH]tests/fate/ffmpeg: Check apng codec for fate-copy-apng

[Carl Eugen Hoyos]

2019-03-15 0:38 GMT+01:00, James Almer :
> On 3/14/2019 8:29 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes fate here without zlib.
>>
>> Please comment, Carl Eugen
>>
>>
>> 0001-tests-fate-ffmpeg-Check-for-apng-codec-for-fate-copy.patch
>>
>> From 209fff61a2a680a5adf5df82774f7dd48fc4701c Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Fri, 15 Mar 2019 00:27:33 +0100
>> Subject: [PATCH] tests/fate/ffmpeg: Check for apng codec for
>> fate-copy-apng.
>>
>> The file has to be created first, fixes fate without zlib.
>> ---
>>  tests/fate/ffmpeg.mak |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
>> index ac68cde..6e9fd28 100644
>> --- a/tests/fate/ffmpeg.mak
>> +++ b/tests/fate/ffmpeg.mak
>> @@ -93,7 +93,7 @@ fate-copy-trac2211-avi:
>> $(TARGET_SAMPLES)/h264/bbc2.sample.h264
>>  fate-copy-trac2211-avi: CMD = transcode "h264 -r 14"
>> $(TARGET_SAMPLES)/h264/bbc2.sample.h264\
>>avi "-c:a copy -c:v copy"
>>
>> -FATE_STREAMCOPY-$(call ALLYES, APNG_DEMUXER APNG_MUXER) += fate-copy-apng
>> +FATE_STREAMCOPY-$(call ALLYES, APNG_DEMUXER APNG_MUXER APNG_DECODER
>> APNG_ENCODER) += fate-copy-apng
>>  fate-copy-apng: fate-lavf-apng
>>  fate-copy-apng: CMD = transcode apng
>> "$(TARGET_PATH)/tests/data/lavf/lavf.apng" apng "-c:v copy"
>
> Use $(call ENCDEC, APNG, APNG) instead.
>
> LGTM, thanks.

Applied with this change.

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

[FFmpeg-devel] Bug in YUV decoder

[Ben Hutchinson]

When I decode rawvideo yuv444p in ffplay that was encoded in ffmpeg (using
the test source called "testsrc"), I notice there is blurring between
adjacent colors (both horizontally and vertically), which would typically
be present in yuv420p. I can avoid this by switching the decoder to use a
pixel format of yuvj444p instead of yuv444p, but that makes the brightness
levels incorrect if the image is encoded as yuv444p instead of yuvj444p (as
one would expect). This problem of blurring the color of the image
(equivalent to yuv420p) also happens in yuv422p (requiring me to switch the
decoder's pixel format to yuvj422p to get it to only have a yuv422
blurring, which is horizontally blurred only). It seems that when I use the
"j" version of yuv, it works fine, but when I use the "non-j" version of
yuv it adds an extra chroma blurring filter on the decoder.

Note that it does not matter what pixel format the encoder uses (j or
non-j). This bug is only present in the decoder, and only when I select the
non-j version of a yuv pixel format. This bug is present in the ffplay
decoder (possibly also in the ffmpeg decoder, but I've not yet tested that).

Here's some sample command lines that produce this bug:
ffmpeg -re -f lavfi -i testsrc=r=10:s=640x480 -f rawvideo -pix_fmt yuv444p
-frames 1 -|ffplay -f rawvideo -pix_fmt yuv444p -framerate 10 -s 640x480 -
ffmpeg -re -f lavfi -i testsrc=r=10:s=640x480 -f rawvideo -pix_fmt yuv422p
-frames 1 -|ffplay -f rawvideo -pix_fmt yuv422p -framerate 10 -s 640x480 -

Here's some sample command lines that avoid the bug by using the "j"
version of yuv in the decoder:
ffmpeg -re -f lavfi -i testsrc=r=10:s=640x480 -f rawvideo -pix_fmt yuv444p
-frames 1 -|ffplay -f rawvideo -pix_fmt yuvj444p -framerate 10 -s 640x480 -
ffmpeg -re -f lavfi -i testsrc=r=10:s=640x480 -f rawvideo -pix_fmt yuv444p
-frames 1 -|ffplay -f rawvideo -pix_fmt yuvj444p -framerate 10 -s 640x480 -

The version of FFMPEG (and FFPLAY) that I discovered this bug in is:
N-93298-g0ce759defd
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel