https://jsbin.com/girazef/edit?js,console,output

The same JS Bin file with updated buttons to show the 0.000001 second difference.  Button 2 is set to 4 seconds and button 3 is set to 4.000001 second.

Tested the issue on reported version 64.0.3282.140 using Windows 7 with attached html file and observed below data.

1. On 64.0.3282.140 -- On clicking Time -1 observed 0 , Time-2 observed 4.0 and Time-3 observed 9.0
2. On 66.0.3343.0 -- On clicking Time -1 observed 0 , Time-2 observed 3.14 and Time-3 observed 8.14
3. On Firefox -- On clicking Time -1 observed 0 , Time-2 observed 4.0 and Time-3 observed 9.0

Firefox behavior and M-64 behavior is same where as M-66 behavior is different. Attaching screencast for reference.

@Reporter: In comment#0 you mentioned 66.0.3343.0 as working behavior. Could you please help us in understanding expected and actual behavior? Also unable to check with https://jsbin.com/girazef/edit?js,console,output as on navigating to that link in canary shows your connection is not private error is seen. 

Deleted: 810094.mp4 1.5 MB

	810094.mp4 1.5 MB View Download

+chcunningham@ for triaging.

Actual behavior is the number 2 on the tested list (66.0.3343.0).  Expected behavior is 1 and 3 (64.0.3282.140 and Firefox). 

http://jsbin.com/girazef/edit?js,output

I hope this link works better for you.  Once again, the link of the updated file uses current time of 4 for button 2 and current time of 4.000001 for button 3 as starting points and you can see that seems to be how far off it is.

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on reported version 64.0.3282.140 using Windows 7 with attached html file and observed below data.

1. On 64.0.3282.140 -- On clicking Time -1 observed 0 , Time-2 observed 4.0 and Time-3 observed 9.0
2. On 645.0.33 -- On clicking Time -1 observed 0 , Time-2 observed 4.0 and Time-3 observed 8.14
3. On 66.0.3343.0 -- On clicking Time -1 observed 0 , Time-2 observed 3.14 and Time-3 observed 8.14

HTML file attached in comment#0 shows different behavior in different milestones and output in attached JSBin file is not available in M66 builds to blocking  issue 810668 .

As issue is reproducible on M66 as mentioned by reporter in commment#7, marking this issue as untriaged. Removing Needs-Bisect label as it would be difficult for TE to bisect this as it shows different behaviors in different milestones.

Could someone from Blink>Media team please have a look at this issue.

Thanks!

Deleted: 810094 in M65.mp4 359 KB

	810094 in M65.mp4 359 KB View Download

After doing more research on this issue, I found that it is also specific to the mp4 as the source of the HTML5 video element.  If you switch the source declaration to the webm before the mp4, the JS Bin functions as expected.

This is still an issue with mp4 format video files.

Are these clips encoded with h264 b-frames? Seeking has never been reliable in such clips.

I have attached the VLC Codec information for the mp4 file used and one that shows the settings for export.  I have used this code in the past and it hasn't presented issues previously.

Deleted: ForGoogle.PNG 8.8 KB

	ForGoogle.PNG 8.8 KB View Download

Deleted: mp4 settings.png 46.7 KB

	mp4 settings.png 46.7 KB View Download

dalecurtis@ could you take another look at this and #13 above?

give to dale. 

First few packets are out of order, so not much we can do here. It's ultimately an ffmpeg bug around seeking. =>sandersd who had some interest in fixing this.

[PACKET]
codec_type=video
stream_index=0
pts=0
pts_time=0.000000
dts=-2
dts_time=-0.133333
duration=1
duration_time=0.066667
convergence_duration=N/A
convergence_duration_time=N/A
size=3971
pos=12033
flags=K_
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=2
pts_time=0.133333
dts=-1
dts_time=-0.066667
duration=1
duration_time=0.066667
convergence_duration=N/A
convergence_duration_time=N/A
size=390
pos=16004
flags=__
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=1
pts_time=0.066667
dts=0
dts_time=0.000000
duration=1
duration_time=0.066667
convergence_duration=N/A
convergence_duration_time=N/A
size=151
pos=16417
flags=__
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=5
pts_time=0.333333
dts=1
dts_time=0.066667
duration=1
duration_time=0.066667
convergence_duration=N/A
convergence_duration_time=N/A
size=260
pos=16592
flags=__
[/PACKET]

Any updates on this one, this is very important for us

#17: Unfortunately, frame-exact seeking in the presence of B-frames is a low priority issue. I recommend re-encoding without B-frames until this issue is fixed.

For this specific example, I was able to obtain frame exact seeking to frame N by seeking to time N/15+0.001. I'm not actually entirely certain why that works, it implies something closer to a rounding issue than a PTS/DTS confusion issue.