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

Pascal Favre Pascal.Favre at gmx.net
Fri Sep 9 16:10:12 UTC 2005

I never use LiveTV because changing channels are to slow.
I suggest to have an option for 'fast-changing-channels' where the input is immediately directed to the output for the specific 
amount of time (say 1 minute).
This allows fast changing channels.
After this time the normal LiveTV behaviour starts, but we still keep receiving the currently received input data.
The first time we halt or rewind to move over to the ringbuffer behaviour.

About the option when provided in seconds: 0 = normal LiveTV behaviour, >0 = seconds to start LiveTV behaviour.

Just an idea. When implemented I will use LiveTV.

----- Original Message ----- 
From: "Cory Papenfuss" <papenfuss at juneau.me.vt.edu>
To: "Development of mythtv" <mythtv-dev at mythtv.org>
Sent: Friday, September 09, 2005 5:21 PM
Subject: Re: [mythtv] Suggestion for improving SLOW channel changing inLiveTV.....

>> I have at various times done some experimenting with this to see what can be
>> done and by reducing the buffering a little and taking out some redundant
>> pausing I was able to get the channel change time down to around 200ms on my
>> DVB-T setup.
>> However, then some other changes went in and change times went sky high
>> again, and I ran out of time to fiddle with it much more.
>> I believe at least 50% of the channel change time can be removed from at
>> least the DVB channel change code.  It should be possible to get the channel
>> retuning done in around 50-100ms with a DVB-T card (or less) and then some
>> small buffering on top would be less than 0.5s changes.
>> I have posted various questions on this in the past, but no one with more
>> knowlege of the code flow has shown any interest in helping out.  I don't
>> have infinite time so I have stopped working on it for the time being.
>> My suggestion is to stop bitching about the time change and put in some
>> timing statements into the channel change code.  Find out which bits are slow
>> and then bang on about *that* bit here on this list.  At least that way it's
>> specific and constructive
>  I guess I'm curious why it's so high to begin with.  It seems to
> me that the card's changing shouldn't take more than a few 10's of
> milliseconds.  The rest is waiting on buffers to fill/flush?
>  I still think that the ideal situation would be to push
> uncompressed video to the screen, while simultaneously sending the
> compressed to the ringbuffer.  If you think about it, all of the PVR
> operations on LiveTV are in a different mode than "channel-surfing."
> Pausing, rewinding, etc require timshifting and decoding the
> recorded/encoded data.  *Diplaying* the other hand (no buffer) can be a
> realtime operation... data coming in gets immediately displayed as *well*
> as buffered to disk.  Transitioning between the two (i.e. realtime->replay
> for hitting "pause" or "rewind" while watching livetv, or replay->realtime
> for hitting channel up/down while watching a time-shifed livetv) need not
> be as responsive as nontransitioning (realtime->realtime channel up/down).
>  Again, I'm not bitching that it hasn't been done.  It seems like a
> lot of work and most people who might implement it (understandably) don't
> care.
>  Besides, for ivtv captures, it would require keeping the RAW YUV
> part in sync and continuously functioning along with the MPEG part.  For
> that matter, it may be academic if the card cannot operate with both at
> the same time.
>  I'll shut up now... :)
> -Cory
> -- 
> *************************************************************************
> * Cory Papenfuss                                                        *
> * Electrical Engineering candidate Ph.D. graduate student               *
> * Virginia Polytechnic Institute and State University                   *
> *************************************************************************


mythtv-dev mailing list
mythtv-dev at mythtv.org

More information about the mythtv-dev mailing list