Hi,
I am experimenting with xineliboutput using the xxmc video driver for the local sxfe frontend on an EPIA-M10000 board with CLE266. I have the OpenChrome Drivers installed. MPEG2 HW decoding seems usually to work, I get around 25% CPU usage. However, when I bring up VDRs OSD everything becomes painfully slow. Why is that? Are there any setup options I can use to make the OSD work decently?
Thanks,
Le lundi 28 janvier 2008 à 09:44 +0100, Ondrej Wisniewski a écrit :
I am experimenting with xineliboutput using the xxmc video driver for the local sxfe frontend on an EPIA-M10000 board with CLE266. I have the OpenChrome Drivers installed. MPEG2 HW decoding seems usually to work, I get around 25% CPU usage. However, when I bring up VDRs OSD everything becomes painfully slow. Why is that? Are there any setup options I can use to make the OSD work decently?
There is a problem with xine, the openchrome driver and VDR. You are too slow - I am seeing 9-12% CPU with current openchrome even with this bug.
I am using vdr-xine rather than xineliboutput
Cheers
Tony
Tony Grant wrote:
There is a problem with xine, the openchrome driver and VDR. You are too slow - I am seeing 9-12% CPU with current openchrome even with this bug.
I am using vdr-xine rather than xineliboutput
Cheers
Tony
Hi Tony,
that was not the answer I was hoping for ;-) Are you saying that there is a bug regarding OSD usage with the combination xine, openchrome and VDR? Can you explain a little more? Any ways around that?
Regarding CPU load I need to check that again at home. I was reporting the overall CPU load on my PC. I should probably check just the consumption of VDR and sxfe. To complicate things the VDR get's it's videostream using streamdev-client from the server box.
Le lundi 28 janvier 2008 à 12:07 +0100, Ondrej Wisniewski a écrit :
There is a problem with xine, the openchrome driver and VDR. You are too slow - I am seeing 9-12% CPU with current openchrome even with this bug.
I am using vdr-xine rather than xineliboutput
<snip>
that was not the answer I was hoping for ;-) Are you saying that there is a bug regarding OSD usage with the combination xine, openchrome and VDR? Can you explain a little more? Any ways around that?
Sorry I forgot to say I am using Fedora Core 8. There is an issue with libxcb and threads - it is fixed in OpenSuze10.3 says Reinhard.
With the OSD I have increase in CPU load and, in the terminal I am running Xine from, warning that I don't have enough colors etc. Can't zap from horizontal to vertical polarization.
Screen goes blue and VDR restarts
I am currently using the multiproto driver linked from the 1.5.14 announcement.
Regarding CPU load I need to check that again at home. I was reporting the overall CPU load on my PC. I should probably check just the consumption of VDR and sxfe. To complicate things the VDR get's it's videostream using streamdev-client from the server box.
OK 26% total on M10000 is about the same as mine
xine 11% average X 3-4% vdr 3-4% + other proccessus
Tony
Tony Grant wrote:
Le lundi 28 janvier 2008 à 12:07 +0100, Ondrej Wisniewski a écrit :
Sorry I forgot to say I am using Fedora Core 8. There is an issue with libxcb and threads - it is fixed in OpenSuze10.3 says Reinhard.
With the OSD I have increase in CPU load and, in the terminal I am running Xine from, warning that I don't have enough colors etc. Can't zap from horizontal to vertical polarization.
Screen goes blue and VDR restarts
I am currently using the multiproto driver linked from the 1.5.14 announcement.
I am using Ubuntu 7.10 with xine lib from the repos. Here's the problem I encounter. Might be the same bug you are talking about:
VDR is running with xineliboutput plugin. Remote frontend sxfe is started on the same PC: $ vdr-sxfe --video=xxmc xvdr://127.0.0.1
Initially I get video and audio just fine with HW decoding. But when I switch channel and the OSD is shown I get lots of these: video_out: Warning! Out of xx44 palette colors!
And shortly after the crash: video_out_xxmc: Using software decoding for this stream. libmpeg2: output port has XxMC capability AFD changed from -2 to -1 video_out_xxmc: Using software decoding for this stream. video_out_xxmc: Using hardware decoding for this stream. *** glibc detected *** vdr-sxfe: double free or corruption (!prev): 0x086d6558 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7c72d65] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7c76800] /usr/lib/xine/plugins/1.1.8/xineplug_vo_out_xxmc.so[0xb6656685]
Looks like a xine problem, specifically the xxmc plugin. :-(
Ondrej ...
Le mardi 29 janvier 2008 à 09:01 +0100, Ondrej Wisniewski a écrit :
I am using Ubuntu 7.10 with xine lib from the repos. Here's the problem I encounter. Might be the same bug you are talking about:
VDR is running with xineliboutput plugin. Remote frontend sxfe is started on the same PC: $ vdr-sxfe --video=xxmc xvdr://127.0.0.1
Initially I get video and audio just fine with HW decoding. But when I switch channel and the OSD is shown I get lots of these: video_out: Warning! Out of xx44 palette colors!
And shortly after the crash: video_out_xxmc: Using software decoding for this stream. libmpeg2: output port has XxMC capability AFD changed from -2 to -1 video_out_xxmc: Using software decoding for this stream. video_out_xxmc: Using hardware decoding for this stream. *** glibc detected *** vdr-sxfe: double free or corruption (!prev): 0x086d6558 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7c72d65] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7c76800] /usr/lib/xine/plugins/1.1.8/xineplug_vo_out_xxmc.so[0xb6656685]
Looks like a xine problem, specifically the xxmc plugin. :-(
Yes that is the bug
Tony
-
Ondrej Wisniewski -
Tony Grant