[Live-devel] Problems "seeking" in MPEG2 TS?

[Brett Granger]

Ross Finlayson wrote:
>> I'm using the live555MediaServer application to stream an mpeg2 ts to a
>> VLC client on linux.  I used the MPEG2TransportStreamIndexer app to
>> create a .tsx file to go along with the .ts file.
>>
>> Playing the stream at a normal scale of 1.0 works just fine, as does
>> playing it in fast forward or fast reverse, using other settings in the
>> scale header.
>>
>> The problem comes when I attempt to "seek" in the stream to a specific
>> time, or attempt to use the --start-time option to VLC to start at a
>> point other than the beginning.
> 
> Instead of usng VLC, could you try running "openRTSP"
> <http://www.live555.com/openRTSP/> with the "-s 15" option.  Let us
> know if that generates a correct output Transport Stream file (i.e.,
> properly starting at the 15s mark).

My apologies... my report of yesterday was filed against release 
2007.04.20 of liveMedia (I still had it on my drive as 
live555-latest.tar.gz...).  That release does have the timing problem I 
described.  However, when I download and use the 2008.01.18 release, the 
packet delivery timing issue is now gone.  "openRTSP -s 15" does indeed 
create a proper ts starting at the 15s mark, and the live555MediaServer 
does continue to deliver RTP packets at full rate after VLC requests the 
second play to npt=15.

However, I have now exposed a second issue, which I believe is a bug in 
VLC (unless it's an issue with the 2006.03.16 release of liveMedia 
against which VLC is built): even though the live555MediaServer 
continues to deliver RTP packets, VLC stops the presentation until clock 
time reaches the point where the next frame would have been displayed if 
no seek had been issued.  VLC appears to buffer up all the packets that 
arrive in the meantime, evidenced by the fact that when I press pause 
and a PAUSE request is sent up, the live server immediately stops 
sending packets, but VLC continues to play for an amount of time equal 
to the distance of the seek before it pauses the presentation.

> 
> 
>>   The VLC implementation of the
>> start-time option results in a PLAY request being sent with "Range:
>> npt=0.000-" followed almost immediately by a second PLAY request with
>> "Range: npt=<new-time>-".
> 
> This seems like a bug in VLC.  What version of VLC are you using?
> (Although we do not support VLC on this mailing list, I will forward
> this information to the VLC developers.)

vlc-0.8.6b (default that came from Ubuntu Feisty repos)...  Whether a 
bug or design choice I don't know, but it's obvious from the VLC code 
why it happens.  The "constructor" equivalent (Open) of their live555 
access_demux automatically and always makes a rtsp->playMediaSession(ms) 
call with the default startTime of 0, *then* the input thread checks for 
a start-time and makes a SET_TIME call, which results in a second 
rtsp->playMediaSession(ms, <start-time>) call after the stream has 
already started being served.  It likely wouldn't be a problem were it 
not for the bug described above of not presenting the new frames until 
the clock  time catches up to the seek time.

Thanks for the support,
--Brett


> --
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel