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

[Brett Granger]

Hi all,

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.  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>-".

In the test I am performing, I set --start-time=15 on the VLC command 
line.  What happens is that although I see in the VLC output that the 
reply to the PLAY request is nearly instantaneous, nothing happens for 
about 15 seconds, and then the data starts to stream and play, although 
VLC throws away the first number of frames because they arrived "too 
late" (VLC prints "late picture skipped").

Putting VLC into debug mode shows that VLC does not print the "first 
packet for pid" message until the full 15 seconds has elapsed, and then 
the first picture is discarded for being slightly over 15 seconds late. 
  Wireshark shows that after the reply to the PLAY request, very few RTP 
packets are sent and they are sent in a strange timing pattern:  I get 2 
RTP packets 3.4 seconds apart, then 2 RTP packets 2.1 seconds apart, 
then 2 packets 1.3 seconds apart, etc... the time between packets 
continues to decay until finally at around the full 15 seconds after the 
PLAY request the stream seems to kick back in in full force.  If I seek 
further into the stream, then the delay goes up correspondingly (e.g. a 
seek of 30 seconds doesn't start playing the new location in the stream 
until 30 seconds later)

I would have expected the server to simply re-seek in the source stream 
and then continue uninterrupted without the long delay...  Is seeking of 
mpeg2 ts streams expected to work with live555MediaServer, or have I run 
into a known problem?  I didn't see anything about this on the live.com 
web site.

Thanks for any thoughts,
--Brett