Http 直播是如何工作的？
我创建了一个示例应用程序来演示 HTTP 直播流的工作原理。
我所做的是，我有一个库，它将输入作为视频文件（avi、mpeg、mov、.ts）并为给定的视频文件生成片段（.ts）和播放列表（.m3u8）文件。当我从库中获取播放列表数据时，我将播放列表（作为字符串）存储在链接列表中。
我编写了一个基本的 Web 服务器，它将为用户请求的片段和播放列表文件提供服务。我正在从 iPhone safari 浏览器请求 playlist.m3u8 文件，并且它正在启动 QuickTime 播放器，并在其中请求收到的播放列表文件中列出的segment.ts 文件。播放每个片段（在当前播放列表中列出）后，它再次请求播放列表，我用下一个播放列表文件进行响应，其中包含其中列出的下一组segment.ts文件。
这就是我们所说的 HTTP 直播吗？
除了这个之外，我还需要做些什么来实现 HTTP 直播流吗？
谢谢。
I have created one sample application for demonstrating a working of HTTP live streaming.
What I have done is, I have one library that takes input as video file (avi, mpeg, mov, .ts) and generating segments (.ts) and playlist (.m3u8) files for the given video file. I am storing playlist (as string) in a linked list, as an when i am getting playlist data from the library.
I have written one basic web server which will server the user requested segment and playlist files. I am requesting playlist.m3u8 file from the iPhone safari browser and it is launching the QuickTime player where it is requesting the segment.ts files listed in the received playlist files. after playing every segments (listed in current playlist) it again requests for the playlist, where i am responding with the next playlist file which contains the next set of segment.ts files listed in it.
Is this what we call HTTP live streaming?
Is there anything else, other that this i need to do for implementing HTTP live streaming?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不多了。如果您正在获取媒体输入流，对它们进行编码，以适合传送的格式进行封装，并通过将其放置在可以从 HTTP 服务器请求的方式来准备要分发的封装媒体，那么您就完成了。实时流媒体背后的想法是，它利用现有的互联网架构，该架构已经针对合理大小的资源的 HTTP 请求进行了优化。
HTTP 流使许多现有的 CDN 解决方案因其自定义流协议、自定义路由和自定义内容缓存而过时。
Not much more. If you are taking input streams of media, encoding them, encapsulating in a format suitable for delivery and preparing the encapsulated media for distribution by placing it in such a way that they can be requested from the HTTP server, you are done. The idea behind the live streaming is that it leverages existing Internet architecture that is already optimized for serving HTTP requests for reasonably sized resources.
HTTP streaming renders many existing CDN solutions obsolete with their custom streaming protocols, custom routing and custom content caching.
您还可以使用适用于 mac os x 的媒体流验证器命令行应用程序来验证 HTTP Web 服务器生成的流。
You can also use media stream validator command line application for mac os x for validating streams generated by the HTTP Web server.
或多或少，但如果您希望服务器将文件推送到 iOS 设备，还可以使用自适应比特率流。这意味着您的范围从跟踪所有 TS 文件的单个“index.m3u8”文件扩展到主索引，然后跟踪您希望在应用程序中支持的每个比特率的索引文件，然后单独跟踪 TS 文件以各自的比特率进行编码。
这是一项大量的工作，但一旦掌握了基础知识，大部分工作都是例行公事/重复性的。
有关流媒体的更多信息，从 iOS 的角度来看，您的圣经应该始终是 TN2224。严格遵守技术说明中的规范，是您通过 App Store 流媒体审批流程的最佳机会。
有些人不介意（在过去的几个月里构建了一个流媒体应用程序，并查看了一大堆视频应用程序的 HTTP 日志，这些应用程序似乎不太遵守规则）——有时苹果会注意到，有时他们不会不是，有时播放器太大，苹果无法干预。
因此，它与接受 Apple 审查的应用程序功能的所有其他方面并没有太大不同。只是有一些方法可以确保您走在正确的轨道上。
当然，从纯粹的技术角度来看，正如 @psp1 提到的，mediastreamvalidator 工具可以帮助您确定您的流是否（在其核心部分，即使不是就其整体能力而言）与 HLS 实现的预期兼容。
注意：您可以使用自己的编码解决方案（使用 ffmpeg，优点是您有更多的控制权，缺点是需要时间来配置并正常工作。此外，一旦您开始说话，甚至一旦你完成了所有的技术工作，你就会发现这很容易，现在你必须弄清楚你要使用哪个许可证。需要拥有一个精美的 H.264 编码器你并跳过所有法律/程序的障碍才能得到一个）。
对于没有可以填满一个足球场的法律/会计团队的开发人员来说，更简单的解决方案是，更容易使用像 Encoding.com、Zencoder 等提供编码服务的第三方网站，这些网站提供点菜服务或通过第三方提供编码服务。月费。优点是他们已经处理了所有的许可 BS，并且只是为您提供简单的“付费使用”服务，这在您为客户构建项目时也可能非常有用。缺点是你现在依赖于 Zencoder/Encoding，另一方面，当你的编码作业因为服务器停机而失败一整天时，或者甚至当 API 不完全工作时，你就会知道按照您的预期或已记录的方式行事！
但无论如何，这就是在将 HLS 服务器投入生产之前了解 Grok 的所有因素！
More or less but there's also adaptive bit-rate streaming to take care of if you want your server to push files to iOS devices. Which means your scope expands from having a single "index.m3u8" file that tracks all the TS files to a master index that then tracks the index files for each bitrate you'd want to support in your application which then individually track the TS files encoded at the respective bit-rates.
It's a good amount of work, but mostly routine/repetitive once you've got the hang of the basics.
For more on streaming, your bible, from the iOS standpoint, should ALWAYS be TN2224. Adhering closely to the specs in the Technote, is your best chance of getting through the App Store approval process vis-a-vis streaming.
Some people don't bother (building a streaming app over the past couple of months and looked at the HTTP logs of a whole bunch of video apps that don't quite seem to stick by the rules) - sometimes Apple notices, sometimes they don't, and sometimes the player is just too big for Apple to interfere.
So it's not very different there from every other aspect of the functionality of your app that undergoes Apple's scrutiny. It's just that there are ways you can be sure you're on the right track.
And of course, from a purely technical standpoint, as @psp1 mentioned the mediastreamvalidator tool can help you figure out if your streams are - at their very core, even if not in terms of their overall abilities - compatible with what's expected of HLS implementations.
Note: You can either roll with your own encoding solution (with ffmpeg, the plus being you have more control, the minus being it takes time to configure and get working just RIGHT. Plus once you start talking even the least amount of scale, you run into a whole host of other problems. And once you're done with all the technical hard-work, you'd find that was easy. Now you'd have to actually figure out which license you need to get for having a fancy H.264 encoder with you and jump through all the legal/procedural hoops to get one).
The easier solution for a developer without a legal/accounting team that could fill a football field, IMO, it's easier to go third-party with sites like Encoding.com, Zencoder etc who provide their encoding services a-la-carte or with a monthly fee. The plus is that they've taken care of all the licensing BS and are just providing you a simple "pay to use" service, which could also be extremely useful when you're building a project for a client. The minus is that you're now DEPENDENT on Zencoder/Encoding, the flip-side of which you'd know when your encoding jobs fail for a whole day because their servers are down, or even otherwise, when the API doesn't quite act as you expect or has been documented!
But anyhow that's about all the factors you got to Grok before pushing a HLS server into production!