I just realized that count+1 itself might overflow if count==UINT_MAX, so I
guess it's better to subtract 1 from the right-hand side. Attached updated
patch.
On Wed, Sep 7, 2016 at 2:21 PM, Sergey Volk wrote:
> Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
>
Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
we need to check that (count + 1) won't cause overflow.
From cfc0f5a099284c95476d5c020dca05fb743ff5ae Mon Sep 17 00:00:00 2001
From: Sergey Volk
Date: Wed, 7 Sep 2016 14:05:35 -0700
Subject: [PATCH] Fix potential in
Looks like it's failing here:
https://code.google.com/p/chromium/codesearch#chromium/src/media/filters/ffmpeg_audio_decoder.cc&l=419
Here is the error message I got from Chrome:
[1:9:0428/101459:VERBOSE2:decoder_selector.cc(195)] InitializeDecoder
[1:9:0428/101459:ERROR:ffmpeg_audio_decoder.cc(421
his directly).
Any opinions on this?
On Thu, Mar 10, 2016 at 12:19 AM, Nicolas George wrote:
> Thanks for the patch.
>
> Le decadi 20 ventôse, an CCXXIV, Sergey Volk a écrit :
> > I have also bumped the major version to 58 locally in version.h, and
> > re-ran make with th
Yeah, I was using Gmail web interface, it does that. I'll try attaching the
patch file next time.
On Thu, Mar 10, 2016 at 1:23 AM, Moritz Barsnick wrote:
> On Wed, Mar 09, 2016 at 15:56:53 -0800, Sergey Volk wrote:
> > -if (fmt_ctx->iformat->flags & AVFMT_SHO
From: Sergey Volk
Date: Wed, 9 Mar 2016 14:34:19 -0800
Subject: [PATCH] Change AVStream::id to int64_t in the next version bump
I have also bumped the major version to 58 locally in version.h, and
re-ran make with the stream id being int64_t and fixed all new
warnings that showed up (only saw
t; On Fri, Mar 04, 2016 at 04:19:18PM -0800, Sergey Volk wrote:
>> Ok, something like this for now, then?
>
> your original patch contained a nice commit message, this one
> doesnt
>
>
>> I'm new to ffmpeg development. When is the next version bump going to hap
Ok, something like this for now, then?
I'm new to ffmpeg development. When is the next version bump going to happen?
---
libavformat/matroskadec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index d20568c..4c3e53a 100644
--- a/libavf
As far as I can see FFmpeg currently doesn't set AVStream::id for
matroska/webm streams. I think we could use either MatroskaTrack::num
(TrackNumber) or MatroskaTrack::uid (TrackUID) for that.
I have found a few discussions claiming that TrackUID could be missing,
even though TrackUID is marked as