问题描述
我有一个简单的NDK Android代码来解码和播放简单的视频文件.我注意到Android具有native_window_set_buffers_timestamp(ANativeWindow，int64_t);方法.
I've got a simple NDK Android code to decode and play simple video file. I have noticed that Android has native_window_set_buffers_timestamp(ANativeWindow, int64_t);method.
我读到它为添加到队列的帧提供了时间戳.是否有可能使用这些标记导致出队并按我的计划时间渲染帧?我有与以下描述类似的代码:在此示例中我以示例方式设置演示时间戳(我确定我有正确的值，我将它们设置为纳秒)，但是视频的渲染和解码速度一样快(太快了).设置时间戳没有任何效果.有没有人解决这个问题?
I read that it gives timestamps to frames added to the queue. Is there a possibility to use these stamps to cause dequeue and render frames in planned by me time moments?I've got code similar to described: in this exampleI'm setting Presentation Time Stamps as in example (I'm sure I've got right values, I set them in nanoseconds), but video is rendered as fast as it is decoded (way too fast). Setting timestamps doesn't have any effect. Has anyone any solution for that problem?
推荐答案
该字段是通过系统传递时间戳的一种方式.它可能会或可能不会影响帧的处理方式.
The field exists as a way to pass timestamps through the system. It may or may not affect how the frame is handled.
IIRC，该字段的最初用途是用于摄像机捕获的视频帧.通过包括捕获帧时的时间戳，生成编码视频的应用程序可以输出准确的时间戳.如果应用程序使用了应用程序接收帧的时间，则时间值会发生很大的变化.
IIRC, the initial use of the field was for frames of video captured by the camera. By including the timestamp from when the frame was captured, an app that generates encoded video can output accurate timestamps. If the app used the time that the frame was received by the app, you'd get significant variation in the time values.
较旧版本的Android在显示框架时会忽略时间戳记.在Android 4.4("KitKat")中，SurfaceFlinger合成器添加了一项功能，该功能允许其根据时间戳保留或丢弃帧.这样做的目的是使A/V同步更容易. 格拉菲卡(Grafika)的预定交换"活动(特别是 doFrame() 方法.
Older versions of Android ignore the timestamp when displaying frames. In Android 4.4 ("KitKat"), the SurfaceFlinger compositor added a feature that allowed it hold or drop frames based on the timestamp. The purpose of this was to make A/V sync easier. This is discussed at length in the comments in Grafika's "scheduled swap" activity, notably those above the doFrame() method.
简而言之，此功能的目标是允许视频播放器稍早提早提交每个帧，以便在音频播放到达适当时间时，它可以准备就绪并在合成队列中等待.当系统繁忙时，尝试在应用程序本身中进行细粒度同步是有问题的. (SurfaceFlinger的运行优先级较高.)
In short, the goal of the feature was to allow a video player to submit each frame slightly early, so that it's ready and waiting in the composition queue when the audio playback reaches the appropriate time. Attempting to do fine-grained sync in the app itself is problematic when the system gets busy. (SurfaceFlinger runs at elevated priority.)
当应用向整个视频文件发送垃圾邮件不是目标时，可以提供适当节奏的播放.为了与向嵌入式PTS提供帧的应用程序向后兼容，并避免在应用程序提交未来数年的时间戳时出现非常长的停顿，SurfaceFlinger会忽略当前时间不到一秒左右的时间戳.因此，您仍然必须用勺子喂帧，但是时间戳可以帮助避免停顿和掉落.
Providing properly-paced playback when an app spams an entire video file was not a goal. For backward compatibility with apps that feed the embedded PTS with the frames, and to avoid very long stalls if an app submits a timestamp that is years in the future, SurfaceFlinger ignores timestamps that are not within a second or so of the current time. So you still have to spoon-feed the frames, but the timestamps can help avoid stalls and drops.
因此...如果要管理自己的视频播放，则必须自己调整输出速度.您可以在Grafika的 SpeedControlCallback 课堂.
So... if you want to manage your own video playback, you will have to pace the output yourself. You can see an example in Grafika's SpeedControlCallback class.
这篇关于Android本机窗口时间戳的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！