On 22 Oct 2006, at 22:56, C.Y.M wrote:
Torgeir Veimo wrote:
On 22 Oct 2006, at 22:33, C.Y.M wrote:
And just for completeness: No serious CPU load when playing back
with
VDR or mplayer.
Yes, if the extra CPU load by mplayer is not even noticeable when
playing back
VDR recordings, and it is not prone to any type or desync, then I
vote
we all
try to figure out what mplayer is doing and repeat it. Whats a few
extra CPU
cycles if it becomes much much more stable in the end.
The reason i mentioned the dvbplayer.c thread, is that this
problem was
mitigated by using different code to feed the softdevice mpeg2
decoder;
using softplay to playback recordings provided dropout free playback.
I'm not sure if softplay works with FF cards, but you might get the
source at softdevice.berlios.de to give it a try.
I use xine with my FF card and it works flawlessly and fixes all my
problems,
but since I never had trouble with the FF card when just watching
live TV, I
thought it was such a waste of CPU to have to use software decoding
for
everything. I only have problems when playing back recordings with
the FF card.
I wasn't talking about using different decoding software, I was
talking about trying some other piece of code thant dvbplayer.c to
read the recording from disk and feeding the hardware decoder. The
softplay plugin is such a different playback mechanism (but I can't
guarrantee that it works with an FF card). My thesis is that there
are issues with dvbplayer.c, which only show under certain
circumstances. One such ciscumstance is using a budget card with
softdevice playback of recordings, and a powerfull cpu.
--
Torgeir Veimo
[EMAIL PROTECTED]
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
