I noticed an issue with mp4 files generated using ffmpeg when it comes to reporting a mediaTime of 0 for the first frame through requestVideoFrameCallback. However, this issue doesn't occur with webm files or when using another encoder like mainconcept or ffmpeg with AAC_mf encoder.
You can see a demo of the problem here: link to demo. When incrementing the frames with video 1, you won't see video progress until the third button press. On the other hand, with video 2-5, the mediaTime is 0, and a single button press increments the video by one frame.
The browser used is Chrome 113.0.5672.92 on Windows 10. The FFMPEG version is 6.0-essentials_build-www.gyan.dev or N-109421-g9adf02247c-20221216.
I've compared the PTS values of video 1 and 2, and they are both 0. The main difference I've observed is that the mp4 duration of the audio track is shorter for video 2.
My ultimate goal is to use requestVideoFrameCallback to determine the current frame. Currently, for video 1, the first frame is at 0.021333 and the second frame is at 0.041333.
I'm unsure if this issue is a bug in Chrome or if it's an expected behavior from the API.
I noticed an issue with mp4 files generated using ffmpeg when it comes to reporting a mediaTime of 0 for the first frame through requestVideoFrameCallback. However, this issue doesn't occur with webm files or when using another encoder like mainconcept or ffmpeg with AAC_mf encoder.
You can see a demo of the problem here: link to demo. When incrementing the frames with video 1, you won't see video progress until the third button press. On the other hand, with video 2-5, the mediaTime is 0, and a single button press increments the video by one frame.
The browser used is Chrome 113.0.5672.92 on Windows 10. The FFMPEG version is 6.0-essentials_build-www.gyan.dev or N-109421-g9adf02247c-20221216.
I've compared the PTS values of video 1 and 2, and they are both 0. The main difference I've observed is that the mp4 duration of the audio track is shorter for video 2.
My ultimate goal is to use requestVideoFrameCallback to determine the current frame. Currently, for video 1, the first frame is at 0.021333 and the second frame is at 0.041333.
I'm unsure if this issue is a bug in Chrome or if it's an expected behavior from the API.