I've gone around in circles trying to figure out why a standard ripped DVD output is choppy when I start it from a VOD stream. I'm attempting to automate my DVD library. I have roughly 500 DVDs that I've purchased over the past 5 years or so. I have ample server diskspace and power to provide an on-demand video system for my house (dual Xeon, 4 terabyte HD, 4 GB RAM) and to provide multiple A/V streams to the computers running at each of the 2 TVs I want to do demand video on. I don't want to do multicast because it's not really a station-oriented broadcast I'm attempting to do. I want streams to be independent of each other, allowing the operator of the PC at the television (with plugins I'm going to write for MythTV) to select what DVD they'd like to stream to the PC and display on the TV.
I want to provide this service in a nearly identical fashion as it's done through the on-demand service available on my digital cable. I rip my DVDs with DVD Decrypter first and place them in my library. When I first started playing around with VLC, I tested streaming the ripped DVD directories using HTTP (worked great across the LAN), MMS (never could get media player to recognize the stream so I gave up), UDP (worked great across the LAN).
I then embarked on the next step, which is to put them into VODs within VLM. The first entry (I'll use the case for the Matrix, since it was the first DVD I ever purchased) looked like this:
new thematrix vod enabled
setup thematrix input dvdsimple://c:\media\dvds\the_matrix
The entry took just fine, but when I connected via RTSP to get the RTP stream, the video was choppy. As in it almost looked like it was all I-frames. So I fired up Ethereal to look at the streams themselves. They weren't all I-frames. There were I, P, and B frames, so it wasn't a case of misuing the Live555 RTP encoder. I also looked at the payloads, which were interesting. Ethereal couldn't decode the payloads of type 96. I'm still not precisely sure what these are, even after reading the source code.
I next attempted something like this:
new thematrix vod enabled
setup thematrix output #std{access=http,mux=ts,url=:9001/thematrix,sap,name="The Matrix"}
setup thematrix input dvdsimple://c:\media\dvds\the_matrix
Which streams just fine, but it starts immediately the first time a client connects, and does not stop when the client disconnects. I could probably work with this via the remote control interface, but I'd like something cleaner. I like the concept of using SAP to announce streams and RTSP to start and shutdown the streaming. I still haven't figured out how to allow the person at the end of the stream to actually use the DVD menus yet (it only appears to work on the VLC client that's providing the stream - if I attach to a stream that provides multiple VOB files with the standard dvd type, it does not allow someone to use the DVD menus.)
Anyway, the RTP output is horrendous. The HTTP and straight non-RTP UDP streams are perfect. I've tested this on 2 windows machines and 2 Linux machines. If I stream with HTTP or raw UDP, the streams are great. If I stream with RTP, the video stream is choppy. The audio stream is fine.
Am I missing something on how to provide the service I'm trying to get to in a reasonable manner? I've just spent 3 days looking at a variety of forum entries, looking at the mail list archives, and whatnot to solve as much of the problems as I could. Incidentally, I get very few messages in the log, even with debug set to 2. I get the extra messages available during setup and instanciation of the streams, but when it's streaming, the client and the server appear to think everything is fine (ie, there are no messages.)
Could anyone give me further insight into this? Is there a way to tell RTSP to setup a non-RTP stream back to the requester? While that's not the ideal solution, it would work for now. I think using the RTP stream is the correct solution, but at this point I'm just looking for anything that will not be choppy and still provide on-demand services that stop when the requesting client disconnects.