need a nice way to handle interruption in input stream

[Chris Worley]

Samuel Hocevar wrote:

> On Tue, Jul 10, 2001, Chris Worley wrote:
> 
> 
>>>    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.
> 
> 
>    This is really strange. VLS doesn't need that much CPU power, did you
> try to profile it to see what was eating CPU ?

I didn't say VLS was eating CPU... the realtime mplexer had to move to 
the client PC because it was eating too much CPU (could only keep up 
at the poorest quality).  The new VLS server is too big; I'm dealing 
with a 2.1.24 kernel on the PowerPC, and old libc5 stuff, etc...

Actually, I don't think I ever compiled the old lightweight VLS for 
the TiVo; I remember evaluating that it should compile.  It was my 
goal, but first I compiled it on my PC, and found that it and current 
vlc had diverged too far apart and were no longer compatible... so I 
never did compile it for the TiVo.

Now that the mplexer has moved to the client, it's a moot point; the 
mpeg2 stream originates from the client now.

> 
> 
>> Complexity?  The html header does not add much complexity.  The only 
>> difference from the Linux invocation previously shown is:
> 
> 
>    The html header does not add much complexity, but is useless. Thus
> adding it deserves no purpose and adds complexity.

There's an "html" option in VLC networking that's grayed out.  I 
figure it's a placeholder for something that will someday work like 
WMP's html interface in Windows.  That's the only reason I bring it up 
as a possible solution.  I know it currently doesn't work, but figure 
somebody stuck that there for a reason.  Given that no other solutions 
fit, I figure that one may be the solution someday.

> 
> 
>> Again: if I'm going to run VLS on the client where I'm running VLC, 
>> what advantages does that provide?
> 
> 
>    This would be useless as well; VLC can pretty much read anything VLC
> does.

It's not the "reading", as the original post (a week ago) states, it's 
the pipe starving.

Are you saying that interruptions in the stream (too slow... stopping 
for 10 seconds, etc...) don't cause problems in VLC (as outlined in 
the original post)?

Thanks,

Chris