ffmpeg - mpeg4 (H.264) 时间戳和图像质量
我在 ffmpeg 库方面遇到了重大问题。
首先，时间戳以某种随机顺序到达。
例如，解压缩时，时间戳 8000 在 4000 之前，依此类推。如果我忽略这些时间戳并仅播放视频，我可以看到帧实际上是按随机顺序到达的。那么，第一个问题是如何处理？这正常吗？我真的不明白这怎么可能。
问题二..
图片质量太差了。看起来需要抗锯齿。 VLC 播放相同的剪辑，具有正确的帧顺序和更好的图像质量。
我的应用程序中的颜色格式是标准 YV12（解压缩后我没有转换它），它由 Video Mixing Renderer 9 过滤器渲染。 （我没有使用 ffmpeg 作为 DirectShow 过滤器）。
（ffmpeg 这么糟糕吗，还是我必须开发一些额外的技能才能用它来获取框架？）
I have major problems with ffmpeg library.
First, timestamps are arriving in some sort of random order.
For example, when decompressing, timestamp 8000 is before 4000 and so on. If I ignore these time stamps and just play the video, I can see that frames are really arriving in random order. So, the first question would be how to handle that? Is that normal? I don't really understand how is that possible at all.
Question nubmer two..
Picture quality is so bad. It looks like it requires anti-aliasing.
VLC plays the same clip with proper frame order and much better picture quality.
Color format in my application is standard YV12 (I didn't convert it after decompressing) and it's being rendered by Video Mixing Renderer 9 filter. (I'm not using ffmpeg as a DirectShow filter).
(Is ffmpeg so bad, or do I have to develop some extra skills just to get the frame with it?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为时间戳的问题在于，当视频包含 B 帧（双向预测）时，这些帧在比特流中的显示顺序不正确。因此，在确定解码帧的 PTS 时必须特别小心。看看这个很好的 ffmpeg 教程页面，看看他们是如何处理这个问题的。
基本上，您需要存储每个解码帧的第一个数据包的 PTS 值。解码后AVFrame结构中的PTS值无效。
至于质量问题，这可能与时间戳问题有关，也可能无关，但我可以向您保证，问题几乎肯定不在于 ffmpeg 库本身，因为它们被广泛使用，甚至可能被 VLC 用作后端解码视频时。
我会查看 教程 并实现与它完全相同的东西，看看是否可以让它工作，然后修改教程代码以满足您的需求。
I believe the problem with the timestamps is that when the video contains B-frames (bidirectionally predicted), the frames occur in the bitstream out of their display order. Because of this, you have to take special care when determining the PTS of a decoded frame. Take a look at this page of a good ffmpeg tutorial and see how they handle this problem.
Basically, you need to store the PTS value of the first packet for each decoded frame. The PTS value in the AVFrame structure after decoding is not valid.
As for the quality issues, this may or may not be related to the timestamp issues, but I can assure you that the problem is almost definitely not with the ffmpeg libraries themselves as they are widely used and may even be used as a backend by VLC when decoding your video.
I would look at the tutorial and implement things exactly like it just to see if you can get it to work, then modify the tutorial code to fit your needs.