[MPlayer-dev-eng] udp/mpeg2-ts streaming

[Nico Sabbi]

Dermot McGahon wrote:

> On Thu, 20 May 2004 15:46:09 +0200, Nico Sabbi <nsabbi at tiscali.it> wrote:
>
>>> At an earlier stage on a pii-400, I was getting "too many video
>>> packets for this buffer" message, and traced through the demuxing.
>>
>>
>> yes, but surely this message was preceded by "your system is too slow 
>> to  handle this", right?
>
>
> Yes it was. Since changing to a P3-700 which will be a fair approximation
> of the 800Mhz C3 VIA target hardware, I haven't gotten the "your system
> is too slow to handle this", until just now when I tried the -nosound
> suggestion :)
>
> Video quality is good with -nosound, but the a/v sync drifts
> immediately and I do get sound.
>
> mplayer -vo xv -nosound rtsp://omnibase/sync_test1
>
> Log file at: http://makeashorterlink.com/?D14052A58
>
> The logs seems to say that X11 video output is being used even
> though I have specified xv.
>
> I then tried the sdl audio output that I've been having some
> success with and a/v sync is _slightly_ out (enough to look
> wrong) and there are some video artifacts. So, the default
> audio output (OSS) with -nosound now gives the best video
> quality (by far), but it doesn't hold audio and video in
> sync at all.
>
> mplayer -vo xv -ao sdl -nosound rtsp://omnibase/sync_test1
>
> Log file at: http://makeashorterlink.com/?E27065A58
>

[xv] is being used, but the symptom is always the same: huge audio_out 
percentages

>
>> Is the video smooth until the end if you append -nosound?
>
>
> Yes, but audio and video are never in sync.
>
> What does that tell you?
>
>
> Dermot.
> -- 
>

I suspect that there's something wrong with the management of audio PTSs 
in this (demux_rtp->demux_ts)
configuration.  It should just work, but there may be bugs.
I'll look into the code tonight.

If you install vls you can simulate a plain udp server/client 
configuration without Live libraries:

vls -d:rtp:127.0.0.1:5001 file.mpg & (maybe the syntax is slightly 
different, check the man page)
mplayer rtp://127.0.0.1:5001

and see if it works better; at least this will permit us to isolate the bug.

    Nico