什么是“启用流媒体”？ A/V 容器格式？
支持流式传输的容器文件格式（如 Matroska 和 MPEG-4 Part 14）与那些不支持“流式传输”的容器文件格式（如 AVI）到底有何区别？
它们是否只是提供元数据和数据的排序，使解码软件能够在无需随机访问媒体文件或大型缓冲区的情况下工作，或者它们是否包含一些同步标头以使客户端能够容忍一定量的数据包丢失（保真度降低） ？
或者这是否是音频和视频编解码器而不是容器必须提供的功能？ （我想不是，因为 MPEG-4 (A)SP 似乎可以在 MPEG-4 Part 14 容器内进行流式传输（无论这意味着什么），但不能在 AVI 内进行流式传输。）
我想知道是否可以发送“流式传输就绪” “通过有损连接（没有任何额外同步或元数据层的 UDP）文件，并合理地期望客户端能够容忍适度的数据包损坏和/或丢失，而不会永久失去同步，或者是否需要某些中间层。
更新： 我发现 MPEG 传输流似乎提供了周期性同步和元数据帧等功能，使客户端能够从数据丢失或损坏中恢复，而 MP4 和 Matroska 似乎只在文件头中提供该信息。
是否真的存在两种流媒体格式，“可流媒体”格式仍然需要可靠的传输协议（例如 HTTP），如 MP4 和 Matroska，以及“适当”的流媒体格式，如 MPEG-TS，可以容忍中流数据丢失，并使客户端能够通过定期包含标头和元数据来随时调整？
RTP 如何适应这里？它似乎提供了许多功能（帧编号、格式描述标头、编解码器如何解释帧（B 或 I 帧）的提示），这些功能也存在于 MPEG-TS 中，但在 MP4 和 Matroska 中不存在。
What exactly distinguishes streaming-enabled container file formats like Matroska and MPEG-4 Part 14 from the ones that are supposedly not "streaming-ready", like AVI?
Do they just provide an ordering of metadata and data that enables decoding software to work without random access to the media file or large buffers, or do they include some synchronization headers to enable a client to tolerate some amount of packet loss (with reduced fidelity)?
Or is that even a feature that has to be provided by the audio and video codecs instead of the container? (I guess not, because MPEG-4 (A)SP seems to be streamable (whatever that means) inside MPEG-4 Part 14 containers, but not inside AVI.)
I'm wondering if it's possible to send a "streaming-ready" file over a lossy connection (UDP without any additional synchronization or metadata layers), and reasonably expect a client to tolerate moderate packet corruption and/or loss without permanently losing synchronization, or if some intermediate layer would be necessary.
Update:
I've found that MPEG transport streams seem to provide features like periodic synchronization and metadata frames to enable a client to recover from data loss or corruption, while MP4 and Matroska only seem to provide that information in the header of the file.
Are there really two kinds of streaming formats, "streamable" ones that still require a reliable transport protocol (e.g. HTTP) underneath like MP4 and Matroska, and "proper" streaming formats like MPEG-TS that can tolerate data loss in mid-stream, and enable clients to tune in at any point in time by periodically including headers and metadata?
How does RTP fit in here? It seems to provide a lot of features (frame numbering, format description headers, hints for the codec on how to interpret a frame (B- or I-frame)) that are also present in MPEG-TS, but absent in MP4 and Matroska.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
像 AVI 这样的文件格式将不同媒体块偏移和长度的完整编译放在专用索引中。该索引位于文件末尾。因此，如果您想播放 AVI，播放器需要首先到达文件末尾以获取该索引，然后才能进行任何播放。这就是 AVI 可流式传输的原因。
在流式传输文件格式中，元数据（媒体类型、时间位置、编码和长度）主要以段标头的形式交错。
Streambale 内容的第二个重要方面是具有时间戳。每个媒体片段必须具有准确的时间戳，以确保如果您播放一个会话（例如 5 小时），则不会由于音频和视频播放速率之间的相对滑动而导致 LipSync 逐渐丢失。 AVI 通常假设显示和音频播放有标准速率 (25 fps)，并让设备随时间推移对其进行管理。这使它变得可怕！
File format like AVI puts a complete compilation of different media chunk offset and lengths in a dedicated Index. this index is placed at the end of the file. Hence, if you want to play AVI, the player needs to first reach the end of the file to get this index before any play can happen. This is what makes AVI streamable.
In a streamable file formats the meta data (type of media, position in time, encoding and length) is interleaved mostly in the form of headers of the segments.
Second important aspect of streambale content is to have timestamps. Each media segment must have an accurate time stamp to ensure that if you play a session for say 5 hours - it should not result in gradual loss of LipSync due to relative slip between Audio and video playout rates. AVI typically assumes that there is a standard rate (25 fps) of display and audio playout and leaves upto device to manage that over time. This makes it horrible!