ffmpeg segfaults with large ogg/vorbis files

[Philius]

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.

[cehoyos]

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

[Philius]

gdb session

[Philius]

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.

[saste]

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

For applying the patches:
git am PATCH

then configure+make+test.

[Philius]

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

[cehoyos]

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

[Philius]

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.

[Philius]

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.

[saste]

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.

[Philius]

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

[michael]

Please upload the first 2mb of the ogg file

[Philius]

First 2MB of 2.5GB ogv

[Philius]

Please find attached the output of

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

Philip