No subject

software encoding takes about 1.3sec to 1.7sec. I know this
because for the hundreds of people who have talked out of
their own @ss, AFAIK I'm the only person who instrumented
the code, and tweaked the readahead and prebuffer of decoded
frames for optimal performance at different bitrates for
hardware and software encoding for local and remote playback
over different types of networks and network's throughput.

I currently have ...68 recordings that I look forward to
watching. I added "Watch List" to help me sort through the
pile. I won't be spending my time flipping through channels
any time soon.  I only use "A/V Test Mode" to check signal
quality, picture settings and audio levels for upcoming
recordings of things I actually want to watch.

I can sit here right now and connect to a remote backend
and see that from the time I hear the up arrow click to the
time audio starts on the next channel is consistently under
three seconds. That's because I sat down and looked at what
was happening in code other people wrote just as Stuart is
doing now.
</soapbox>

But back on topic, 1.3sec to 1.7sec suggests that it takes
40 to 50 NTSC frames worth of data to fill the pipeline.
That's volume of data not number of frames and there are
lots of variables. After changing channels the playback is
about as close as to real time as possible. When there are
static or dark frames like going into a commercial, the encoder
can compress more efficiently and therefore puts out less data.
Now it may take 60 to 70 frames worth to fill the pipe. The
player uses up the remaining decoded frames then has to stop
until more frames are available. When the player unpauses it
is further behind and less likely to have to pause again.

The point is, when you are in live, it's always going to pause
when the picture goes dark unless you've paused or rewound.

> One thing I have noticed while testing is that if the video is

Different issue =)...

--  bjm