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

[Chris Delis]

On Fri, 14 Nov 2003, Michael Janer wrote:

> 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.


First of all, it has nothing to do with the recreating the ringbuffer! :-)
(Willy and Isaac's posts on myth-dev set me straight on that!)

After perusing some code a little (experts, please correct me if I'm
wrong... I'm just trying to learn/understand and _not_ complaining :-),
it seems that the thread communication in mythfrontend is a little laxed
in handling state changes (probably done on purpose because it simplifies
development, not as many semaphores/mutexes/etc to deal with, which
means less chance for deadlock).  For instance, in libmythtv/tv_rec.cpp,
I notice a few busy-waits here and there such as:

        timeout = QDateTime::currentDateTime().addSecs(10);

        while (internalState != kState_None &&
               QDateTime::currentDateTime().secsTo(timeout) > 0)
            usleep(100);

...and in the main run tv loop, there also appears to be a one second sleep
before checking state changes (I understand the need for the usleep as it allows
the other threads to "do work"):

void TVRec::RunTV(void)
{
    paused = false;

    runMainLoop = true;
    exitPlayer = false;
    finishRecording = false;

    while (runMainLoop)
    {
        if (changeState)
            HandleStateChange();

        usleep(1000);

During an event (such as a channel change), there is a good chance that
mythfrontend is waiting longer that it has to before handling it.  There are
more efficient ways of signaling the state change events, but at the cost
of more complex code.

Am I way off?  I'm just guessing that this might be _some_ of the reason
for _some_ of the delay that might be happening in the GUI.  I haven't even
attempted to look through the code that deals with the video/audio streams.
Bruce's argument sounds resonable to me.

And for the record... I don't mind the pause during channel changes.  I
am quite content using the EPG and browse!  



>  
> 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
> 
> 
> 
> 
> 
>