[mythtv] tracking the cause of channel change slowness

Pekka Jääskeläinen pekka.jaaskelainen at gmail.com
Mon Feb 20 17:10:07 UTC 2006

> The reinit happens whenever the resolution or aspect ratio changes. So
> if the dummy stream (in your case themes/default/dummy720x480p50.ts)
> has a different resolution than the previous channel and the target
> channel then you will need to rescale the OSD twice. Now if the previous
> and source channel have different properties you will have to rescale
> at least once, but you can avoid at least one rescale by making caching
> the last seen resolution on any channel in the channel table and using
> that to select the dummy stream to play.. (You can pass it the aspect
> ratio as well and use that to select a stream, we just don't do it
> currently).

OK. Thanks for the explanation. One question arises: could one disable
the OSD temporarily for the channel change? Then one could enable the OSD
again after unpause, and scale the images while the new channel stream is
playing? This would improve the sensed channel change time.

Another unrelated question: is it possible to play the previous
channel's buffer
while changing to the new one? This would make the channel delay less
as the user may watch the previous channel while changing to the next. It
seems I have always at least 5 secs of the previous channel in the buffer.

> A more complicated thing you could do with OSD::Reinit() is lazy
> reinitialization. Some of these OSD's are unlikely to be on the screen

This sounds like the most sensible and far-reaching option. I actually
thought of
this already, but wasn't really sure if it makes sense at all, or
would it be worth
the trouble, given the new UI code being implemented and all (does it
affect OSD

> during a channel change, so if you just cached the new wmult, and hmult
> and reinitialize in the paint rutine, you could avoid some expensive
> reinits, such as the ones that rescale images (OSDTypePosSlider), or
> recreate a lot of object/images (OSDGenericTree). I don't know if
> this one is a good idea, because it could make the OSD UI much less
> responsive when it is needed.

I think it's a good idea. The responsivity should not be an issue, as
we always rescale only the *requested* OSD image -- it should not take
too much time.
Now *all* images are scaled and it takes 0.5-1 secs on my P4 2.6GHz system.
It's not too much even if it was experienced as a whole, as it's
experienced only
once / OSD image type.

So if you think this kind of patch could be accepted, I could
implement it the next time I have free time. If you have pointers for
how you would do it, I'm listening,
as it improves the possibilities to get the patch merged without rewriting it


More information about the mythtv-dev mailing list