使用IMFSinkWriter编码的视频播放速度随宽度变化问题排查

嗨，看你的问题描述，我刚好之前折腾过Win32 Sink Writer做无音频录屏的场景，这种播放速度随分辨率变的问题，大概率是帧时间戳的计算或传递出了问题，和缓冲区大小的直接关系其实不大，咱们一步步拆解排查：

核心排查方向：帧时间戳的正确性 #

• 先确认rtDuration的计算是否准确：你用MFFrameRateToAverageTimePerFrame(m_FPS, 1, &rtDuration)计算每帧时长，这个函数返回的是100纳秒为单位的MF时间基准值。30FPS的话，每帧时长应该是≈33333333（1/30秒 = 33333333.33... 100ns），你可以先打印这个值，确认不同分辨率下它都是固定的，没有被分辨率参数意外修改。
• 检查rtStart的更新逻辑：如果你的AppendFrame里只是简单执行rtStart += rtDuration，理论上是对的，但要确保这个更新完全和分辨率无关。比如有没有地方误把宽度值乘到了rtStart或者rtDuration里？这会直接导致宽屏时每帧的时间间隔被缩小，播放器自然会加速播放。

检查Sink Writer的帧传递细节 #

• 确认IMFSample的时间戳设置：在调用WriteFrame里的IMFSinkWriter::WriteSample之前，你给每个sample设置的SetSampleTime(rtStart)和SetSampleDuration(rtDuration)必须是正确的100ns单位值。另外，不要错误设置MFSampleExtension_Discontinuity标记（除非真的是断帧场景），否则播放器会重新计时，打乱播放节奏。
• 无音频场景下，Sink Writer完全依赖视频帧的时间戳来控制播放速度，没有音频时钟做参考。所以只要某几帧的时间间隔不对，播放器就会严格按照时间戳来播放，出现速度异常。

排查分辨率相关的错误关联 #

• 检查IMFMediaType的参数设置：视频媒体类型的MF_MT_FRAME_SIZE要正确设置为当前分辨率（比如3840x1080或640x1080），MF_MT_FRAME_RATE必须是30/1的分数值（用MFSetAttributeRatio设置）。如果媒体类型里的帧率被错误地和分辨率关联（比如误把宽度当成帧率的分子），编码器会输出错误的时序元数据，导致播放器解析错误。
• 检查位图数据处理逻辑：有没有在转换位图到MF媒体缓冲区的过程中，误把宽度值当成了时间相关的系数？比如计算缓冲区大小是对的，但某些地方把宽度乘到了时间戳里，这就会直接导致宽屏时速度变快。

缓冲区的间接影响（可能性较低） #

• 虽然你没有音频，但如果视频缓冲区的设置导致帧被丢弃或重复，也可能影响播放速度，但这种情况通常是卡顿而非匀速变快变慢。你可以检查IMFSinkWriter::BeginWriting的返回值，以及WriteSample的调用结果，确认没有出现错误码（比如MF_E_BUFFER_TOO_SMALL之类的）。

快速调试技巧 #

• 打印每一帧的rtStart和rtDuration：对比3840x1080和640x1080场景下的数值，看是否每帧的时间间隔都是固定的33333333，起始时间是否是均匀递增的。
• 直接读取IMFSample的时间戳：在调用WriteSample前，用GetSampleTime和GetSampleDuration取出数值打印，确认时间戳没有被意外修改。
• 强制固定分辨率测试：比如暂时把输出分辨率固定为1920x1080，看播放速度是否正常，再换其他分辨率对比，快速定位是否是分辨率影响了时间戳计算。

总的来说，最可能的根源是时间戳的计算被分辨率参数意外关联了，导致宽屏时每帧的时间间隔被错误缩小，播放器就会加快速度播放。重点排查时间戳更新逻辑和媒体类型的参数设置，应该就能解决问题。

内容的提问来源于stack exchange，提问作者Chaost