need a nice way to handle interruption in input stream

[Chris Worley]

Samuel Hocevar wrote:

> On Tue, Jul 10, 2001, Chris Worley wrote:
> 
>>>    VLS is only on the server side ; 
>> 
>> That's why it's not a good solution -- we'd have to run it on the 
>> client side.
> 
> 
>    Why can't you use VLS on the server side instead of using mplexer ?

Because the server is a 50Mhz powerpc... it doesn't have the guts to 
mplex the stream, so the a/v streams are sent in two different sockets 
to the client for realtime mplexing.

As I said earlier, I tried the old lightweight VLS, but it has 
diverged from compatibility with the current VLC.


> 
>> In this case, the html would be generated locally (out the mplexer, 
>> into vlc).  Really, just a short HTML preamble (declaring the 
>> following data as mpeg) to the Program Stream.
> 
> 
>    This would be useless and would only add complexity to the /dev/stdin
> method. Under Win32 you'd need a netcat equivalent anyway, so you best
> bet would be to code a network input into vlc which would accept a
> stream sent by mplexer.

Complexity?  The html header does not add much complexity.  The only 
difference from the Linux invocation previously shown is:

(echo "HTTP/1.0 200 OK";echo "Accept-Ranges: bytes"; echo 
"Content-Length: 999999999"; echo "Connection: close"; echo 
"Content-Type: video/x-mpeg2" ; echo ""; netmplex) | nc -l -p 80

Netcat is available for Windows.

But, since Widows can't stream pipes, we've recoded netmplex to listen 
on port 80, and send it's output that route.

Again: if I'm going to run VLS on the client where I'm running VLC, 
what advantages does that provide?  I don't do Windows myself, but 
there are folks that are and it would be nice to be compatible (i.e. 
run the same software on the TiVo side).

Anyway, I think this might be getting off the main subject, unless VLS 
starving doesn't cause VLC problems?

Chris