[Changed] Xine/mplayer and delay during playback SD/HD video

[nite_man]

Hi,

I'd like ask about CPU loading during HD video playback. In my case mplayer takes 50-80% of CPU. As result I can see small delays continuously. Any suggestions or recommendations to improve HD video playback will be very appreciated!

TIA

[nite_man]

I've found the same problem with DivX playback after a few hours of working of core. See these log messages:

Code: [Select]

05      04/23/09 1:21:40.291            [ID: 1004]  CHAPTER:0 POS:6362640 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:41.976            [ID: 1004]  CHAPTER:0 POS:6364320 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:43.627            [ID: 1004]  CHAPTER:0 POS:6366000 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:45.282            [ID: 1004]  CHAPTER:0 POS:6367640 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:46.946            [ID: 1004]  CHAPTER:0 POS:6369320 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:48.649            [ID: 1004]  CHAPTER:0 POS:6371000 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:50.417            [ID: 1004]  CHAPTER:0 POS:6372800 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:52.133            [ID: 1004]  CHAPTER:0 POS:6374520 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:53.820            [ID: 1004]  CHAPTER:0 POS:6376160 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:55.408            [ID: 1004]  CHAPTER:0 POS:6377800 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:56.729            [ID: 1004]  CHAPTER:0 POS:6379120 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:58.025            [ID: 1004]  CHAPTER:0 POS:6380400 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:21:59.325            [ID: 1004]  CHAPTER:0 POS:6381720 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:22:00.638            [ID: 1004]  CHAPTER:0 POS:6383040 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:22:01.947            [ID: 1004]  CHAPTER:0 POS:6384320 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
05      04/23/09 1:22:03.523            [ID: 1004]  CHAPTER:0 POS:6385880 TITLE:0 SUBTITLE:-1 AUDIO:-1 TOTAL:6533440 (seek 0) t.c. ctr 1 freq 1, <0xac2ffb90>
As you may see sometimes the time between message is 1 sec, sometimes - 2-3. After reboot it again starts play without any delay. I don't see any loading of the system. The CPU is used by just 22.2%. But Xine takes 40-50% of CPU but normally it's 30-40%.

Any idea why it can be happened?

TIA

[colinjones]

Michael,

The log entries are normal (although should be 1 per second all the time) - they are just the timestamps used to keep track of the location through playback so that the resume and split stream functions can work.

It sounds like you are describing the well known xine issue..... after a period of time, playback starts to get jerky... the longer the time and/or the more video files you playback the worse it gets. A Quick Reload fixes the problem. It has been postulated that it is a leak in xinelib (memory leak? can't remember), and I believe someone said that they believe it is more general than just LMCE, so perhaps it is a bug that will be fixed in 0810? Not sure, I haven't seen any of those using 0810 Alpha comment on it... but obviously, HD video is going to be effected even more....

[totallymaxed]

Michael,

The log entries are normal (although should be 1 per second all the time) - they are just the timestamps used to keep track of the location through playback so that the resume and split stream functions can work.

It sounds like you are describing the well known xine issue..... after a period of time, playback starts to get jerky... the longer the time and/or the more video files you playback the worse it gets. A Quick Reload fixes the problem. It has been postulated that it is a leak in xinelib (memory leak? can't remember), and I believe someone said that they believe it is more general than just LinuxMCE, so perhaps it is a bug that will be fixed in 0810? Not sure, I haven't seen any of those using 0810 Alpha comment on it... but obviously, HD video is going to be effected even more....

Hmmm... weirdly I have just been testing the latest 0810 Alpha and this problem is still there even with SD content. So as xinelib has certainly changed between 0710 and 0810 its hard to see how this could be purely a xinelib issue.

It needs to be fixed for sure though :-(

Andrew

[colinjones]

Damn! Had my fingers tightly crossed!

Does the xine wrapper do anything once it has kicked off playback? Or does the call to the xine library do everything from then on until playback is finished? I guess xine wrapper at least has to send the time stamp events.... just trying to think of something that could be leaking or otherwise going awry in the wrapper part, that could be causing this... doesn't seem all that likely.... unless the wrapper is constantly calling something in xinelib to keep the playback going (also doesn't seem likely) that could potentially then cause this issue.... it really is a pain!

[nite_man]

Thanks guys for clarification! The strange thing is that. I didn't face with that problem in the past when I played just SD content and run UI2 with low resolution. Now I run UI2 without transparency with resolution 1080p. Maybe it's related somehow. If quick reloading of router help I suspect that problem should be with xine wrapper. Otherwise it won't help at all. Moreover, the same problem appears with mplayer and HD content. So, maybe it something more generic then just wrapper?

[bulek]

Hi,

I also spotted similar behaviour. If I have a long uptime and have played many files, than there is a higher chance that video will be jerky...

I'm not using any higher resolution than 800x600 on MD.

HTH,

regards,

Bulek.

[totallymaxed]

Hi,

I also spotted similar behaviour. If I have a long uptime and have played many files, than there is a higher chance that video will be jerky...

I'm not using any higher resolution than 800x600 on MD.

HTH,

regards,

Bulek.

Posde has a theory that it might be caused by the polling on port 12000 for timecode updates. This sounds plausible to me...so we'll test it.

Andrew

[MarcoZan]

Hi all

if it can be of any help, on low "horse power" MD this issue (jerky videos) shows near the end of the first playback (when movie is long).
A router reload always clears the situation.

Regards
Marco

[totallymaxed]

Hi all

if it can be of any help, on low "horse power" MD this issue (jerky videos) shows near the end of the first playback (when movie is long).
A router reload always clears the situation.

Regards
Marco

Ok... thanks ;-)

Andrew

[nite_man]

Posde has a theory that it might be caused by the polling on port 12000 for timecode updates. This sounds plausible to me...so we'll test it.

Keep us updated, please. I also try to dig it as deep as I can

[totallymaxed]

Posde has a theory that it might be caused by the polling on port 12000 for timecode updates. This sounds plausible to me...so we'll test it.

Keep us updated, please. I also try to dig it as deep as I can

Will do. May get time on our 810 alpha test system later to run some tests on this port 12000 theory.

Andrew