Out of memory handling in ffmpeg

[GoogleCodeExporter]

Not all parts of ffmpeg code handle out of memory conditions.
Is it possible to patch the ffmpeg so it does not crash? 

Original issue reported on code.google.com by paveltbo...@gmail.com on 22 Nov 2013 at 9:59

Attachments:

• ffmpeg_malloc.rtf

[GoogleCodeExporter]

I suggest to report unchecked allocations to ffmpeg directly. I don't develop 
ffmpeg, i just use it.

Original comment by h.lepp...@gmail.com on 23 Nov 2013 at 5:51

• Changed state: Upstream

[GoogleCodeExporter]

Thanks LAV Filters Developer!
We worked with you before on similar issue a year ago. I am one of the
owners of MotionRocket LLC.
You have implemented an option for us in LAV Splitter for max cache size
which found it's place in the mainstream LAV Filters code.
We would like to make similar donation to your project if you are willing
to submit that bug to ffmpeg since you have certain credibility with them.
If we do that it may take a lot longer.

Best regards:
Pavel Bonev

Original comment by paveltbo...@gmail.com on 24 Nov 2013 at 3:47

[GoogleCodeExporter]

I fixed the one allocation that you pointed out in your document myself and 
submitted the patch to ffmpeg for inclusion.

After fixing this, I can't get it to crash anymore.
Maybe you want to try? Here is a test build:

http://files.1f0.de/lavf/LAVFilters-0.59.1-35-g0fa14cd.zip

Original comment by h.lepp...@gmail.com on 24 Nov 2013 at 9:00

• Changed state: Started

[GoogleCodeExporter]

Not crashing there any more. It deadlock however in seek to position when in 
low memory state.

Original comment by paveltbo...@gmail.com on 10 Dec 2013 at 2:24

[GoogleCodeExporter]

Also 64-bit performance of version 0.59.1 is much lower compared to 64-bit v 
0.58.2 and 32-bit 0.59.1. Test file: Elysium 4K trailer.

Original comment by paveltbo...@gmail.com on 10 Dec 2013 at 3:46

[GoogleCodeExporter]

Seeking is a bit of a problem in DirectShow, if seeking fails because there is 
no memory to execute the operation, it'll most likely end in a bad situation. 
Not sure how to really improve on that.

Regarding 64-bit, there was a build issue in 0.59.1 that disabled 
multi-threaded decoding on some codecs. The build system was fixed and the 
issue should not happen again, hopefully.

Original comment by h.lepp...@gmail.com on 10 Dec 2013 at 9:26

[GoogleCodeExporter]

Is there an updated install (32 and 64-bit) with ffmpeg patch we can test?

Original comment by paveltbo...@gmail.com on 11 Dec 2013 at 11:30

[GoogleCodeExporter]

These fixes are included in 0.60.1. Please re-open the issue if it still 
crashes.

Original comment by h.lepp...@gmail.com on 26 Jan 2014 at 9:32

• Changed state: Fixed