lavf demuxer/decoder memory leak?

[zapco]

I'm running the latest rev of x264 - 1834 8-bit depth/32-bit compile on WinXP SP3 - and have just tried moving from Avisynth to direct .m2ts input to x264.

I'm making lower-bitrate/DVD9 backups of some of my Blu-rays, so the incoming video is all 1920x1080@24p H264 or VC-1.

The issue I'm having is that x264's memory usage - when using lavf as the demuxer - goes through the roof. It initializes at around 450 MB, and then just continues to climb as it encodes, passing the 1GB mark at around 20000 frames (I have 1GB RAM).

Is this a known bug, and/or is there any workaround? I'm specifically not using ffms because of its insistence on indexing, which I don't need (these are all one-shot encodes - I'm not doing any editing or processing at all) and which would literally take hours to do over my network from my NAS.

I guess the other question would be: can ffms' indexing be disabled?

Oh, and FWIW, here's my command line:

x264.1834.exe --demuxer lavf --force-cfr --crf 19 --tune film -o output.mkv input.m2ts

[kemuri-_9]

I'm running the latest rev of x264 - 1834 8-bit depth/32-bit compile on WinXP SP3 - and have just tried moving from Avisynth to direct .m2ts input to x264.

I'm making lower-bitrate/DVD9 backups of some of my Blu-rays, so the incoming video is all 1920x1080@24p H264 or VC-1.


is the leak occurring with only one of h264 or vc-1 source m2ts or both?

a sample that can reproduce the issue also helps.

I guess the other question would be: can ffms' indexing be disabled?

no, indexing is mandatory through how ffms works by design, it can not be disabled.

I'm grabbing some samples off of mplayer's site to see if i can replicate a leak in the mean time.

Edit:
Also, where did you get that build of x264? knowing which version of ffmpeg it was built against can also be helpful...

[zapco]

Thanks for the response, kemuri.

It's happening with both H264 and VC-1, although H264 seems to be a bit more "extreme," i.e. the memory usage rises faster (H264 @ 20000 frames is ~1GB, VC-1 @ 20000 is around 900 MB). Also, I've only had the opportunity to do longer encodes with a couple files of each format, so it may end up varying a bit more with different files of each format.

I'm using the latest x264 build from x264.nl (I initially discovered this behavior with r1735 from x264.nl - hadn't checked for updates in awhile - so I downloaded r1834 today, but same behavior).

...and actually, before I upload a sample, I just did a quick (~10000 frame) test with a different H264 Blu-ray that I had muxed to .mkv, and the memory leak *seems* to be much less severe, i.e. increasing much more slowly. However, this is a different movie, so to make sure, I'll need to remux my original "problem" .m2ts to .mkv. That'll take awhile as it's over on my NAS (and the .m2ts is ~35 GB), but I'll let you know what the results are as soon as I can.

[zapco]

OK, .mkv doesn't make a difference - it was just that particular movie.

Thus far I've found two movies that exhibit this most noticeably: Master and Commander, and The Taking of Pelham 123, both H264.

I'd be happy to upload clips from both, but two questions:

1) How much would be enough? The memory increase starts as soon as x264 initializes, but I'm not sure how much you need to see to make a definitive analysis...50 MB? 500 MB?

2) What service should I use for uploading? I don't do this very often, and I see a lot of rapidshare vs. mediafire vs.yousendit etc., so if you could recommend one, that would be very helpful.

[Blue_MiSfit]

Encoding 1080p video with 1 GB of RAM on Windows is utter madness :)

Please at least double this! If you can't for some reason, then you should either downres your movies to 720p, or back off on memory heavy settings. Which settings these are exactly is a bit over my head, but I'd imagine things like motion search complexity and lookahead would be the biggest offenders.

BTW, I wouldn't even try HD encoding with less than 2GB of RAM, especially given OS overhead. Beyond this, I'd suggest an additional 1 to 1.5GB per stream you're encoding simultaneously.

[zapco]

Well, I've encoded a couple dozen 1080p movies via Avisynth and DirectShowSource (with ffdshow as the decoder) on that machine (3.0 GHz C2D) with zero problems...for comparison's sake, Avisynth et al. starts at around 530 MB, climbs to ~725 MB, and then just hovers there for the rest of the encode - the machine is quite usable for other (non-RAM intensive) tasks while it's encoding.

[roozhou]

In my test with mencoder 2 years ago, 500mb of free memory is sufficient for 1080P x264 encoding. And remember Avisynth may consume lots of memory.

[kemuri-_9]

OK, .mkv doesn't make a difference - it was just that particular movie.

Thus far I've found two movies that exhibit this most noticeably: Master and Commander, and The Taking of Pelham 123, both H264.

I'd be happy to upload clips from both, but two questions:

1) How much would be enough? The memory increase starts as soon as x264 initializes, but I'm not sure how much you need to see to make a definitive analysis...50 MB? 500 MB?


hmm... i just need enough to replicate that the lavf demuxer is actually leaking, so after libx264 has finished all its allocation (usually within the first 100 frames - unless there's a large lookahead) + enough past that to see a leak occurring...

how may frames does it take to leak around 50 MB ?
that might be a good starting point...


2) What service should I use for uploading? I don't do this very often, and I see a lot of rapidshare vs. mediafire vs.yousendit etc., so if you could recommend one, that would be very helpful.

I never use these sites so i can not offer recommendations, maybe someone else can offer some useful opinions on this.

[zapco]

Well, maybe "memory leak" isn't the right term, but I'm not a programmer so I'm not sure what else to call it...

For instance, with Master and Commander, x264+lavf takes about 1800 frames to increase its memory usage by 50 MB.

In contrast, Avisynth gets there in just under 300 frames...the key difference is that once Avisynth hits ~725 MB, it stays right there, +/- 3 MB - x264+lavf just keeps right on going (virtual memory usage hits 1.8 GB(!) at around 20000 frames). As such, it doesn't really appear that a short (~50 MB) sample will help...

Also, while I don't think this will come as a surprise, I'll just mention it for completeness: Avisynth's CPU usage is pretty much a constant 100%, i.e. both cores floored with very little fluctuation, while x264+lavf is all over the map - lots of peaks and valleys in Process Explorer's graph.

[TheRyuu]

I never use these sites so i can not offer recommendations, maybe someone else can offer some useful opinions on this.

I like Speedyshare or Mediafire.

Don't use shitty sites like rapidshare that are slow and make you wait for the download.

[J_Darnley]

Encoding 1080p video with 1 GB of RAM on Windows is utter madness :)

If you stopped using --preset placebo you might think differently.

[kemuri-_9]

Well, maybe "memory leak" isn't the right term, but I'm not a programmer so I'm not sure what else to call it...

For instance, with Master and Commander, x264+lavf takes about 1800 frames to increase its memory usage by 50 MB.

In contrast, Avisynth gets there in just under 300 frames...the key difference is that once Avisynth hits ~725 MB, it stays right there, +/- 3 MB - x264+lavf just keeps right on going (virtual memory usage hits 1.8 GB(!) at around 20000 frames). As such, it doesn't really appear that a short (~50 MB) sample will help...


fine, then give me enough of a sample you think i can replicate and fix the issue with.


Also, while I don't think this will come as a surprise, I'll just mention it for completeness: Avisynth's CPU usage is pretty much a constant 100%, i.e. both cores floored with very little fluctuation, while x264+lavf is all over the map - lots of peaks and valleys in Process Explorer's graph.

besides the fact that we're having to guess at what your avisynth script is, no it's not surprising.

[zapco]

Alrighty then, here's the first 30 seconds of Master and Commander (146 MB), cut with tsMuxer and uploaded to Mediafire (thanks, TheRyuu):

http://www.mediafire.com/?xognmbuqd84x4a4

This clips nicely demonstrates the difference in x264's behavior with lavf vs. ffms.

With ffms, x264's private byte usage hits 461 MB right around 100 frames and then stays right there.

With lavf, it just keeps right on climbing, slowly but surely.

The command line is exactly what I posted in the first post of the thread (obviously, with or without "--demuxer lavf" as needed), and FWIW, my Avisynth script that I was comparing to is literally DirectShowSource() (with ffdshow r3562 being called as the decoder).

[kemuri-_9]

still unable to reproduce the issue,

here's a screen shot of the memory history from my runs of your sample with lavf vs ffms:

http://kemuri9.net/forumpics/x264_leak_not_reproducible_small.png
(click for full size) (http://kemuri9.net/forumpics/x264_leak_not_reproducible.png)

As the picture indicates, lavf is flatline and doesn't increase (it also has a very slightly less private byte usage than ffms according to the procexp reports on the other tab)

I'm currently using ffmpeg r26165.

You still haven't specified where the x264.exe you're using originated from nor what ffmpeg it was built against.
If i can't replicate the issue, then i can't fix it sadly.

[zapco]

Hmm, very strange...and actually, I did indicate that I got the x264 executable from x264.nl in my second post.

Here's the version string when I run it with "--help":

x264 core:112 r1834 a51816a
There doesn't appear to be any way to determine what version of ffmpeg it was compiled against...?

Well, anyhoo, thanks much for downloading the sample and taking a look...unless someone else can reproduce this, I guess it'll just be a "non-specific anomaly" on my machine...although I am heading back to work tomorrow, so I'll give it a shot on my Dell laptop (2.0 GHz C2D).

[sneaker_ger]

Here's what it looks like on Win 7 64, Core i7. (catted 5 files in tsmuxer for better visibility)

http://www.abload.de/img/lavf_ml_53rn3.png

[zapco]

Thanks much for testing, sneaker, and yep, that's exactly what it looks like on my machine...I was able to replicate it on my aforementioned Dell C2D laptop, and also a 3GHz P4 running Win7 with 1GB RAM: [Austin Powers]"I also like to live dangerously"[/Austin Powers]...veddy interestink...

Kemuri-9, I notice from your screenshot that you appear to be running on an AMD processor, and sneaker and I are running Intels...do you have access to an Intel box that you could try this on?

[kemuri-_9]

Kemuri-9, I notice from your screenshot that you appear to be running on an AMD processor, and sneaker and I are running Intels...do you have access to an Intel box that you could try this on?

A) I'm also on windows XP x64 and not on win7 like you folks...
though it wasn't reproducible on my server 2008 box either...

B) The only Intel processor around me is my work laptop, which i left at the office (just back from work). I can bring it home tomorrow. it also is loaded with win7...

[Chikuzen]

http://img831.imageshack.us/img831/1117/nlvsmine.png

source is zapco's sample m2ts.
There seems to be no leak in my build (http://www.mediafire.com/download.php?z1b5vapcyaaz35w).
I think that jarod should rebuild newer ffmpeg and x264.

my environment
C2Q Q9450 / Windows7 64bit
cross-mingw.gcc452.generic.20101218(komisar)
ffmpeg r26251

[zapco]

There seems to be no leak in my build (http://www.mediafire.com/download.php?z1b5vapcyaaz35w).
Confirmed! Memory usage with lavf stays rock steady.

:thanks:

[kemuri-_9]

glad to see this get concluded...

[Jarod Middelman]

zapco, others,

Can you check if this updated libraries build fixes your problems?

1834_32bit_8bit_depth_memleakfix (http://x264.nl/dump/x264_1834_32bit_8bit_depth_memleakfix/x264.exe)

And here (eventlog) (http://x264.nl/dump/x264_1834_32bit_8bit_depth_memleakfix/eventlog.txt) you can check the difference in libraries used.

[sneaker_ger]

No change:
http://www.abload.de/img/lavf_ml_newbuild9s6o.png

[Jarod Middelman]

Chikuzen in #x264 has also confirmed the bug is still there.

Komisar's/JEEB's/Jarod's GCC builds are all affected with this memory leak. So using latest libraries isn't the solution, guess the guru's have to figure this one out!

But Chikuzen was able to built a build that wasn't affected, let's ask him!

[zapco]

After testing 16 different source files, made up of a variety of Blu-ray and HD-DVD rips with all versions of video (H264, VC-1, MPEG-2) and nearly all audio (DD, DD+, DTS-HD, TrueHD, no LPCM yet) codecs supported by those formats represented, it appears that the memory leak issue is entirely related to whether or not audio is present in the stream, and to a certain extent, what type of audio it is.

Here's a summary of what audio formats cause the memory leak - I tested four files of each format (DD, DD+, DTS-HD, TrueHD):

x264 r1834 from x264.nl - lavf: Any audio
x264 r1834 from x264.nl - ffms: None
x264 r1834 chikuzen's build - lavf: DD always, DD+ never, DTS-HD sometimes, TrueHD always
x264 r1834 chikuzen's build - ffms: None
x264 r1834 Jarod's memleakfix build - lavf: Same as x264.nl (not chikuzen's) [Late edit: Oops, missed this one]

If the video is demuxed (to either mkv or m2ts), none of the builds have any memory issues using lavf - memory usage stays steady.

So, making good on my previous edit, here are 5 second samples of streams representing each audio codec. Catting a 1-2 min. file should be enough to see what's happening. Also, note that running with "--preset ultrafast", as well as ouputting to NUL, makes it much quicker and easier to determine if the leak is happening or not. The amount of memory used is much different, of course, but it makes it much easier in making "red light/green light" determinations:

DTS-HD (that does cause the memory leak): The "bond" sample from mplayerhq
http://samples.mplayerhq.hu/A-codecs/DTS/bond_sample_dtshdma.m2ts

DD (this is the "mildest" format, so you may need to cat a 3-5 min. file to really see it): Gattaca
http://www.mediafire.com/?m18n8ebxen7o2ro

DD+: Out of Sight
http://www.mediafire.com/?5qqqpfp6dqpgc75

TrueHD (this is the worst, i.e. most obvious): How to Train Your Dragon
http://www.mediafire.com/?1e15wq6mev8wph6

[kemuri-_9]

try this new x264_fix_lavf_memleak (http://kemuri9.net/dev/x264/experimental/x264_fix_lavf_memleak.7z) build.
it seems like the issue is largely fixed though there seems to be a very very slight leak with that How.to.Train.Your.Dragon.2010.Blu-ray.H264.true-hd51_5sec.m2ts sample now.

waiting for valgrind results to see if i can track where this remainder is being caused.

edit:
valgrind results came in finally and it decided to tell me that there is no such leak. at this point i'm presuming that lavf simply decided to use a couple more MB of memory part-way through the encode.
re-running again with 100x that sample doesn't seem to leak, so it looks like my previous change did fix the issue completely.

[zapco]

Thanks much, kemuri-9 - looking great so far!

No leaks on any of my test files, and I'm currently running a full encode of How To Train Your Dragon, i.e. the full movie written out to an .mkv and without "--preset ultrafast".

Guesstimating from the current encoding speed, it'll be done about 8 hours from now, and I'll report back with the results (it's only 3000 frames in so far, but memory usage is literally ruler flat).

[zapco]

Encode just finished:

memory at start: 473 MB

memory at end: 476 MB

I just started another full encode (2-pass) on another of my test files - this one with DTS-HD - and it's also rock-solid @ 3000 frames.

It looks like we can call it "fixed." ;)

:thanks:

[kemuri-_9]

thanks for continuing the confirmation.

the fix has been integrated into the next commit storm.

[Snowknight26]

http://stfcc.org/pics/i/c6039f52795ca237ca2954e35907a696_th.jpg (http://stfcc.org/pics/i/c6039f52795ca237ca2954e35907a696.png)

Glad it's fixed. :D

[Warbucks81]

Using the x64 version(rev 1867) from x264.nl, I still experience the memory leak.

[zapco]

I don't have access to any 64-bit Windows installs, so someone else will have to verify - any takers?

[kemuri-_9]

Using the x64 version(rev 1867) from x264.nl, I still experience the memory link.

not reproducible with the samples from zapco that exhibited leaks before the committed fix.

please provide a sample that can replicate the issue.

[Warbucks81]

not reproducible with the samples from zapco that exhibited leaks before the committed fix.

please provide a sample that can replicate the issue.

Did some more testing and it wasn't x264. It was something else causing the high memory usage.