windows phone 中的 HTTP Live Stream 格式

kingxuke 2013-04-26 07:34:26

windows phone 中的 HTTP Live Stream 格式是什么？如搜狐视频、QQ视频、爱奇艺和乐视播放器的视频源是什么格式(肯定是windows phone 支持的视频格式，但想知道确切是哪一种)。

想在 windows phone 上实现 HTTP Live Stream 的播放（类似Apple m3u8板式的播放列表），但不知道如何入手，是否一定在使用 IS Live Smooth Streaming 或者 HTTP Live Stream Client SDK(3iVX)?

...全文

259 3 打赏收藏转发到动态举报

写回复

3 条回复

切换为时间正序

请发表友善的回复…

发表回复

kingxuke 2013-05-11

打赏
举报

回复

自己慢慢摸索吧，谢谢91program版主 可以帮忙年下我的另一个问题么？ http://bbs.csdn.net/topics/390454992

kingxuke 2013-04-27

打赏
举报

回复

91program：多谢版主回答，能给个思路么？我用抓包工具（wireshark）抓搜狐视频的包（手机通过无线连的笔记本），发现全是TCP包，而不是RTP包，所以不知道怎么进一步分析。刚毕业开始做，没经验，希望指点一下。如果可以帮忙解决，愿意支付费用（请站内联系）。

谢谢

91program 2013-04-27

打赏
举报

回复

肯定是windows phone 支持的视频格式，呵呵...，这个不一定。要看播放器的实现。

whtepaper-iphone about http live stream(by realwork)

get http_live_stream_architecture from apple developer website

http live streaming guide

Hardware Video Encoding on iPhone — RTSP Server example On iOS, the only way to use hardware acceleration when encoding video is to use AVAssetWriter, and that means writing the compressed video to file. If you want to stream that video over the network, for example, it needs to be read back out of the file. I’ve written an example application that demonstrates how to do this, as part of an RTSP server that streams H264 video from the iPhone or iPad camera to remote clients. The end-to-end latency, measured using a low-latency DirectShow client, is under a second. Latency with VLC and QuickTime playback is a few seconds, since these clients buffer somewhat more data at the client side. The whole example app is available in source form here under an attribution license. It’s a very basic app, but is fully functional. Build and run the app on an iPhone or iPad, then use Quicktime Player or VLC to play back the URL that is displayed in the app. Details, Details When the compressed video data is written to a MOV or MP4 file, it is written to an mdat atom and indexed in the moov atom. However, the moov atom is not written out until the file is closed, and without that index, the data in mdat is not easily accessible. There are no boundary markers or sub-atoms, just raw elementary stream. Moreover, the data in the mdat cannot be extracted or used without the data from the moov atom (specifically the lengthSize and SPS and PPS param sets). My example code takes the following approach to this problem: Only video is written using the AVAssetWriter instance, or it would be impossible to distinguish video from audio in the mdat atom. Initially, I create two AVAssetWriter instances. The first frame is written to both, and then one instance is closed. Once the moov atom has been written to that file, I parse the file and assume that the parameters apply to both instances, since the initial conditions were the same. Once I have the parameters, I use a dispatch_source object to trigger reads from the file whenever new data is written. The body of the mdat chunk consists of H264 NALUs, each preceded by a length field. Although the length of the mdat chunk is not known, we can safely assume that it will continue to the end of the file (until we finish the output file and the moov is added). For RTP delivery of the data, we group the NALUs into frames by parsing the NALU headers. Since there are no AUDs marking the frame boundaries, this requires looking at several different elements of the NALU header. Timestamps arrive with the uncompressed frames from the camera and are stored in a FIFO. These timestamps are applied to the compressed frames in the same order. Fortunately, the AVAssetWriter live encoder does not require re-ordering of frames. When the file gets too large, a new instance of AVAssetWriter is used, so that the old temporary file can be deleted. Transition code must then wait for the old instance to be closed so that the remaining NALUs can be read from the mdat atom without reading past the end of that atom into the subsequent metadata. Finally, the new file is opened and timestamps are adjusted. The resulting compressed output is seamless. A little experimentation suggests that we are able to read compressed frames from file about 500ms or so after they are captured, and these frames then arrive around 200ms after that at the client app. Rotation For modern graphics hardware, it is very straightforward to rotate an image when displaying it, and this is the method used by AVFoundation to handle rotation of the camera. The buffers are captured, encoded and written to file in landscape orientation. If the device is rotated to portrait mode, a transform matrix is written out to the file to indicate that the video should be rotated for playback. At the same time, the preview layer is also rotated to match the device orientation. This is efficient and works in most cases. However, there isn’t a way to pass this transform matrix to an RTP client, so the view on a remote player will not match the preview on the device if it is rotated away from the base camera orientation. The solution is to rotate the pixel buffers after receiving them from the capture output and before delivering them to the encoder. There is a cost to this processing, and this example code does not include this extra step.

2012年3月HTTP Live Streaming (HLS) 视频直播技术的第8个版本的修订草案，常用的流媒体协议主要有 HTTP 渐进下载和基于 RTSP/RTP 的实时流媒体协议，这二种基本是完全不同的东西，目前比较方便又好用的我建议使用 HTTP 渐进下载的方法。在这个中 apple 公司的 HTTP Live Streaming 是这个方面的代表。它最初是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的流.现在见到在桌面也有很多应用了，HTML5 是直接支持这个。

Windows客户端开发

7,660

社区成员

18,840

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章