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 torgeir@xxxxxxxxx
