[mythtv-users] channel changing speed, is 3 seconds normal?

Joe MacDonald jamacdon at hwy97.com
Wed Oct 1 01:37:46 EDT 2003


I used to be an intense channel surfer and my wife hated it.

I have a PVR-250 with the grey remote. I press the green key and it lists
the contents of the current show in th OSD. I then use that to see whats on
other channels. I find that this is actually faster and better as I can keep
watching the current channel while seeing whats on the other channels.

As a bonus, I don't get hounded by my wife for switching channels on her.

Joe

----- Original Message ----- 
From: "Bruce Markey" <bjm at lvcm.com>
To: "Discussion about mythtv" <mythtv-users at mythtv.org>
Sent: Tuesday, September 30, 2003 9:44 PM
Subject: Re: [mythtv-users] channel changing speed, is 3 seconds normal?


> Mark Edwards wrote:
> > guessing that this relates to the ringbuffer in mythbackend. The channel
is
> > probably changed instantly, but the front-end doesn't see the new data
until
> > the ringbuffer gets around to supplying it...
>
> Up to this point, this is a much better guess than most ;-).
> The speculation about all the time being attributed to removing
> the ringbuffer (or to the filesystem filesystem type) has been
> repeated so much that it's taken on a life of it's own. As much
> as it's been reiterated, it simply is not the key issue.
>
> Where you're guess is on track is that the frontend can't start
> playing until it has new data flowing that it can play.
>
> Think of it like turning the spigot on a hose and waiting for
> water to come out the nozzle. What's hosed here (I couldn't
> resist ;-) 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 then
> 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 but doesn't allow the player to get
> any data until it meets a minimum amount of buffered data (the
> 'rebuffering" message means that it is below this minimum).
>
> 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 2sec
> or more of data in the pipeline. Even if the first frame was
> displayed more quickly, there would need to be some stuttering
> until it fell far enough behind for all the steps to have enough
> data to work with.
>
> If the ringbuffer was continuous rather than restarting after a
> channel change, channel changes still wouldn't be instantaneous.
> You would see the last 2 or 3 seconds of the old channel before
> the first frame of the new channel is displayed.
>
> Xawtv doesn't record so it can pretty much grab a raw frame and
> display it. It only needs to have a couple frames so channel
> changes can happen in a fraction of a second. However, it takes
> time for myth to grab, encode, write, read, pass to another
> process, decode then display.
>
> This is not to say that there aren't ways to trim a tenth of
> a second or two off the channel changes or that there might be
> problems that could cause channel changes to take more than
> 3 seconds. What I am saying is that unless there is some magic
> new redesign, channel changes will have to have a delay on the
> order of 2 seconds or more as a result of recording the data
> into a file so that timeshifting is possible.
>
> --  bjm
>
>
>
>
> !DSPAM:3f7a5cc1160197882487250!
>


----------------------------------------------------------------------------
----


> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
> !DSPAM:3f7a5cc1160197882487250!
>



More information about the mythtv-users mailing list