<!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">
This might certainly be a possibility. It will probably take a lot of
work as well.<br>
<br>
Another thing I had been thinking of is to allow the GUI/OSD to
continue working so you could keep switching channels even though the
system is in the progress of getting all the data through the pipeline.
This is a far cry from a perfect solution but when "channel surfing" it
could give you the _feeling_ of having ~1 second channel change times.
And if you're like me and immediately skip 80% of the channels after
having seen them for a fraction of a second this migth actually work.
It does mean of course that when you encounter something worth watching
that you're probably several channels ahead alreay so you'll have to go
back. Like I said a far cry from being perfect but it might actually be
possible to implement without too much hassle. (PS: I did test this
once using an external channel change script, so in theory it could
work :-)<br>
<br>
Cheers,<br>
-Tako<br>
<br>
Jelle wrote:<br>
<blockquote type="cite"
cite="mid1068866244.23317.35.camel@silicon.elements">
<pre wrap="">On Fri, 2003-11-14 at 18:59, Tako Schotanus wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I'm afraid I don't entirely agree with your analysis of the situation.
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.
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.
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.
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?
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.
</pre>
</blockquote>
<pre wrap=""><!---->
What about this: Make a 'low delay uncompressed audio/video' mode, lets
call it the 'fastpath'. The fastpath is more restrictive than the normal
path but has a very low latency (mainly for channel surfing...). Accept
restrictions, such as requires a faster CPU/memory bandwidth, and only
when frontend and backend are on the same machine, and only if backend
and frontend drivers support the fastpath feature, and maybe no OSD,
etc. For low CPU power systems, maybe even disable all
compression/recording/pausing on this backend if the fastpath is in use.
Example: If the backend and frontend are on the same system and if they
both support this feature, then allow the backend and frontend to
allocate a chunk of shared memory for a doublebuffered uncompressed
frame. In the backend, the thread/process that has the uncompressed
frames first can then memcpy() the uncompressed frame to the shared
memory, before any compression is started on it. And the frontend can
then resize&copy it onto the screen (of course, with the right
semaphores for the shared memory, and something similar for the audio).
That should result in a latency that comes pretty close to using xawtv
directly.
That would allow people who really want low latency and fast channel
surfing to do that, given that they buy enough CPU and put a frame
grabber in the machine with the frontend where they want low latency.
Some people may then just buy an extra cheap low quality Bt878 in their
frontends just to get fastpath for fast channel surfing. For those
people, it may even be possible to then have a second backend flip
channels in parallel, so that all current live TV features are still
available, with a one-time 4 second time shift that is... Then if you
channel surf, and you stay on the same channel for more than 4 seconds,
you can choose to switch to the 'normal' backend if you accept repeating
the last 4 seconds one time... normal backend if you accept repeating
the last 4 seconds one time...
Jelle.
</pre>
<blockquote type="cite">
<pre wrap="">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".
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).
-Tako
Bruce Markey wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Boyd II, Willy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">...
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?
</pre>
</blockquote>
<pre wrap="">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
____________________________________________________________________
_______________________________________________
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>
<pre wrap="">
______________________________________________________________________
_______________________________________________
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>
<pre wrap=""><!---->
</pre>
<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>