[MPlayer-dev-eng] a/v sync

[Dermot McGahon]

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.

Connections are also not being torn down properly i.e
sending an RTSP TEARDOWN. Before I started modifying
mplayer this was working for "standard" rtsp streams,
iirc, so this must be my own breakage also.

The VOD server is capable of streaming 80Mb/s. Cabling
is CAT5 through 100-base-T switches and hubs, which even
degraded, should be at least 64Mb/s or 8MB/s. The test
stream is 3.8Mb/s so I wouldn't have expected a network
overload until streaming about twenty streams, if even
then.

If I don't clear down the stream on the VOD server
manually - by running a utility, equivalent to sending
an RTSP TEARDOWN from the client - and try to stream
again, then A/V sync starts off completely borked, like
at 80 or 90. This must be reading residual data from
the previous streaming session. I'm not sure how to
flush data from any linux networking buffers they may
be waiting for select/recv to read from.

I've been distracted with other work, but I want to make
progress on this today/tomorrow so back to gdb with me.


Dermot.
--