CN101287097A - 手持通信设备支持ipv6网络的视频点播系统架构及方法 - Google Patents
手持通信设备支持ipv6网络的视频点播系统架构及方法 Download PDFInfo
- Publication number
- CN101287097A CN101287097A CNA2007100393335A CN200710039333A CN101287097A CN 101287097 A CN101287097 A CN 101287097A CN A2007100393335 A CNA2007100393335 A CN A2007100393335A CN 200710039333 A CN200710039333 A CN 200710039333A CN 101287097 A CN101287097 A CN 101287097A
- Authority
- CN
- China
- Prior art keywords
- webserver
- terminal
- message
- request
- length
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
一种手持通信设备支持IPv6网络的视频点播系统架构及方法，其主要克服现有技术存在的图像质量和数据传输上的缺点，在手持通信设备和网络服务器上分别增设了图像质量和传输功能模块，并提供了应答式解决协议，以及在具体实施上提供了实施细则，从而提高了数据流的通畅度，减小了不必要的传输带宽和节省了费用开销。同时，提出了对客户分类支持的思想和利用现有资源的方法，以提高支持效率。
Description
技术领域
本发明涉及一种通信设备和网络服务器的互通点播结构和方法。
背景技术
现有的手机和网络服务器的互通点播架构如图3所示，二者之间以C/S结构形式联结在一起，它们之间的联结需要支持的功能模块：
甲、在终端，即客户端C上包括点播平台11，如界面/协议层、音、视频编解码器12、网络通信模块13，如RSVP、IPV6协议栈(TCP/IP)、OS和标志14，如BB/MAC以及射频器15；
乙、在网络服务器端(S)则包括点播服务器21，如界面/协议层、音视频编解码器22、网络通信模块23、如RSVP、IPV6协议栈(TCP/IP)、OS和标志24，如BB/MAC以及射频器25。
如上所述，在现有技术中，虽然引入了IPV6替代IPV4，IPV6在可用IP地址空间改善了端到端的安全性，和对于移动通信的内在支持，提高了服务质量(QoS)以及减轻系统管理负担等方面都有显著优势。然而，如何提高数据流的通畅度，充分利用现有资源，进一步减小不必要的带宽浪费和费用开销却仍不令人满意。
发明内容
如上所述，如何克服现有手机与网络服务器之间的互通点播结构和方法所存在缺点，进一步提高图像的质量和数据流的通畅度，以及减小不必要的带宽浪费和费用的开销，乃是本发明所要解决的技术问题，为此，本发明的目的在于提供一种手持通信设备支持IPV6网络的视频点播系统结构及方法。同时，本方法很好的解决了手持设备利用既有视频资源的问题，而不需要对既有资源作任何的改变。
本发明的技术方案如下：
根据本发明的一种手持通信设备和网络视频服务器的互通点播架构，其中终端，即手机或手持通信设备由一基站经由因特网联结另一基站而与网络服务器形成C/S连接结构，该终端中设有点播平台，音视频编解码器、网络通信模块、标志模块和射频模块；该网络服务器中，也设有点播服务器、音视频编解码器、网络通信模块、标志模块和射频模块，特点是，在终端中还增设图像质量和传输功能模块；同样，在网络服务器中相应设置图像质量和传输功能模块。
客户端和服务器端属于同一个总的发明构思，根据本发明的一种手持通信设备和网络视频服务器的互通点播的图像质量和传输方法，包括步骤：S1、终端向网络服务器发出注册请求；S2、网络服务器向终端回答注册结果并分配视频ID；S3、终端向网络服务器发出资源查询请求，S4、网络服务器向终端作出应答，并返回服务支持，供选择；S5、终端向网络服务器请求所需分辨率等其它信息，S6、网络服务器回复终端确定支持的分辨率；S7、终端向网络服务器发送准备好接收信息，S8、网络服务器向终端发回在新频道上终端发送视频信息和视频数据；S9、终端向网络服务器发出重传请求，S10、网络服务器响应终端之请求，进行信息重传；S11、终端向网络服务器发出快进请求，S12、网络服务器响应终端之请求，确认快进数据；S13、终端向网络服务器发出快退请求，S14、网络服务器响应终端快退请求，并确认快退数据；S15、终端向网络服务器发出暂停请求，S16、网络服务器响应暂停；S17、终端向网络服务器发出停止请求，S18、网络服务器确认停止请求，结束此次操作；S19、终端向网络服务器发出控制请求，S20、网络服务器对终端作出控制响应。
本发明的优点是：手持通信设备根据自己需要的分辨率发送消息给网络服务器，网络服务器按照协议算法向手提设备发送应答消息，(确认或拒绝)，决定发送文件的大小(帧的大小)，包括使用的缩减分辨率的规则信息，从而可以减少数据流量，使得图像流畅度增加，减少了不必要的带宽浪费和不必要的费用的开销。同时对于已有资源的利用十分方便，对各种客户分类支持的思想，满足不同客户的需求。充分利用现有的丰富资源以吸引客户，提供对市场开拓的支持，从而最终使得用户费用的下降。
附图说明
图1是本发明的总体框架示意图。
图2是本发明的视频图像质量和传输的方法流程图。
图3是已有手持设备和网络视频服务器的互通点播框架示意图。
具体实施方式
下面根据图1和图2给出本发明一个较好的实施例，并通过对实施例的描述，进一步给出本发明的具体实施细节，使能更好地说明本发明的方法特征和功能特色，而不是用来限定本发明的范围。
该方法使用客户/服务器(C/S)通用通信模式。任何一端可以同时扮演两个角色。并且执行协议之对等方完全透明。
本方法不包括服务器寻址，地址解析等内容。主要内容如下：
在实施例中，结合图1和图2提供了视频点播构架和方法，实施例中进一步提供点播进程中的细则。
(一)消息类型与格式：
本方法支持的消息类型定义如下表(消息ID为十六进制数)：
(1)数据包格式：
通用数据包格式
| 消息ID | 消息控制 | 消息体(由消息元组成) |
| 2bytes | 4bytes | N bytes(字节数由消息控制指出) |
(2)消息ID(2字节)
消息ID定义了消息的类型，用以区分不同的控制、数据和状态信息。消息类型由主消息类型，次消息类型，三级消息类型和请求应答序号组成。格式如下：
| 主消息类型 | 子消息类型 | 三级消息类型 | 请求/应答序号 |
| 15 12 | 11 8 | 7 4 | 3 0 |
已定义取值：
(3)消息控制(4字节)
消息控制定义了当前消息的状态/指示，用以对后面数据体的进行不同的控制。消息类型由优先级，消息序列号，消息体长度组成。
格式如下：
已定义取值：
| 分段(2bit) | 0，1，2，3。0表示不分段；1表示分段且是分段第一部分；2表示分段中间部分；3表示分段的最后一部分。 |
| 优先级(3bit) | 0～7，8级QoS，优先级递减。控制消息将得到较高的优先级。 |
| 消息序列号(6bit) | 递增，唯一 |
| 消息长度(12bit) | 字节数，包含消息体全部长度 |
(4)消息元(Information Element)
消息元定义了消息体的一种内容格式，消息体由若干个消息元组成。每个消息元都是独立的。可以出现在不同的消息中。消息元由消息元ID，消息元长度，消息元内容组成。
消息元分为必须出现，和可选出现。
必须出现，即在某一消息(体)中，用到该消息元时，该消息元必须出现，否则消息解析会出现报错。
可选出现，即在某一消息(体)中，用到该消息元时，该消息元非必须出现，可以出现，也可以不出现。不影响消息解析。
格式如下：
| Element ID(1byte) | 消息元ID |
| Element Length(1bytes) | 消息元长度 |
| Element Content(N bytes) | 消息元体(内容) |
注意：消息元支持嵌套。
消息元定义见下表
| Information Element ID | 消息元名称 | 备注 |
| 0 | 用户名 | |
| 1 | 用户密码 | |
| 2 | 返回状态 | |
| 3 | 用户ID | |
| 4 | 向服务器请求信息 | |
| 5 | 视频格式支持信息 |
| 6 | 音频格式支持信息 | |
| 7 | 播放文件信息 | |
| 8 | 播放帧率信息 | |
| 9 | 视频内容 | |
| 10 | 视频帧序号响应 | |
| 14 | 客户端请求信息 |
(二)数据包封装/解析规则：
本发明方法必须支持数据包封装解析过程。
根据消息ID，封装/解析消息控制部分，然后附加/解析消息体，消息体内容为消息元格式，消息元支持嵌套。在消息控制之后(消息体之前)，增加CRC校验码，对消息头(消息ID和消息控制)部分校验，可以增强纠错能力(关于CRC校验方法参看相关文档，这里不给出详细说明)。
(三)传输帧生成转换：
本发明方法必须支持传输帧生成转换方法。
转换方法遵循等比映射法则。即按照视频资源的原始存储分辨率和需要转换成的分辨率的比例关系进行。将原始数据帧按照比例映射到所要生成的帧里面。
控制信息中有分段字段，2比特，取值为0～3。
0表示不分段；
1表示分段，且为分段第一部分；
2表示分段中间部分，可以有多个中间段；
3表示分段最后一部分。
(四)分段/重组(Fragment/de-fragment)规则：
本发明方法必须支持分段/重组机制。
只有数据帧允许分段(fragment)。当数据帧超过了分段阈值(fragmentthreshold)时，需要分段和重组操作。
数据如果分段，则必须在所有分段正确的情况下，才可以重组，否则丢弃。
当数据为分段时，消息序列号不变。
(五)用户状态维护：
本发明方法必须支持用户状态维护。
服务器需要对用户进行维护，为每一个用户ID维护状态信息。客户端一旦成功注册，就表示已经和服务器间建立了连接，必须定期向服务器端发送心跳包，指示客户端处于活跃状态。
当用户ID注销后，应销毁该用户ID的状态消息。
客户端维护点播状态信息，状态信息需同步。当服务器发现失步后，服务器必须进行同步操作。
(六)本发明方法内容和详细过程：
下述各消息格式中所列消息元均为必须出现，严格遵循。可选消息元没有列出。
(1)注册与注销请求
注册请求
首先需要客户端向服务提供者注册。注册完成后，服务器返回消息，表示是否注册成功。如果注册成功，服务器会分配一个用户ID。用户ID会在后面的过程中使用。如果在指定的时间内没有获得响应，则进行超时处理。可以发起新的注册过程。一旦注册成功，客户端将定期向服务器端发送消息，以确认客户端活跃。
消息格式如下：
| 9000 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 0 | 用户名 |
| Element Length(1bytes) | x | 用户名长度 |
| Element Content(x bytes) | 用户名 |
| Element ID(1byte) | 1 | 用户密码 |
| Element Length(1bytes) | x | 用户密码长度 |
| Element Content(x bytes) | 用户密码 |
注销请求
在注册成功后，用户可以根据需要注销该次注册。客户端发送注销请求后，等待响应。若在一定时间内没有响应消息，则重新发送该消息，若三次发送均未收到响应，则视为服务器故障，客户端强制退出。
当服务器维护的状态信息发现长时间没有来自该客户端的消息时，则认为该客户端已经非活跃状态，自动注销该客户端状态消息。若在服务器端注销之前，该客户端重新注册，则视为新注册，服务器将重新为之分配新的服务ID。
消息格式如下：
| 9300 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 3 | 用户ID |
| Element Length(1bytes) | 4 | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
(2)服务器注册和注销响应
响应注册
当有客户端需要注册时，服务器必需分配一个用户ID，且服务器须维护该用户ID的状态信息。内容包括，当前序列号，当前播放状态及位置等。
消息格式如下：
| 9001 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段 | 0 |
| 优先级 | 3 |
| 消息序列号 | x |
| 消息长度 | n |
消息体内容：
| Element ID(1byte) | 0 | 用户名 |
| Element Length(1bytes) | x | 用户名长度 |
| Element Content(x bytes) | 用户名 |
| Element ID(1byte) | 3 | 用户ID |
| Element Length(1bytes) | 4 | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
| Element ID(1byte) | 2 | 返回状态 |
| Element Length(1bytes) | 2 | 状态长度 |
| Element Content(2bytes) | 状态内容(状态值) |
状态值列表如下：
响应注销
如果用户注销了，则清除/收回资源。客户端发送注销请求后，等待响应。服务器端发送本消息，响应客户端请求，并注销所有资源。
当服务器维护的状态信息发现长时间没有来自该客户端的消息时，则认为该客户端已经处于非活跃状态，自动注销该客户端状态消息。若在服务器端注销之前，该客户端重新注册，则视为新注册，服务器将重新为之分配新的服务ID。
消息格式如下，
| 9301 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 3 | 用户ID |
| Element Length(1bytes) | 4 | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
| Element ID(1byte) | 2 | 返回状态 |
| Element Length(1bytes) | 2 | 状态长度 |
| Element Content(2bytes) | 状态内容(状态值) |
状态值列表如后：
(3)心跳包
客户端一旦注册成功，客户端将定期向服务器端发送消息，以确认客户端活跃。周期为60秒。服务器将根据心跳包的规律到达，来判断其正常状态。服务器端不需要对该消息响应，发送响应包。
消息格式如下，
| 9400 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 3 | 用户ID |
| Element Length(1bytes) | 4 | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
| Element ID(1byte) | 2 | 返回状态 |
| Element Length(1bytes) | 2 | 状态长度 |
| Element Content(2bytes) | 状态内容(状态值) |
状态值列表如后：
(4)资源查询请求
请求服务器支持内容：用以协商确定传输相关信息。客户端需要列出所要查询的内容，服务器根据内容返回响应的值。
| 9100 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | 12 |
消息体内容：
| Element ID(1byte) | 3 | 用户ID |
| Element Length(1bytes) | 4 | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
| Element ID(1byte) | 4 | 向服务器请求信息 |
| Element Length(1bytes) | 0 | 信息长度 |
| Element Content(0bytes) | 信息内容 |
请求信息内容：
| Element ID(1byte) | 5 | 视频格式支持信息 |
| Element Length(1bytes) | 0 | 格式信息长度 |
| Element Content(0bytes) | 格式信息列表内容 |
注意：服务器必须支持QCIF格式。
| Element ID(1byte) | 6 | 音频格式支持信息 |
| Element Length(1bytes) | 0 | 格式信息长度 |
| Element Content(0bytes) | 格式信息列表内容 |
| Element ID(1byte) | 7 | 播放文件信息 |
| Element Length(1bytes) | 0 | 长度 |
| Element Content(0bytes) | 播放文件列表内容 |
| Element ID(1byte) | 8 | 播放帧率信息 |
| Element Length(1bytes) | 0 | 长度 |
| Element Content(x bytes) | 速率信息列表内容 |
(5)资源查询请求响应
服务器对客户端的资源查询请求予以响应。若为非法则不响应。
| 9101 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | 12 |
消息体内容：
| Element ID(1byte) | 3 | 用户ID |
| Element Length(1bytes) | 4 | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
| Element ID(1byte) | 4 | 服务器支持信息 |
| Element Length(1bytes) | x | 信息长度 |
| Element Content(x bytes) | 信息内容 |
以下为服务器支持信息4的嵌套内容：
| Element ID(1byte) | 5 | 视频格式支持信息 |
| Element Length(1bytes) | x | 格式信息长度 |
| Element Content(x bytes) | 格式信息列表内容 |
注意：服务器必须支持VGA格式。
| Element ID(1byte) | 6 | 音频格式支持信息 |
| Element Length(1bytes) | 0 | 格式信息长度 |
| Element Content(0bytes) | 格式信息列表内容 |
| Element ID(1byte) | 7 | 播放文件信息 |
| Element Length(1bytes) | x | 长度 |
| Element Content(x bytes) | 播放文件列表内容 |
| Element ID(1byte) | 8 | 播放速率信息 |
| Element Length(1bytes) | x | 长度 |
| Element Content (x bytes) | 速率信息列表内容 |
(6)确定分辨率等资源
客户端根据服务器的返回内容选择，发回服务器。
| 9200 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | 12 |
消息体内容：
| Element ID(1byte) | 3 | 用户ID |
| Element Length(1bytes) | 4 | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
| Element ID(1byte) | 14 | 客户端请求信息 |
| Element Length(1bytes) | x | 信息长度 |
| Element Content(x bytes) | 信息内容 |
以下为客户端请求信息14的嵌套内容：
| Element ID(1byte) | 5 | 格式支持信息 |
| Element Length(1bytes) | x | 格式信息长度 |
| Element Content(x bytes) | 选择的格式内容 |
| Element ID(1byte) | 6 | 音频格式支持信息 |
| Element Length(1bytes) | 0 | 格式信息长度 |
| Element Content(0bytes) | 选择的音频格式 |
| Element ID(1byte) | 7 | 播放文件信息 |
| Element Length(1bytes) | x | 长度 |
| Element Content(x bytes) | 播放文件名/地址 |
| Element ID(1byte) | 8 | 播放帧速率信息 |
| Element Length(1bytes) | x | 长度 |
| Element Content(x bytes) | 选择的速率内容 |
其他信息略。
(7)服务器确定客户端选择
服务器收到客户的需求后，发送相应的确认信息。表示服务器准备好。
| 9201 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 0 | 用户名 |
| Element Length(1bytes) | x | 用户名长度 |
| Element Content(x bytes) | 用户名 |
| Element ID(1byte) | 2 | 返回状态 |
| Element Length(1bytes) | 2 | 状态长度 |
| Element Content(2bytes) | 状态内容(状态值) |
状态值列表如下：
(8)客户端准备接收
客户端收到服务器响应的确认消息后，开始等待接收视频信息。
| 8000 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 0 | 用户名 |
| Element Length(1bytes) | x | 用户名长度 |
| Element Content (x bytes) | 用户名 |
| Element ID(1byte) | 2 | 返回状态 |
| Element Length(1bytes) | 2 | 状态长度 |
| Element Content (2bytes) | 状态内容(状态值) |
状态值列表见后。
(9)服务器发送
服务器根据客户端的请求，将视频资源转换成所需的分辨率要求，发送至客户端。视频资源的转换也在该协议中，转换方法遵循等比映射法则。
| 8001 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | x |
| 优先级(3bit) | 5 |
| 消息序列号(6bit) | 0 |
| 消息长度(12bit) | n |
消息体内容：
| ElementID(1byte) | 0 | 用户名 |
| Element Length(1bytes) | x | 用户名长度 |
| Element Content (x bytes) | 用户名 |
| Element ID(1byte) | 9 | 视频内容 |
| Element Length(1bytes) | x | 视频内容长度 |
| Element Content(x bytes) | 帧序列号+视频内容 |
帧序列号为4字节，包括帧号和分段号。格式如下：
| 帧号 | 分段号 |
| 31 8 | 7 0 |
当有分段时帧序列号不变。分段号只有在消息控制域为分段时才有效，否则忽略。发送方数据如果不分段，分段号域为0。
(10)客户端接收/响应
客户端接收并请求下一帧。用于播放。
| 8002 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 3 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 0 | 用户名 |
| Element Length(1bytes) | x | 用户名长度 |
| Element Content(x bytes) | 用户名 |
| Element ID(1byte) | 2 | 返回状态 |
| Element Length(1bytes) | 2 | 状态长度 |
| Element Content(2bytes) | 状态内容(状态值) |
状态值列表见后。
| Element ID(1byte) | 10 | 视频帧序号响应 |
| Element Length(1bytes) | 4 | 长度 |
| Element Content(4bytes) | 下一帧序号 |
(11)重传请求
客户端接收并请求服务器重放下一帧，用于播放
| 8003 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 5 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 2 | 用户ID |
| Element Length(1bytes) | x | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
| Element ID(1byte) | 10 | 视频帧序号响应 |
| Element Length(1bytes) | 4 | 长度 |
| Element Content(4bytes) | 请求下一帧序号 |
(12)停止请求与响应
请求
| 7000 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 5 |
| 消息序列号(6bit) | x |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 2 | 用户ID |
| Element Length(1bytes) | x | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
响应
| 7001 | xxxx xxxx | 消息体 |
| 2bytes | 4bytes | n bytes(字节数由消息控制指出) |
消息控制：
| 分段(2bit) | 0 |
| 优先级(3bit) | 5 |
| 消息序列号(6bit) | 0 |
| 消息长度(12bit) | n |
消息体内容：
| Element ID(1byte) | 2 | 用户ID |
| Element Length(1bytes) | x | 用户ID长度 |
| Element Content(x bytes) | 用户ID |
至此，正常的播放可以进行，以上为必须实现部分。
快进，快退等操作为可选内容。略。
(12)暂停请求与响应
(13)快进请求与响应
(14)快退请求与响应
(15)播放参数控制请求与响应
已定义状态值列表：
| 状态ID(2bytes) | 含义 | 备注 |
| 0 | 成功 | 根据消息含义确定具体成功含义 |
| 1 | 用户名重复注册 | |
| 2 | 用户名或密码错误 | |
| 3 | 消息格式错误 | |
| 4 | 有错误的 | |
| 5 | 选择配置错误 | |
| 6 | 接收未准备好 | 要求对方暂缓发送 |
| 7 | 接收失败 | 要求重新发送 |
| 等 |
Claims (2)
1、 一种手持通信设备和网络视频服务器的互通点播架构，其中终端(1)由基站(17)经因特网(3)链接基站(27)而与网络服务器(2)形成C/S连接结构，该终端(1)中设有点播平台(11)、音、视频编解码器(12)、网络通信模块(13)、标志模块(14)和射频模块(15)；该网络服务器(2)中设有点播服务器(21)、音、视频编解码器(22)、网络通信模块(23)、标志模块(24)和射频模块(25)，其特征在于，在终端(1)中还增设图像质量和传输功能模块(16)；在网络服务器(2)中相应设置图像质量和传输功能模块(26)。
2、 一种手持通信设备和网络视频服务器的互通点播的图像质量和传输方法，包括步骤：S1、终端(1)向网络服务器(2)发出注册请求，S2、网络服务器(2)向终端(1)回答注册结果并分配用户ID；S3、终端(1)向网络服务器(2)发出资源查询请求，S4、网络服务器(2)向终端(1)作出应答，并返回服务支持，供选择；S5、终端(1)向网络服务器(2)请求所需分辨率等其它信息，S6、网络服务器(2)回复终端(1)确定支持的分辨率；S7、终端(1)向网络服务器(2)发送“准备好接收”信息，S8、网络服务器(2)向在新频道上终端发送视频信息和视频数据；S9、终端(1)向网络服务器(2)发出重传请求，S10、网络服务器(2)响应终端(1)之请求，进行信息重传；S11、终端(1)向网络服务器(2)发出快进请求，S12、网络服务器(2)响应终端(1)之请求，确认快进数据；S13、终端(1)向网络服务器(2)发出快退请求，S14、网络服务器(2)响应终端快退请求，并确认快退数据；S15、终端(1)向网络服务器(2)发出暂停请求，S16、网络服务器(2)响应暂停；S17、终端(1)向网络服务器(2)发出停止请求，S18、网络服务器(2)确认停止请求，结束此次操作；S19、终端(1)向网络服务器(2)发出控制请求，S20、网络服务器(2)对终端(1)作出控制响应。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2007100393335A CN101287097A (zh) | 2007-04-10 | 2007-04-10 | 手持通信设备支持ipv6网络的视频点播系统架构及方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2007100393335A CN101287097A (zh) | 2007-04-10 | 2007-04-10 | 手持通信设备支持ipv6网络的视频点播系统架构及方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101287097A true CN101287097A (zh) | 2008-10-15 |
Family
ID=40059035
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2007100393335A Pending CN101287097A (zh) | 2007-04-10 | 2007-04-10 | 手持通信设备支持ipv6网络的视频点播系统架构及方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101287097A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102821311A (zh) * | 2012-05-30 | 2012-12-12 | 浙江宇视科技有限公司 | 一种视频数据包优先级设置方法和装置 |
-
2007
- 2007-04-10 CN CNA2007100393335A patent/CN101287097A/zh active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102821311A (zh) * | 2012-05-30 | 2012-12-12 | 浙江宇视科技有限公司 | 一种视频数据包优先级设置方法和装置 |
| CN102821311B (zh) * | 2012-05-30 | 2015-07-15 | 浙江宇视科技有限公司 | 一种视频数据包优先级设置方法和装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102210118B (zh) | 用于多播通信的数据速率自适应的方法 | |
| EP2106178B1 (en) | Improved communications throughput with multiple physical data rate transmission determinations | |
| CN101473616B (zh) | 用于可靠地传递多播数据的方法和装置 | |
| US7286551B2 (en) | Media access control device guaranteeing communication quality in wireless LAN for VoIP | |
| US8913627B2 (en) | Method to improve channel utilization in a time division multiple access based protocol | |
| US20070286121A1 (en) | Systems and techniques for selective point-to-multipoint retransmission of multicast frames in a wireless network | |
| CN103858373A (zh) | 用于低速无线网络中的长分组的改进的分段 | |
| US20070223527A1 (en) | Method and system for transmission of different types of information in wireless communication | |
| WO2019149053A1 (zh) | 一种基于融合传输系统的数据传输方法 | |
| KR101991388B1 (ko) | 이종 네트워크상에서의 컨텐츠 전송 방법 및 이를 위한 장치 | |
| JP5161106B2 (ja) | デジタルテレビブロードキャストサービスを受信するためのゲートウェイ、端末および対応する方法 | |
| WO2019205803A1 (zh) | 基于harq技术的通信方法、设备及系统 | |
| JP5277158B2 (ja) | データ受信方法、修復方法および対応する端末 | |
| CN101166106A (zh) | 用于减少网络中的重发请求的方法和设备 | |
| US8526432B2 (en) | Packet processing system for a network packet forwarding device and method thereof | |
| WO2010108416A1 (zh) | 转发可伸缩视频编码数据报文的方法、设备和通信系统 | |
| US20120026999A1 (en) | Local area broadcasting service system and method, and wireless transmission device applied therein | |
| CN109067497B (zh) | 一种适用于超短波tdma无线信道的高效组网方法 | |
| CN101668027B (zh) | 多媒体内容的提供方法、系统和客户端 | |
| CN101287097A (zh) | 手持通信设备支持ipv6网络的视频点播系统架构及方法 | |
| CN111405617B (zh) | 基于ap请求代理的ndn无线局域网流媒体传输方法及系统 | |
| KR101699351B1 (ko) | 파일 정정 배포 모드를 요청하는 방법 | |
| Long et al. | A hybrid DMB-T and WLAN network for broadband wireless access services | |
| US20120093175A1 (en) | Method and apparatus of transmitting packet in communication system | |
| KR101745648B1 (ko) | 오류 정정 기반의 방송 패킷 재전송 시스템 및 그 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| ASS | Succession or assignment of patent right |
Owner name: JIXINKANG INFORMATION TECHNOLOGY (SHANGHAI) CO., L Free format text: FORMER OWNER: SHANGHAI JIXIN COMMUNICATION TECHNOLOGY CO., LTD. Effective date: 20110310 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 200051 TOWER C, 26/F, SICHUANG BUILDING, NO. 3, LANE 600, TIANSHAN ROAD, SHANGHAI TO: 200233 NO. 633, JINZHONG ROAD, CHANGNING DISTRICT, SHANGHAI |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20110310 Address after: 200233 Shanghai city Changning District Admiralty Road No. 633 Applicant after: ShangHai Basecom Technology Co., Ltd. Address before: 200051 days in Shanghai City Road 600 Lane 3, building 26 floor C block. Applicant before: Shanghai Jixin Communication Technology Co., Ltd. |
|
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20081015 |