Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
29th July 2014, 14:14 | #1 | Link |
Registered User
Join Date: Jul 2014
Posts: 10
|
x264: excessive memory usage with --seek
I'm trying to use the --seek and --frames options in x264 to hone in on the right settings for a section of video that's giving me some trouble. In doing so, I'm wondering if I've found a bug.
Basically, whenever I use --seek with a high starting frame number, the encoder takes quite a while to actually begin encoding (minutes). During that time memory usage steadily increases until it's at 99% usage. Then it levels off for a bit until it hits the target frame range, the memory usage drops slightly as the encode begins. When it's finished, it instantly drops back down to normal levels. Here's the simplest version of the command I'm using that will reproduce this: Code:
C:\Users\Owner>D:\x264_Testing\x264-r2453-ea0ca51.exe --bitrate 23000 --seek 10000 --frames 500 -o output.avc source.mov My system is a core i7 2600K, 8GB RAM, Windows 7 64bit. However, on a laptop I'm using for testing (also Win7), I see similar behavior though I'm using smaller test files there. The source Quicktime is a ProRes 422 HQ 1080p/23.98 file (91 minute feature film), but on the laptop I'm testing with an uncompressed AVI file at 1080p/2398, so I don't think the Quicktime file is the problem. When I run the encode without --seek, the encode starts almost immediately, memory usage hovers at about 1.4-1.5GB (that's total system physical memory usage) And I guess the question is - with --seek, why doesn't it start almost instantly, just at the target start frame (as it does when I don't use --seek)? |
29th July 2014, 20:43 | #2 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
I ran into this same issue. When using uncompressed v210 in AVI and seeking 100000+ frames my memory would actually fill and the process would be killed by Windows. I have 32GB of RAM and was using 64-bit x264 so the memory usage was quite high.
I ended up piping from AVISynth instead of using --seek. |
29th July 2014, 20:52 | #3 | Link |
Registered User
Join Date: Jul 2007
Posts: 552
|
Can you specify what demuxer was used when you experienced this problem. ffms/lavf/avs? Also can you try to use another demuxer (with --demuxer option) to see if this is specific to one of the demuxers or all. As to why encoding doesn't start immediately is also depends from used demuxer and for some of them it need full decoding from first frame to specified with --seek to be frame accurate.
|
30th July 2014, 20:36 | #7 | Link | |
Registered User
Join Date: Jul 2014
Posts: 10
|
Ok, so we're back up and running, piping the video through Avisynth. However, in order to open the Quicktime we still need to use ffms. After much research, it seems that the best results are to use the following avisynth script to open the file:
Quote:
This is great because it also gets us good dithering from 10bit source - but to load up a feature film it takes forever to index, and since we'll only ever use x264 with ProRes or Uncompressed Quicktime files (never GOP-based source files), is there an alternative that gets you the same result as above, but without the wait for an index file? I can see the need to create an index file for GOP based source files before you can do any trimming, but I don't see why it's necessary for our situation, using frame-based formats like Uncompressed Quicktime. According to the thread above, using QTSource probably isn't a good idea because it lacks proper 10->8bit dithering, which we need. Thanks! |
|
30th July 2014, 21:12 | #8 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Quote:
f3kdb_dither() |
|
30th July 2014, 23:19 | #9 | Link | |
Registered User
Join Date: Jul 2014
Posts: 10
|
Quote:
|
|
31st July 2014, 08:16 | #11 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
The output coming from L-SMASH with stacked=true and format=YUV422P16 should be the same/very similar to the ones coming from ffms2 with enable10bithack=true.
The output with format=YUV422P8 is still dithered, so it's OK, but maybe you need a particular dither algorithm. |
31st July 2014, 12:44 | #13 | Link | |
Registered User
Join Date: Jul 2014
Posts: 10
|
Quote:
With P8 (which may work for our purposes since it's dithering), we get a nice looking image at the proper size - no splitting, no green. Is what we're seeing with P16 due to the way high bit depth files are handled? (I read a little about how the way this is done in Avisynth is to kind of fake it out by having two 8-bit images merged into one image, or something like that). If so, could something be wrong with our setup? We're using AviSynth+ since it's 64bit, if that makes a difference. Thanks! Last edited by friolator; 31st July 2014 at 12:47. |
|
31st July 2014, 12:52 | #14 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
AviSynth does not know higher bitdepths than 8. Filters like lsmashvideosource() work around it by putting 8 bits on the top and the other 8 bits on the bottom (=16 bits total). The "stacked=true" is the same hack as ffms2's "enable10bithack=true".
If you are looking for 8 bit output and you're ok with lsmash's built-in dithering it is indeed perfectly fine to simply use lsmashvideosource("input.mov", format="YUV422P8") and be done with it. |
Tags |
seek, x264 |
Thread Tools | Search this Thread |
Display Modes | |
|
|