[Live-devel] MPEG2TransportStreamFramer duration estimate/trickplay

[Ross Finlayson]

>I'm having another go at implementing trickplay using VLC and a Kasenna
>Omnibase VOD server.

Please don't use the "K" word here :-)  I think the issues you describe 
apply to playing *any* incoming MPEG-2 Transport stream that uses raw 
UDP.  (Note, BTW, that for playing streams that use RTP/RTCP, you shouldn't 
need to use a "MPEG2TransportStreamFramer", because the incoming data 
should already have correct presentation timestamps (thanks to RTCP).)

>On the first attempt, I did have to introduce an
>MPEG2TransportStreamFramer,
>so that StreamRead in livedotcom.cpp would be passed a correct duration
>parameter. Correct handling of duration and PCR are required to make
>this work.
>
>This time around, I'm seeing incorrect duration values after a PLAY is sent
>with an updated Scale value. I think that this is because the PCR resets
>after the second PLAY

Yes, that's what it looks like.

>If you could look at the attached log and perhaps advise on any possible
>change to MPEG2TransportStreamFramer::updateTSPacketDurationEstimate() or
>elsewhere, which could help to deal with this situation, I would really
>appreciate it.

Here's what I'd try:
1/ Add the following code to 
"MPEG2TransportStreamFramer::doStopGettingFrames()":
         PIDStatus* pidStatus;
         while ((pidStatus = (PIDStatus*)fPIDStatusTable->RemoveNext()) != 
NULL) {
                 delete pidStatus;
         }
(This will reset the existing PCR/duration estimate.)
2/ In VLC's "livedotcom.cpp", just before you do something that might cause 
the PCR values to change, call
         tk->readSource->stopGettingFrames();
(This will cause "MPEG2TransportStreamFramer::doStopGettingFrames()" to get 
called.)

Let us know if that works.  If so, I'll add 1/ to the released code.



	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>