[rbp] Avoid blocking the video thread keeping the video fifo full. #2158

Merged
merged 1 commit into from Feb 3, 2013

Conversation

Projects
None yet
5 participants
Member

popcornmix commented Feb 1, 2013

OpenMAX IL is an asynchronous media player. The key to getting good performance is to ensure the audio and video fifo have sufficient data to withstand any processing spikes by the ARM.
Ideally the fifos would allow the arm to crash, and video and audio playback to continue smoothly for a couple of seconds.

I've examined the fifo behaviour, and found the video fifo is always almost empty. (The audio fifo is full).
It turns out that the PlayerVideo task (which submits video frames to GPU fifo) blocks until the presentation time has arrived before calling FlipPage (in order to keep subtitles etc. synced).
This is very bad. We generally only one frame of video data in the GPU fifo. This means a spike in ARM workload (e.g. bringing up OSD, or a peak in bitrate) causes the fifo to empty and video to stutter.

The patch here avoids blocking, and lets the FlipPage happen on a later packet.
I've found with this patch, my test clip (1080p with software DTS audio decode) I can play without stuttering at 700MHz. Without this patch it fails to play even at 1000MHz.

@popcornmix popcornmix [rbp] Avoid blocking the video thread keeping the video fifo full.
OpenMAX IL is an asynchronous media player. The key to getting good performance is to ensure the audio and video fifo have sufficient data to withstand any processing spikes by the ARM.
Ideally the fifos would allow the arm to crash, and video and audio playback to continue smoothly for a couple of seconds.

I've examined the fifo behaviour, and found the video fifo is always almost empty. (The audio fifo is full).
It turns out that the PlayerVideo task (which submits video frames to GPU fifo) blocks until the presentation time has arrived before calling FlipPage (in order to keep subtitles etc. synced).
This is very bad. We generally only one frame of video data in the GPU fifo. This means a spike in ARM workload (e.g. bringing up OSD, or a peak in bitrate) causes the fifo to empty and video to stutter.

The patch here avoids blocking, and lets the FlipPage happen on a later packet.
I've found with this patch, my test clip (1080p with software DTS audio decode) I can play without stuttering at 700MHz. Without this patch it fails to play even at 1000MHz.
ac86e23
Member

FernetMenta commented Feb 1, 2013

Blocking in FlipPage is indeed bad. I have solved this in #870 (add buffering) but not yet adopted to OpenMax. Would you have time to do so after I have rebased?

Contributor

davilla commented Feb 1, 2013

Interesting. aml could use this too in dvdplayer. FernetMenta, the one difference from rpi/aml and others is the video frame is not available to gles. It is being rendered to a separate video plane and XBMC is not even in control of then it flips. The whole concept of wait to FlipPage goes out the window but you do have to retain something for when the GUI os popped up over a playing video.

Member

FernetMenta commented Feb 1, 2013

Yes, I see the difference but also strong similarities. In case of aml the video buffers are provided by the underlying system (right?), for the other platforms they have to be provided by renderers. Video players should focus on decoding and need to be decoupled from presentation stage. This is the job of RenderManager.

Contributor

davilla commented Feb 1, 2013

yes, just a FYI, there's a new dvplayer/amcodec implementation in pivos repo. will be doing a PR soon for it. Here, amcodec is doing hw decode but the actual video frames are rendered outside of gles.

Koenkk referenced this pull request in xbianonpi/xbian Feb 2, 2013

Closed

Reduce overclock #262

huceke merged commit 997517f into xbmc:master Feb 3, 2013

rbej commented Feb 3, 2013

Please add this for Frodo branch.

Koenkk referenced this pull request in xbianonpi/xbian Feb 17, 2013

Closed

Apply various patches to XBMC Frodo 12 Stable #263

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment