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@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
