C/C++可搜索电影格式库
我正在对一些非常大的视频文件（通常高达 16MP）进行一些处理，并且我需要一种方法来以允许查找特定帧（而不是像 ffmpeg 那样的时间）的格式存储这些视频。我打算滚动我自己的格式，将所有单独的 zlib 压缩帧连接在一起，然后在末尾附加一个索引，将帧号链接到文件字节索引。不过，在开始之前，我只是想检查一下以确保我没有重复其他格式/库的功能。有谁听说过允许无损压缩和随机访问视频的格式/库？
I'm doing some processing on some very large video files (often up to 16MP), and I need a way to store these videos in a format that allows seeking to specific frames (rather than to times, like ffmpeg). I was planning on just rolling my own format that concatenates all of the individually zlib compressed frames together, and then appends an index on the end that links frame numbers to file byte indices. Before I go about this though, I just wanted to check to make sure I'm not duplicating the functionality of another format/library. Has anyone heard of a format/library that allows lossless compression and random access of videos?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在大多数视频编解码器中很难找到特定帧的原因是大多数帧依赖于另一个帧或多个帧，因此必须将帧作为一个组进行解码。因此，大多数库只会让您寻找最接近的 I 帧（帧内 - 可独立解码的帧）。要实际从非 I 帧生成图像，需要来自其他帧的数据，因此您必须解码许多帧的数据。
我看到解决这个问题的唯一方法是在文件上创建某种索引。换句话说，遍历文件并创建对应于文件的特定时间或部分的帧的索引。由于大多数库的查找函数只能查找 I 帧，因此您可能必须查找最近的 I 帧，然后从那里解码到您想要的确切帧。
如果空间不是很重要，我建议像你说的那样做，但是使用 JPEG 压缩而不是 zlib，因为它会为你提供更高的压缩比，因为它利用了你正在处理图像数据的事实。
如果空间是一个问题，P 帧（取决于之前的帧）可以大大减小文件的大小。我不会搞乱 B 帧（取决于之前和未来的帧/帧），因为它们让事情变得正确变得更加困难。
我过去已经解决了在存在 B 和 P 帧的情况下寻找特定帧的问题，使用 ffmpeg (libavformat) 将视频解复用为数据包（每个数据包 1 帧的数据）并将它们连接到单个文件中。重要的是保留并索引该文件，以便您可以找到给定帧的数据包边界。如果该帧是 I 帧，您只需将该帧的数据输入 ffmpeg 解码器即可对其进行解码。如果该帧是 B 或 P 帧，则必须返回到最后一个 I 帧并从那里向前解码。要做到这一点可能非常棘手，特别是对于 B 帧，因为它们通常以与显示方式不同的顺序发送。
The reason it is hard to seek to a specific frame in most video codecs is that most frames depend on another frame or frames, so frames must be decoded as a group. For this reason, most libraries will only let you seek to the closest I-frame (Intra-frame - independently decodable frame). To actually produce an image from a non-I-frame, data from other frames is required, so you have to decode a number of frames worth of data.
The only ways I have seen this problem solved involve creating an index of some kind on the file. In other words, make a pass through the file and create an index of what frame corresponds to a certain time or section of the file. Since the seeking functions of most libraries are only able to seek to an I frame so you may have to seek to the closest I-frame and then decode from there to the exact frame you want.
If space is not of high importance, I would suggest doing it like you say, but use JPEG compression instead of zlib as it will give you a lot higher compression ratio since it exploits the fact you are dealing with image data.
If space is an issue, P frames (depend on previous frame/frames) can greatly reduce the size of the file. I would not mess with B frames (depend on previous and future frame/frames) since they make it much harder to get things right.
I have solved the problem of seeking to a specific frame in the presence of B and P frames in the past using ffmpeg (libavformat) to demux the video into packets (1 frame's worth of data per packet) and concatenate these into a single file. The important thing is to keep and index into that file so you can find packet bounds for a given frame. If the frame is an I-frame, you can just feed that frame's data into an ffmpeg decoder and it can be decoded. If the frame is a B or P frame, you have to go back to the last I-frame and decode forward from there. This can be quite tricky to get right, especially for B-frames since they are often sent in a different order than how they are displayed.
某些格式允许您更改每秒关键帧的数量。
例如，我使用 ffmpeg 以每秒 25 帧和每秒 25 个关键帧的速度编码为 flv，然后使用可以很好地移动到关键帧的播放器。基本上这允许我逐帧搜索。
另外，我上次检查 Quicktime 可以逐帧搜索，而不必让每个帧都是关键帧。
可能不适用于你，但这是我的想法。
Some formats allow you to change the number of key frames per second.
For example, I've used ffmpeg to encode to flv at 25 frames per second with 25 key frames per second, and then used a player that was fine in moving to key frames. Basically this allowed me to do frame by frame seeking.
Also the last time I checked quicktime can do frame by frame seek without having to have each frame being a key frame.
May not be applicable to you but that's my thoughts.