[MPlayer-dev-eng] a/v sync

[Nico Sabbi]

Dermot McGahon wrote:

> On Wed, 5 May 2004 20:36:43 +0200, Roberto Togni <r_togni at tiscali.it>  
> wrote:
>
>> On 2004.05.05 10:35, Dermot McGahon wrote:
>> [...]
>>
>>> The files I am using for testing are available at:
>>>  ftp://ftp2.kasenna.com/private/images/demo.assets
>>> The ones in particular being used are:
>>>  sync_3.8Mbps_MPEG2-FullD1.mpg
>>>   tahiti_dreams_3.8Mbps_MPEG2_FullD1.mpg
>>
>> The first file plays ok here, with correct a/v sync.
>> I'm still sownloading the second one (hey, those files are big!), but 
>> no  problem in the first 30 seconds.
>> I'm on a P4 2.4, latest mplayer and ffmpeg cvs, xv output.
>>
>> So i think it's really a performance problem.
>
>
> I've moved from a PII-400 to a PIII-700 and they are both
> playing correctly from disk.
>
> I'm still having problems playing them as RTSP/UDP streams
> but that's likely related to using two demuxers and somehow
> filling the buffers incorrectly, or something. A/V sync
> is never right. Audio seems to be a little too fast,
> steadily keeps gaining seconds on video, and eventually
> there is an EOF on audio and video continues on.
>
> I get the "your computer is too slow to play this message"
> and get occasional crashes in decode_video.
>
> The ffmpeg codec seems to give better video quality than
> mpeg12, but apart from that it's not a codec related
> problem. A/V sync and crashes occur for either codec.
>
> I get "too many video packets in the buffer" message.
>
> The second demuxer is demux_ts, the first is demux_rtp. I
> think something in demux_rtp is not set up properly for
> demux_ts. I'm investigating.


unlikely, I remember I checked it when I posted the patch to pipe the 
demuxers.
A/V desync may be due to mplayer's inability to handle the load
("your computer is too slow to play this" is a symptom).
I wonder if demux_rtp is buffering data before feeding demux_ts, and if so
demux_rtp may be optimized.

A log with -v could be helpful to understand what's going wrong