[mythtv] Channel change time improvements

[James Courtier-Dutton]

On 22 June 2010 17:45, Robert Johnston <anaerin at gmail.com> wrote:
> On 22/06/2010 3:03 AM, James Courtier-Dutton wrote:
>>
>> Hi,
>>
>> I have done some more work looking at the channel change time.
>> The main cause of the long channel change time is that myth deletes
>> all the C++ objects of the old channel, waits for them to all
>> disappear, and the creates new C++ objects for the new channel.
>> The delete takes at least 2 seconds to do.
>> I would suggest that it would be better if instead of deleting objects
>> when changing channel, is to leave all the objects there, and just
>> change to writing to a different filename. Much like log rotating.
>>
>> I did a lot of development on xine media player, which has a stream
>> model from input to output.
>> if the input stream changes, e.g. A DVD menu selection happens, the
>> input is told to change to different content, the input inserts a
>> control packet into the stream between the old content and the new.
>> This allows downstream processes, e.g. codecs, to flush themselves
>> correctly before starting to process the new content.
>> This permits xine to react to DVD menu selections very quickly.
>>
>> I cannot find anywhere in myth where this "control packet" concept
>> appears.
>> Can someone point me to it if it exists, and if not, I will try to
>> implement support for it.
>
> What happens if the "Channel Change" happens across inputs? Or across
> backends?
>
> If you are changing channel across inputs, you will need to tear down and
> rebuild the channel. So in theory this could be backgrounded (Don't wait for
> the objects to be destroyed before building the new ones), but if there is
> only one input, doing this will cause an error (As you're trying to open an
> object before it's been closed fully).
>

The object would still not be destroyed. They would just move from a
"Playing" state to a "Stopped" state.
When you "STOP" the stream, it places a "stream stopped" control
packet in the stream.
When you "PLAY" the stream from the other input, it places a "stream
started" control packet in the stream.
When you retune on a single input, one does not need to STOP, PAUSE,
or anything else, the control packet handles the change smoothly.
The myth-backend would decide if one just needed a re-tune or one
needed a "STOP" on one input, and a "PLAY" on the other input.
So, instead of deleting objects, the object just changes states from
"PLAY" to "STOP" etc.
The "PLAY" and "STOP" commands can be asynchronous, and the
transitions are quick as one is not waiting for objects to be created
and destroyed.

Kind Regards

James