View Full Version : x264 encoding for Android (Nexus 7 2013)
Stereodude
10th August 2013, 21:40
So I've been playing around with encoding videos for playback with MX Player on my Nexus 7 (2013) with x264. So far everything I've tried plays back correctly with hardware acceleration. It will play full blown 1080p blu-ray spec h.264 streams just fine.
This is basically where I've ended up line for 1280px wide encoding since 1920px wide content wasn't noticeably sharper despite being 1:1 on the display.
Sample command line:
x264.exe --crf 20 --preset veryslow --tune film --level 4.1 --keyint 120 --open-gop --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile sample.chp -o sample.264 sample.avs
Is there any low hanging fruit (command line options) to further shave bits that I'm missing without reducing the visual quality. FWIW, I arrived at a CRF of 20 after trying a pretty wide range of values and watching the output. I tried increasing the bframes above 8, but that didn't help. I know I can increase the keyframe interval further for marginal gains, but it seems like I'm into diminishing returns there.
Blue_MiSfit
10th August 2013, 23:57
You should probably use VBV since you're targeting a hardware device. Honestly, for 720p I'd suggest just targeting HP@3.1, so use 17500 for both bufsize and maxrate.
Stereodude
11th August 2013, 00:05
Don't you get better compression efficiency with the higher levels due to the higher number of frames that can fit in the buffer?
Blue_MiSfit
11th August 2013, 10:46
Only if your content is complex enough to require that much buffer.
17.5 Mbps is plenty for 720p30/24. If you need to do 720p59.94 then you're automatically at either level 3.2 or level 4, both of which have 25 Mbps max bitrates in high profile.
jq963152
11th August 2013, 11:47
@ Blue_MiSfit:
With this:
Don't you get better compression efficiency with the higher levels due to the higher number of frames that can fit in the buffer?
he probably was not reffering to the VBV buffer.
Instead, he probably was referring to the reference frames count, i.e. the decoded picture buffer (DPB).
At a framesize of 1280x720, Level 3.1 and Level 3.2 allow for 5 reference frames only.
Level 4.0 and 4.1 however allow for 9 reference frames at a framesize of 1280x720.
And considering that Stereodude is using --preset veryslow (which uses 16 reference frames, i.e. --ref 16), there would be an advantage in using Level 4.0 or 4.1 instead of Level 3.1 or 3.2, because the former would encode with 9 reference frames, whereas the latter would encode with only 5 reference frames.
STaRGaZeR
11th August 2013, 15:02
@ Blue_MiSfit:
With this:
he probably was not reffering to the VBV buffer.
Instead, he probably was referring to the reference frames count, i.e. the decoded picture buffer (DPB).
At a framesize of 1280x720, Level 3.1 and Level 3.2 allow for 5 reference frames only.
Level 4.0 and 4.1 however allow for 9 reference frames at a framesize of 1280x720.
And considering that Stereodude is using --preset veryslow (which uses 16 reference frames, i.e. --ref 16), there would be an advantage in using Level 4.0 or 4.1 instead of Level 3.1 or 3.2, because the former would encode with 9 reference frames, whereas the latter would encode with only 5 reference frames.
The former could use up to 9 reference frames. There is no point in having more references if they are not useful (read: used).
Stereodude
11th August 2013, 17:43
You should probably use VBV since you're targeting a hardware device. Honestly, for 720p I'd suggest just targeting HP@3.1, so use 17500 for both bufsize and maxrate.Well, that didn't really have the impact I expected (at least on this source).
Level 4.1 no vbv restrictions:
x264.exe --crf 20 --preset veryslow --tune film --level 4.1 --keyint 120 --open-gop --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile video.chp -o video_1280_20.264 video_1280.avs
avs [info]: 1280x682p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:1584 Avg QP:17.04 size: 93768
x264 [info]: frame P:26163 Avg QP:20.54 size: 21017
x264 [info]: frame B:100651 Avg QP:26.44 size: 3744
encoded 128398 frames, 20.01 fps, 1606.30 kb/s
Level 3.1 w/ vbv restrictions :
x264.exe --crf 20 --preset veryslow --tune film --vbv-maxrate 17500 --vbv-bufsize 17500 --level 3.1 --keyint 120 --open-gop --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile video.chp -o video_1280_20_lvl3.1.264 video_1280.avs
avs [info]: 1280x682p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile High, level 3.1
x264 [info]: frame I:1584 Avg QP:17.05 size: 93706
x264 [info]: frame P:26163 Avg QP:20.54 size: 21158
x264 [info]: frame B:100651 Avg QP:26.28 size: 3865
encoded 128398 frames, 21.92 fps, 1629.81 kb/s
Level 4.1 w/ vbv restrictions :
x264.exe --crf 20 --preset veryslow --tune film --vbv-maxrate 17500 --vbv-bufsize 17500 --level 4.1 --keyint 120 --open-gop --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile video.chp -o video_1280_20_lvl4.1_.264 video_1280.avs
avs [info]: 1280x682p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:1584 Avg QP:17.04 size: 93725
x264 [info]: frame P:26163 Avg QP:20.54 size: 20996
x264 [info]: frame B:100651 Avg QP:26.27 size: 3866
encoded 128398 frames, 19.50 fps, 1623.69 kb/s
benwaggoner
13th August 2013, 18:42
Is there any low hanging fruit (command line options) to further shave bits that I'm missing without reducing the visual quality. FWIW, I arrived at a CRF of 20 after trying a pretty wide range of values and watching the output. I tried increasing the bframes above 8, but that didn't help. I know I can increase the keyframe interval further for marginal gains, but it seems like I'm into diminishing returns there.
Seems like the actual bitstream itself is getting everything it can take useful advantage of. You could always try --placebo to set an upper bound of what is possible in theory. Higher keyint and maybe longer --rc-lookahead could help marginally.
Psychovisual and image tuning is probably what's left at this point. Throwing in a --nr 100 to 250 generally has little visual impact at 720pm, but can shave some bits off by encoding small random noise a little less. For content with annoying noise that's getting visibly quantized, it can help quality a bit, although I don't know if you'd be seeing that at your CRF.
CRF 20 seems kinda high for that many pixels on that small a screen unless someone's using a magnifying glass. Trying 20.5 might help a bit.
What's in your .qpfile? That will override a lot of other settings, so you should only where you know how to do things better than the encoder (like setting chapter points).
Stereodude
13th August 2013, 23:37
CRF 20 seems kinda high for that many pixels on that small a screen unless someone's using a magnifying glass. Trying 20.5 might help a bit.I guess I'm picky. :p
What's in your .qpfile? That will override a lot of other settings, so you should only where you know how to do things better than the encoder (like setting chapter points).It's only got I frame definitions for chapters.
I've tried encoding a few other things and am surprised that Level 3.1 and Level 4.1 as so close in bitrate (nearly identical). I wasn't expecting that.
Blue_MiSfit
14th August 2013, 03:25
The levels. aren't really that different. Take the blocks per second (determining max frame sizes and rates) out of the equation and you're left with max bitrates and number of reference frames.
Baseline -> Main is a huge jump, and Main -> High is a fairly big deal as well, but generally speaking unless your content and application dictates average bitrates near the level boundary, you're likely not going to see much benefit from using a higher level.
TL;DR - stay conservative with your profile / level assignments unless you have a good reason to do otherwise.
nakTT
28th November 2013, 05:39
Anyone inow if we have a simple free apps for android so I can encode video using x264 on my phone? Thank you in advance.
Blue_MiSfit
28th November 2013, 08:02
Please don't re-open dead threads.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.