我正在创建一个使用套接字将数据发送到其他设备的应用。我正在使用Http协议来发送和接收数据。现在的问题是，我必须传输视频，我不知道如何发送视频（或流视频）。
如果用户直接跳转到视频中间，那么我应该如何发送数据。
...谢谢
答案 0 :(得分：17)
HTTP并没有真正考虑到流媒体设计。老实说，最好的协议是基于UDP的（SCTP在某些方面甚至更好，但支持是粗略的）。但是，我感谢您可能受限于HTTP，因此我会按照书面回答您的问题。
我还应该指出，流媒体视频实际上是一个非常深刻的主题，我在这里所做的就是尝试触及您可能想要调查的一些方法。如果您可以控制端到端解决方案，那么您可以做出一些选择 - 如果您只控制一端，那么您的选择或多或少取决于另一端的可用内容。
如果您只想从文件的开头播放，那么它非常简单 - 制作一个标准的HTTP请求，只要您已经缓冲了足够的视频就可以开始播放，您可以在赶上之前完成下载文件下载率。您不需要任何特殊的服务器支持，任何视频格式都可以使用。
寻求更棘手。你可以采取像使用这样的网站采取的做法，即只是在文件下载得足以到达视频中的那一点之前，根本不允许用户进行搜索（或者只是让他们看一眼旋转器，直到达到该点）。然而，这并不是大多数人现在所期望的用户体验。
为了做得更好，您需要控制流媒体客户端。我建议一起处理文件，然后一次为一个块制作byte range requests。当用户搜索到文件的中间时，您可以计算出文件中的字节偏移量，并从该点开始发出字节范围请求。
如果视频格式在开始时包含某种索引，那么您可以使用它来计算文件偏移量 - 因此，您的视频客户端在进行任何搜索之前必须至少请求获取索引。
如果格式没有任何形式的索引但是它以恒定比特率（CBR）编码，那么您可以执行初始HEAD请求并查看Content-Length标题以查找文件的大小。然后，如果用户在视频中寻找40％的路径，例如，您只需要通过编码帧的40％。这依赖于对文件格式的充分了解，您可以计算出适当的搜索点，以便您可以识别帧信息等（或者至少是一种编码格式，即使您跳转也可以使用音频和视频流进行重新同步在文件中的任意点）。只要格式可以从任意搜索中恢复，这种方法也可以使用可变比特率（VBR）。
这并不理想，但正如我所说，HTTP并非真正用于流式传输。
如果您可以控制文件格式和服务器，则可以通过将每个块作为单独的资源来简化生活。这就是Apple HTTP live streaming和Microsoft smooth streaming都有效的方式。他们需要工具支持来预处理视频，我不知道你是否能控制服务器端。但是，可能值得研究。这些也做了更聪明的技巧，例如允许客户端在以不同比特率编码的流的多个版本之间切换，以应对带宽差异。