need a nice way to handle interruption in input stream
cworley at symbionsys.com
Tue Jul 10 17:33:02 CEST 2001
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?
More information about the vlc-devel