<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I'm afraid I don't entirely agree with your analysis of the situation.<br>
<br>
You mention a lot of steps as if the very fact that there are a lot of
them immediately and irrevocably means that there is nothing that can
be done about it. It maybe explains why there is a 3-4 second wait
_now_ but it doesn't conclusively prove that it can't be improved upon.<br>
<br>
The card needs time to start grabbing its data, but when using a PVR
there's no time lost in mythtv to do any encoding. Running mplayer
directly on /dev/videoX and manually changing the channel shows that it
is technically possible to do the recording/encoding phase in under a
second.<br>
<br>
Then we need to start pumping the data over the network, true, but on a
connection that has already been set up this delay can be neglected, so
we'd only need some buffers to allow for the occasional peak in network
traffic.<br>
<br>
50 to 70 frames in the pipeline, any reason why there have to be so
many? Does everybody need the same amount of buffers? How about the
VIA en PVR hardware decoders, couldn't they do with a lot less
buffering? Couldn't network and decode buffers be combined somehow so
we don't start connecting "hoses" with different capacities?<br>
<br>
The buffering is needed of course, but its not like a Discman's
shock-proof/anti-skip buffer because there's no way to record live tv
more quickly than it comes in, so when the buffer runs out it runs out
and you'll have to wait until the buffer fills again. But maybe a
setting would be usefull so people can tweak the buffer size to their
own situation. Maybe some people will even allow the occasional
pre-buffer pause just to take off half a second from the channel
switching time.<br>
<br>
And very nice that you try to educate people about how to use a DVR but
besides the fact that it sounds very patronizing you also forget that
there are lots of people using MythTV in countries that have no or only
very limited XMLTV support. For those people it is impossible to just
let the system record the entire selection of interesting movies of the
coming 2 weeks or "any action movie that has Arnold in it".<br>
<br>
And finally Isaac has told people on the list more than once that it
could very well be possible to improve the channel change time and that
he'll be happy to receive any patches that improve it. As long as he
(and other) are satisfied with the way it works now he (they) probably
won't do anything about it. So any work will have to come from somebody
annoyed enough with the delay that he'll sit down and do something
about it. (don't expect it to be easy though because like Bruce
explained, the current situation _is_ like a long hose with several
connected parts with limited capacity).<br>
<br>
-Tako<br>
<br>
Bruce Markey wrote:<br>
<blockquote type="cite" cite="mid3FB55A71.808@lvcm.com">Boyd II, Willy
wrote:
<br>
<blockquote type="cite">...
<br>
One thing I'm still trying to figure out is how this 3,4-second buffer
is
<br>
determined. Is it variable, and depending mainly on speed of hardware?
<br>
</blockquote>
<br>
There isn't one thing that is a 3,4-second buffer. there are a
<br>
series of steps from when the first frame is available to the
<br>
encoder on the backend until the frames can be played by the
<br>
player on the frontend.
<br>
<br>
Think of it like turning the spigot on a hose and waiting for
<br>
water to come out the nozzle. What's hosed here (yes, old timers,
<br>
I *will* use this pun every time this comes up ;-) is that the
<br>
encoder starts and the player sends off its first RequestBlock.
<br>
First, the backend starts grabbing frames from the card. Once
<br>
it has a few it can start to compress them and write them to the
<br>
file. Next, another thread waits until it can read enough data
<br>
from the file to send it over a socket to the frontend. The read
<br>
ahead thread on the frontend starts to read data from the socket.
<br>
<br>
Once the read ahead thread is satisfied, the data can be decoded
<br>
and stuffed into a buffer of decoded frames that the player can
<br>
play. The player can't start until it has a minimum number of
<br>
frames. If the player runs out of frames to play, it has to stop
<br>
and wait for more frames to be decoded. When this happens you see
<br>
the 'prebuffering pause' message.
<br>
<br>
So, for the player to run smoothly, there needs to be about 50 to
<br>
70 frames worth of data in the pipeline. Depending on the bitrate,
<br>
resolution, compression type and other factors, this will take
<br>
from 1.7 sec up to maybe 3 sec. There are also other things that
<br>
need to happen from the time you press a key untime the channel
<br>
change starts that can add a little to the delay. This has all
<br>
been sanded and polished but it's just plain going to take more
<br>
than 2 sec.
<br>
<br>
Now, it's nice to hear people say that TiVo channel changes seem
<br>
to be instant but this just isn't true. TiVo is a monolithic
<br>
device where they can handle things a little more directly but
<br>
there is still about 1 second of delay. MythTV hasn't been a
<br>
monolithic single process since 0.7. It now splits the frontend
<br>
and backend to allow multiple systems to work together so there
<br>
needs to be interprocess communications. It also supports remote
<br>
frontends so the design has to account for network buffering to
<br>
allow these will play video smoothly. These things make the "hose"
<br>
a little longer but the functionality is worth it. Especially
<br>
considering that you shouldn't ever have to "channel surf" once
<br>
you understand what you can do with a DVR system.
<br>
<br>
-- bjm
<br>
<br>
<br>
<br>
<pre wrap="">
<hr width="90%" size="4">
_______________________________________________
mythtv-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a>
<a class="moz-txt-link-freetext" href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a>
</pre>
</blockquote>
</body>
</html>