Video rendering too slow

[bennuttall]

We've found that using the very efficient rendering command provided by @waveform80 produces files which omxplayer generally fails to play.

The command

avconv -y -f image2 -r 10 -i animation/frame%03d.jpg -c:v libxvid -aspect:v 16:9 -q:v 5 animation.mp4

takes about 1 minute per 10 frames (which is great) but omxplayer fails to play it (though the videos do play on other machines).

However the command

avconv -r 10 -i animation/frame%03d.jpg -vcodec libx264 animation.mp4

plays videos fine, but takes about 5 minutes per 10 frames.

Currently I'm thinking the latter option is preferable, as it does work (and the command is shorter) but it would be nice if it rendered faster.

If anyone has a suggestion for some middle-ground, ideally something faster than the second command, but one that successfully plays with omxplayer, I'd be grateful. Please comment here with solutions.

Btw, I'm using the latest Raspbian image (June 2014), which comes with on omxplayer build from 22nd March 2014.

[waveform80]

The major issues (by my very limited understanding) are as follows:

1. The Pi supports H.264 decompression (playback) out of the box (if it didn't, video recording on the camera would be semi-pointless!). However, H.264 compression is extremely costly, at least with x264 on the CPU. The GPU is powerful enough to compress 720p30 from the camera in realtime, but remember that the CPU is paltry compared to the GPU, and that x264 will be doing a lot more work than the camera encoder as it'll be figuring out B-frame usage, etc. (still, it might be worth investigating using the camera's H.264 encoder?)
2. The xvid codec involves a lot less work than x264, so it compresses in a reasonable time on the Pi's CPU, but playback doesn't work reliably.
3. MPEG1 and MPEG2 codecs also involve a lot less work than x264, but won't work for playback on a Pi unless the user has purchased the relevant license (is xvid output MPEG2? I thought it was another MPEG4 encoder but I'm happy to be corrected!)
4. Finally, I suspect another requirement is that whatever is used should be reasonably trivial to install (like ffmpeg/avconv). Requiring multi-hour custom builds (like upstream versions of ffmpeg) is unlikely to be meet the practicality requirement.

Or put another way:

• command must support compression as a reasonable speed (e.g. no less than a frame every few seconds?)
• output must support decompression (playback) with omxplayer on a Pi without additional licenses (no MPEG1/2)
• application should be reasonably simple to install (no multi-hour custom builds)

I'll have another crack at solving this when I get a spare second ... I think the most promising avenues at the moment are probably MJPEG (compression will be abysmal but it might be reasonably quick), and utilizing the camera's GPU-based encoder (won't produce quite as good quality/compression as x264 but who cares - it'll still be way faster than anything else and the quality/compression will probably still be better than xvid/MJPEG)

[bennuttall]

Hi Dave - thanks again for chipping in.

Yes - all points you raised are valid/correct.

I've added a note about rendering options (use a PC): 0e39180

[asb]

Have you tried a newer omxplayer? e.g. a build from
http://omxplayer.sconde.net/

On 23 June 2014 19:15, Ben Nuttall notifications@github.com wrote:

We've found that using the very efficient rendering command provided by
@waveform80 https://github.com/waveform80 produces files which omxplayer
generally fails to play.

The command

avconv -y -f image2 -r 10 -i animation/frame%03d.jpg -c:v libxvid -aspect:v 16:9 -q:v 5 animation.mp4

takes about 1 minute per 10 frames (which is great) but omxplayer fails
to play it (though the videos do play on other machines).

However the command

avconv -r 10 -i animation/frame%03d.jpg libx264 animation.mp4

plays videos fine, but takes about 5 minutes per 10 frames.

Currently I'm thinking the latter option is preferable, as it does work
(and the command is shorter) but it would be nice if it rendered faster.

If anyone has a suggestion for some middle-ground, ideally something
faster than the second command, but one that successfully plays with
omxplayer, I'd be grateful. Please comment here with solutions.

Btw, I'm using the latest Raspbian image (June 2014), which comes with on
omxplayer build from 22nd March 2014.

—
Reply to this email directly or view it on GitHub
#4.

[bennuttall]

Not tried new omxplayer yet. Will do. Was there any difference in the recent Raspbian release?

Eben suggested I upload a video and get Dom and the team to look at it. Will try that too.