[mythtv] Suggestion for improving SLOW channel changing inLiveTV.....

Isaac Richards ijr at case.edu
Sat Sep 10 17:27:48 UTC 2005

On Saturday 10 September 2005 09:34 am, Nobody wrote:
> On Sat, Sep 10, 2005 at 04:44:47AM -0400, Isaac Richards wrote:
> > On Saturday 10 September 2005 04:33 am, Ed W wrote:
> > > The contructive thing to do is to put in a few timing statements into I
> > > think it's NuppleVideoPlayer.cpp and start tracking down the exact
> > > delays (Isaac, please remind me where the main code is).  It's actually
> > > fairly tricky because there are multiple threads and they synchronise
> > > on signals, hence you can't just look at the code flow to see all the
> > > delays.
> >
> > Main control logic's in tv_rec.cpp and tv_play.cpp.  The various threads
> > they're stopping/starting live elsewhere, but should be easy enough to
> > find with grep.
> >
> > And yes, this is how you speed up channel changing, not by coming up with
> > crazily overcomplicated schemes.
> Sounds so easy when someone else has thought it up eh Isaac?

When someone else thought it up?  I've done exactly what Ed's proposed before, 
with channel changing.  It's why it doesn't take 8 or 10 seconds. =)  
Optimizing things by, uh, figuring out what's slow isn't exactly a brand new 

Lat year, I even proposed an entirely different method of doing LiveTV, which 
would (as a side effect) have intrinsically faster channel changing, but I've 
had better things to work on.  I simply don't use LiveTV mode enough to spend 
terribly much time on it.  No one else has bothered to either, so...

> Rather then slamming everyone for even bothering to come up with ideas, or
> decreeing something as not worth it because YOU don't see the value, I
> would think it'd be more constructive to follow the path of the kernel :
> put up or shut up.

I think I've done enough 'putting up' that I can say what code + designs that 
I would accept in my project.

> The code and the result will speak for itself.
> To have a petty argument about what a PVR is and question why someone would
> want to watch live TV _without_ a buffer, was amusing to say the least. 
> (it's called buffer-while-paused-only) and it works very well:
> 1) - go live, 0 buffer
> 2) - hit pause for a commercial / whatever
>    -- myth starts buffering
> 3) - hit play, ff, skip .. whatever.

Which, as you describe, breaks rewinding unless you've already paused 
something.  That's a big missing feature.

Both this and the 'do both until the user tries to rewind/pause' ideas, oddly 
enough, doesn't work in Myth unless you want to require that every frontend 
machine has a bttv/regular v4l card in it.  Can't get raw video and audio 
without one (ivtv will allow raw video capture, but afaik, no audio.  DVB + 
HDTV users are just completely out of luck).  You _need_ raw video and audio 
if you want to get rid of a large chunk of channel change time.  It also 
doesn't work for anyone who's split a backend out to a different machine.  
Sending completely uncompressed audio + video around a network doesn't scale 
at all.


More information about the mythtv-dev mailing list