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

Ed W lists at wildgooses.com
Sat Sep 10 08:33:00 UTC 2005


>>>Just an idea. When implemented I will use LiveTV.
>>>Pascal
>>>      
>>>
>> 	That sounds similar to what I was suggesting.  I don't see why
>>there needs to be an element of time involved though... just keep on
>>displaying realtime data until there's a reason not to.  Hit pause and
>>there's a bit of lag while the display transitions from raw capture to
>>decoded ringbuffer.  From then-on, it's ringbuffer until you change
>>channel.
>>    
>>
>
>Lot of extra work + code complexity for extremely minimal gain.
>  
>

I agree.

But hang on a second, this message is in reply to my message which has 
already said that I think you should stop winging about the slow speed 
of the buffering because it's fixable, and instead start trying to help 
profile it and speed it up.  The immediate answer is yet another 
suggestion on how to implement live tv?

Look, myth is as simple as this, there is a playback app which plays 
back from a file on disk.  There is a recording app which records 
sheduled programs.  So to change channels you just set an immediate 
schedule to record the next channel and cancel the last one (well 
something like that).

Contrary to your expectation the time needed to implement the above is 
millisecs.  The delay seems to be in shutting down the old playback 
(because it seems to pause and wait for a lot of threads in an 
unneccesary way), and then starting up the new playback and recorder 
seems to again be waiting far longer for events than neccessary.

I *have* had channel change times on a pre 0.18 myth on DVB of the order 
<200ms. It *is* possible.  However, I have barely enough time to write 
this note and ask you to do something constructive.

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.

For example here's a quick win: I think the audiooutputbase.cpp code 
actually waits for the audio output to pause the device before it says 
that it's paused.  I can't see any reason why this is necessary and it 
seems to just cause a short gap in the audio for me (unneccessary).  You 
can shave a few ms off by removing this.

...OK now it's your turn, go find all the other slowdowns.

This is a really constructive thing that people can help with now, so 
please don't sit on your "I don't know how to code" haunches and get on 
and start profiling the slowdowns.

Good luck

Ed W


More information about the mythtv-dev mailing list