[MPlayer-dev-eng] [PATCH] dvb fix

[Nico]

Arpi wrote:

>Hi,
>
>  
>
>>My theory is that mpeg multiplexing of dvb-t berlin, together with the
>>demultiplexing and syncing strategy of mplayer might be the problem.  If
>>I find out more and/or can reproduce the thing, I'll write again...
>>
>>BTW very good argument against this being a hardware problem is, that
>>CPU and kernel load is ok and, more important, that everything works ok
>>if I use -nosound or -cache.
>>    
>>
>
>there is a 'design issue' with mplayer (and most other players i know):
>it sync to audio (or wall clock), instead of stream clock.
>
>so if your clock reference (soundcard timer in case of mplayer) isn't in
>100.00000% sync with your stream source's sync (dvb broadcaster) then you'll
>either overflow the input buffer (so after a while you get the 'too many
>packets' thingie), or underflow it (so it will play faster than data comes,
>resulting a-v desync (it cant play audio slower, but it can play video
>slower).
>
>this problem was once discussed, afair started by Ross about the live.com
>streaming support.
>
>btw, if the clocks are near in sync, then overflow won't occur in near time
>(maybe after several hours of run) and underflow can be compensated out by
>-cache's prebuffering. so, i think it's small underflow in your case.
>
>the best solution would be to sync playback to the stream clock.
>the problem is that there is no such thing as 'stream clock', at least with
>mpeg es/ps streams. maybe it is with mpeg-ts ?
>
yes, System Clock Reference, and for every program there's a Program 
Clock Reference.
And there's also another field that indicates, for a program,  which 
stream (pid) the playback
should be synced to.

>also, if you do know the exact bitrate of your incoming stream, you could
>count bytes and use that as clock reference.
>another idea is reading the stream in blocking mode (via -cache), and try to
>keep the cached data size (averaged/smoothed!) near constant.
>if it gets lower, then speed up playback a bit, if it gets bigger,
>then slow down playback a bit.
>if you're lucky & clever, and can avoid waveing (the usual side-effect of
>speed feedback) then it could work well.
>
>we really need to implement sth like this in g2, to support realtime
>(wallclock-synced rate at the server) streams/broarcasts correctly.
>
>
>A'rpi / Astral & ESP-team
>
>--
>Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
>
>_______________________________________________
>MPlayer-dev-eng mailing list
>MPlayer-dev-eng at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>
>  
>