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.