[Live-devel] Kasenna MediaBase support

[Ross Finlayson]

Derk-Jan,

>Thought it was better to discuss this here.
>I really want to try to get this working no matter how much it's their
>fault for not keeping to the latest specs (and actually creating broken
>implementations).

OK, fair enough.

>4: VLC needs to be able to call a demux from another demux (TS streams
>need to be demuxed)

Yes, this is something that's needed for playing 'proper' MPEG-2 TS/RTP 
streams also.

>I know how I would go about doing the RAW/RAW/UDP request...
>I've actually already hacked up liveMedia a bit to use RAW/RAW/UDP, and
>i edited the SETUP to use the aggregate uri instead of the
>non-aggregate, because there is only 1 TS Stream and otherwise the
>server reports 460 (i know, it's a mess :)
>
>
>Anyway, these are the results:
>(Notice the completely ridiculous SDP the server responds with... )

The SDP actually seems OK, except for the fact that it apparently lies 
about the nature of the stream that it's supposed to be 'describing'.

Now, just to make things clear (in my own mind): Do I understand this 
correctly? Despite advertising that the stream consists of (i) a MPEG video 
RTP stream and (ii) a MPEG audio stream, the stream actually consists of a 
single MPEG Transport Stream over UDP.  Is this correct??  If so, how 
incredibly brain damaged!

I'd prefer that any changes to the LIVE.COM libraries necessary to support 
this Kasenna crap be kept as small as possible.  One possible way to 
proceed would be for the RTSP client code to (when a Kasenna stream is 
detected) throw away the SDP description that comes from the Kasenna 
server, and instead generate a different SDP description that *really* 
describes the stream.  This new, proper SDP description would be passed to 
"MediaSession::initializeWithSDP()", which then wouldn't need to change at 
all, except to add support for creating a source for raw UDP streams - 
using the "BasicUDPSource" class.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>