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

[Tako Schotanus]

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.

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:

> 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
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>mythtv-users mailing list
>mythtv-users at mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20031115/3f27e2e2/attachment.html