How to Convert/Encode/Render video for slow device?

[LeoKac]

Hello, I know there is no best video codec or format. Because, each codec is designed for its corresponding job and situation.

Well, here is my situation:


I have an Android Tablet, that can play any video with any codec or format, but if the video is high quality, the playback slows down because it has slow CPU and GPU.


Here is the system info of my device:


Android version: 4.1.2 Jelly Bean


Display: 1280x720
Chipset: Nvidia Tegra 2 T20
CPU: ARMv7 Processor Dual-core 900 MHz Cortex-A9
GPU: ULP GeForce
RAM: 700 MB
Internal Storage: 20 GB
SD card: no




So, this is not very slow tablet but not fast enough for smooth h.264/x264 video playback.


I know h.264 and x264 reaquire fast CPU to play video.


So, please tell me which video format and codec is good for my situation to play 720p and HQ video smoothly on my device and not take so much memory.


Well, I want to watch 720p and HQ movies on my slow device, and I am looking for good codec to convert a movie and not to take more than 10 GB memory. and of course the video playback must be smooth.

I have tried many MP4 720p h.264 or x264 movies to play with many Android video players, but each player just slow down the playback in both mode:

Hardware encoding
Software encoding


Thanks you so so much.....

[Marin85]

Certain x264 settings have direct impact on the decoding performance. Most notably, lowering the number of ref frames should make the stream much easier to decode on low-end devices without sacrificing much quality. So you still might be able to get smooth H.264 playback. The other thing is bitrate, but it is directly correlated with quality, although on such a small screen it probably does not matter that much.

Other than that, MPEG-2 is very lightweight and should be very decoding-friendly.

I am a little surprised though that you are having problems with H.264 720p playback.

[sneaker_ger]

Most notably, lowering the number of ref frames should make the stream much easier to decode on low-end devices without sacrificing much quality.

While there are hard limits on ref frames I think this is mostly just a question of how much memory is available, i.e. the file with either play or not play (without artifacts), but the impact of the ref frame number on the decoding performance itself should be negligible.

The other thing is bitrate, but it is directly correlated with quality, although on such a small screen it probably does not matter that much.

This on the other hand does play a bigger role. x264 allows limiting the bitrate with --vbv-maxrate and --vbv-bufsize.


Wikipedia says that the Tegra 2 only does H.264 baseline(--profile baseline) decoding in hardware. So try to use that and limit the bitrate to 20 Mbit/s and 30 fps max. Not all Android players make use of the hardware decoding so ask the player devs if their player does - I assume this is the case for the one built into Android.

https://en.wikipedia.org/wiki/Tegra#Tegra_2
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/63258/kw/video/p/7901,7906

[Marin85]

While there are hard limits on ref frames I think this is mostly just a question of how much memory is available, i.e. the file with either play or not play (without artifacts), but the impact of the ref frame number on the decoding performance itself should be negligible.
Well, I have been stuck for a while with an older ThinkPad with Core 2 Duo cpu and no DXVA and have always had that problem of getting smooth playback from H.264 1080p. On the side of software decoding one can do only so much about it, but on the encoding side I have found lowering ref count to be quite helpful. Given that 720p normally utilizes even more ref frames than 1080p, I think that might prove useful to the OP.

[sneaker_ger]

To quote the x264 help of --tune:
- fastdecode:
--no-cabac --no-deblock --no-weightb
--weightp 0

Notice that neither --ref nor --bframes are listed. --no-cabac, --no-weightb and --weightp 0 are already implied by --profile baseline, btw.

Anyways, I tried a test myself and there actually was some measurable difference, although it was <4%, which is probably too small to be relevant for practical purposes but still bigger than I expected:
http://abload.de/img/ref1epsl2.png
http://abload.de/img/ref16vmsms.png
(--preset medium, --bitrate 15000, 1920x800 @ 24/1.001 fps)
final bitrate --ref 1: 14923.22
final bitrate --ref 16: 14940.78 (~0.1% bigger)

I used GraphStudio which only shows average fps, though, while spikes could be interesting. Decoder was LAV Video in software mode.

[Marin85]

These are some interesting figures. Spikes will definitely be a factor, though. Also, what hardware did you use for the decoding? In my experience, --ref 16 1080p @ 10 Mbps is definitely a no go for my cpu - it will play back, but with lots of stutter. I suspect that the decoding performance difference will be even bigger, the slower the decoding hardware is.

Interesting that you mention --bframes. I have had my fair share playing around with --bframes 0 + crf, and such encodes appear to utilize more cpu than a 'standard' encode with B-frames at same bitrate. But since it's crf, I don't know how well the vbv model works in that case when no B-frames are being used.

For a reference, I am using Intel Core 2 Duo T7400 (2x2.16 GHz).

EDIT: If you can upload both 1080p clips somewhere, I would gladly give them a shot on my system.

[Stereodude]

What player/app are you using on your tablet? Most of the SoC's in tablets and phones have hardware accelerators that significantly help in decoding H.264 video. It sounds like you're trying strictly CPU based decoding.