Flash player 10.1 seeks an additional frame (not accurate)

Question

Wondering if this is a known issue? our engineer has done extensive testing to prove that the behavior is correct pre 10.1. With AS2 and AS3. With FMS 3.5.6 and 4.0. With smart seeking and not. With smart seeking even the player realizing that it seeked to the wrong time! Unfortunately we cannot tell our customers to not upgrade to 10.1. Many of them already have 10.3
sample files mentioned in this report can be found here
http://d1yb9lkqglrfzu.cloudfront.net/PlayerSeekTestAS3.zip
Adobe Flash Player 10.1 and later – netstream.seek in a fms rtmp stream seeks an additional frame
Product:
Adobe Flash Player
Version:
10.1 or later
Platform:
PC
Operating system:
Windows XP SP3, Windows 7 Ultimate
Summary:
Seeking into a rtmp stream served by Flash Media Server using netstream.seek(offset) will seek an additional frame when played in Adobe Flash Player version 10.1 or later.
Description:
There is a sample video player included (PlayerSeekTestAS3.swf) to help reproduce this issue. The player allows loading a stream, playing/pausing it and seeking to a specified time or frame. For testing purposes there is also included a burnt-in timecode mp4 file (timecodeSample.mp4), but the issue can be observed using one of the sample files included in the Flash Media Server 4.0 installation (like Adobe/Flash Media Server 4/applications/vod/media/ sample1_1500kbps.f4v).
Steps to reproduce:
Open the sample player (PlayerSeekTestAS3.swf) in Adobe Flash Player version earlier than 10.1 (tested using versions WIN 10,0,2,54, WIN 10,0,12,36, WIN 10,0,22,87, WIN 10,0,32,18, WIN 10,0,42,34 and WIN 10,0,45,2).
Write a valid rtmp stream url in the url text box of the sample player and click Load button (this creates a netConnection). If the connection is successful it creates a new netStream and plays it).
After the video has started to play, click the Pause Button (this calls netStream.togglePause function).
Seek to a specified time by writing it in the “Seek to time” textbox and clicking the associated GO button. (this calls netStream.pause() and then netStream.seek(time)). If testing with file timecodeSample.mp4, seek to time 10. If testing with sample1_1500kbps.f4v seek to time 5.
Repeat the same steps using a version of Adobe Flash Player later than 10.1.
Open the sample player (PlayerSeekTestAS3.swf) in Adobe Flash Player version later than 10.1 (tested using versions WIN 10,1,53,64, WIN 10,2,153,2, and WIN 10,3,181,14).
Write the same rtmp stream url in the url text box of the sample player and click Load button.
After the video has started to play click the Pause Button.
Seek to the same time as before by writing it in the “Seek to time” textbox and clicking the associated GO button. If testing with file timecodeSample.mp4, seek to time 10. If testing with sample1_1500kbps.f4v seek to time 5.
Expected result:
The same frame should be displayed in the video section of the sample player after the sequence of steps described above.
Actual result:
When using Adobe Flash Player later than version 10.1 the same sequence of steps will have sought an additional frame so the frames displayed in the video section of the sample player do not match.
When testing with file timecodeSample.mp4, seeking to time 10 displays:
timecode: 03:44:18:24 in Adobe Flash Player earlier than 10.1
timecode : 03:44:18:25 in Adobe Flash Player 10.1 or later
When testing with file sample1_1550kbps.f4v, seeking to time 5 displays different frames in the 2 described cases. However, seeking to time 4.96 (approximately one frame before) in Adobe Flash Player 10.1 or later will produce the same frame as previous Adobe Flash Player versions.
Additional info:
The issue is reproducible only for FMS streams and it has been reproduced using Flash Media Server 3.5.5, 3.5.6 and 4.0.
The sample player displays the current player version and type, it polls and displays the netStream.time property and in Adobe Flash Player versions later than 10.1 it allows checking a Smart Seek check box before loading the stream. When Smart Seek is on, the netStream.time value seems to be correct (when not using smart seek the netStream.time will always take the value of the offset sent in netStream.seek(offset)) and based on that we can use netStream.step to step to the correct frame.
For example, when testing with file timecodeSample.mp4 in Adobe Flash player 10.1 or later:
without Smart Seek selected, after seeking to time 10, the “Current time” label will display 10
with Smart Seek selected, after seeking to time 10, the “Current time” label will display 10.06 (more than 1 frame after time 10), clicking “Step 1 frame back” will seek to the correct frame and the “Current time” label will display 10.026.
The same can be observed when testing with file sample1_1500kbps.f4v in Adobe Flash Player 10.1 or later:
without Smart Seek selected, after seeking to time 5, the “Current time” label will display 5
with Smart Seek selected, after seeking to time 5, the “Current time” label will display 5.072 (more than 1 frame after time 5), clicking “Step 1 frame back” will seek to the correct frame and the “Current time” label will display 5.005.

Answer 1

I've recently come across a similar issue, but my seek to returns a different frame result.
For example with an encoded video that is 29.97fps, a seek to 10 seconds returns 9:28 in the video (via TC window burn), yet Flash returns a time of 10.00.
With an encode of 23.976, a seek to 10 seconds returns 9:23 (via TC window burn), yet again Flash returns a time of 10.00.
Every once and a while the result is frame accurate, but I can't yet find a way to reliably recreate it.
As with tuvman1, I have confirmed that the the above issues worked correctly when using a player that was pre 10.1