Hi,
It's possible that it fixes the issue. When I did the patch I noticed some
places used a similar value and some are using -1. I think this should be a
define (probably set to UINT64_MAX) that is used everywhere. It's just a marker
to say the length is unknown.
> On February 22, 2019 at 9:
Sent http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240418.html -
which passes fate and fixes the issue with our test clip.
- dale
On Fri, Feb 22, 2019 at 12:31 PM Dale Curtis
wrote:
> +steve who submitted the original patch.
>
> - dale
>
>
> On Thu, Feb 21, 2019 at 2:30 PM Dale Curtis
+steve who submitted the original patch.
- dale
On Thu, Feb 21, 2019 at 2:30 PM Dale Curtis wrote:
> One of our test clips is behaving differently after this patch:
> https://cs.chromium.org/chromium/src/media/test/data/bear-320x240-live.webm
>
> The printed log message is:
> [matroska,webm @
One of our test clips is behaving differently after this patch:
https://cs.chromium.org/chromium/src/media/test/data/bear-320x240-live.webm
The printed log message is:
[matroska,webm @ 0x1516c84f4e00] Invalid length 0xff >
0x12f in parent
Looking through the code I'm unsur
On Wed, Feb 13, 2019 at 01:41:31PM +0100, Michael Niedermayer wrote:
> Reported-by: Steve Lhomme
> This was found through the Hacker One program on VLC but is not a security
> issue in libavformat
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/matroskadec.c | 21 +
>
Reported-by: Steve Lhomme
This was found through the Hacker One program on VLC but is not a security
issue in libavformat
Signed-off-by: Michael Niedermayer
---
libavformat/matroskadec.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/libavformat/matroskadec.c b/libavf
