Using the keyboard to control the position in a movie (via left/right and Up/down arrows) leads to noticeable delays (1-5s), with a slight 'hiccup' afterwards, and bizarre behaviour (ie. having to pause and unpause to get movie to resume). If I specify a seek time from the command line (via -l) it is a little faster, but then there is a 'hiccup' every time. A quick google search and I came across the concept Key frames or I frames which speed up the seek times.

Is omxplayer slow because it does not use these iframes or is it just slow because of its processor? Is there anything I can do to the video files to speed up this process?

  • OMXplayer is one of the few applications that takes advantage of the Raspberry Pi's GPU, so the issue is not the processor. – syb0rg Nov 28 '13 at 17:39
  • @syb0rg I am aware of the hardware acceleration, for whatever reason I just assumed seeking would be carried out by the CPU (It's a file read or the calculation of how far ahead to jump). Can you confirm it is GPU not CPU related please – puk Nov 28 '13 at 19:24
  • The CPU is used to calculate where to jump to, the GPU loads the jump. – syb0rg Nov 28 '13 at 19:31
  • @syb0rg I am just guessing here, but seeing as how the GPU can render 1080p in real time, and the 'jumps' take 1-5s, it stands to reason that the bottle neck is the CPU calculating where to jump, is that correct? – puk Nov 28 '13 at 19:34
  • It depends. As your question stands right now, it seems the hiccup is as it's rendering to where you jumped. Or is the hiccup after you press the button to jump before the rendering? – syb0rg Nov 28 '13 at 19:46

This behaviour has very little to do with the hardware. Yes it is true that using the GPU speeds up rendering of encoded video or rendering 3D graphics but they must follow a strict standard. The GPU is not a round robin solution that magically makes everything work.

The core problem is the compression settings used with the encoder for your file. If it was encoded by a noob or used custom settings to try and get the best compression settings, this is the consequence, slow seek times and artefacts.

Bluray files follow industry standard profiles so that any decoding hardware that follow these standards can quickly deal with user requests. We are talking about 15mbs video rate with i-keyframes every second. This takes up a lot of space but gives you the best quality of video and the fastest seek response with no artefacts. (5~10GB files)

When you acquire a video file encoded by somebody that needs smaller files because they are in a remote place, they use a custom profiles, usually achieved by reduces i-keyframes in the video, to reduce file size but keep a fairly decent image quality. Something like 2~15 seconds apart will reduce the file size up to 40% without loosing video quality, impressive!!??

When the software reads the video from start to end without interruption, its fine, but when you seek on video that has i-keyframes very far apart, this is what happens. Lets assume i-keyframes are 5 seconds apart.

  • Seek to 6 seconds
  • Decoder looks for keyframe before seek time, found at 5 seconds.
    • If its an i-keyframe, read data from file between 5 seconds to 10 seconds, as RAW video in to video buffer. Now start to play from 6 seconds from memory and continue to buffer from file as normal.
    • If its not an i-keyframe keep on searching backwards until we can load an render the entire part of the video.

This in memory process can take some time to process the video file.

The artefacts that you experience are caused by unusual framesizes, weird framerates or really big keyframe spaces. If you see this is means the video file has its keyframes very widely spread apart and the player and hardware was not able to fully load the segment of video into memory to chop it up. So it loaded the best P or B frame and started playing from there. Sometimes strange framesizes cause corruption during splitting of video in memory and these artefacts are produced.

There are so many variables that cause really bad video experience- but its mostly because people encode video without actually understanding how to do it properly, using bad examples, or built in high compression profiles that are designed for continious streaming, like webcam feeds, TV feeds but are used for stored video instead !

The video decoders on the Pi are designed to decode video and work best with video containers that strictly conform to specified standards or streaming profiles where you cannot seek.

  • Nice answer. 2 questions, first, are you saying that if I find better encoded videos, it will mostly solve my problem, and second, how could I find out what compression format a video is using – puk Mar 12 '14 at 3:42
  • 1
    One of the nicest programs I ever used to peek inside video containers is VirtualDub. Its is a bit complex to understand at first but it will provide you will all the information, codecs, keyframes, analyse stuff, fix stuff, edit and transcode. Try and take some bluray sample video and encode it your self. Try with handbrake first, use the built in settings. See how that reacts on the Pi, with different settings, frame sizes etc. I, personally use PlexMedia server where I keep all my videos. Plex transcodes video very nicely for the client over DLNA, to XBMC or PlexClients! – Piotr Kula Mar 12 '14 at 9:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.