[streaming] Re: VOD implementation suggestions

[Dermot McGahon]

On Mon, 6 Sep 2004 17:28:05 -0700 (PDT), James Pennywise  
<pennywis at tremendous.yoonix.com> wrote:

>> On Mon, 6 Sep 2004, Dermot McGahon wrote:
>> I'm still going to do the bits I said I would do, I just don't
>> know exactly when. Maybe this week, maybe next!
>
> Hmm... In skimming over the previous thread, I don't see where you said
> what you were going to do. Care to give me a pointer?

For the moment, all that I am interested in, is using vlc as an
rtsp/udp vod client for kasenna vod servers. Actually, this is
working since last Thursday, with a few bugs which will need
attention. I am also using vlc as an iptv multicast client, but
it could already do that. Next, I will look at SAP/SDP, fix the
unicast rtsp/kasenna bugs .. and see where to go after that.

I would be very interested in a standard compliant rtsp server
in vlc and will help where I can. This would allow me to replace
the Kasenna vod server with something home grown.



>> I'm still a little confused about how to detect for sure which vod
>> server you are connecting to. Maybe issuing a DESCRIBE RTSP command
>> before SETUP is the way to go? An alternative is to request sgimb
>> instead of sdp in the SETUP, but this is completely Kasenna specific,
>> and a waste of time for any other vod server.
>
>> From reading the RFC over the last few days, I believe that the client
> should issue the OPTIONS method, as illustrated in RFC 2326, Section 10
> (DESCRIBE is for describing the media); however, I believe that OPTIONS
> only describes the available methods, not the available header entities
> (eg - CSeq, Session, Transport, etc). It sounds like the best way to
> figure out if header entities are supported is by sending them and seeing
> if the server responds with an Unsupported header entity (RFC 2326,
> Section 13.41).
>
> Unfortunately both the OPTIONS method and the Unsupported header entity
> are not required for RFC compliant implementations (RFC 2326, Appendix
> D.1) and it seems like nobody has even attempted to write an RFC  
> compliant
> RTSP server so far...

Oh the server implements the OPTIONS method; but it's still no
good. What I'm trying to isolate, is the brand of server i.e the
rtsp dialect! OPTIONS will not tell us that in every case. Don't
worry, I'll figure this out.

Also, I would expect that the LIVE.COM RTSP server is, to a
greater extent than any of the others, standards compliant.


Sending request: OPTIONS rtsp://omnibase/sync_test RTSP/1.0
CSeq: 1
User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.06.11)


Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 1
Message: OPTIONS Successful
Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, SET_PARAMETER,  
GET_PARAMETER, SET_PLAYMODE, TEARDOWN
Date: Tue, 07 Sep 2004 18:08:56 GMT


> Perhaps the other trick is to use the Server header entity (RFC 2326,
> Section 13.36) which is recommended to be implemented in even minimal
> implementations.
>


I know the one you're talking about. It's not is 13.36 though. It's in
12.36 and references a H section which I've been unable to find. There
is more information in D.2 which says that it's highly recommended, but
that's of zero use to me, because recommended or not, it's not
implemented in the OPTIONS response from the Kasenna vod servers, but
is implemented in the DESCRIBE response. So, I know how to get this
information for Kasenna, but will need help from people with other
vod servers with regards to how to distinctly identify them.



Dermot.
--

-- 
This is the streaming mailing-list, see http://www.videolan.org/streaming/
To unsubscribe, please read http://www.videolan.org/support/lists.html