Opened 10 years ago

Closed 10 years ago

#185 closed defect (fixed)

ffmpeg segfaults with large ogg/vorbis files

Reported by: Philip Ashmore Owned by:
Priority: important Component: avformat
Version: git-master Keywords: segfault ogg/vorbis
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

I've got a 2.7GB ogg/vorbis file I want to convert to an AVI.
I recorded it with cheese.
I built a debugging version of ffmpeg 0.6.1 and ran it under kdbg to track it down.
The problem is in oggdec.c line 282.
It's trying to double the buffer size and that allocation fails, but this isn't checked.

I think mmap() is the only way to go with such large files.
Question: can ffmpeg or some other program split up a large file before processing?
ffmpeg would need to be aware of this for two-pass processing.
I downloaded ffmpeg-0.7-rc1 and the problem in oggdec.c is still there.

Attachments (4)

gdb.txt (12.6 KB ) - added by Philip Ashmore 10 years ago.
gdb session
0001-mem-prefer-SIZE_MAX-over-INT_MAX-in-av_malloc-and-av.patch (1021 bytes ) - added by Stefano Sabatini 10 years ago.
0002-oggdec-add-integer-overflow-and-allocation-check-in-.patch (1.0 KB ) - added by Stefano Sabatini 10 years ago.
1st2MB.ogv (2.0 MB ) - added by Philip Ashmore 10 years ago.
First 2MB of 2.5GB ogv

Change History (16)

comment:1 by Carl Eugen Hoyos, 10 years ago

Priority: normalimportant
Status: newopen
Version: unspecifiedgit-master

Please try latest git master and provide the complete output and backtrace etc. when you observe the crash as explained on http://ffmpeg.org/bugreports.html

by Philip Ashmore, 10 years ago

Attachment: gdb.txt added

gdb session

comment:2 by Philip Ashmore, 10 years ago

Done.

Since the problem was inside memcpy.c, the disassembly wouldn't be useful, but for future reference,
what does "disass $pc-32 $pc+32" mean? gdb didn't understand it.

comment:3 by Stefano Sabatini, 10 years ago

Please try latest git with the attached patches 0001 and 0002.

For applying the patches:
git am PATCH

then configure+make+test.

comment:4 by Philip Ashmore, 10 years ago

I did a

git pull -a

Then I downloaded the patches into a "patches" sibling directory and then did

cat ../patches/*.patch | git-am

and re-ran configure.
I got the following error

ERROR: libx264 version must be >= 0.115.

I had a look at wheezy's repos and libx264 only goes up to 112, so it's a no-go on Debian for the
moment.

I recorded the "problem" video using cheese - about 49 minutes @ 640x480, video 30Hz
, audio 1 channel @ 44,100KHz, which came to 2.5GB.
I ended up splitting the conversion run into 30 mins + 19 mins and joining the two avi's, dropping the
audio and rotating 180 degrees - I recorded myself solving a sudoku puzzle in real-time to try to
capture the stream-of-consciousness involved, so small flurries of activity in a mostly static frame.

The video info claims 30fps but it looks more like 2-3 fps which may be because of disk/cpu
bottle-necking + small variations in lighting conditions affecting overall illumination, if that helps.

The resulting AVIs have visible tinges of green(top) + pink(bottom) which aren't present in the
original, with -sameq(246MB) and hqdn(73MB).

comment:5 by Carl Eugen Hoyos, 10 years ago

You do not need x264 to test Stefano's patches.

comment:6 by Philip Ashmore, 10 years ago

Done.

I recently upgraded the kernel to 2.6.38-2-amd64 because it looked like my swap space wasn't being used.

It's being used now.

The conversion used all 3GB of my physical memory plus another 3.4GB of swap to complete.
Those green/pink tinges are no longer there.

comment:7 by Philip Ashmore, 10 years ago

The final output after

ffmpeg -i sudoku-0.7.1-ud.avi -vf "hflip,vflip,hqdn3d" sudoku-0.7.1.avi

came to 58.2MB.

comment:8 by Stefano Sabatini, 10 years ago

Back to the original issue, can you confirm that patch 0002 fixes the reported crash?

You don't need libx264, filters or other stuff, for testing it, try the simplest possible command.

comment:9 by Philip Ashmore, 10 years ago

Huh? To summarize comments (4) through (7),

  1. I applied the two patches on a freshly git-pulled repo (4)
  2. got stuck with x264 (4)
  3. was informed it wasn't needed for the test (5)
  4. proceeded with the build/test (6)
  5. it uses a lot of memory, but works (6)
  6. it results in a smaller and better quality AVI(6,7)

Regards,
Philip

comment:10 by Michael Niedermayer, 10 years ago

Please upload the first 2mb of the ogg file

by Philip Ashmore, 10 years ago

Attachment: 1st2MB.ogv added

First 2MB of 2.5GB ogv

comment:11 by Philip Ashmore, 10 years ago

Please find attached the output of

dd if=2011-05-10-021123.ogv of=1st2MB.ogv bs=1M count=2

Philip

comment:12 by Michael Niedermayer, 10 years ago

Reproduced by developer: set
Resolution: fixed
Status: openclosed
Note: See TracTickets for help on using tickets.