FFMPEG, x264, multi-core

[MattKB]

Hi,

I have a fresh build of FFMPEG and x264 that I built today. I have noticed 2 things (I don't think anything changed in my most recent build - I just wanted to mention that I am on the most recent code).

I am doing 2 pass encoding on a 2 core machine.

1) It seems that the first pass of my encode only uses 1 core regardless of what I set -threads to. Is this an FFMPEG issue? x264 issue? An issue with a setting I am using?

2) On the 2nd pass, in order to fully load the machine I need to use 4 threads on a 2 core machine. What is the "optimal" number of threads to use for encoding based on the number of cores in the machine?

Thanks

[Sharktooth]

number of cores * 1.5
however, its highly probable you cant fill the cores in the first pass if you specified a high number of b-frames along the b-adapt 2 option.

[MattKB]

I am using -bf 16 and -badapt 2. However I tried -badapt 1 and it still only used 1 core (though the FPS went way up). Is it the high b-frame # that causes the lack of parallelism? I don't understand what the encoder is doing and whether it could become more parallel. Now with -badapt 2, which I would like to make use of for better quality, it would be cool to be able to load the system during the first pass. Is this technically possible (just curious)?

[Dark Shikari]

Originally Posted by MattKB

I am using -bf 16 and -badapt 2. However I tried -badapt 1 and it still only used 1 core (though the FPS went way up).

The frametype decision part of the encoder isn't parallelized. This isn't a problem for b-adapt 1, which is really really fast. It is a problem for b-adapt 2, which, at least for really high --bframes values, isn't fast at all.

Originally Posted by MattKB

Now with -badapt 2, which I would like to make use of for better quality, it would be cool to be able to load the system during the first pass. Is this technically possible (just curious)?

Sure, just use --bframes 3 or so instead of 16.

[MattKB]

What is the quality tradeoff for bf16/b-adapt1 vs. bf3/b-adapt2?

Also, as I said even wht using bf16/b-adapt1, I only saw 1 core being used. Is this because my quality settings are low enough for the 1st pass that 16 bframes becomes a parallelism blocker even though the decision mechansim is faster?

[kemuri-_9]

is x264 giving a warning similar to
x264 [warning]: not compiled with pthread support! ?
if it is, it means you didn't give it the ability to multithread when you compiled it.
which would explain it is only working with 1 thread no matter what you put for --threads x

of course this error only happens if you used the x264 cli, not ffmpeg with libx264...
i don't recall offhand what errors ffmpeg has for attempting threading w/o thread support...

[MattKB]

Originally Posted by kemuri-_9

is x264 giving a warning similar to
x264 [warning]: not compiled with pthread support! ?
if it is, it means you didn't give it the ability to multithread when you compiled it.
which would explain it is only working with 1 thread no matter what you put for --threads x

This is not the problem. I am able to load the cores in the 2nd pass as I said above.

[LoRd_MuldeR]

Originally Posted by MattKB

What is the quality tradeoff for bf16/b-adapt1 vs. bf3/b-adapt2?

With "--b-adapt 1" and "--bframes 16" the encoder will not use more than 2 consecutive b-frames very often.
So "--b-adapt 2" with "--bframes 3" should produce a better result in fact. More than "--bframes 5" with "--b-adapt 2" is usually overkill.

That's because "--bframes" only limits the maximum number of consecutive b-frames.
It still depends on the b-frame decision method how many consecutive b-frames will actually be used.
The "old" (fast) method is fast, but tends to use very few b-frames. The "new" (slow) method chooses the optimal number of b-frames.
Hence it's better to use the "new" method and use a sane "--bframes" value...

[burfadel]

As DS has mentioned previously, the old b-frame decision method was far from perfect, and setting it to 16 b-frames didn't represent any benefit above a setting of 4. I think there was a bug at one stage which gave the illusion that there was! With the new method, having 5 b-frames optioned is more efficient than having 16 b-frames in the old method, and in fact even though setting a higher number offers diminishing returns, even setting at 3 represents better b-frame utilisation in most circumstances when you discount the aforementioned bug.

[MattKB]

I change my settings to use -bf 5 and -b_strategy 2, and a few things:

1) I am still not really seeing much parallelism on the 1st pass. I'm going to go under the assumption that the 1st pass is mostly working on b-frame decision and as such there is not much parallelism possible.

2) Now I am seeing the following warning at the very end of the 2nd pass:

[libx264 @ 0x17593170]2nd pass has more frames than 1st pass (726).2kbits/s
[libx264 @ 0x17593170]continuing anyway, at constant QP=18
[libx264 @ 0x17593170]disabling adaptive B-frames
[libx264 @ 0x17593170]2nd pass has more frames than 1st pass (726)
[libx264 @ 0x17593170]continuing anyway, at constant QP=18
[libx264 @ 0x17593170]disabling adaptive B-frames
[libx264 @ 0x17593170]2nd pass has more frames than 1st pass (726)
[libx264 @ 0x17593170]continuing anyway, at constant QP=18
[libx264 @ 0x17593170]disabling adaptive B-frames

Note that this message is repeated based on the number of threads in use. In this case I am using 3 threads. If I use 1 thread I see the message once. Any ideas?

[Dark Shikari]

Originally Posted by MattKB

I change my settings to use -bf 5 and -b_strategy 2, and a few things:

1) I am still not really seeing much parallelism on the 1st pass. I'm going to go under the assumption that the 1st pass is mostly working on b-frame decision and as such there is not much parallelism possible.

-bf 5 -b_strategy 2 is still pretty damn slow. Try -bf 3 or something.

Originally Posted by MattKB

2) Now I am seeing the following warning at the very end of the 2nd pass:

[libx264 @ 0x17593170]2nd pass has more frames than 1st pass (726).2kbits/s
[libx264 @ 0x17593170]continuing anyway, at constant QP=18
[libx264 @ 0x17593170]disabling adaptive B-frames
[libx264 @ 0x17593170]2nd pass has more frames than 1st pass (726)
[libx264 @ 0x17593170]continuing anyway, at constant QP=18
[libx264 @ 0x17593170]disabling adaptive B-frames
[libx264 @ 0x17593170]2nd pass has more frames than 1st pass (726)
[libx264 @ 0x17593170]continuing anyway, at constant QP=18
[libx264 @ 0x17593170]disabling adaptive B-frames

Note that this message is repeated based on the number of threads in use. In this case I am using 3 threads. If I use 1 thread I see the message once. Any ideas?

Sounds like ffmpeg is being broken and is dropping frames at the end of the first pass.

[LoRd_MuldeR]

Originally Posted by Dark Shikari

Sounds like ffmpeg is being broken and is dropping frames at the end of the first pass.

Avidemux had a similar problem, until it was fixed recently:
http://avidemux.org/admForum/viewtop...d=29706#p29706

[MattKB]

Apart from the FFMPEG issue, even if I set -bf 0 I still see barely any parallelism on the 1st pass (I can tell it uses the 2nd core, but very little). Here is my encode script if anyone has any further input on why I can't get parallelism on the 1st pass.

nice -n 10 ffmpeg -t 30 -i $1 -croptop $5 -cropbottom $6 -cropleft $7 -cropright $8 \
-s $3 -y -an -pass 1 -vcodec libx264 -threads $NUM_THREADS \
-b ${BIT_RATE}k -maxrate ${BIT_RATE}k -bufsize ${BUF_SIZE}k -rc_init_occupancy ${BUF_INIT}k -flags +loop \
-cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -me_method epzs -subq 1 -trellis 0 \
-refs 1 -bf 0 -b_strategy 0 -coder 1 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 \
-i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 $2

nice -n 10 ffmpeg -t 30 -i $1 -croptop $5 -cropbottom $6 -cropleft $7 -cropright $8 -s $3 -y \
-acodec libfaac -ab 96k -ar 48000 -pass 2 -vcodec libx264 -threads $NUM_THREADS \
-b ${BIT_RATE}k -maxrate ${BIT_RATE}k -bufsize ${BUF_SIZE}k -rc_init_occupancy ${BUF_INIT}k \
-flags +loop -cmp +chroma -partitions +parti8x8+parti4x4+partp8x8+partp4x4+partb8x8 \
-flags2 +dct8x8+wpred+bpyramid+mixed_refs -me_method umh -subq 8 -trellis 1 -refs 6 -bf 0 \
-directpred 3 -b_strategy 0 -bidir_refine 1 -coder 1 -me_range 16 -g 250 \
-keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 \
-qmin 10 -qmax 51 -qdiff 4 $2

[LoRd_MuldeR]

Originally Posted by MattKB

Apart from the FFMPEG issue, even if I set -bf 0 I still see barely any parallelism on the 1st pass

Are sure that your source isn't the bottleneck here?

Also the "-rc_eq" option is obsolete, I think. The RC equitation is hardcoded now.

[MattKB]

The source could definitely be the issue. In this case it is 1080x720 H264. Honestly the threading model of FFMPEG confuses me. I think you can use the -threads option for both the decoder and the encoder. I am pretty sure that the H264 decoder included in FFMPEG is now multithreaded, however when I added -threads 3 to the input I saw little difference. I'm not sure if this is because the decoder is not efficient.

Should I also be using cores *.5 for the # of input threads?

Also in the 2nd pass does audio happen on its own thread?

You would think that FFMPEG would be able to determine the appropriate # of threads for the operation at hand automatically, but that is probably a question for a different forum.

[LoRd_MuldeR]

AFAIK ffmepg's H.264 decoder had at least two different methods of multi-threading in the past:
Slice-based multi-threading (works with sliced sources only) and CABAC-based multi-threading (works with all sources that use CABAC, but not very efficient).
I think Frame-based multi-threading (similar to x264's implementation) for ffmpeg's H.264 decoder is under development, but not ready yet...

(And I think the "threads = cores * 3/2" formula applies to x264 only)

[Dark Shikari]

Originally Posted by LoRd_MuldeR

AFAIK ffmepg's H.264 decoder had at least two different methods of multi-threading in the past:
Slice-based multi-threading (works with sliced sources only) and CABAC-based multi-threading (works with all sources that use CABAC, but not very efficient).

I think Frame-based multi-threading (similar tCo x264's implementation) for ffmpeg's H.264 decoder is under development, but not ready yet...

CABAC-based multithreading was never committed in ffmpeg trunk; its only used in FFDshow.

[LoRd_MuldeR]

Originally Posted by Dark Shikari

CABAC-based multithreading was never committed in ffmpeg trunk; its only used in FFDshow.

I see. So unless MattKB's source is sliced or he is using an experimental ffmpeg build from MT-branch, there's no multi-threading at all for the source/decoder.

[MattKB]

Originally Posted by LoRd_MuldeR

I see. So unless MattKB's source is sliced or he is using an experimental ffmpeg build from MT-branch, there's no multi-threading at all for the source/decoder.

I checked (using -debug 1) and the source IS sliced, and most of the frames do not use deblocking (which I read somewhere doesnt work for the MT support in the decoder), so I would think it could be done in parallel.

In either case you would think 1 core could be used for decoding and the other core could be used for encoding with a shared memory buffer between them, but I have no idea how FFMPEG is implemented and this is more of an intellectual excercise so I give up!

[Dark Shikari]

Originally Posted by MattKB

I checked (using -debug 1) and the source IS sliced, and most of the frames do not use deblocking (which I read somewhere doesnt work for the MT support in the decoder)

Its only deblocking between slices that breaks the multithreading, not deblocking in general. Its a flag set in the header.