I am using a third party plug-in for HTTP Live Streaming playback, http://code.google.com/p/apple-http-osmf/
Porting the plug-in from OSMF 1.0 to OSMF 2.0 did not go as smoothly as I had hoped.
A change in behaviour between OSMF 1.0 and OSMF 2.0 is causing us trouble when seeking in Apple HLS streams.
Playing a stream where the first segment has a non-zero timestamp, if one seeks for example 10 minutes into the file, the seek will complete instantly and in some cases a single frame from the new time is rendered but the scrub bar and time indicator will reset to zero and count up at a normal rate as if it was playing, then after up to 20 seconds, playback will resume at the new location and scrub bar and time indicator will return to the right value.
Build OSMFPlayer using at.matthew.httpstreaming.HTTPStreamingM3U8NetLoader to provide the video element and modify org.osmf.net.httpstreaming.HTTPNetStream to ignore _initialTime in the seek function.
1) Using OSMF 1.0, the result is a player that plays and seeks normally.
2) Using OSMF 2.0, the result is a player that does not behave right when seeking in streams that have a non-zero _initialTime.
Example of a stream that exhibits this problem: http://fastly.zenzuz.com/streaming/GUSGUS/prog_index.m3u8
- OSMF 2.0
- apple-http-osmf svn r11
- OSMFPlayer from the OSMF framework samples
Immediately after seeking, the buffer level in HTTPNetStream will go far above the configured maximum buffer level, by the seek amount, so seeking 10 minutes into the file will result in a buffer level of a tad over 600 seconds. When playback resumes, the buffer level will return to normal. One of the changes in OSMF 2.0 from version 1.0 is a difference in how the NetStream class is used, OSMF 2.0 uses an extra instance of NetStream for buffering.
Live document on this issue in open Google Docs:
Where exactly are the NetStream time codes derived from?