search

sachinkosare / apple-http-osmf

Automatically exported from code.google.com/p/apple-http-osmf
0 stars 0 forks source link

Seek issues after migrating from OSMF 1.0 to 2.0 #19

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Originally posted here:
http://forums.adobe.com/thread/1029903

What steps will reproduce the problem?

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.

What is the expected output? What do you see instead?

A change in behaviour between OSMF 1.0 and OSMF 2.0 is causing us trouble when 
seeking in 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.

What version of the product are you using? On what operating system?

- OSMF 2.0
- apple-http-osmf svn r11
- OSMFPlayer from the OSMF framework samples

Please provide any additional information below.

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:
https://docs.google.com/document/d/1TO9oyg8cK5ezSLNkeyCTKdtFA__fDY8g7t 
e2PWt-UTw/edit

Original issue reported on code.google.com by gud...@medizza.com on 27 Jun 2012 at 9:33

GoogleCodeExporter commented 9 years ago 
As mentioned on http://forums.adobe.com/thread/1054096, this seems to be 
related to reading the DTS off the stream headers as negative, then shoving it 
onto the FLVTag.timestamp which is uint, causing the initalTime appended to all 
seeks to be huge if the initial DTS is slightly negative.  Not sure if FLVTag 
spec allows negative, but changing the type to int is a good workaround.

Original comment by greg.kin...@gmail.com on 20 Feb 2013 at 9:41