onVideoDecode and pause reliable to stop on a precise frame?

[tobiasBora]

Thanks for this project.

I need to seek/stop on a precise frame (exactly, without going too far, coming back etc…), and I was thinking to use this tool as the in-browser tools are not frame precise.

Do you think this project can be of any help to play a video and stop/seek a precise frame? In particular, can I reliably call pause in onVideoDecode to stop the video once the frame is displayed, or can it lead to race conditions where the pause is executed after the next frame is displayed?

[tobiasBora]

Also, is currentTime frame precise (as a setter or getter)? And is there a way to get the fps from the video, or do I need to hardcode it?

[phoboslab]

• currentTime is updated for every frame, yes
• The frame rate can be accessed at player.video.frameRate. This is the desired frame rate as stated in the MPEG file header, not the actual, current rate that the video is being rendered at at the moment. Of course the current frame rate should closely match the desired one, if we're not bottlenecked
• Calling .pause() will immediately pause the video, yes

And finally, there's NO seeking implemented in the current version of this library. Single stepping through frames is straight forward (pause the video and call player.video.decode() to step), but you can not seek to an arbitrary frame or time.

For what it's worth, the old version of JSMpeg, before the rewrite with WASM support, had seek functionality (but is missing other features). You can still get it here: https://github.com/phoboslab/jsmpeg/tree/186666dd9c2d1fd3430d41f15f695d4a78ed1e42

[tobiasBora]

Thanks for your answer! Too bad seeking is not possible… So I misunderstood, what is the setter of .currentTime – get or **set** the current playback position in seconds doing?

[phoboslab]

Ha, oh wow. Sorry. It's been too long since I worked on this. The docs are right, of course. There's some rudimentary support to jump to a specific time by setting player.currentTime.

However, it blindly starts decoding, even when it lands on a P-frame. So you will see some motion compensation decoded on top of the wrong I-frame. Allowing only to jump to the nearest I-frame and/or decoding all necessary P-frames on top is not implemented. (The old version had this, I believe).

You can fiddle around with this all by just opening your JS console on https://jsmpeg.com/perf.html and typing player.currentTime = 17. You'll see the artifacts you get from seeking to P-frames.

[tobiasBora]

I see, thanks a lot! So maybe this issue can be kept open until seeking is implemented?

[phoboslab]

Well, don't hold you breath. If I ever get back to this project, it will probably be yet another rewrite on top of pl_mpeg, which would fix a bunch of issues that JSMpeg still has. Plus of course a "unified" code base.