CN105872779A - 清鹤数字电视头端获取电信清流的应用软件 - Google Patents

清鹤数字电视头端获取电信清流的应用软件 Download PDF

Info

Publication number
CN105872779A
CN105872779A CN201610242969.9A CN201610242969A CN105872779A CN 105872779 A CN105872779 A CN 105872779A CN 201610242969 A CN201610242969 A CN 201610242969A CN 105872779 A CN105872779 A CN 105872779A
Authority
CN
China
Prior art keywords
stream
data
transmission
digital television
program
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
Application number
CN201610242969.9A
Other languages
English (en)
Inventor
叶德建
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Cleartv Corp Ltd
Original Assignee
Shanghai Cleartv Corp Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Shanghai Cleartv Corp Ltd filed Critical Shanghai Cleartv Corp Ltd
Priority to CN201610242969.9A priority Critical patent/CN105872779A/zh
Publication of CN105872779A publication Critical patent/CN105872779A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种用于现有数字电视行业的清流获取的解决方案,以构建一个综合、健壮的清流获取平台。该方案充分利用了现有的网络数据获取技术和电信运营商所提供的数字电视接入设备,同时具有提供灵活和健壮的数字电视服务的优点。该平台不仅可以帮助业务合作伙伴能够快速开发,灵活的整合各种数字电视数据资源和应用;同时还可以适应各种数字电视信号源和网络环境,并能够以较低的成本灵活的在各种方案之间进行切换,在提供较好的扩展性的同时使得对终端用户的使用影响降到最低。

Description

清鹤数字电视头端获取电信清流的应用软件
技术领域
本发明涉及新媒体技术领域,特别是涉及云与大数据分析。
背景技术
电视技术服务的形式已经从模拟电视发展到数字电视,从广播电视服务到互动视频服务。电视的使用范围早已超越了广播娱乐界,并深深地扩展到文化教育、科研管理、工矿企业、医疗卫生、公安交通、军事宇航等各个重要部门。数字电视节目源,无论是点播、直播还是交互式视频服务,都通过传输流的形式进行服用和传输。传输流在解决了传输和封装的问题,同时也给各种应用平台和第三方服务提供商与数字电视信号交互提供了可能。一般的数字电视技术大都采用DVB-T、DVB-S信号源,接收机,编码器,交换机,数字电视机的解决方案,如图1所示。有些国家和地区,由于版权和媒体管理的限制,信号源通常是由政府指定的运营商控制和管理,用户和第三方服务提供商只能从这些指定的运营商那里获取信号,或者必须从运营商那里获取授权许可。
我们从现有的数字电视运营商对数字电视服务所提供的服务开始,通常最初获得的数字电视信号时模拟信号,是不能够直接使用的,要经过卫星接收机、编码器或网络适配器等硬件设备进行转换或处理,然后才可以输出到用户和第三方数字电视服务提供商使用。这些处理主要分为三类:1)针对卫星电视信号,通常使用卫星接收机进行模拟-数字的转换,以供在本地使用,这种方式灵活性较差,用户可定制性较低,卫星接收机的成本较高。2)对于光纤传输的电视信号,必须经过网络适配器,进行光电转换,这样的专用线路和设备优点是,信号稳定、频率资源丰富。缺点是成本非常高,只有运营商级别的用户才会采用这种方式。3)对于地面网络传输的电视信号,包括有线电视电缆和家庭宽带网络,都需要通过编码器对电视信号进行码率控制和编码格式的转换,一般的第三方数字电视服务提供商和集成商会采用这种方式。我国也是采用这种操作模式,其中电信作为唯一的互联网和有线电视服务供应商,拥有独一无二的地面信号传输网络和平台,而其他软件公司、内容提供商和设备供应商作为数字电视服务提供商合作伙伴,开发和提供基于该网络的视频处理服务和客户端管理接口。这种操作模式的优点是:他以相对合理的成本提供较高的灵活性;它允许除了电信提供商之外的第三方集成商和服务提供商能够进入数字电视业务中,并通过各种中间设备和接口对数字电视业务进行集成和处理,最终能够为用户提供灵活的性能和低廉的价格。用户可以享受由数字电视提供商提供的基本数字电视服务和订制的数字电视服务并且可以与不同的行业融合,这有利于促进数字电视服务的发展和推广。
新型交互式数字电视业务的出现和发展,进一步推动了数字电视业务的发展,增强了对于数字电视服务的灵活性的需求。数字电视节目的直播方案中,以苹果的HLS(HTTPLive Streaming)技术最具代表性。如图2所示,HLS技术主要基于TS的视频流或文件进行封装传输,HLS类似一个容器封装MPEG TS传输格式,而TS格式正是数字电视标准领域里最普遍的一种视频传输标准,HLS视频编解码采用MPEG-4或H.264,音频采用AAC,将其应用在数字电视技术方案上几乎不需要改动。也正因如此,基于HLS的数字电视直播方案得到了广泛的应用。但是无论是其它的直播方案还是基于HLS技术的数字电视直播方案,前提是已经获取到了未经加密或加扰的视频流,即电信清流。最初的数字电视直播方案通常无法应对电信行业中多变的视频格式。这是因为,电信运营商或数字电视信号提供商为了鉴权、认证和计费等接入需要,通常都不会将TS码流直接放在网络中进行传输,而是对TS流再次进行封装,例如,采用UDP传输的TS流会通过RTP对TS流进行封装,采用TCP传输的TS流会通过RTSP对TS流进行封装。这对于单纯采用硬件技术进行数字电视直播的解决方案是一个挑战,并且不利于第三方数字电视服务集成商的介入。
因此,现有的数字电视直播方案中,第三方数字电视服务集成商和企业用户通过电信运营商的硬件设备获取到多媒体数据和信令流后,要通过硬件编码器或适配器来进行数据流和业务流的分离,以及视频数据的处理。这样所带来的操作上的不灵活性,以及不健壮性等问题是显而易见的。首先,对于多媒体数据的格式转换和其它操作会受限于硬件设备的功能,一旦需求发生变化,就必须更新或升级硬件设备。其次,单纯的硬件设备方案,不能很好的适应于实际电信业的发展和变化,多媒体的编解码技术和标准都在不断更新和变化,一旦电信业采用了新的标准和新的传输格式,那么也需要通过更新和升级硬件设备才能继续适应行业的变化。这样多带来的运营成本和业务上的不连续性还是颇为显著的。
基于以上原因,本发明的目的在于提出一种用于现有数字电视行业的清流获取解决方案,以构建一个 综合、健壮的清流获取平台。该方案充分利用了现有的网络数据获取技术和电信运营商所提供的数字电视接入设备,同时具有提供灵活和健壮的数字电视服务的优点。有了这个技术平台可以帮助业务合作伙伴能够快速开发,灵活的整合各种数字电视数据资源和应用。同时,最新的交互式网络电视也可以很容易的利用该方案获取用户所关心的内容,并最终获得较高的客户满意度和市场占有率。终端用户可以获取并透明的尽享数字电视应用所带来的感官体验。更重要的是,这个平台可以适应各种数字电视信号源和网络环境,并能够以较低的成本灵活的在各种方案之间进行切换,在提供较好的扩展性的同时使得对终端用户的使用影响降到最低。
发明内容
为了克服上述现有技术的不足,本发明提出了一种数字电视清流获取的技术方案,构建了一个适应于各种应用环境的电信数字电视清流的获取平台。
本发明所采用的技术方案是:基于中国电信在不同地区所提供的数字电视网络,为电信用户创建一整套在不同网络环境、不同应用需求、不同集成策略下均可获取到电信清流的应用软件。该应用软件在不增加额外的网络设备,不增加网络拓扑的复杂性的前提下,向数字电视的企业用户和数字电视集成商提供稳定的电信清流。不仅如此,还可以根据网络环境的变化,启用本地视频发送机制,避免因网络异常情况导致终端用户的娱乐体验收到较大影响。本发明所提供的电信数字电视清流获取方案,共有4部分构成:正常组播收流并转发、基于以太网层抓包的获取方式、硬件编码器方式、网络异常时本地文件发送。第一部分,在数字电视节目未经电信进行额外的封装协议进行处理的条件下,数字电视节目是以MPEG传输流的方式在网络上传输,任何能够兼容传输流格式的播放器和电视机都可以直接解码并播放该节目。在这种网络环境下,直接将电信清流从交换机转发到用户的媒体服务器上,以便进行转码和EPG服务处理。第二部分,当电信的数字电视节目的MPEG传输流是经过其它协议进行封装后,再次使用网络协议进行传输的,无法直接使用网络协议栈对传输流进行解析得到节目数据,可以在以太网层进行抓包,然后根据不同的网络协议(UDP或TCP)逐层解析,并最终获得电视节目清流。第三部分,对于以上两种网络环境下,当研发能力不足或追求更简单的解决方案,可以采用硬件编码器方案来进行节目清流的提取。第四部分,当网络发生异常,或者其它原因造成无法获取节目流时,采用转发本地文件来生成清流的方式,避免了因数字电视节目的缺失而导致节目不可用,影响终端客户的满意度。以上四部分考虑了不同网络环境和客户自身的需求,针对特定节目源可以仅采用一种方案,也可以在不同方案之间调整或动态切换,因此提供了一种健壮的头端电信清流获取方案。
与现有技术相比,本发明的有益效果是:(1)该方法充分考虑到各种不同的网络环境和用户的实际需求,利用电信数字电视节目进行直播给出了高效的解决方案。该方案在网络传输环境较好且简单时,采用了传统的编码器方案和直接转发方案,在网络环境和传输流封装较为复杂时,创新型的采用了底层抓包技术和本地文件发送的策略,从而具备了更高的灵活性和冗余性,可以在硬件成本和研发成本之间进行权衡,这些都是现有的电信清流获取方案所不具备的。
(2)以上所述的方案针对现有电信数字电视节目的传输格式和协议进行处理,并且可以很灵活方便的对传输流进行其它操作,为用户提供了灵活性。更重要的是该方案具有较好的可扩展性,即使将来电信的数字电视节目传输流改变了流封装格式,抑或增加了封装复杂度,该方案可以通过增加相应改变部分的处理技术,从而使得该方案仍能正常工作。总而言之,基于该方案的应用软件是健壮的、灵活的并且是可扩展的。
附图说明
图1为传统的电视节目前端和客户端示意图
图2为HLS切片技术的基本原理
图3为本发明系统框架图
图4为本发明软件协议层
图5为本发明的逻辑流程图
图6为本发明中各部分关系和可扩展性示意图
具体实施方式
下面结合附图和实施案例,对本发明的具体实施方式进一步详细描述。以下实施案例用于说明本发明,但是不用于限制本发明的使用范围。
本发明提出了一种数字电视清流获取的技术方案,构建了一个适应于各种应用环境的电信数字电视清流的获取平台。该方案的特点是可以适应各种数字电视信号源和网络环境,并能够以较低的成本灵活的在各种方案之间进行切换,在提供较好的扩展性的同时使得对终端用户的使用影响降到最低。
图3中给出了本发明的适用场景,本发明主要适用于中国电信的数字电视业务所提供的电视节目。通常网络是通过光纤入户,连接光猫,光猫上可以直接连机顶盒或者通过交换机再连接机顶盒。通常在数字电视业务中的用户级光纤每根带宽为100Mbps,可以同时传输7个标清频道的电视节目。若需要40个标清频道,则需要6个光猫,40个机顶盒。
本发明用于部署的单一的互联网服务供应商的网络上,在不增加网络拓扑复杂性的前提下,从机顶盒前端获取头端清流。如图3(a)中所示:101为系统所需提取的电视节目信号入口,即电信光猫;连接光猫的102为L2层交换机;连接交换机的103是电信所提供的机顶盒,若为终端用户就可以通过HDMI线缆直接连到电视机即可。而对于数字电视前端系统来说,需要在光猫之后到机顶盒之前获取电信清流。
本发明的第一个应用案例是:上海电信的清流获取方案。如图3(b)所示:110为光猫,经过光猫我们的HLS切片服务器112就可以直接获取到10个频道以传输流格式传输的电视节目,若需要30个频道,只需要申请3个光猫即可,即将另外2个光猫也连接到交换机111上。HLS可以将电视节目切片供用户观看直播。显然,从光猫输出的电视节目即为清流,如果需要对传输流进行其它操作,可以在112上进行操作后直接发给HLS服务器。
本发明的第二个应用案例是:广东电信的电视节目清流获取方案。图3(c)所示:201和202为光猫,连接光纤输入,然后光猫的输出连接到交换机的镜像端口中,相对应的另一侧连接的203和204为Hub,也连接在交换机的镜像端口上,机顶盒205和206连接在Hub上,服务器207连接在交换机的监控端口上,监控端口可以收到所有镜像端口的数据包,因此,服务器就可以抓取到所有的数字电视节目数据包,经过解析获得TS数据流并转发给HLS服务器,再通过web服务器发布出来,用户就可以观看到数字电视节目的直播。
本发明的第三个应用案例是:武汉地铁的清流获取方案。图3(d)所示:其中301为光猫,交换机304接在光猫上,同时,电信机顶盒302和服务器303也连接在电信机顶盒上,当有多播数字电视节目清流传过来,则直接将多播流转发到HLS服务器或者机顶盒上,当来自于301的多播视频传输流发生中断,那么则转发本地传输流文件到HLS服务器或者是机顶盒,从而保证数字电视节目清流的连续性,提高用户体验的满意度。
本发明的第四个应用案例是:某酒店的清流获取方案,该酒店的项目技术支持力量薄弱,并且在相当长的一段时间内不会改观,因此采用的是编码器获取清流的方案。图3(e)所示:其中401为光猫,402为机顶盒,输出直接送到编码器404,编码器的输出为MPEG传输流格式的数字电视节目数据,通过交换机402可以直接送到终端用户的机顶盒或者是先发送给HLS服务器,然后再发布给端用户播放。
图4显示了这个应用软件平台的协议层,不同网络环境下,不同的封装格式,获取清流的位置有所不同。
对应于以上所述的第一个应用场景,即上海电信清流的获取方案,直接可以在网络协议栈的应用层101获取到MPEG传输流数据,即为数字电视节目的清流,根据应用需要,可以直接发送给机顶盒,也可以先发送给HLS服务器,经过切片分段后经web服务器发布出去,以供机顶盒进行直播服务。
对于以上所述的第二个应用场景,广东电信清流的获取方案,数据解析过程如下:
1)步骤201:从网络协议栈的第二层数据链路层抓取到MAC数据帧。
2)步骤202:对MAC协议帧进行解析,取出负载即PPPoE数据帧。
3)步骤203:再对PPPoE数据帧进行PPPoE协议解析,去除PPPoE头部,取得其负载也就是IP数据包。
4)步骤204:接下来进行IP协议的解析,IP协议头部的长度也是可变的,需要用总长度减去头部长度获得负载的起始位置,进而取得IP数据包的负载,TCP数据段或UDP数据段。
5)步骤205:对于广东电信来说,标清数字电视节目是通过UDP协议传输的,高清数字电视节目是通过TCP协议传输的。因此还要进行UDP协议或者TCP协议的解析,UDP协议的解析较为简单,只需 去除固定长度的UDP头部,即可获得最终的MPEG传输流数据。TCP协议的解析稍为复杂,这是因为TCP协议的头部长度是可变的。
6)步骤206:对于高清电视节目,完成TCP协议段的解析后,获取到负载数据后,还需要进行最后一次协议解析,即RTSP协议解析。RTSP协议实际上是将信令和数据放在同一个逻辑信道中传输,即都通过TCP协议所建立的连接。也就是说,MPEG传输流是经过RTSP协议封装的。其中数据的其实4个字节都是“0x24000524”,也就是说所有开始四个字节的值不为“0x24000524”的数据包都是信令包,都可以直接丢弃。
7)至此,就获得到了完整的MPEG传输流数据,这时可以将数据直接发送给HLS服务器,或者发送给端用户机顶盒使用。
对于以上所述的第三个应用场景,武汉地铁的电信清流获取步骤如下:
1)首先在应用层检查是否能够接收到多播MPEG传输流,如果能够接收到数据流,则直接将数据流转发给HLS服务器,或者某个多播IP地址。
2)如果未能接收到多播MPEG传输流,如果不能够接收到数据流,则开始启动本地TS文件转发以形成清流发送给HLS服务器,或者某个多播IP地址。
3)在本地文件的转发过程中,不断在应用层检测是否有来自于网络的多播流出现,一旦出现立即停止本地文件发送,开始进行多播传输流的转发。
对于以上所述的第四个应用场景,某酒店的电信清流获取方案,是在应用层对获取到的原始YUV视频信号和原始音频信号进行编码封装处理,并最终输出MPEG传输流格式的输出,这种清流可以直接传输给HLS服务器或者机顶盒使用。
总之,与传统的数字电视头端清流获取方法相比,本发明提供了更多的选择,提供了更加灵活的清流获取技术;不需要额外的硬件设备支持,降低了用户的投入负担,同时可以应对各种网络环境状况;此外,很明显的一个优势就是,我们直接在网络协议栈的第二层抓包,这样不仅可以处理目前的传输流封装格式或协议,还可以通过增加插件类的形式对其进行扩展,以支持新的封装格式或协议。
图5给出了该发明的逻辑流程,在图5中,包括网络协议栈501和清流获取软件502,,以及端用户503。离线数据文件、HLS服务器也都在502中。清流获取软件从网络协议栈中获取数据,经过处理后,将数据发送给HLS服务器,最后发布给端用户503使用。从网络协议栈获取数据并进行处理的方法如下:
1)第一步,打开网络设备,并进行相应配置,以便进行数据的抓取。
2)第二步,检测是否能够获取到数据,若能够获取到数据,就进行相应的数据处理。如果在MAC层经过PPPoE封装,则需要进行PPPoE协议的解析。如果在传输层经过RTSP协议的封装,还要进行RTSP协议的解析,并最终获取有效负载。
3)第三步,获取到纯净的MPEG传输流后,直接将其转发给HLS服务器。
4)第四步,HLS服务器对MPEG传输流进行切片和分段处理,然后通过web服务器发布出去。
5)第五步,用户可以通过点播获得到实时传输的MPEG传输流,即数字电视节目清流。
其中的第四步,HLS服务器对MPEG传输流的处理方法如下:
1)第一步,对每一个频道启动一个线程,首先初始化接收soket和各种配置信息
2)第二步,检查是否有有效的MPEG传输流接收到
3)第三步,在接收到的MPEG传输流中寻找PMT和PAT信息,并重建PMT和PAT表。
4)第四步,初始化m3u8文件,包括文件命名以及文件标签的生成。
5)第五步,在接收到的MPEG传输流中,寻找完整的数据包,并将其放入ts文件中。
6)第六步,查看是否到达分片时间,如果到达,就在MPEG传输流中寻找I帧。
7)第七步,一旦发现I帧,就立即将从I帧开始的数据写入下一个ts文件中,并在I帧之前写入PMT和PAT表,同时还需要更新m3u8文件。
8)第八步,将超时或到期到一定门限的ts文件删除。
9)第八步,不断重复以上的第五步到第八步。
该方法的一个特点是:它可以保证的整个前端清流获取系统的服务质量,其它的相关应用都可以从该应用软件获取清流。服务功能是质量是通过以下措施实现:
1)使用一个电信提供的数字电视节目服务供应商专用的传输网络。大多数的视频和音频采用的时多播的方式来提高传输效率,减少了骨干网络拥塞的可能性。保证了网络传输的服务质量。
2)最终保证服务的整体质量被配置到生产网络环境,实现了服务质量整体的管理和调度机制。“端到端”的服务机制,质量包括错误控制(如前向纠错),的客户端状态云的实时监控和服务质量,及时调整服务方式,服务器使用流缓冲区可以解决传输不稳定带来的性能降级。
3)在上述两种方式传输的所有的清流数据,都可以通过多个技术策略进行实现,这使得他们的服务质量有保证。这些客户端代码和服务器端的计算结果,根据用相同的参考时钟的时间轴进行同步协同工作,以形成完整的网络视频的应用,所以服务功能的网络视频应用的质量来实现。
该方法所使用的集中技术策略以及他们之间的关系,如图6所示。1)直接转发服务和本地文件发送服务:这两种技术策略通常需要配合工作,当有多播数据流并且该多播数据流未经特殊的协议封装的前提下,可以直接对数据流进行转发;当网络发生异常,无多播数据流或者无法使用多播数据流时,可以发送本地文件,这样可以保证清流输出的连续性,保证了用户的数字电视节目的可用性,提高用户的满意度。2)数据链路层的抓包服务和直接转发服务:当网络上有多播数据流可用,并且多播数据流没有经过复杂协议的封装的前提下,可以直接通过转发服务获得头端清流;但是当多播数据流是经过复杂的网络协议封装过,那么就必须对这些网络协议解封装,就只能通过数据链路成的抓包服务来获取头端清流。3)编码器方案和其它三种服务的关系:当网络上传输的多播数据流或TCP数据流可以识别,并且没有紧急情况的时候,完全可以不采用编码器方案来解决,毕竟采用了编码器方案就意味着成本的增加。但是,编码器方案可以当作应急处理手段,当紧急情况发生时,或者当其他的服务不可使用时,就可以采用这种方式来对数字电视节目编码,并输出头端清流。3)四种清流获取技术和HLS服务器的关系:以上所述的四种清流获取策略都是为了向端用户提供数字电视直播清流,传统的直播方案都是通过流媒体方案来提供服务的,r而HLS服务器则是一种非流媒体服务器的电视节目直播解决方案。HLS服务器作为清流获取技术的重要配合组件,可以完美实现从头端清流到数字电视节目的直播。
上述四种清流获取技术互为补充,各有所长,最终使得客户的服务质量有保证。作为一个可执行的平台,与不同的应用集成和各种资源配合,其可靠性是有保障在以下几个方面:
1)平台所部署的环境都为企业级Linux服务器,具有较高的可靠性和稳定性。
2)平台所依赖的库均为业内知名库,其稳定性和可靠性具有普遍的认可度。
3)平台所采用的技术都是在其它场合使用较为可靠的技术方案。
4)平台具有在不同网络环境的适应性:基于数据链路层抓包的服务也可以替代直接转发服务来进行工作,在网络多播流不可用时,还可以通过发送本地文件的方式来保证清流的输出,这就使得整个系统维持较高的稳定性和可靠性。
该平台的可扩展性部署的便利显示如下:它提供的服务的集成接口便于新功能的添加,而不会影响其他人;只有内核平台上的客户端预装,易于部署;应用程序下载到缓冲区每次执行,以保证其及时更新;部署在云计算的形式可以应付平台的扩充在服务器;该平台在时间收集客户机和服务器的信息,以确保负载平衡,从而有利于用户的管理。

Claims (16)

1.一种用于现有数字电视行业的清流获取解决方案,以构建一个综合、健壮的清流获取平台,其特征在于:
1)该方案充分利用了现有的网络数据获取技术和电信运营商所提供的数字电视接入设备,同时具有提供灵活和健壮的数字电视服务的优点;
2)针对现有电信数字电视节目的传输格式和协议进行处理,可以很灵活方便的对传输流进行其它操作,为用户提供了灵活性和扩展性;
3)该方法充分考虑到各种不同的网络环境和用户的实际需求,利用电信数字电视节目进行直播给出了高效的解决方案;
4)可以适应各种数字电视信号源和网络环境,并能够以较低的成本灵活的在各种方案之间进行切换,在提供较好的扩展性的同时使得对终端用户的使用影响降到最低;
2.根据权利要求1所述的方案,其特征在于:充分利用现有网络数据获取技术和电信运营商所提供的数字电视接入设备,网络数据获取技术包括正常的通过网络协议栈在传输层获取应用数据的技术,以及在数据链路层获取MAC帧数据的技术。电信运营商所提供的数字电视接入设备包括光猫、机顶盒等接入设备。
3.根据权利要求1所述的灵活的整合各种数字电视数据资源和应用,其中的数字电视资源包括直播数据资源,以及一些订制的非直播数据资源,具体可以分为如下三种:
1)实时直播的通过UDP多播传输的标清电视节目资源;
2)实时直播的通过TCP单播传输的高清电视节目资源;
3)离线传输流文件格式的节目资源;
4.根据权利要求1所述的各种数字电视信号源和网络环境,其中所述的信号源包括:
1)以PPPoE协议在MAC层对数据帧进行封装后的数据帧;
2)以UDP协议传输的数据段有效载荷是经过RTP协议封装的;
3)通过TCP协议传输的数据段的有效载荷是经过RTSP协议封装的;
4)通过TCP协议传输的数据段的有效载荷是TS流数据和信令混合传输的;
5)以TS传输流的形式直接存储的多媒体文件数据;
5.根据权利要求1所述的技术方案包括以下几种:
1)在数字电视节目未经电信进行额外的封装协议进行处理的条件下,数字电视节目是以MPEG传输流的方式在网络上传输,在这种网络环境下,直接将电信清流从交换机转发到用户的媒体服务器上;
2)当电信的数字电视节目的MPEG传输流是经过其它协议进行封装后,再次使用网络协议进行传输的,无法直接使用网络协议栈对传输流进行解析得到节目数据,可以在以太网层进行抓包,然后根据不同的网络协议(UDP或TCP)逐层解析,并最终获得电视节目清流;
3)对于以上两种网络环境下,当研发能力不足或追求更简单的解决方案,可以采用硬件编码器方案来进行节目清流的提取;
4)当网络发生异常,或者其它原因造成无法获取节目流时,采用转发本地文件来生成清流的方式,避免了因数字电视节目的缺失而导致节目清流的不可用;
5)获得清流之后,为了实现直播可以采用基于HLS技术的直播技术方案。
6.根据权利要求1所述的网络环境包括多播流正常传输,以及当网络不可用而导致的无多播流可用的环境。
7.根据权利要求3所述的节目资源,其特征在于:
1)通过UDP传输的多播节目流封装包括PPPoE协议和PPP协议;
2)通过TCP传输的高清节目流封装包括PPPoE协议、PPP协议和RTSP协议,
8.根据权利要求5所述的第一种技术的方法,其特征在于:提供了较低的运行成本以及计算开销。
9.根据权利要求5所述的第二种技术,即采用数据链路层抓取MAC帧来获取标清数字电视节目清流的具体步骤如下:
1)将网卡设置为混杂模式,抓取符合条件的数据帧,即以太网帧头部的帧类型字段值符合下一层数据封装类型;
2)将获取到的以太网帧头部去除,获得有效载荷部分,即PPPoE帧;
3)根据PPPoE协议的规定,去除PPPoE头部,获取其有效载荷部分;
4)将上一步所获取到的数据帧,去除固定长度的PPP协议头部;
5)对数据包进行IP协议解析,根据IP协议包头部的尺寸和有效载荷偏移来判断数据包的有效性,若有效,则记录目的多播IP地址,并去除掉IP包头部;
6)对数据包进行UDP协议解析,根据目的IP地址和目的端口号判断是否是需要的数据段,若是,则去除UDP头部;
7)将所获得的传输流数据转发到HLS服务器处理以提供直播服务。
10.根据权利要求5所述的第二种技术,即采用数据链路层抓取MAC帧来获取高清数字电视节目清流的具体步骤如下:
1)将网卡设置为混杂模式,抓取符合条件的数据帧,即以太网帧头部的帧类型字段值符合下一层数据封装类型;
2)将获取到的以太网帧头部去除,获得有效载荷部分,即PPPoE帧;
3)根据PPPoE协议的规定,去除PPPoE头部,获取其有效载荷部分;
4)将上一步所获取到的数据帧,去除固定长度的PPP协议头部;
5)对数据包进行IP协议解析,根据IP协议包头部的尺寸和有效载荷偏移来判断数据包的有效性,若有效,则记录目的单播IP地址,并去除掉IP包头部;
6)对数据包进行TCP协议解析,根据目的IP地址和目的端口号判断是否是需要的数据段,若是,则去除掉TCP头部,获得TCP的有效载荷部分;
7)判断TCP协议段的有效载荷部分第1个字节是否为0x24,若是0x24则将头部4个字节去除;
8)将最终所获得的传输流数据转发到HLS服务器处理以提供直播服务。
11.根据权利要求5所述的第三种技术,其特征在于:以较为简便的方式实现了电信清流的生成,可以在一定程度上规避技术风险,加速部署进度。
12.根据权利要求5所述的第四种技术,具体步骤如下:
1)当能够从网络获取到电信节目多播流时,直接进行多播数据流的转发;
2)当网络出现异常或多播节目流不可用时,打开本地传输流文件,并按照时间戳进行发送;
3)当本地文件发送结束后,再次重复进行发送;
4)在文件的发送过程中,不断检测网络多播流的状态,一旦发现可以接收到多播流,则立即停止本地文件的发送,继续进行多播流的转发;
13.根据权利要求9和10所述的方法,其特征在于:采用了数据链路层数据帧抓取的方式获取原始的头端信号。是通过将运行抓取程序的服务器连接到交换机的监控端口来具体实现的。
14.根据权利12所述的方法,其特征是:不仅可以实现无间断的头端清流获取,还可以实现节目的插播。
15.根据权利15所述的节目插播实现方式如下:
1)可以在多个多播流之间进行切换,实现插播;
2)可以在多播流和多个本地传输流文件之间进行插播;
3)可以在多个本地传输文件之间进行插播;
4)可以在多播流和本地传输流文件之间进行周期性的插播。
16.根据权利要求5所述的解决方案,其特征在于:针对不同的传输流封装格式和封装协议,可以很容易进行扩展,从而支持其它的封装格式和封装协议。
CN201610242969.9A 2016-04-20 2016-04-20 清鹤数字电视头端获取电信清流的应用软件 Pending CN105872779A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610242969.9A CN105872779A (zh) 2016-04-20 2016-04-20 清鹤数字电视头端获取电信清流的应用软件

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610242969.9A CN105872779A (zh) 2016-04-20 2016-04-20 清鹤数字电视头端获取电信清流的应用软件

Publications (1)

Publication Number Publication Date
CN105872779A true CN105872779A (zh) 2016-08-17

Family

ID=56632441

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610242969.9A Pending CN105872779A (zh) 2016-04-20 2016-04-20 清鹤数字电视头端获取电信清流的应用软件

Country Status (1)

Country Link
CN (1) CN105872779A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107018444A (zh) * 2017-05-08 2017-08-04 无锡职业技术学院 一种基于PPPoE拨号接入的电信头端清流获取方法
CN108881114A (zh) * 2017-05-10 2018-11-23 上海交通大学 一种用于stl/sfn传输的rtp协议封装方法
WO2022116810A1 (zh) * 2020-12-01 2022-06-09 深圳Tcl数字技术有限公司 一种 alp 数据包的处理方法、存储介质及电子设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1728721A (zh) * 2004-07-27 2006-02-01 邓里文 一种用于因特网与以太网融合的适配方法
CN101218575A (zh) * 2004-11-29 2008-07-09 思科技术公司 用于将点对点协议移植到接入网络协议的技术
CN101826937A (zh) * 2010-03-18 2010-09-08 常熟理工学院 适用于下一代移动互联网的链路层差错控制系统及其方法
CN102271090A (zh) * 2011-09-06 2011-12-07 电子科技大学 基于传输层特征的流量分类方法及装置
CN102685586A (zh) * 2012-04-18 2012-09-19 上海广播电视信息网络有限公司 一种采用ip技术集成数字高清电视应用平台
CN103533428A (zh) * 2012-10-31 2014-01-22 Tcl集团股份有限公司 将智能终端网页视频推送到电视播放的方法及智能终端

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1728721A (zh) * 2004-07-27 2006-02-01 邓里文 一种用于因特网与以太网融合的适配方法
CN101218575A (zh) * 2004-11-29 2008-07-09 思科技术公司 用于将点对点协议移植到接入网络协议的技术
CN101826937A (zh) * 2010-03-18 2010-09-08 常熟理工学院 适用于下一代移动互联网的链路层差错控制系统及其方法
CN102271090A (zh) * 2011-09-06 2011-12-07 电子科技大学 基于传输层特征的流量分类方法及装置
CN102685586A (zh) * 2012-04-18 2012-09-19 上海广播电视信息网络有限公司 一种采用ip技术集成数字高清电视应用平台
CN103533428A (zh) * 2012-10-31 2014-01-22 Tcl集团股份有限公司 将智能终端网页视频推送到电视播放的方法及智能终端

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107018444A (zh) * 2017-05-08 2017-08-04 无锡职业技术学院 一种基于PPPoE拨号接入的电信头端清流获取方法
CN107018444B (zh) * 2017-05-08 2019-12-20 无锡职业技术学院 一种基于PPPoE拨号接入的电信头端清流获取方法
CN108881114A (zh) * 2017-05-10 2018-11-23 上海交通大学 一种用于stl/sfn传输的rtp协议封装方法
CN108881114B (zh) * 2017-05-10 2020-12-29 上海交通大学 一种用于stl/sfn传输的rtp协议封装方法
WO2022116810A1 (zh) * 2020-12-01 2022-06-09 深圳Tcl数字技术有限公司 一种 alp 数据包的处理方法、存储介质及电子设备

Similar Documents

Publication Publication Date Title
CN109788314A (zh) 一种视频流数据传输的方法和装置
CN108881815B (zh) 一种视频数据的传输方法和装置
CN108134916B (zh) 一种4k终端和4k终端的数据处理方法
CN108881927A (zh) 一种视频数据合成方法和装置
CN110166433B (zh) 一种视频数据获取的方法和系统
CN109194982A (zh) 一种传输大文件流的方法和装置
CN107959818B (zh) 一体化终端和一体化终端的数据处理方法
CN108124158B (zh) 多媒体终端及多媒体终端的数据处理方法
CN108307212B (zh) 一种文件点播方法和装置
WO2012094915A1 (zh) 流媒体前向纠错实现方法及系统
CN108966018B (zh) 基于视联网的视频播放方法、装置、电子设备及存储介质
CN105872779A (zh) 清鹤数字电视头端获取电信清流的应用软件
CN108574816B (zh) 一种视联网终端以及基于视联网终端的通信方法、装置
CN108632679B (zh) 一种多媒体数据传输的方法和一种视联网终端
CN110602542B (zh) 音视频同步的方法、音视频同步系统、设备及存储介质
CN100471265C (zh) 基于无源光网络的电视信号传输接入方法
CN112350792B (zh) 一种应急广播数据转发复用方法
CN110149305A (zh) 一种基于视联网的多方播放音视频的方法和中转服务器
WO2014067366A1 (zh) 一种组网方法及组网装置
CN108966003A (zh) 一种电视数据处理的方法和装置
CN111629277B (zh) 视频数据传输方法、装置及计算机可读存储介质
CN110086773B (zh) 一种音视频数据的处理方法和系统
CN108989831A (zh) 一种多码流的网络录制方法和装置
CN110324667B (zh) 一种新型视频流的播放方法和系统
CN110445761A (zh) 一种视频拉流方法及装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20160817

WD01 Invention patent application deemed withdrawn after publication