[MPlayer-dev-eng] Re: MPlayer-dev-eng digest, Vol 1 #1128 - 11 msgs

[Ross Finlayson]

> > However, I do want to make sure that the *functionality* of "rtp://..." -
> > for receiving/playing DVB streams - is still present.  I believe that DVB
> > streams (which are MPEG-2 Transport Streams, right?) can be received using
>
>No. DVB itself uses TS in teh air, but the DVB - net gateway does ts->ps
>with PID filtering, and give you multicast mpeg-ps streams.

Looking at "dvbstream.c" (from <http://www.dchapman.com/dvbstream/>), I see 
that by default it multicasts a MPEG Transport Stream over RTP, but - if 
given the "-ps" option - it will multicast a MPEG Program Stream instead.

(For MPEG Transport Streams)
> > a SDP file of the form
> >
> > v=0
> > m=video <port> RTP/AVP 33
> > c=IN IP4 <address>/255
>
>how does this look like for mpeg-PS streams?

Hmm, we have a problem here, because the "dvbstream" code uses RTP payload 
type 34 for streaming MPEG Program Streams.  This is wrong, wrong, wrong!, 
because payload type 34 is a static payload type that's reserved for H.263 
video.  This means that compliant RTP receiving tools will break if they 
try to receive such a stream.

Instead, "dvbstream" should be using a dynamic payload type (>= 96) when 
they stream MPEG Program Streams.  If it did this, it would be possible to 
receive it using a SDP file like:

v=0
c=IN IP4 <address>/255
m=video <port> RTP/AVP 96
a=rtpmap:96 MP2P/90000

(I'll need to sort this out with the author of "dvbstream".)

But anyway, the LIVE.COM code should be able to receive RTP MPEG Transport 
Streams OK.

Can anyone point me at a *file* of  DVB data that, when streamed using 
"dvbstream", "mplayer" is able to successfully receive and play (using the 
"rtp://" hack)?  I'd like to be able to test this out for myself.

>do mplayer's -aid -vid -sid options still work to select audio,video,sub ?

They should.  The RTP code will just present raw transport stream (or 
program stream) data to the rest of mplayer, which will presumably do 
appropriate demultiplexing then.

         Ross.