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
VDR or mplayer.
Yes, if the extra CPU load by mplayer is not even noticeable when
VDR recordings, and it is not prone to any type or desync, then I
try to figure out what mplayer is doing and repeat it. Whats a few
cycles if it becomes much much more stable in the end.
The reason i mentioned the dvbplayer.c thread, is that this
mitigated by using different code to feed the softdevice mpeg2
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
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
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.
vdr mailing list