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