[vdr] FF card A/V sync suggestion

Torgeir Veimo torgeir at pobox.com
Mon Oct 23 00:30:07 CEST 2006

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 at pobox.com

More information about the vdr mailing list