如何确定 html 视频元素的预期帧速率 [英] How to determine the intended frame-rate on an html video element

问题描述

有没有办法确定在 html 视频元素中播放的内容的预期帧率?

Is there a way to determine the intended frame rate of content playing in the html video element?

视频元素甚至知道预期的 FPS 或帧数，还是只是猜测"(可能是 24fps)并以猜测的速度播放?

Does the video element even know the intended FPS or frame count, or does it simply "guess" (maybe 24fps) and play at the guessed speed?

以下是我失败的尝试:

• 在视频元素本身上查找 FPS 或 FrameCount 属性--不！

• Look for a FPS or FrameCount property on the video element itself--Nope!

查找有关 FPS 或 FrameCount 的跨视频格式标头信息--不一致！

Look for cross-video-format header info about FPS or FrameCount--Nothing consistent!

寻找在帧改变时触发的事件——不！

Look for an event that is triggered upon frame changing--Nope!

我的下一次尝试更加复杂:通过将帧捕获到画布元素来对视频进行采样，并通过确定像素何时发生变化来计算帧数.

My next attempt is more complicated: Sample the video by capturing frames to a canvas element and count frames by determining when the pixels change.

在我进行复杂的尝试之前，有人有更简单的答案吗?

Does anyone have a simpler answer before I do the complicated attempt?

推荐答案

了解视频的帧率并不像您想象的那么有用.
浏览器使用一些技巧来匹配电影的帧率和屏幕的刷新率，所以如果你查看 currentTime 属性，你会看到 实际帧持续时间(== currentTime - previous currentTime)不是一个常数，它因帧而异.

Knowing the frame-rate of the video wouldn't be as useful as you might think.
Browsers uses of some tricks to make a match between the frame-rate of the movie and the refresh-rate of the screen, so if you look at currentTime property, you'll see that the actual frame duration ( == currentTime - previous currentTime) is not a constant, it varies from frame to frame.

在此示例视频中:http://jsfiddle.net/3qs46n4z/3/ 模式是:
4-1-5-1 :
4 帧 21.3 + 1 帧 32 + 5 帧 21.3 + 1 帧 32.

On this sample video : http://jsfiddle.net/3qs46n4z/3/ the pattern is :
4-1-5-1 :
4 frames at 21.3 + 1 frame at 32 + 5 frames at 21.3 + 1 frame at 32.

因此，如果您想在避免过度绘制的同时始终在画布上显示最新帧，解决方案可能是:
- 在每个 rAF 上，查看视频的当前时间:
• 相同的 ?-> 什么都不做.
• 改变了吗?-> 更新框架.

So if you want to always display the latest frame on a canvas while avoiding overdraw, the solution might be to :
- On each rAF, look at the current time of the video :
• Same ? -> do nothing.
• Changed ? -> update frame.

无论你想做什么，比较两个 currentTime === 两个数字可能比比较两个 imageDatas 更快；-)

And whatever you want to do, comparing two currentTime === two numbers might be faster than comparing two imageDatas ;-)

查看规范以找到我所说的证据，我发现此注释有细微差别:

Edit : looking into the specifications to find evidence of my saying, i found a nuance with this Note :

 Which frame in a video stream corresponds to a particular playback position is defined by the video stream's format.

(http://www.w3.org/TR/2011/WD-html5-20110113/video.html )

所以严格地说我们只能说(当前时间相同)暗示(帧相同).
我只能打赌倒数是正确的 => 不同的时间意味着不同的框架.
在上面的示例中，Chrome 试图通过尝试获得 45 Hz (= 60/2 + 60/4) 来匹配我 60Hz 计算机上电影的 24Hz，最接近 48 = 2*24.对于创建的 21 个帧，我不知道它是插入帧还是仅复制帧.它肯定会根据浏览器/设备(尤其是 Gpu)而变化.我敢打赌，任何最近的台式机或功能强大的智能手机都可以进行插值.

So strictly saying we can only say that (the current time is the same) implies (the frames are identical).
I can only bet that the reciprocal is true => different time means different frame.
In the example above, Chrome is trying to match the 24Hz of the movie on my 60Hz computer by trying to get 45 Hz ( = 60 / 2 + 60 / 4), the nearest from 48 = 2*24. For the 21 created frames i don't know if it interpolates or merely duplicates the frames. It surely changes depending on browser/device (Gpu especially). I bet any recent desktop or powerful smartphone does interpolate.

无论如何，考虑到使用 imageData 进行检查的成本很高，您最好绘制两次而不是检查.

Anyway given the high cost of checking with the imageData, you'd much better draw twice than check.

Rq1:我想知道在多大程度上使用 Xor 模式 + 一次对 0 32 位进行测试可以提高比较时间.(getImageData 很慢.)

Rq1 : I wonder to which extent using Xor mode + testing against 0 32 bits at a time could boost the compare time. (getImageData is slow.)

Rq2:我确信有一种使用播放速率来同步"视频和显示，并知道哪一帧是真正的(== 未插值)帧的黑客方法.(所以这里有两个通过 1)同步 2)倒带和检索帧).

Rq2 : I'm sure there's a hacky way to use the playback rate to 'sync' the video and the display, and to know which frame is a genuine ( == not interpolated ) frame. ( so two pass here 1) sync 2) rewind and retrieve frames).

Rq3:如果您的目的是获取每个视频帧并且仅视频的帧，那么浏览器不是最佳选择.如上所述，(桌面)浏览器确实会进行插值以尽可能匹配显示帧速率.这些帧不在在原始流中.甚至还有一些高端的3D"(2D+时间)插值设备，其中甚至不打算显示初始帧(！).另一方面，如果您对(内插的)输出流没有问题，则对 rAF 的轮询将提供您看到的每一帧(您不能错过任何帧(除非您的应用程序正在忙于执行)别的东西).

Rq3 : If your purpose is to get each and every video frame and only the video's frame, a browser is not the way to go. As explained above, the (desktop) browsers do interpolate to match as closely as possible the display frame rate. Those frames were not in the original stream. There are even some high-end '3D' (2D+time) interpolation devices where the initial frames are not even meant to be displayed (! ). On the other hand, if you are okay with the (interpolated) output stream, polling on rAF will provide every frames that you see (you can't miss a frame (except obviously your app is busy doing something else) .

Rq4:插值(== 无重复帧)在最近/不错的 GPU 驱动桌面上的可能性为 99.99%.

Rq4 : interpolation ( == no duplicate frames ) is 99.99% likely on recent/decent GPU powered desktop.

Rq5:确保预热您的函数(在启动时调用它们 100 次)并且不创建垃圾以避免 jit/gc 暂停.

Rq5 : Be sure to warm your functions (call them 100 times on start) and to create no garbage to avoid jit / gc pauses.

这篇关于如何确定 html 视频元素的预期帧速率的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！