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

[Tim Harvey]

I think the desire here is to quickly skip by certain channels that you
know you don't want to watch, and/or quickly see a frame of video.  I
know when I channel-surf, I skip channels very often based on the first
frame or two that I see.

I wonder if there is someway we could tweak the buffer needs to allow a
quick frame or a few frames initially, 'then' pause to buffer up more of
a healthy ringbuffer once the user has sat on a particular channel for a
specific period of time (a second or two... configurable).

With this scenario, if the user hits the channel up/down repeatedly
never sitting on a channel for more than a second or so, they never see
this secondary pause and they 'perceive' it to be changing channels
fast. 

I know there was a lot of tweaking done on the ringbuffer capacities a
week or so ago to try to make channel changing faster, but the fact
remains that it still takes 2 to 3 seconds to change a channel (on my
system with current CVS using PVR 250/350) which really sucks if your
just trying to get from ch3 to ch10 and are 'trained' to do it via ch
up/down instead of hitting numbers (its more than being lazy... I don't
watch tv enough to know that its ch10 I want but I can instantly
recognize frames to see if it's a show I might be interested in... often
recognizing the station logo is enough as well).

Does this suggestion make sense?  Does it seem doable or worthwhile?
Perhaps its something I can play with when I get some time and more
familiarity with the code.

Tim

> -----Original Message-----
> From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-
> bounces at mythtv.org] On Behalf Of Bruce Markey
> Sent: Tuesday, September 30, 2003 9:44 PM
> To: Discussion about mythtv
> 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
>