Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi Part 2 - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
---- Thread: OpenELEC Testbuilds for RaspberryPi Part 2 (/showthread.php?tid=184866)



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - rbej - 2013-08-22

Updated Gotham Branch

- updated Xbmc Gotham

- [utils] Speed up url processing on music library

- [rbp/omxplayer] Improve the player diagnostics overlay

- [rbp/omxplayer] Avoid too many calls to GPU

http://netlir.dk/rbej/builds/

http://lysin.me/rbej


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-08-22

(2013-08-21, 23:51)popcornmix Wrote: Found it. We update buffering stats once per packet received. Typically there are 24 of these for video, and slightly more for audio per second.
The stats info involves querying the gpu for the current media time. Talking to the gpu is a little expensive (but fine for ~100 call per second).

However TrueHD audio generates thousands of packets per second. We discard them after receiving them, but they still trigger the media time request to gpu.
Thousands of gpu requests per second is enough to slow things down.

I need to add a rate limiter so gpu is only queried a maximum of, say, 50 or 100 times per second.

Oh you star - I'm afraid I took a break from this yesterday so you've saved me a ton of effort! Smile

Give me a shout if there's a patch you want me to test!

Edit1: I see you've posted a patch, will test and let you know... should this apply cleanly to master head?
Edit2: Yay, github.com is experiencing server errors... Smile


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-08-22

(2013-08-22, 07:41)rbej Wrote: Do you understand that im not developer and i no fixed any issues.

OE 3.1.6 include Frodo, not Gotham.

I understand it already, but I just want to know if other users have this problem also.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - rterblanche - 2013-08-22

(2013-08-22, 09:34)Koloss Wrote:
(2013-08-22, 07:41)rbej Wrote: Do you understand that im not developer and i no fixed any issues.

OE 3.1.6 include Frodo, not Gotham.

I understand it already, but I just want to know if other users have this problem also.

I don't but I only reboot when updating. Other than that my Pi stays on. Found less problems with card corruption like that.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - spjonez - 2013-08-22

(2013-08-22, 09:34)Koloss Wrote:
(2013-08-22, 07:41)rbej Wrote: Do you understand that im not developer and i no fixed any issues.

OE 3.1.6 include Frodo, not Gotham.

I understand it already, but I just want to know if other users have this problem also.
There was one build a while back that gave me boot issues, but I haven't had any since. I also only reboot to update otherwise I leave my Pi on all the time.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-08-22

(2013-08-21, 23:51)popcornmix Wrote: Found it. We update buffering stats once per packet received. Typically there are 24 of these for video, and slightly more for audio per second.
The stats info involves querying the gpu for the current media time. Talking to the gpu is a little expensive (but fine for ~100 call per second).

Yep, looks like you nailed it! Blade Runner now buffers very nicely and with no stutter/stall after resuming the movie, and it maintains B 99% af: 42% vf: 100% throughout. And it's the same results when starting the movie from the beginning.

mike7's test video from post #345 also plays back without a hitch, absolutely perfect!

I included the diagnostics display patch which seems to be a lot calmer, however the third line - D (Video: vc1...) - overlaps slightly the "P" line above - it looks like the 3rd and 4th lines need to be moved down a bit as there's a gap between the 4th and 5th lines. Personally I'd also remove the fps display since it doesn't relate to the video, and is likely to confuse rather than inform. Final very minor nit: there's a space following the opening parenthesis of the C and W lines (and a space preceeding the W closing parenthesis) - there are no such spaces in any of the other lines so it's just an issue of consistency...

Would it be possible (if you have the time) to post a brief description of what some of these diagnostic items mean? I've seen this wiki page but suspect it's a little out of date, and some fields don't apply to omxplayer. I'm most interested in understanding how the buffer values may relate to any cache values specified in advancedsettings.xml.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - mike7 - 2013-08-22

(2013-08-22, 17:41)MilhouseVH Wrote:
(2013-08-21, 23:51)popcornmix Wrote: Found it. We update buffering stats once per packet received. Typically there are 24 of these for video, and slightly more for audio per second.
The stats info involves querying the gpu for the current media time. Talking to the gpu is a little expensive (but fine for ~100 call per second).
mike7's test video from post #345 also plays back without a hitch, absolutely perfect!

Yes!!! Tested with rbej build, can't wait raspbmc backport.
Thank you very much.

One more question, is it possible to extract and play ac3 core from TrueHD at playback? As workaround I need to extract core and remux.

PS. Hope multichannel PCM and HD (DTS-MA & TrueHD) passthrough will come soon.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-08-22

(2013-08-22, 17:41)MilhouseVH Wrote: Would it be possible (if you have the time) to post a brief description of what some of these diagnostic items mean? I've seen this wiki page but suspect it's a little out of date, and some fields don't apply to omxplayer. I'm most interested in understanding how the buffer values may relate to any cache values specified in advancedsettings.xml.

The most important settings are vf and af. They are video fifo fullness, and audio fifo fullness. This fifo is between the ARM and GPU. If this ever reaches zero then we underrun and stutter.
Ideally one of these will always be approximately 100%. This fifo contains a few seconds of buffered data, and that means the GPU can happily continue playing for that time, however busy the ARM is.
The audio data here is after audio decode.

Next most important are vq and aq. These are video queue and audio queue. This queue is between demuxer and video and audio threads (all on arm).
Ideally one of these will always be approximately 100%. This queue contains a few seconds of buffered data to handle stalls in file access.
The audio data here is before audio decode.

I believe the buffer % (e.g. 0 B 99%) is just the max of vq and aq.

Generally when CPU is the limiting resource (e.g. software decoding of multichannel audio) then the audio fifo will drain first.
When file (e.g. nfs) bandwidth is the limiting resource (e.g. wifi connection) then the audio/video queues will drain first.

There is also an additional buffer, which traditionally was only enabled for "internet" sources (basically urls that started with http://).
This buffer is three times the value of cachemembuffersize in advancedsettings.
I believe the new setting alwaysforcebuffer means the "internet" buffer is applied to all files which can help slow network (e.g. wifi) setups.
I believe the "0 B" number is the size of the "internet" buffer is in use.

By default the ffmpeg demuxer limits the rate at which a file is read to approximately the maximum bitrate.
I'm not sure why that would ever be desirable, but apparently gigibit ethernet + slow CPU can spend all its time filling buffers and none decoding.
But with the Pi's 100Mbit ethernet, I don't see that as a problem.
readbufferfactor allows that limit to be increased.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-08-22

Thanks for that, very useful.

Presumably the size of cachemembuffersize has no impact whatsoever when alwaysforcebuffer is 0 and media is local (non-http)? That is to say, increasing cachemembuffersize will not improve local media playback performance unless alwaysforcebuffer is enabled.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Huuh - 2013-08-22

I'm having huge problems with the OSD while playing videos less than 720p in resolution. There's no stop, play, pause, "x" in the corner, etc. buttons when I move the mouse.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-08-22

(2013-08-22, 18:58)MilhouseVH Wrote: Presumably the size of cachemembuffersize has no impact whatsoever when alwaysforcebuffer is 0 and media is local (non-http)? That is to say, increasing cachemembuffersize will not improve local media playback performance unless alwaysforcebuffer is enabled.

Yes. It is possible that increasing video/audio fifo and queue sizes would be more beneficial than using alwaysforcebuffer.
The extra cache means an extra memory copy into and (probably) out of the cache.
cachemembuffersize requires 3 times the size required (1/3 is a back buffer purely there for seeking backwards small amounts. 1/3 is the normal buffer. I don't know about the other 1/3...)

On a 512M board we can probably afford more memory to go to the queues and fifos. No way of specifying that externally, but if you are building your own, you could play with these sizes.
Look for small_mem in xbmc/cores/omxplayer, and you can see the sizes of buffers used for 256M and 512M boards. Might be interesting to try increasing them.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-08-22

(2013-08-22, 08:18)rbej Wrote: Updated Gotham Branch

- updated Xbmc Gotham

- [utils] Speed up url processing on music library

- [rbp/omxplayer] Improve the player diagnostics overlay

- [rbp/omxplayer] Avoid too many calls to GPU

http://netlir.dk/rbej/builds/

http://lysin.me/rbej

Thanks. This has fixed the reboots when changing view mode I was getting Smile

I'm still having a couple of issues though:

1) skiplusand skipminus not working properly whilst watching movies.The log shows

15:04:03 T:3060539392 DEBUG: LIRC: Update - NEW at 892332:197 0 KEY_NEXT devinput (KEY_NEXT)
15:04:03 T:3060539392 DEBUG: OnKey: sleep (0xdf) pressed, action is SkipNext

15:04:07 T:3060539392 DEBUG: LIRC: Update - NEW at 896658:19c 0 KEY_PREVIOUS devinput (KEY_PREVIOUS)
15:04:07 T:3060539392 DEBUG: OnKey: pause (0xdd) pressed, action is SkipPrevious

(SkipNext does nothing and SkipPrevious goes to the start of the Movie, which is obviously a bit annoying)

even though I've got

<skipplus>BigSkipForward</skipplus>
<skipminus>BigSkipBack</skipminus> (I tried nop as well)

set under <FullscreenVideo> (and Global)

and Lircmap.xml has

<skipminus>KEY_PREVIOUS</skipminus>
<skipplus>KEY_NEXT</skipplus>

2) The other issue I have is with the TV EPG. When first opened without TV playing, selecting a channel starts TV and goes fullscreen but if I open the EPG whilst TV is playing and select a channel, it changes channel but stays on the EPG and I have to press Back to go to Home and then Back again to go fullscreen (I have Red set to Fullscreen but that doesn't work from any of the PVR pages either). These EPG issues aren't present in Windows XBMC.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-08-22

(2013-08-22, 19:06)popcornmix Wrote: On a 512M board we can probably afford more memory to go to the queues and fifos. No way of specifying that externally, but if you are building your own, you could play with these sizes.
Look for small_mem in xbmc/cores/omxplayer, and you can see the sizes of buffers used for 256M and 512M boards. Might be interesting to try increasing them.

With your latest GPU/time fix I'm not seeing any playback performance issues right now - kind of a shame the fifo queues can't be tuned in advancedsettings but I know there is resistance to that kind of thing (perhaps understandable).

I took a quick look at omxplayer and it seems to be allocating the following memory to the queues:
Code:
audio: 3MB (256MB) and 6MB (512MB)
video: 10MB (256MB) and 40MB (512MB)

I've got no problems right now with these values (512MB board) but I guess if I were connecting over WiFi or had a really lousy network it might be beneficial to use larger values.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-08-22

@popcornmix: I'm just viewing a fairly low bit rate HD movie over NFS (DTS 1536 kb/s audio, h264 1280x544 video with a typical video bit rate of 4-5Mb/s), and I've noticed that vq is very low, in fact it's mostly 0% even though CPU is only 40% and vf is 100%.

Is this a problem (vq == 0), or is it simply that ffmpeg read ahead (readbufferfactor is 4.0) doesn't need to read ahead at all as there is more than sufficient network bandwidth to supply the video queue with data as it is needed? The Pi is reading about 800KB/second.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-08-22

(2013-08-22, 19:50)MilhouseVH Wrote: @popcornmix: I'm just viewing a fairly low bit rate HD movie over NFS (DTS 1536 kb/s audio, h264 1280x544 video with a typical video bit rate of 4-5Mb/s), and I've noticed that vq is very low, in fact it's mostly 0% even though CPU is only 40% and vf is 100%.

Is this a problem (vq == 0), or is it simply that ffmpeg read ahead (readbufferfactor is 4.0) doesn't need to read ahead at all as there is more than sufficient network bandwidth to supply the video queue with data as it is needed? The Pi is reading about 800KB/second.

If aq is at 100% then no more packets are read (if it's audio you have nowhere to out it).
So it's quite normal for one of the audio/video queues to be full and one quite empty.

There is also a max time (8 seconds I believe) limit for the queues.
For low bit rates you may be pretty empty after 8 seconds (and the GPU fifo may have swallowed what is there).


This forum uses Lukasz Tkacz MyBB addons.