[MPlayer-dev-eng] [PATCH] Re: Mplayer unable to play MPEG2-TS over RTP (Was: Mplayer as a Client for VideoLAN server)

[Nico]

Hi,

attached is a prototype of a patch that (if my understanding of 
mplayer's demuxing api is correct) should solve Rett's problem.

I believe it's general and clean enough to prevent misdetetctions of 
streams.
Especially consider these two lines:

+  od = demux_open_stream(s, DEMUXER_TYPE_UNKNOWN, -1, -1, -1, NULL);
+ // WILL TURN TO (OR CAN BE FORCED TO)  DEMUXER_TYPE_MPEG_TS or any 
other DEMUXER_TYPE_* if needed of correctly  flagged
+

It implements the pipelined demuxing that I adviced in a previous email.

Note that the resulting demuxer deals only with streams that have audio 
and video interleaved in one,
but changing it so as to deal with  seperate streams is trivial: just 
reassign sh_audio if an audio demuxer_stream was previously open.

I'm not totally sure it's the best/cleanest way to create a pipelined 
demuxing, but as far as I can see (and considering the total lack of docs,
and that the only reference I had was a mail by Arpi (thanks!) ) it 
seems correct (some warnings apart).

I tested it streaming via VLS a TS  file to 127.0.0.1 and using

./mplayer sdp:///root/file.sdp

where file.sdp contains

v=0
s=Test MPEG-2 TS session
t=0 0
m=video 1234 RTP/AVP 33
c=IN IP4 127.0.0.1/255


as suggested by Ross.

Rett, please consider that in its actual form demux_ts.c suffers on 
 high bitrate TS streams, because of the excessive fragmentation 
inherent in the structure of MPEG-TS.

To everybody: I'd love to have advices on how to reduce this effect.

    Nico




Rett Walters wrote:

>Hello:
>
>It was suggested to me by Nico to post to this list for help with an thread that I
>started on the mplayer-users list.
>
>I have found an issue using Mplayer with the live.com streaming libraries to play an
>an MPEG2 Transport stream over RTP generated from VideoLAN Server (www.videolan.org).
>
>Since VideoLAN is not RTSP compliant, I used the sdp:// url format and specified a
>sdp file that describes the stream as RTP/AVP type 33 and gives the port number and
>multicast address of the stream.
>
>Mplayer starts, a video window comes up, and a few frames of garbage appear before
>MPlayer crashes.
>
>At Ross Finlayson's suggestion, I ran Mplayer the same way with the -dumpvideo
>option.  I then played back the dump and found a perfect MPEG2 file with AUDIO that
>played with Mplayer just fine.  The key here is the stream had audio and video, when
>I told mplayer to only dump the video.
>
>This led Nico to suggest that there is something wrong with the demuxer logic for
>RTP that can't deal with an interleaved a/v stream like MPEG2-TS.
>
>It appears the the RTP logic in Mplayer expects audio and video to be in separate
>streams, and that maybe another demuxer layer needs to be added to account for
>interleaved streams.
>
>Several products both commercial and open-source stream video over MPEG2-TS in
>single RTP stream.  Looking into this issue would make Mplayer a viable alternative
>for several applications, especially with its second-to-none output device support.
>
>Thanks for any help anyone can provide.
>
>Rett Walters
>
>
>  
>


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rtp-20030719.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20030720/160885a0/attachment.txt>