date:20200906

Fixes: signed integer overflow: -1429092 * -32596 cannot be represented in type 
'int'
Fixes: 
24419/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5157849974702080

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

diff --git a/libavcodec/ffwavesynth.c b/libavcodec/ffwavesynth.c
index 8d3ac81aef..d92bb38c45 100644
--- a/libavcodec/ffwavesynth.c
+++ b/libavcodec/ffwavesynth.c
@@ -373,7 +373,7 @@ static void wavesynth_synth_sample(struct wavesynth_context 
*ws, int64_t ts,
 in->amp  += in->damp;
 switch (in->type) {
 case WS_SINE:
-val = amp * ws->sin[in->phi >> (64 - SIN_BITS)];
+val = amp * (unsigned)ws->sin[in->phi >> (64 - SIN_BITS)];
 in->phi  += in->dphi;
 in->dphi += in->ddphi;
 break;
-- 
2.17.1

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

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

Re: [FFmpeg-devel] qsv: question on CONFIG macros

2020-09-06 Thread Mark Thompson

On 04/09/2020 16:57, Rogozhkin, Dmitry V wrote:

Hi,

Can someone, please, help to clarify:
1. Where CONFIG_QSV and CONFIG_LIBMFX gets defined (I don't see that in
the grep output - attached below)?

By configure, they end up in config.h in the build directory.

2. What's relationship between these 2? Which one should actually be
used? /from the first glance they are about the same.../

CONFIG_LIBMFX is the top level test for the presence of libmfx libraries
(--enable-libmfx to configure).

CONFIG_QSV seems to be enabled by lots of things depending on libmfx? It does
look like it might be identical (possibly you could have CONFIG_LIBMFX but not
CONFIG_QSV by disabling all components using it, but that's not helpful).

Using the "Quick Sync Video" marketing name in libavcodec does rather seem like an error
now, since it referred to the codec parts and has mostly been retired by Intel now (like the older
marketing name, "Clear Video"). Perhaps we can get rid of it entirely inside the code?

I think the right name to use is mfx (so CONFIG_LIBMFX, CONFIG_MFXENC, CONFIG_MFXDEC;
then mfx_h264, mfx_hevc, etc.), since that name is embedded the API and won't be able to
change on the whims of marketing (though the "qsv" name will have to hang
around in external APIs for a while).

The change of all of the developer branding from "Media SDK" to "oneAPI Video"
looks like it will be irrelevant because it's still the same libmfx underneath, though all of the
documentation will need an update.

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

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

[FFmpeg-devel] [PATCH 2/2] tools/target_dec_fuzzer: Adjust threshold for WMV3IMAGE

Fixes: Timeout (1131sec -> 1sec)
Fixes: 
24727/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5754167793287168

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

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 5a4fcf6b62..f17b4df0a2 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -180,6 +180,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 case AV_CODEC_ID_TRUEMOTION2: maxpixels  /= 1024;  break;
 case AV_CODEC_ID_VP7: maxpixels  /= 256;   break;
 case AV_CODEC_ID_VP9: maxpixels  /= 4096;  break;
+case AV_CODEC_ID_WMV3IMAGE:   maxpixels  /= 8192;  break;
 case AV_CODEC_ID_ZEROCODEC:   maxpixels  /= 128;   break;
 }
 
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH 3/8] avutil/timecode: do not trash bits on invalid av_timecode_get_smpte arguments

On Sat, Sep 05, 2020 at 08:22:12PM +0200, Marton Balint wrote:
> The function has no way to return error, so let's clip or calculate modulo.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavutil/timecode.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavutil/timecode.c b/libavutil/timecode.c
> index c0956adadb..806638ddfc 100644
> --- a/libavutil/timecode.c
> +++ b/libavutil/timecode.c
> @@ -84,6 +84,11 @@ uint32_t av_timecode_get_smpte(AVRational rate, int drop, 
> int hh, int mm, int ss
>  ff /= 2;
>  }
>  
> +hh = hh % 24;
> +mm = av_clip(mm, 0, 59);
> +ss = av_clip(ss, 0, 59);
> +ff = ff % 40;
> +
>  tc |= drop << 30;
>  tc |= (ff / 10) << 28;
>  tc |= (ff % 10) << 24;
> -- 
> 2.26.2

lgtm

> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 6/8] avcodec: use av_timecode_make_smpte_tc_string2 in hevc and h264 decoder

On Sat, Sep 05, 2020 at 08:22:15PM +0200, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/h264_slice.c | 2 +-
>  libavcodec/hevcdec.c| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index c7b2764270..cfc29e186c 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1325,7 +1325,7 @@ static int h264_export_frame_props(H264Context *h)
>  int   ff = h->sei.picture_timing.timecode[i].frame;
>  
>  tc_sd[i + 1] = av_timecode_get_smpte(h->avctx->framerate, drop, 
> hh, mm, ss, ff);
> -av_timecode_make_smpte_tc_string(tcbuf, tc_sd[i + 1], 0);
> +av_timecode_make_smpte_tc_string2(tcbuf, h->avctx->framerate, 
> tc_sd[i + 1], 0, 0);
>  av_dict_set(&out->metadata, "timecode", tcbuf, 0);
>  }
>  h->sei.picture_timing.timecode_cnt = 0;
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index b77df8d89f..c1de75abe1 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2843,7 +2843,7 @@ static int set_side_data(HEVCContext *s)
>  int   ff = s->sei.timecode.n_frames[i];
>  
>  tc_sd[i + 1] = av_timecode_get_smpte(s->avctx->framerate, drop, 
> hh, mm, ss, ff);
> -av_timecode_make_smpte_tc_string(tcbuf, tc_sd[i + 1], 0);
> +av_timecode_make_smpte_tc_string2(tcbuf, s->avctx->framerate, 
> tc_sd[i + 1], 0, 0);
>  av_dict_set(&out->metadata, "timecode", tcbuf, 0);
>  }
>  

have tested with 50fps timecode sample and the result looks good now.

> -- 
> 2.26.2
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/8] avutil/timecode: cosmetics on av_timecode_get_smpte

On Sat, Sep 05, 2020 at 08:22:11PM +0200, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavutil/timecode.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/libavutil/timecode.c b/libavutil/timecode.c
> index cb916970ef..c0956adadb 100644
> --- a/libavutil/timecode.c
> +++ b/libavutil/timecode.c
> @@ -71,31 +71,28 @@ uint32_t av_timecode_get_smpte_from_framenum(const 
> AVTimecode *tc, int framenum)
>  uint32_t av_timecode_get_smpte(AVRational rate, int drop, int hh, int mm, 
> int ss, int ff)
>  {
>  uint32_t tc = 0;
> -uint32_t frames;
>  
>  /* For SMPTE 12-M timecodes, frame count is a special case if > 30 FPS.
> See SMPTE ST 12-1:2014 Sec 12.1 for more info. */
>  if (av_cmp_q(rate, (AVRational) {30, 1}) == 1) {
> -frames = ff / 2;
>  if (ff % 2 == 1) {
>  if (av_cmp_q(rate, (AVRational) {50, 1}) == 0)
>  tc |= (1 << 7);
>  else
>  tc |= (1 << 23);
>  }
> -} else {
> -frames = ff;
> +ff /= 2;
>  }
>  
>  tc |= drop << 30;
> -tc |= (frames / 10) << 28;
> -tc |= (frames % 10) << 24;
> +tc |= (ff / 10) << 28;
> +tc |= (ff % 10) << 24;
>  tc |= (ss / 10) << 20;
>  tc |= (ss % 10) << 16;
>  tc |= (mm / 10) << 12;
>  tc |= (mm % 10) << 8;
>  tc |= (hh / 10) << 4;
> -tc |= (hh  % 10);
> +tc |= (hh % 10);

lgtm

>  
>  return tc;
>  }
> -- 
> 2.26.2
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to use initialized device

2020-09-06 Thread Mark Thompson


On 04/09/2020 19:24, Rogozhkin, Dmitry V wrote:

On Thu, 2020-09-03 at 01:02 +, Rogozhkin, Dmitry V wrote:


(If you do implement it then you can delete all of the ad-hoc
treatment in ffmpeg, like has been done for the other hardware
codecs.)


I like deleting code:). Ok, this sounds good. Let's try to understand
what might be missing in the current implementation since I honestly
don't see any gaps - it just works.


@Mark. We did internal review and believe that DEVICE_CTX path is
actually ready to be used and just needs to be activated. Can you,
please, let me know how you would like to proceed:
1. We can either consider review and apply the fix first (this patch)
then deal with ad_hoc in non-related patch series
2. Or we can go with the bigger patch series right away and address
both device_ctx + ad_hoc

2nd variant might require longer time to verify and review which would
hold the fix. What are your thoughts?


I'm not sure what you have tested, because it definitely doesn't work.

If you return the hardware surface format from get_format() with 
METHOD_HW_DEVICE_CTX then it just ignores you and gives you software frames 
anyway, because it only supports that case with METHOD_HW_FRAMES_CTX.

For example, with below patch to test it in the hw_decode example:

$ doc/examples/hw_decode qsv test.264 /dev/null
Assertion frame->format == AV_PIX_FMT_QSV failed at 
src/doc/examples/hw_decode.c:108
Aborted

(It incorrectly returned an NV12 frame.)

- Mark


diff --git a/doc/examples/hw_decode.c b/doc/examples/hw_decode.c
index 71be6e6709..45f401a179 100644
--- a/doc/examples/hw_decode.c
+++ b/doc/examples/hw_decode.c
@@ -105,6 +105,8 @@ static int decode_write(AVCodecContext *avctx, AVPacket 
*packet)
 goto fail;
 }

+av_assert0(frame->format == AV_PIX_FMT_QSV);
+
 if (frame->format == hw_pix_fmt) {
 /* retrieve data from GPU to CPU */
 if ((ret = av_hwframe_transfer_data(sw_frame, frame, 0)) < 0) {
@@ -191,6 +193,8 @@ int main(int argc, char *argv[])
 }
 video_stream = ret;

+decoder = avcodec_find_decoder_by_name("h264_qsv");
+
 for (i = 0;; i++) {
 const AVCodecHWConfig *config = avcodec_get_hw_config(decoder, i);
 if (!config) {
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index fc25dc73e5..f2fac17354 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -47,7 +47,8 @@ const AVCodecHWConfigInternal *ff_qsv_hw_configs[] = {
 &(const AVCodecHWConfigInternal) {
 .public = {
 .pix_fmt = AV_PIX_FMT_QSV,
-.methods = AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX |
+.methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX |
+   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX |
AV_CODEC_HW_CONFIG_METHOD_AD_HOC,
 .device_type = AV_HWDEVICE_TYPE_QSV,
 },
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dv: allow returning damaged audio

2020-09-06 Thread Dave Rice

> On Aug 3, 2020, at 5:16 PM, Michael Niedermayer  
> wrote:
> 
> On Mon, Aug 03, 2020 at 10:38:21PM +0200, Marton Balint wrote:
>> 
>> 
>> On Sun, 2 Aug 2020, Dave Rice wrote:
>> 
>>> 
>>> 
 On Aug 1, 2020, at 5:26 PM, Marton Balint  wrote:

 On Sat, 1 Aug 2020, Michael Niedermayer wrote:

> On Sat, Aug 01, 2020 at 07:28:53PM +0200, Marton Balint wrote:
>> 
>> 
>> On Sat, 1 Aug 2020, Michael Niedermayer wrote:
>> 
>>> Fixes: Ticket8762
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>> libavformat/dv.c | 49 +---
>>> 1 file changed, 42 insertions(+), 7 deletions(-)
>> 
>> If "dv remux loses sync", then the timestamps should be fixed, not
>> additional packets should be generated based on previously read packet 
>> data
>> (which is a fragile approach to begin with, e.g. what if the first frame 
>> is
>> the corrupt one?).
> 
> Ticket8762 is about stream copy, so if no packets are returned for audio
> but are for video and just timestamps are updated this would at least on
> its own probably not work that well.

 If the timestamps are good, a good player should be able to play it
 correctly, even if audio stream is sparse.

 None of the demuxers generate packets because the timestamps are not
 continous, I just don't think it would be consistent if DV suddenly
 started to do this. E.g. what if the user wants to drop video with
 no audio?
>>> 
>>> In practice, when dv frames with video and no audio are interleaved
>>> within a dv stream that otherwise has both, it is because the playback
>>> videotape player of the dv tape is in pause mode or the tape is damaged.
>>> These frames most common are filled with only video dif blocks that note
>>> concealment (so the image is a copy of a prior image) and the audio
>>> source pack metadata is missing, but the paylock of the audio dif blocks
>>> are filled with error code so they would decode as silence.
>> 
>> But if the audio source pack metadata is missing, then how can you determine
>> the audio settings?

I tested with QuickTime Player 7 and when frames are read with the audio source 
pack metadata missing, the first audio source pack is used. So these frames 
provide silent output as an earlier audio source pack is used. The disadvantage 
here is that a mid stream change such as 32kHz to 48kHz causes QuickTime Player 
7 to mangle the audio by applying the wrong characteristics.

>> Or the number of samples the errornous frame contains
>> (e.g. 1600 v.s 1602)?
> 
> some testcase would be useful here where this is done clearly wrong currently

I put two additional samples at 
https://archive.org/download/001.dv.audiogap/001.dv.audiogap.dv 
 and 
https://archive.org/download/001.dv.audiogap/DVC00036_001.dv.audiogap.dv 
. 
Each contains a series of frames in the middle that have all video blocks as 
concealed and all audio blocks are simply error code with no audio source pack.

For each example, both "ffmpeg -i file -c copy out” and “ffmpeg -i file out” 
has a loss of sync in the result and an audio track shorter than the video.

But true, a frame with no audio source pack does not communicate if it should 
be 1600 or 1602 samples.

In the SMPTE specification for DV at 
http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf

,
 it says on page 18 that for NTSC systems, the five-frame pattern should be: 
1600, 1602, 1602, 1602, 1602. So if a frame has no audio source pack, the 
pattern of prior frames could be used or simply use this pattern upon finding a 
sequence of such frames starting at 1600. Or possibly the relationship between 
the starting time of the audio data and the starting time for the video data 
could be used to guess if 1600 or 1602 maintains the alignment more closely.

>> Also maybe setting the CORRUPT packet flag should be done in this case?
> 
> yes was thinking that too, that should be in the next revision

In the reference specification, table 26 shows how the STA value is interpreted 
to note if the frame contains concealed video DIF blocks or not. This doesn’t 
necessarily mean that the frame is corrupt, but that it is the product of data 
concealment caused by a misreading of the DV videotape.

[…]
Dave

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

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

Re: [FFmpeg-devel] [PATCH 7/8] avfilter/vf_showinfo: use av_timecode_make_smpte_tc_string2

On Sat, Sep 05, 2020 at 08:22:16PM +0200, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavfilter/vf_showinfo.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index 1be939614d..c63e6f075f 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -114,7 +114,7 @@ static void dump_stereo3d(AVFilterContext *ctx, 
> AVFrameSideData *sd)
>  av_log(ctx, AV_LOG_INFO, " (inverted)");
>  }
>  
> -static void dump_s12m_timecode(AVFilterContext *ctx, AVFrameSideData *sd)
> +static void dump_s12m_timecode(AVFilterContext *ctx, AVFilterLink *link, 
> AVFrameSideData *sd)

use framerate direclty instead of link for input?

>  {
>  const uint32_t *tc = (const uint32_t *)sd->data;
>  
> @@ -125,7 +125,7 @@ static void dump_s12m_timecode(AVFilterContext *ctx, 
> AVFrameSideData *sd)
>  
>  for (int j = 1; j <= tc[0]; j++) {
>  char tcbuf[AV_TIMECODE_STR_SIZE];
> -av_timecode_make_smpte_tc_string(tcbuf, tc[j], 0);
> +av_timecode_make_smpte_tc_string2(tcbuf, link->frame_rate, tc[j], 0, 
> 0);
>  av_log(ctx, AV_LOG_INFO, "timecode - %s%s", tcbuf, j != tc[0]  ? ", 
> " : "");
>  }
>  }
> @@ -380,7 +380,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *frame)
>  dump_stereo3d(ctx, sd);
>  break;
>  case AV_FRAME_DATA_S12M_TIMECODE: {
> -dump_s12m_timecode(ctx, sd);
> +dump_s12m_timecode(ctx, inlink, sd);
>  break;
>  }
>  case AV_FRAME_DATA_DISPLAYMATRIX:
> -- 
> 2.26.2
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_buffers: remove unused function argument

2020-09-06 Thread Andriy Gelman

On Thu, 27. Aug 23:12, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> Signed-off-by: Andriy Gelman 
> ---
>  libavcodec/v4l2_buffers.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index 02f23d954b..4b2679eb38 100644
> --- a/libavcodec/v4l2_buffers.c
> +++ b/libavcodec/v4l2_buffers.c
> @@ -274,7 +274,7 @@ static int v4l2_buf_to_bufref(V4L2Buffer *in, int plane, 
> AVBufferRef **buf)
>  return ret;
>  }
>  
> -static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, const uint8_t* 
> data, int size, int offset, AVBufferRef* bref)
> +static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, const uint8_t* 
> data, int size, int offset)
>  {
>  unsigned int bytesused, length;
>  
> @@ -386,7 +386,7 @@ static int v4l2_buffer_swframe_to_buf(const AVFrame 
> *frame, V4L2Buffer *out)
>  h = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
>  }
>  size = frame->linesize[i] * h;
> -ret = v4l2_bufref_to_buf(out, 0, frame->data[i], size, offset, 
> frame->buf[i]);
> +ret = v4l2_bufref_to_buf(out, 0, frame->data[i], size, offset);
>  if (ret)
>  return ret;
>  offset += size;
> @@ -395,7 +395,7 @@ static int v4l2_buffer_swframe_to_buf(const AVFrame 
> *frame, V4L2Buffer *out)
>  }
>  
>  for (i = 0; i < out->num_planes; i++) {
> -ret = v4l2_bufref_to_buf(out, i, frame->buf[i]->data, 
> frame->buf[i]->size, 0, frame->buf[i]);
> +ret = v4l2_bufref_to_buf(out, i, frame->buf[i]->data, 
> frame->buf[i]->size, 0);
>  if (ret)
>  return ret;
>  }
> @@ -479,7 +479,7 @@ int ff_v4l2_buffer_avpkt_to_buf(const AVPacket *pkt, 
> V4L2Buffer *out)
>  {
>  int ret;
>  
> -ret = v4l2_bufref_to_buf(out, 0, pkt->data, pkt->size, 0, pkt->buf);
> +ret = v4l2_bufref_to_buf(out, 0, pkt->data, pkt->size, 0);
>  if (ret)
>  return ret;
>  
> 

Will apply this soon if no one objects.

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

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

Re: [FFmpeg-devel] [PATCH] ffplay: fix autoexit doesn't work in the case of pb->error

2020-09-06 Thread Zhao Zhili



> On Aug 27, 2020, at 4:20 PM, Marton Balint  wrote:
> 
> 
> 
> On Thu, 27 Aug 2020, Zhao Zhili wrote:
> 
>> ---
>> Goto fail will make ffplay exit immediately. I'm not sure
>> it is the expected behavior. How about just remove the
>> check on pb->error so decoders can drain normally?
> 
> I think it is fine as is, if we simply ignored the error, then looping would 
> start at the place of the error. Also probably it is not good practice to 
> keep using an IO context which already had an IO error.
> 
>> 
>> fftools/ffplay.c | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
>> index 6c9c041e9a..9ff0425163 100644
>> --- a/fftools/ffplay.c
>> +++ b/fftools/ffplay.c
>> @@ -3028,8 +3028,12 @@ static int read_thread(void *arg)
>>packet_queue_put_nullpacket(&is->subtitleq, 
>> is->subtitle_stream);
>>is->eof = 1;
>>}
>> -if (ic->pb && ic->pb->error)
>> -break;
>> +if (ic->pb && ic->pb->error) {
>> +if (autoexit)
>> +goto fail;
>> +else
>> +break;
>> +}
>>SDL_LockMutex(wait_mutex);
>>SDL_CondWaitTimeout(is->continue_read_thread, wait_mutex, 10);
>>SDL_UnlockMutex(wait_mutex);
> 
> LGTM, thanks.

Ping for further review or merge, thanks.

> 
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org  with 
> subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH 1/8] avcodec/jpeglsenc: Don't use put bits API for byte-aligned writes

2020-09-06 Thread Paul B Mahol

On Sat, Sep 05, 2020 at 01:17:09AM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt 
> ---
> Is it actually guaranteed that the allocated packet size is
> sufficient? If it is, one could use unchecked writes throughout; if it
> isn't, should I add a check to properly error out in case the buffer is
> too small? (And what would the return value be in this case?)
> 
>  libavcodec/jpeglsenc.c   | 80 +---
>  libavcodec/mjpegenc.h|  6 ---
>  libavcodec/mjpegenc_common.c |  6 +++
>  3 files changed, 52 insertions(+), 40 deletions(-)
> 

lgtm.

Packet size may be smaller than needed, if there is no check it will fail.

Usually it is allocated to max possible encoded packet size.

Can not be sure, need to try encoding special pixels combinations that
never happen in reality (almost).

Ultimately some codecs check if encoded packet gonna exceed uncompressed
frame than they just store uncompressed  and properly mark bitstream.
(Latest FFv1 encoder version, previous versions had this misfeature/bug)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/8] avcodec/jpeglsenc: Move check out of loop

2020-09-06 Thread Paul B Mahol

On Sat, Sep 05, 2020 at 01:17:11AM +0200, Andreas Rheinhardt wrote:
> ls_encode_line() encodes a line of input, going from left to right. In
> order to calculate a predicted value it uses the left and upper-left
> value of the output picture (that is, it uses how a decoder would see
> the already encoded part of the picture), unless this is the very first
> pixel of this line in which case one uses the first pixel of the last
> (upper) line and the line before the last line. Therefore the loop
> contained a check for whether this is the beginning of a new line. This
> commit moves said check out of the loop by initializing these values
> before the loop and by updating these values at the end of the loop
> body; already read/calculated values are reused for this (the prediction
> also needs the value of the upper pixel and this can be reused for the
> upper left value of the next iteration of the loop).
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/jpeglsenc.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/ffwavesynth: Fix integer overflow in wavesynth_synth_sample / WS_SINE

2020-09-06 Thread Nicolas George

Michael Niedermayer (12020-09-06):
> Fixes: signed integer overflow: -1429092 * -32596 cannot be represented in 
> type 'int'
> Fixes: 
> 24419/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5157849974702080
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ffwavesynth.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Ok.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to specify a device for VAAPI backend

2020-09-06 Thread Mark Thompson


On 03/09/2020 05:59, myp...@gmail.com wrote:

On Thu, Sep 3, 2020 at 9:21 AM Xiang, Haihao  wrote:

On Wed, 2020-09-02 at 14:04 +, Soft Works wrote:

-Original Message-
From: ffmpeg-devel  On Behalf Of
Rogozhkin, Dmitry V
Sent: Wednesday, September 2, 2020 3:54 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
specify a device for VAAPI backend

On Wed, 2020-09-02 at 07:31 +, Soft Works wrote:

-Original Message-
From: ffmpeg-devel  On Behalf Of
Rogozhkin, Dmitry V
Sent: Wednesday, September 2, 2020 9:00 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device
to specify a device for VAAPI backend

On Wed, 2020-09-02 at 04:28 +, Xiang, Haihao wrote:

On Wed, 2020-09-02 at 04:20 +, Soft Works wrote:

-Original Message-
From: ffmpeg-devel  On


Behalf


Of

Haihao Xiang
Sent: Wednesday, September 2, 2020 6:01 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Haihao Xiang 
Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
-hwaccel_device to specify a device for VAAPI backend

According to the FFmpeg documentation, -hwaccel_device can be
used to select a device for hardware acceleration

Example:
ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
h264_qsv \ -i
in.h264 -c:v hevc_qsv out.h265


No. The docs say about hwaccel_device

It can either refer to an existing device created with
-init_hw_device by name,

=> /dev/dri/renderD129 is not an existing device name

or it can create a new device as if ‘-init_hw_device’
type:hwaccel_device were called immediately before.

=> /dev/dri/renderD129 is not a valid string for init_hw_device


Well, it seems that's where documentation does not reflect the
reality since (as pointed by Haihao below)
https://trac.ffmpeg.org/wiki/Hardware/VAAPI
is full of contradictory examples.




Hence, the patch doesn't make sense.


in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,

If only one stream is being used, -hwaccel_device can also accept
a device path directly

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...

I think it can be applied to qsv too.



I agree. Part of ffmpeg help:
 -hwaccel hwaccel name  use HW accelerated decoding
 -hwaccel_device devicename  select a device for HW acceleration

To me specifying device via -hwaccel_device in the way it is being
suggest in commit is pretty intuitive and is better than explain
people that there is - qsv_device for that purpose. Niceness of
-hwaccel_device is that it is not tight to particular acceleration,
hence easier to work with for end users.


In case of QSV, the usage of hwaccel_device is already defined:

device selects a value in ‘MFX_IMPL_*’. Allowed values are:
auto sw  hw  auto_any hw_any hw2 hw3 hw4

I agree that it would be more intuitive, but you can't just give it a
different meaning from one day to another and break functionality.


Adding new values does not break functionality! No one  suggests to drop
existing set of values (sw, hw, etc.) - these are remaining. But basically
suggestion is to extend allowed set to accept drm device specification on
Linux, that's it. Honestly, I don't see problem here.
Some background story: hw,hw2,hw3 allows to select adapter for msdk
library on Windows, but they don't allow to do that on Linux. On Linux all
these hw options are basically the same for the reason that device is being
specified externally via SetHandle call. On Linux only sw/hw makes a
difference (other story that sw msdk library is not actually released
currently
on Linux). That's the origin of the request: we need a good way to specify
adapter on Linux.


As mentioned, there are cases where both needs to be specified on Windows:
hw, hw2, hw3,.. plus adapter number.

'qsv_device' is for specifying adapter number on Windows and DRI on Linux
'hwaccel_device' is for specifying hw, hw2, hw3 (everywhere)


According to https://trac.ffmpeg.org/ticket/7649, -qsv_device was added to
workaround device selection on Linux.

On Windows, we should not use another option to specify the adapter number, the
adapter is 1:1 mapped to the hw impl. I think we should fix it if the current
QSV depends on -qsv_device on Window.

https://github.com/Intel-Media-SDK/MediaSDK/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L245-L264



I see no reason to start mixing that and allowing to specify DRI via
'hwaccel_device' parameter.

That would make things just worse instead of improving anything.


 From user's perspective, we may use the same device selection for both QSV and
VAAPI on Linux. It is easy for user to move from QSV to VAAPI or inverse.


Which case want to mix the  QSV and VAAPI in one FFmpeg pipeline? Do
you have a real case for this?

I know we used  VAAPI as decoder and QSV as encoder before when QSV
decoder have some limitation in FFmpeg

But I think we are better to fix QSV decoder in FFmpeg part or MSDK,
do you have any other case to mix VAAPI and QSV?


Benefit

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/mips: Refine get_cabac_inline_mips.

On Sat, Sep 05, 2020 at 10:25:17AM +0800, Shiyou Yin wrote:
> 1. Refined function get_cabac_inline_mips.
> 2. Optimize function get_cabac_bypass and get_cabac_bypass_sign.
> 
> Speed of decoding h264: 5.23x ==> 5.45x(tested on 3A4000).
> ---
>  libavcodec/mips/cabac.h | 131 
> +---
>  1 file changed, 102 insertions(+), 29 deletions(-)

It seems this breaks build here

CC  libavcodec/h264_cabac.o
/tmp/ccQcUsBK.s: Assembler messages:
/tmp/ccQcUsBK.s:172: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $10,$10'
/tmp/ccQcUsBK.s:3391: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $24,$24'
/tmp/ccQcUsBK.s:3759: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $21,$21'
/tmp/ccQcUsBK.s:3837: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $21,$21'
/tmp/ccQcUsBK.s:3998: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $22,$22'
/tmp/ccQcUsBK.s:4074: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $21,$21'
/tmp/ccQcUsBK.s:4147: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $22,$22'
/tmp/ccQcUsBK.s:4213: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $22,$22'
/tmp/ccQcUsBK.s:4255: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $23,$23'
/tmp/ccQcUsBK.s:4383: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $21,$21'
/tmp/ccQcUsBK.s:4496: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $22,$22'
/tmp/ccQcUsBK.s:4572: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $21,$21'
/tmp/ccQcUsBK.s:4645: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $22,$22'
/tmp/ccQcUsBK.s:4711: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $22,$22'
/tmp/ccQcUsBK.s:4753: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $23,$23'
/tmp/ccQcUsBK.s:4798: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $21,$21'
/tmp/ccQcUsBK.s:5003: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $14,$14'
/tmp/ccQcUsBK.s:5099: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $25,$25'
/tmp/ccQcUsBK.s:5212: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $25,$25'
/tmp/ccQcUsBK.s:5283: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $25,$25'
/tmp/ccQcUsBK.s:5396: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $9,$9'
/tmp/ccQcUsBK.s:5721: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $21,$21'
/tmp/ccQcUsBK.s:5791: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $21,$21'
/tmp/ccQcUsBK.s:5960: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $22,$22'
/tmp/ccQcUsBK.s:6036: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $21,$21'
/tmp/ccQcUsBK.s:6110: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `dsbh $22,$22'
...

mips-linux-gnu-gcc-7 (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc

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

You can kill me, but you cannot change the truth.

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

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

Re: [FFmpeg-devel] [PATCH 8/8] avcodec/jpegls: Remove unused structure

On Sat, Sep 05, 2020 at 01:17:16AM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/jpegls.h | 4 
>  1 file changed, 4 deletions(-)

LGTM

thx

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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

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

[FFmpeg-devel] [PATCH] avformat/electronicarts: Check if there are any streams

Fixes: Assertion failure (invalid stream index)
Fixes: 
25120/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6565251898933248

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

diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 2ee5e1b6fa..6976a133c3 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -530,20 +530,17 @@ static int ea_read_header(AVFormatContext *s)
 if (ea->num_channels <= 0 || ea->num_channels > 2) {
 av_log(s, AV_LOG_WARNING,
"Unsupported number of channels: %d\n", ea->num_channels);
-ea->audio_codec = 0;
-return 1;
+goto no_audio;
 }
 if (ea->sample_rate <= 0) {
 av_log(s, AV_LOG_ERROR,
"Unsupported sample rate: %d\n", ea->sample_rate);
-ea->audio_codec = 0;
-return 1;
+goto no_audio;
 }
 if (ea->bytes <= 0 || ea->bytes > 2) {
 av_log(s, AV_LOG_ERROR,
"Invalid number of bytes per sample: %d\n", ea->bytes);
-ea->audio_codec = AV_CODEC_ID_NONE;
-return 1;
+goto no_audio;
 }
 
 /* initialize the audio decoder stream */
@@ -564,8 +561,13 @@ static int ea_read_header(AVFormatContext *s)
   
st->codecpar->bits_per_coded_sample;
 ea->audio_stream_index   = st->index;
 st->start_time   = 0;
+return 1;
 }
+no_audio:
+ea->audio_codec = AV_CODEC_ID_NONE;
 
+if (!ea->video.codec)
+return AVERROR_INVALIDDATA;
 return 1;
 }
 
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH] tiff: remove tiff type check for ICC profiles

2020-09-06 Thread Lynne

Sep 5, 2020, 20:23 by d...@lynne.ee:

> Although the ICC specifications say to check for this, libtiff doesn't
> and neither does any other TIFF implementation, and the TIFF specs
> say that Photoshop has a different way to encapsulate ICC profiles,
> and are asking for advice on how to deal with it.
>
> So basically, photoshop puts a different type than what's specified,
> no other implementation checks for this, we do because we tried to
> follow the specs although its harmless to not, and ran into this bug
> because we didn't know about it.
>
> Patch attached.
>

Patch applied and bug closed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avcodec/hlsenc: Fix playlist not getting flushed when using custom io

2020-09-06 Thread Steve Lam

---
 libavformat/hlsenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index cb31d6aed7..fdfa907234 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -287,6 +287,7 @@ static int hlsenc_io_close(AVFormatContext *s, AVIOContext 
**pb, char *filename)
 if (!*pb)
 return ret;
 if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
hls->encrypt) {
+avio_flush(*pb);
 ff_format_io_close(s, pb);
 #if CONFIG_HTTP_PROTOCOL
 } else {
-- 
2.17.1


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

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

Re: [FFmpeg-devel] [PATCH] avformat/electronicarts: Check if there are any streams

2020-09-06 Thread James Almer

On 9/6/2020 7:57 PM, Michael Niedermayer wrote:
> Fixes: Assertion failure (invalid stream index)
> Fixes: 
> 25120/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6565251898933248
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/electronicarts.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
> index 2ee5e1b6fa..6976a133c3 100644
> --- a/libavformat/electronicarts.c
> +++ b/libavformat/electronicarts.c
> @@ -530,20 +530,17 @@ static int ea_read_header(AVFormatContext *s)
>  if (ea->num_channels <= 0 || ea->num_channels > 2) {
>  av_log(s, AV_LOG_WARNING,
> "Unsupported number of channels: %d\n", ea->num_channels);
> -ea->audio_codec = 0;
> -return 1;
> +goto no_audio;
>  }
>  if (ea->sample_rate <= 0) {
>  av_log(s, AV_LOG_ERROR,
> "Unsupported sample rate: %d\n", ea->sample_rate);
> -ea->audio_codec = 0;
> -return 1;
> +goto no_audio;
>  }
>  if (ea->bytes <= 0 || ea->bytes > 2) {
>  av_log(s, AV_LOG_ERROR,
> "Invalid number of bytes per sample: %d\n", ea->bytes);
> -ea->audio_codec = AV_CODEC_ID_NONE;
> -return 1;
> +goto no_audio;
>  }
>  
>  /* initialize the audio decoder stream */
> @@ -564,8 +561,13 @@ static int ea_read_header(AVFormatContext *s)
>
> st->codecpar->bits_per_coded_sample;
>  ea->audio_stream_index   = st->index;
>  st->start_time   = 0;
> +return 1;

fwiw, return value for AVInputFormat.read_header() should be 0 for
success, < 0 for failure (Mind, while > 0 is not defined, it's currently
treated like 0).

>  }
> +no_audio:
> +ea->audio_codec = AV_CODEC_ID_NONE;
>  
> +if (!ea->video.codec)
> +return AVERROR_INVALIDDATA;
>  return 1;
>  }
>  
> 

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

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

[FFmpeg-devel] [PATCH 04/10] avformat/segment: Fix segfault when error happens and segment list is output

The segment muxer has an option to output a file containing a list of
the segments written. The AVIOContext used for writing this file is
opened via the main AVFormatContext's io_open callback; seg_free()
meanwhile unconditionally closes this AVIOContext by calling
ff_format_io_close() with the child muxer (the one for the actual output
format) as AVFormatContext.

The problem hereby is that the child AVFormatContext need not exist,
even when the AVIOContext does. This leads to a segfault in
ff_format_io_close() when the child muxer's io_close callback is called.

Situations in which the AVFormatContext can be NULL range from an
invalid reference stream parameter to an unavailable/bogus/unsupported
output format to inability to allocate the AVFormatContext.

The solution is to simply close the AVIOContext with the AVFormatContext
that was used to open it: The main AVFormatContext.

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

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 9fafec0e35..e30e47b62e 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -660,7 +660,7 @@ static int select_reference_stream(AVFormatContext *s)
 static void seg_free(AVFormatContext *s)
 {
 SegmentContext *seg = s->priv_data;
-ff_format_io_close(seg->avf, &seg->list_pb);
+ff_format_io_close(s, &seg->list_pb);
 avformat_free_context(seg->avf);
 seg->avf = NULL;
 av_freep(&seg->times);
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 09/10] avformat/segment: Fix error messages

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

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 0253b750b8..3dcbda6957 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -511,7 +511,7 @@ static int parse_times(void *log_ctx, int64_t **times, int 
*nb_times,
 /* check on monotonicity */
 if (i && (*times)[i-1] > (*times)[i]) {
 av_log(log_ctx, AV_LOG_ERROR,
-   "Specified time %f is greater than the following time %f\n",
+   "Specified time %f is smaller than the last time %f\n",
(float)((*times)[i])/100, 
(float)((*times)[i-1])/100);
 FAIL(AVERROR(EINVAL));
 }
@@ -561,7 +561,7 @@ static int parse_frames(void *log_ctx, int **frames, int 
*nb_frames,
 f = strtol(fstr, &tailptr, 10);
 if (*tailptr || f <= 0 || f >= INT_MAX) {
 av_log(log_ctx, AV_LOG_ERROR,
-   "Invalid argument '%s', must be a positive integer <= 
INT64_MAX\n",
+   "Invalid argument '%s', must be a positive integer < 
INT_MAX\n",
fstr);
 FAIL(AVERROR(EINVAL));
 }
@@ -570,7 +570,7 @@ static int parse_frames(void *log_ctx, int **frames, int 
*nb_frames,
 /* check on monotonicity */
 if (i && (*frames)[i-1] > (*frames)[i]) {
 av_log(log_ctx, AV_LOG_ERROR,
-   "Specified frame %d is greater than the following frame 
%d\n",
+   "Specified frame %d is smaller than the last frame %d\n",
(*frames)[i], (*frames)[i-1]);
 FAIL(AVERROR(EINVAL));
 }
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 06/10] avformat/segment: Fix leak and invalid free of AVIOContext

seg_init() and seg_write_header() currently contain a few error paths
in which an already opened AVIOContext for the child muxer leaks (namely
if there are unrecognized options for the child muxer or if writing the
header of the child muxer fails); the reason for this is that this
AVIOContext is not closed in the deinit function. If all goes well, it
is closed when writing the trailer. From this it also follows that the
AVIOContext also leaks when the trailer is never written, even when
writing the header succeeds.

But simply freeing said AVIOContext in the deinit function is
complicated by the fact that the AVIOContext may or may not have been
opened via the io_open callback: If options are set to discard header
and trailer, said AVIOContext can also be a null context which must not
be closed via the io_close callback. This may lead to crashes, as
io_close may presume the AVIOContext's opaque to be set. It currently
works with the default io_close callback which simply calls avio_close(),
because avio_close() doesn't care about opaque being NULL since commit
6e8e8431e15a58aa44cfdd8c11f9ea096837c0fa. Therefore this commit records
which of the two kinds of AVIOContext is currently in use to use the
right way to close it.

Finally there was one instance (namely if initializing the child muxer
fails with no unrecognized options) where the AVIOContext was always
closed via the io_close callback. The above remark applies to this; it
has been fixed, too.

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

diff --git a/libavformat/segment.c b/libavformat/segment.c
index b8eb0289c4..55d7f62ca0 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -80,6 +80,7 @@ typedef struct SegmentContext {
 int   list_flags;  ///< flags affecting list generation
 int   list_size;   ///< number of entries for the segment list file
 
+int is_nullctx;   ///< whether avf->pb is a nullctx
 int use_clocktime;///< flag to cut segments at regular clock time
 int64_t clocktime_offset; //< clock offset for cutting the segments at 
regular clock time
 int64_t clocktime_wrap_duration; //< wrapping duration considered for 
starting a new segment
@@ -661,8 +662,14 @@ static void seg_free(AVFormatContext *s)
 {
 SegmentContext *seg = s->priv_data;
 ff_format_io_close(s, &seg->list_pb);
-avformat_free_context(seg->avf);
-seg->avf = NULL;
+if (seg->avf) {
+if (seg->is_nullctx)
+close_null_ctxp(&seg->avf->pb);
+else
+ff_format_io_close(s, &seg->avf->pb);
+avformat_free_context(seg->avf);
+seg->avf = NULL;
+}
 av_freep(&seg->times);
 av_freep(&seg->frames);
 av_freep(&seg->cur_entry.filename);
@@ -777,6 +784,7 @@ static int seg_init(AVFormatContext *s)
 } else {
 if ((ret = open_null_ctx(&oc->pb)) < 0)
 return ret;
+seg->is_nullctx = 1;
 }
 
 av_dict_copy(&options, seg->format_options, 0);
@@ -791,7 +799,6 @@ static int seg_init(AVFormatContext *s)
 av_dict_free(&options);
 
 if (ret < 0) {
-ff_format_io_close(oc, &oc->pb);
 return ret;
 }
 seg->segment_frame_count = 0;
@@ -834,6 +841,7 @@ static int seg_write_header(AVFormatContext *s)
 ff_format_io_close(oc, &oc->pb);
 } else {
 close_null_ctxp(&oc->pb);
+seg->is_nullctx = 0;
 }
 if ((ret = oc->io_open(oc, &oc->pb, oc->url, AVIO_FLAG_WRITE, NULL)) < 
0)
 return ret;
@@ -984,6 +992,7 @@ static int seg_write_trailer(struct AVFormatContext *s)
 goto fail;
 if ((ret = open_null_ctx(&oc->pb)) < 0)
 goto fail;
+seg->is_nullctx = 1;
 ret = av_write_trailer(oc);
 close_null_ctxp(&oc->pb);
 } else {
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 08/10] avformat/segment: Remove redundant code for freeing in write_trailer

This code mostly duplicates code in the deinit function; the only
exception is av_opt_free(): The options are freed generically lateron.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/segment.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index d895e6a678..0253b750b8 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -991,30 +991,21 @@ static int seg_write_trailer(struct AVFormatContext *s)
 {
 SegmentContext *seg = s->priv_data;
 AVFormatContext *oc = seg->avf;
-int ret = 0;
+int ret;
 
 if (!oc)
-goto fail;
+return 0;
 
 if (!seg->write_header_trailer) {
 if ((ret = segment_end(s, 0, 1)) < 0)
-goto fail;
+return ret;
 if ((ret = open_null_ctx(&oc->pb)) < 0)
-goto fail;
+return ret;
 seg->is_nullctx = 1;
 ret = av_write_trailer(oc);
-close_null_ctxp(&oc->pb);
 } else {
 ret = segment_end(s, 1, 1);
 }
-fail:
-if (seg->list)
-ff_format_io_close(s, &seg->list_pb);
-
-av_opt_free(seg);
-
-avformat_free_context(oc);
-seg->avf = NULL;
 return ret;
 }
 
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 10/10] avformat/segment: Avoid duplicating string when parsing frames list

Signed-off-by: Andreas Rheinhardt 
---
The first check in the loop could be removed btw; its only advantage is
a better error message.

 libavformat/segment.c | 38 ++
 1 file changed, 14 insertions(+), 24 deletions(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 3dcbda6957..38fca253a2 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -525,46 +525,38 @@ end:
 static int parse_frames(void *log_ctx, int **frames, int *nb_frames,
 const char *frames_str)
 {
-char *p;
-int i, ret = 0;
-char *frames_str1 = av_strdup(frames_str);
-char *saveptr = NULL;
-
-if (!frames_str1)
-return AVERROR(ENOMEM);
-
-#define FAIL(err) ret = err; goto end
+const char *p;
+int i;
 
 *nb_frames = 1;
-for (p = frames_str1; *p; p++)
+for (p = frames_str; *p; p++)
 if (*p == ',')
 (*nb_frames)++;
 
 *frames = av_malloc_array(*nb_frames, sizeof(**frames));
 if (!*frames) {
 av_log(log_ctx, AV_LOG_ERROR, "Could not allocate forced frames 
array\n");
-FAIL(AVERROR(ENOMEM));
+return AVERROR(ENOMEM);
 }
 
-p = frames_str1;
+p = frames_str;
 for (i = 0; i < *nb_frames; i++) {
 long int f;
 char *tailptr;
-char *fstr = av_strtok(p, ",", &saveptr);
 
-p = NULL;
-if (!fstr) {
+if (*p == '\0' || *p == ',') {
 av_log(log_ctx, AV_LOG_ERROR, "Empty frame specification in frame 
list %s\n",
frames_str);
-FAIL(AVERROR(EINVAL));
+return AVERROR(EINVAL);
 }
-f = strtol(fstr, &tailptr, 10);
-if (*tailptr || f <= 0 || f >= INT_MAX) {
+f = strtol(p, &tailptr, 10);
+if (*tailptr != '\0' && *tailptr != ',' || f <= 0 || f >= INT_MAX) {
 av_log(log_ctx, AV_LOG_ERROR,
"Invalid argument '%s', must be a positive integer < 
INT_MAX\n",
-   fstr);
-FAIL(AVERROR(EINVAL));
+   p);
+return AVERROR(EINVAL);
 }
+p = tailptr + 1; /* Might point one past '\0' */
 (*frames)[i] = f;
 
 /* check on monotonicity */
@@ -572,13 +564,11 @@ static int parse_frames(void *log_ctx, int **frames, int 
*nb_frames,
 av_log(log_ctx, AV_LOG_ERROR,
"Specified frame %d is smaller than the last frame %d\n",
(*frames)[i], (*frames)[i-1]);
-FAIL(AVERROR(EINVAL));
+return AVERROR(EINVAL);
 }
 }
 
-end:
-av_free(frames_str1);
-return ret;
+return 0;
 }
 
 static int open_null_ctx(AVIOContext **ctx)
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 05/10] avformat/segment: Fix leak of string on error

A string containing the segment's filename that the segment muxer
allocates got only freed in its write_trailer function. This implies
that it leaks if write_trailer is never called, e.g. if initializing
the child muxer fails. This commit fixes this by freeing the string
in the deinit function instead.

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

diff --git a/libavformat/segment.c b/libavformat/segment.c
index e30e47b62e..b8eb0289c4 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -665,6 +665,7 @@ static void seg_free(AVFormatContext *s)
 seg->avf = NULL;
 av_freep(&seg->times);
 av_freep(&seg->frames);
+av_freep(&seg->cur_entry.filename);
 }
 
 static int seg_init(AVFormatContext *s)
@@ -993,7 +994,6 @@ fail:
 ff_format_io_close(s, &seg->list_pb);
 
 av_opt_free(seg);
-av_freep(&seg->cur_entry.filename);
 
 cur = seg->segment_list_entries;
 while (cur) {
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 01/10] avformat/segment: Don't overwrite AVCodecParameters after init

The segment muxer copies the user-provided AVCodecParameters to the
newly created child streams in its init function before initializing the
child muxer; and since commit 8e6478b723affe4d44f94d34b98e0c47f6a0b411,
it does this again before calling avformat_write_header() if that is
called from seg_write_header(). The reason for this is complicated:

At that time writing the header was delayed, i.e. it was not triggered
by avformat_write_header() (unless the AVFMT_FLAG_AUTO_BSF was unset),
but instead by writing the very first packet. The rationale behind this
was to allow to run bitstream filters on the packets in the interleavement
queue in order to generate missing extradata from them before the muxer's
write_header function is actually called.

The segment muxer went even further: It initialized the child muxer and
ran the child muxer's check_bitstream functions on the packets in its
own muxing queue and stole any bitstream filters that got inserted. The
reason for this is that the segment muxer has an option to write the
header to a separate file and for this it is needed to write the child
muxer's header without delay, but with correct extradata. Unsetting
AVFMT_FLAG_AUTO_BSF for the child muxer accomplished the first goal and
stealing the bitstream filters the second; and in order for the child
muxer to actually use the updated extradata, the old AVCodecParameters
(set before avformat_init_output()) were overwritten with the new ones.

Updating the extradata proceeded as follows: The bitstream filter itself
simply updated the AVBSFContext's par_out when processing a packet, in
violation of the new BSF API (where par_out may only be set in the init
function); the muxing code then simply forwarded the updated extradata,
overwriting the par_in of the next BSF in the BSF chain with the fresh
par_out of the last one and the AVStream's par with the par_out of the
last BSF. This was an API violation, too, of course, but it made
remuxing ADTS AAC into mp4/matroska work.

But this no longer serves a useful purpose since the aac_adtstoasc BSF
was updated to propagate new extradata via packet side data in commit
f63c3516577d605e51cf16358cbdfa0bc97565d8; the next commit then removed
the code in mux.c passing new extradata along the filter chain. This
alone justifies removing the code for setting the AVCodecParameters a
second time.

But there is even another reason to do so: It is harmful. The ogg muxer
parses the extradata of Theora and Vorbis in its init function and keeps
pointers to parts of it. Said pointers become dangling when the
extradata is overwritten by the segment muxer, leading to
use-after-frees as has happened in ticket #8881 which this commit fixes.

Ticket #8517 is about another issue caused by this: Immediately after
having overwritten the old AVCodecParameters the segment muxer checks
whether the codec_tag is ok (the codec_tag is set generically when
initializing the child muxer based upon muxer-specific lists). The check
used is: If the child output format has such a list and if the codec tag
of the non-child stream does not match the codec id given the list of
codec tags and if there is a match for the codec id in the codec tag
list, then set the codec tag to zero (and not to the existing match),
otherwise set the codec tag of the child stream to the codec tag
of the corresponding stream of the main AVFormatContext (which is btw
redundant given that the child AVCodecParameters have just been
overwritten with the AVCodecParameters of the corresponding stream of
the main AVFormatContext).

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/segment.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index f67456fa57..0c9b93725d 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -817,26 +817,9 @@ static int seg_write_header(AVFormatContext *s)
 {
 SegmentContext *seg = s->priv_data;
 AVFormatContext *oc = seg->avf;
-int ret, i;
+int ret;
 
 if (!seg->header_written) {
-for (i = 0; i < s->nb_streams; i++) {
-AVStream *st = oc->streams[i];
-AVCodecParameters *ipar, *opar;
-
-ipar = s->streams[i]->codecpar;
-opar = oc->streams[i]->codecpar;
-avcodec_parameters_copy(opar, ipar);
-if (!oc->oformat->codec_tag ||
-av_codec_get_id (oc->oformat->codec_tag, ipar->codec_tag) == 
opar->codec_id ||
-av_codec_get_tag(oc->oformat->codec_tag, ipar->codec_id) <= 0) 
{
-opar->codec_tag = ipar->codec_tag;
-} else {
-opar->codec_tag = 0;
-}
-st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio;
-st->time_base = s->streams[i]->time_base;
-}
 ret = avformat_write_header(oc, NULL);
 if (ret < 0)
 return ret;
-- 
2.20.1

___
f

[FFmpeg-devel] [PATCH 03/10] avformat/segment: Fix segfault on allocation error, avoid allocation

If the user has set none of the options specifying the segments'
durations, a default value of 2s is used by duplicating a "2" string and
using av_parse_time() on it. Yet duplicating the string was unchecked
and if the allocation failed, one would get a segfault in
av_parse_time().

This commit solves this by avoiding duplicating the string altogether if
no string has been provided; instead the duration is set explicitly to
what av_parse_time() would return for the string "2".

Signed-off-by: Andreas Rheinhardt 
---
One could btw make the segment_time an option of type
AV_OPT_TYPE_DURATION, but then one could no longer distinguish the cases
in which the value has been set to its default value by the user and the
one in which the user hasn't set the option at all. Would this be a
problem?

Btw: Why are values <= 0 allowed for this?

 libavformat/segment.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 0c96c8c50c..9fafec0e35 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -704,9 +704,9 @@ static int seg_init(AVFormatContext *s)
 return ret;
 } else {
 /* set default value if not specified */
-if (!seg->time_str)
-seg->time_str = av_strdup("2");
-if ((ret = av_parse_time(&seg->time, seg->time_str, 1)) < 0) {
+if (!seg->time_str) {
+seg->time = 200;
+} else if ((ret = av_parse_time(&seg->time, seg->time_str, 1)) < 0) {
 av_log(s, AV_LOG_ERROR,
"Invalid time duration specification '%s' for segment_time 
option\n",
seg->time_str);
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 02/10] avformat/segment: Fix leak of duration/framenumber lists upon error

The code to free them is not in the segment muxer's deinit function,
but in its write_trailer function which means that these lists leak if
write_trailer isn't called after their allocation. This happens e.g. if
the given lists are invalid (e.g. consisting only of ',' (which delimit
entries)), so that parsing them fails and so does the muxer's init
function; write_trailer is then never called.

This has been fixed by moving the code to free them to the deinit
function.

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

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 0c9b93725d..0c96c8c50c 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -663,6 +663,8 @@ static void seg_free(AVFormatContext *s)
 ff_format_io_close(seg->avf, &seg->list_pb);
 avformat_free_context(seg->avf);
 seg->avf = NULL;
+av_freep(&seg->times);
+av_freep(&seg->frames);
 }
 
 static int seg_init(AVFormatContext *s)
@@ -991,8 +993,6 @@ fail:
 ff_format_io_close(s, &seg->list_pb);
 
 av_opt_free(seg);
-av_freep(&seg->times);
-av_freep(&seg->frames);
 av_freep(&seg->cur_entry.filename);
 
 cur = seg->segment_list_entries;
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 07/10] avformat/segment: Free SegmentListEntries in deinit, not write_trailer