[JoeSchmoe007]

I am running latest version of OpenELEC (3.0.0, via image downloaded from here: http://openelec.tv/get-openelec/download...load/10/76) on Raspberry Pi. Raspberry Pi is connected to TV via HDMI

1) When XBMC boots the scrolling "news" line at the bottom is a bit jerky. Is this the same for everybody?

2) Is frame rate displayed on video diagnostic info correct? For 1080P videos (Apple trailers, youtube or video from the flash drive) I never get 24 FPS as expected. Frame rate displayed is always fluctuating between 7 and 14 FPS yet video seems fluid without any noticeable frame drops and quality deterioration. To take factors like internet performance out of equation just download this video: http://divxtrailers.divx.com/BigBuckBunn...PlusHD.mkv and let me know what you see.

3) Audio seems to be always out of sync with video. Video diagnostic info always displays something between -2 and -4 (same for the test MKV file I linked to about) and it sometimes is noticeable visually as well. Can this be fixed?

None of this is an issue when running version of XBMC for Windows on my desktop. Frame rate is almost precisely 24 FPS and audio and video are always in sync. Scrolling news line is perfectly smooth too.

[Milhouse]

1) Scrolling text uses a lot of CPU on the Pi, so disable the RSS feed - it's jerky for everyone.

2) On the Pi, the FPS shown in the video diagnostic panel is that of the GUI, not the Video - the Pi GUI frame rate bears no relation to the video frame rate and can be ignored. When a video is playing, the GUI is idle so the frame rate drops right down, which is why you see FPS of between 7 and 14. Rest assured the Video is playing back at the correct FPS, you just can't tell from the video diagnostic panel.

3) Dunno, can't say I've had this problem.

[JoeSchmoe007]

1) Scrolling text uses a lot of CPU on the Pi, so disable the RSS feed - it's jerky for everyone.

2) On the Pi, the FPS shown in the video diagnostic panel is that of the GUI, not the Video - the Pi GUI frame rate bears no relation to the video frame rate and can be ignored. When a video is playing, the GUI is idle so the frame rate drops right down, which is why you see FPS of between 7 and 14. Rest assured the Video is playing back at the correct FPS, you just can't tell from the video diagnostic panel.

3) Dunno, can't say I've had this problem.

What about Windows version of XBMC? What does that rate mean for it? GUI or Video? I think it is video

Can you try the .MKV file that I linked to and tell me what a/v delay is for you? Or if this is too much of a hassle - any publicly available source/stream that is convenient for you that I can try to compare with what you are seeing?

Thanks.

[Milhouse]

What about Windows version of XBMC? What does that rate mean for it? GUI or Video? I think it is video

Totally different video playback implementation. The behaviour you observe is Pi specific, as the omxplayer is asynchronous and its frame rate can't be measured (so what you see is the frame rate of the GUI, not the video). In Windows (and quite possibly other non-Pi Linux implementations), the video playback is synchronous, so GUI frame rate == video frame rate.

Can you try the .MKV file that I linked to and tell me what a/v delay is for you? Or if this is too much of a hassle - any publicly available source/stream that is convenient for you that I can try to compare with what you are seeing?

I'll try, but I won't be able to test it for a few more hours - my Pi is in the middle of scraping a new library...

[JoeSchmoe007]

What about Windows version of XBMC? What does that rate mean for it? GUI or Video? I think it is video

Totally different video playback implementation. The behaviour you observe is Pi specific, as the omxplayer is asynchronous and its frame rate can't be measured (so what you see is the frame rate of the GUI, not the video). In Windows (and quite possibly other non-Pi Linux implementations), the video playback is synchronous, so GUI frame rate == video frame rate.

Can you try the .MKV file that I linked to and tell me what a/v delay is for you? Or if this is too much of a hassle - any publicly available source/stream that is convenient for you that I can try to compare with what you are seeing?

I'll try, but I won't be able to test it for a few more hours - my Pi is in the middle of scraping a new library...

I appreciate you taking time to try whenever you can get to it. If you do - let me know specific time code when you looked at a/v delay (say 1 minute into the video).

[Milhouse]

Timecode 03:02, a/v: -4.080.

Audio seems to be in sync, or close enough for it not to be a problem.

[JoeSchmoe007]

Timecode 03:02, a/v: -4.080.

Audio seems to be in sync, or close enough for it not to be a problem.

I am not sure I understand you correctly. This value is in seconds as far as I know. Are you saying 4 seconds of a difference is not a problem?

[Milhouse]

A silent (non-speaking) movie isn't really ideal test material, but from what I could see on screen and hear, the sounds were in sync with the visuals, yes.

There was certainly no 4 second delay, so once again the number in the diagnostics could be meaningless for the Pi platform.

[JoeSchmoe007]

A silent (non-speaking) movie isn't really ideal test material, but from what I could see on screen and hear, the sounds were in sync with the visuals, yes.

There was certainly no 4 second delay, so once again the number in the diagnostics could be meaningless for the Pi platform.

OK, I see what you mean. I sort of had the same suspicion - that a/v number may not be accurate. Especially in this clip it does seem that there is no perceptible delay. On streaming videos, though, I did notice some delay.