[mythtv-users] I'm in....

[Michael Janer]

Why is it that SageTV can do this channel change with a PVR 250 or 350 at about the same speed as a Tivo?  I would imagine the engine in mythtv can be sped up in some way.  Sagetv has a client server setup also and seems to be able to make the channel changes pretty decent ~1 second.  I imagine if SageTV can do it with java and windows, Mythtv should definately be able to do it.
 
Honer

________________________________

From: mythtv-users-bounces at mythtv.org on behalf of Bruce Markey
Sent: Fri 11/14/2003 5:42 PM
To: Discussion about mythtv
Subject: Re: [mythtv-users] I'm in....



Boyd II, Willy wrote:
> ...
> One thing I'm still trying to figure out is how this 3,4-second buffer is
> determined.  Is it variable, and depending mainly on speed of hardware?

There isn't one thing that is a 3,4-second buffer. there are a
series of steps from when the first frame is available to the
encoder on the backend until the frames can be played by the
player on the frontend.

Think of it like turning the spigot on a hose and waiting for
water to come out the nozzle. What's hosed here (yes, old timers,
I *will* use this pun every time this comes up ;-) is that the
encoder starts and the player sends off its first RequestBlock.
First, the backend starts grabbing frames from the card. Once
it has a few it can start to compress them and write them to the
file. Next, another thread waits until it can read enough data
from the file to send it over a socket to the frontend. The read
ahead thread on the frontend starts to read data from the socket.

Once the read ahead thread is satisfied, the data can be decoded
and stuffed into a buffer of decoded frames that the player can
play. The player can't start until it has a minimum number of
frames. If the player runs out of frames to play, it has to stop
and wait for more frames to be decoded. When this happens you see
the 'prebuffering pause' message.

So, for the player to run smoothly, there needs to be about 50 to
70 frames worth of data in the pipeline. Depending on the bitrate,
resolution, compression type and other factors, this will take
from 1.7 sec up to maybe 3 sec. There are also other things that
need to happen from the time you press a key untime the channel
change starts that can add a little to the delay. This has all
been sanded and polished but it's just plain going to take more
than 2 sec.

Now, it's nice to hear people say that TiVo channel changes seem
to be instant but this just isn't true. TiVo is a monolithic
device where they can handle things a little more directly but
there is still about 1 second of delay. MythTV hasn't been a
monolithic single process since 0.7. It now splits the frontend
and backend to allow multiple systems to work together so there
needs to be interprocess communications. It also supports remote
frontends so the design has to account for network buffering to
allow these will play video smoothly. These things make the "hose"
a little longer but the functionality is worth it. Especially
considering that you shouldn't ever have to "channel surf" once
you understand what you can do with a DVR system.

--  bjm





-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5486 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-users/attachments/20031114/45e63f77/attachment.bin