DLNA的一个场景的工作过程
来源:互联网 发布:清单好帮手软件 编辑:程序博客网 时间:2024/04/25 23:37
场景:用户将手机A中的媒体内容播放到电视B上。(DMC+DMR)
在这个场景中,前提是,A和B必须连接到同一个局域网中。假定电视B先接入局域网,手机A后接入局域网,然后再进行播放操作,那么该场景大概是这样的:
B接入局域网以后,B需要建立多播socket,然后加入DLNA这个多播组(譬如说是239.255.255.250,数据端口是1900),同时不断监听1900端口发送过来的报文数据。
如果报文以M-SEARCH开头,那么就说明,局域网内有设备正在进行查找。B现在扮演DMR的角色,那么它就应该处理所有Renderer的M-SEARCH报文,接收到相应报文之后,需要给查询方发送一个回复报文,回复报文中包含了当前DMR的基本信息。
A现在加入局域网,它也建立多播socket,也加入到多播组中,然后根据A上用户选择进行DMR搜索之后,A发出M-SEARCH报文,局域网多播机制会将该报文发送给DLNA多播组中所有监听者,于是B也收到了该报文。B开始解析报文,它知道对方搜索的正式DMR,于是它立刻给多播组内发一条回复报文,告诉搜索方自己就是DMR。于是A又收到了该回复报文,A解析了该回复,得到了DMR的基本信息,它接着把这些基本信息装载到UI上,于是用户看到了该DMR的信息。
如果用户已经选择了某个媒体资源,那么就可以直接进行具体的流媒体push操作了。
关于push操作,其实是这样的。无论对于DMR+DMC的push场景,或者DMS+DMR的pull场景,媒体提供方其实也要提供一个服务就是流媒体服务器(就是NanoHTTPD或者netty等去实现的)。所以在A和B这个场景中,A是DMC,所以它提供了一个媒体服务器。当报文发出并得到回复之后,事实上这一步只是确定了DMR有谁,接着用户选择了某个DMR,这就确定了要与之通信的DMR是谁,然后,A和B其实就已经建立了一种端对端的关系,A会先发起一个HTTP请求,告诉B,我要播放什么格式的内容,它的URL地址是什么,然后B接收到请求之后,解析到要播放的地址文件格式及其地址等信息之后,先会判断它支持不支持这个媒体内容,如果不知吃,那么就需要返回一个400或者什么错误码给A(错误码,DLNA spec里都有详细介绍),如果它支持,那么就开始建立与该流媒体的连接,通过HTTP去拿数据,然后根据媒体类型再在本地进行解码,然后进行播放。
在刚才的过程中,如果媒体文件是视频或者音频,那就更复杂一些,一是B要进行实时解码播放,二是还需要把播放的进度不断返回给A,因为对于A来讲,它需要把播放进度条展示给用户去看。同时A一般还会提供一些更具体的视频、音频操作,例如暂停、恢复、跳转等。这些都是协议里面规定的,具体如何去通信,还要仔细的阅读spec
在这个场景中,前提是,A和B必须连接到同一个局域网中。假定电视B先接入局域网,手机A后接入局域网,然后再进行播放操作,那么该场景大概是这样的:
B接入局域网以后,B需要建立多播socket,然后加入DLNA这个多播组(譬如说是239.255.255.250,数据端口是1900),同时不断监听1900端口发送过来的报文数据。
如果报文以M-SEARCH开头,那么就说明,局域网内有设备正在进行查找。B现在扮演DMR的角色,那么它就应该处理所有Renderer的M-SEARCH报文,接收到相应报文之后,需要给查询方发送一个回复报文,回复报文中包含了当前DMR的基本信息。
A现在加入局域网,它也建立多播socket,也加入到多播组中,然后根据A上用户选择进行DMR搜索之后,A发出M-SEARCH报文,局域网多播机制会将该报文发送给DLNA多播组中所有监听者,于是B也收到了该报文。B开始解析报文,它知道对方搜索的正式DMR,于是它立刻给多播组内发一条回复报文,告诉搜索方自己就是DMR。于是A又收到了该回复报文,A解析了该回复,得到了DMR的基本信息,它接着把这些基本信息装载到UI上,于是用户看到了该DMR的信息。
如果用户已经选择了某个媒体资源,那么就可以直接进行具体的流媒体push操作了。
关于push操作,其实是这样的。无论对于DMR+DMC的push场景,或者DMS+DMR的pull场景,媒体提供方其实也要提供一个服务就是流媒体服务器(就是NanoHTTPD或者netty等去实现的)。所以在A和B这个场景中,A是DMC,所以它提供了一个媒体服务器。当报文发出并得到回复之后,事实上这一步只是确定了DMR有谁,接着用户选择了某个DMR,这就确定了要与之通信的DMR是谁,然后,A和B其实就已经建立了一种端对端的关系,A会先发起一个HTTP请求,告诉B,我要播放什么格式的内容,它的URL地址是什么,然后B接收到请求之后,解析到要播放的地址文件格式及其地址等信息之后,先会判断它支持不支持这个媒体内容,如果不知吃,那么就需要返回一个400或者什么错误码给A(错误码,DLNA spec里都有详细介绍),如果它支持,那么就开始建立与该流媒体的连接,通过HTTP去拿数据,然后根据媒体类型再在本地进行解码,然后进行播放。
在刚才的过程中,如果媒体文件是视频或者音频,那就更复杂一些,一是B要进行实时解码播放,二是还需要把播放的进度不断返回给A,因为对于A来讲,它需要把播放进度条展示给用户去看。同时A一般还会提供一些更具体的视频、音频操作,例如暂停、恢复、跳转等。这些都是协议里面规定的,具体如何去通信,还要仔细的阅读spec
- DLNA的一个场景的工作过程
- DLNA的一个场景的工作过程
- 一个基本的工作场景
- 有关DLNA的一个讲座
- 有关DLNA的一个讲座
- 有关DLNA的一个讲座
- DLNA 技术与工作的结合
- USB Specification 一个鼠标的工作过程
- dlna 的思路
- DLNA的介绍
- DLNA的一些体会
- DLNA的架构
- 工作中遇到的一个值得学习的存储过程//
- 关于DLNA的一些问题
- DLNA(明基的返校讲座)
- 点击一个程序,程序在操作系统的工作过程
- Velocity的工作过程
- pppoe的工作过程
- IOS 5 for Developers
- 一些有意思的算法代码
- Silverlight开发历程—RenderTransform特效(TranslateTransform,RotateTransform,ScaleTransform,skewTransform)
- JavaScript 文本框变成密码框
- oracle的sqlldr命令
- DLNA的一个场景的工作过程
- _tcsstr的源码
- Windows下的DOS命令集锦
- xbmc又前进了一步
- 什么时候用抽象类什么时候用接口
- Mybatis报了Error setting null parameter问题解决
- CentOS系统更新Python
- C++数组应用之特殊矩阵的压缩存储
- MQ远程队列配置