need a nice way to handle interruption in input stream

[Chris Worley]

Henri Fallon wrote:

> On Tue, Jul 10, 2001, Chris Worley wrote:
> 
>> What advantages would running the network server give me?
> 
> 
> I hadn't caught what you were doing precisely. Sorry about that.
> 
> But you said you were doing this over a network  didn't you ?
> 
> What is the format used in this network stream ? On the client side, do
> you run "nc | vlc -" or already used a network input ?

The software on the capture side has been changing radically.
I'm using a TiVo to capture the mpeg2 video.  It's a 50Mhz gutless 
powerpc.  There was a multiplexer for the TiVo, but it only worked 
(could keep up with realtime) in "basic" (poor) quality.

Back then, I did compile the old lightweight VLS server for the TiVo, 
but I believe that VLS and the current VLC had grown apart... there 
were lots of problems getting the video across.

Now, there's a "netmplex": "nc"'s are used to get the a/v streams off 
the TiVo, "netmplex" grabs those streams a multiplexes them on the 
local PC.  With this, realtime playback of high quality captured video 
is possible on a 350Mhz machine.

Netmplex puts it's output on stdout, which I pipe into vlc:

  netcat | ( while true ; do vlc --width=300 --height=200 -V sdl 
/dev/stdin && break; done )

The "while" loop keeps vlc reading from the input stream, even if it 
segv's (there's a momentary interruption).  Strangely, if I write the 
netcat output to a file, then playback that file with vlc, there's 
much less chance of segv'ing.

I believe, the high number of segv's during realtime playback (not 
from a file) is also a function of fluctuations in the incoming 
stream, and the need to float the timebase.

Even just moving the stream off the TiVo can cause "stuttering": 
anybody watching TV from the TiVo sees momentary pauses.  This 
requires the capture-to-net software running on the TiVo to run at a 
very low priority -- which causes bigger interruptions in the input 
stream, leading to the beginning of this thread.

Also, there are Windows users that need a viewer; vlc is probably the 
best choice, but we don't want to run VLS on Windows machines, and 
pipes don't work in Windows, so, the html option, when available, will 
probably be the best (only compatible) approach.

Chris