Hi,
My investigations into this are leading to the fact that there is a bug in the MPEG TS handling in libavformat or libavcodecs. At least when XvMC VLD is involved but possibly in all cases although other decoding methods my cope with the bug better.
What "appears" to happen is that when the PMT changes is that the AVCODEC for the old stream starts calling XVMC_VLD_field_end() multiple times intertwined with the new stream starting to send valid MPEG streams and hence calling XVMC_VLD_field_start(), XVMC_VLD_decode_slice() ... XVMC_VLD_field_end(). This messes up the hardware decoding when XVMC_VLD_field_end() appears out of order.
I also notice that when a stream is removed in av_remove_stream():2099 it manages its list of streams by moving up a complex data structure with a memmove() routine. This is a potentialy very dangerous thing to do with complex data structures containing pointers etc etc ...
Can anyone give me a run down on what actually is suposed to happen when a channel is changed in MythTv when using DVB and TS streams ?
I would have expected someting like:
DVB -> MPEGTS -> VideoCodec -> Sync -> Video Out -> AudioCodec -> Sync -> Audio Out
I would have though that all that would need changing would be the DVB system selecting different PID's and possibly re-tuning, then MPEGTS selecting the different streams. The Video out should not need any changes (aprat from size changes which would be being handled already). Is this the case ?? Ant pointers to the higher levels of code where the channel change is implemented ??
Terry
_______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev