[go: up one dir, main page]

CN104509139B - 用于提供彩信服务的方法 - Google Patents

用于提供彩信服务的方法 Download PDF

Info

Publication number
CN104509139B
CN104509139B CN201280074975.8A CN201280074975A CN104509139B CN 104509139 B CN104509139 B CN 104509139B CN 201280074975 A CN201280074975 A CN 201280074975A CN 104509139 B CN104509139 B CN 104509139B
Authority
CN
China
Prior art keywords
user agent
video content
mms
option
repeater
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.)
Active
Application number
CN201280074975.8A
Other languages
English (en)
Other versions
CN104509139A (zh
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN104509139A publication Critical patent/CN104509139A/zh
Application granted granted Critical
Publication of CN104509139B publication Critical patent/CN104509139B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106Processing image signals
    • H04N13/161Encoding, multiplexing or demultiplexing different image signal components
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106Processing image signals
    • H04N13/139Format conversion, e.g. of frame-rate or size
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12Messaging; Mailboxes; Announcements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24Transfer of terminal data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2213/00Details of stereoscopic systems
    • H04N2213/007Aspects relating to detection of stereoscopic image format, e.g. for adaptation to the display format

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明涉及一种用于从服务器或中继器向多媒体网络中的用户代理提供彩信服务的方法(100),所述方法(100)包括:通过所述服务器或中继器确定(101)视频内容的视频内容特征;确定(103)所述用户代理的显示和/或解码能力;将所述视频内容的选项发信号通知(105)给所述用户代理;以及根据所述显示和/或解码能力并且根据通过所述用户代理从所述视频内容的发信号通知的选项中选择的选项(223)提供(107)所述视频内容。

Description

用于提供彩信服务的方法
技术领域
本发明涉及一种用于从服务器或中继器向多媒体网络中的用户代理提供彩信服务的方法,尤其涉及一种用于根据3GPP(第三移动通信标准化伙伴项目)彩信服务规范从MMS服务器/中继器B向MMS用户代理B提供彩信服务(MMS)的方法。
背景技术
深度感知是以三维形式(3D)感知世界以及物体的距离的视觉能力。立体3D视频指代用于通过向观看者的左眼和右眼单独地呈现场景的两个偏离图像而形成场景深度的错觉的技术。立体3D视频通过经由两个单独的摄像机捕获场景来传送场景的3D感知,这使得场景的物体投射到左侧图像和右侧图像中的不同位置。
通过经由两个以上单独的摄像机捕获场景,形成了多视图3D视频。根据选定的所捕获图像对,可以呈现场景的不同视角(视图)。多视图3D视频允许观看者交互地控制观看点。多视图3D视频可以被视作表示来自不同视角的同一场景的多个立体3D视频的多路复用。
从右侧视图到左侧视图的像素(物体)的位移被称作视差。视差的值限定感知深度。作为一个实例,当视差等于0且随后在图像平面(即,屏幕)上感知相关像素(物体)时,通过负视差感知相关像素(物体)以呈现给屏幕前方的观看者并且通过正视差感知相关像素(物体)以呈现给屏幕后方的观看者。
帧兼容封装格式在于对构成立体3D视频的两个视图进行亚采样并且将它们封装在一起,以便产生与2D帧基础设施兼容的视频信号。
在典型的操作模式中,与相同时间相关的两个立体帧被封装到具有相同2D兼容视图分辨率的空间布置中。所述空间封装布置通常使用并排格式或顶部-底部格式,其中下采样过程应用于每个视图:以此方式,每个视图呈现相对于对应的2D视图支持的空间分辨率减半的空间分辨率。
为了避免由帧兼容封装格式引入的清晰度的缺乏,有可能以全分辨率传输两个视图。最常见的格式是帧封装,其中左侧视图和右侧视图是按时序交错的。以此方式,两个视图具有与对应的帧兼容封装格式相比加倍的分辨率。
在帧兼容立体视频中,将立体对空间封装到单个帧中在编码器侧执行,并且因此获得的帧作为单个视图进行编码。由解码器产生的输出帧含有立体对的构成帧。编码器侧指示使用过的帧封装格式,方法是按照H.264/AVC标准中规定的来规定辅助增强信息(SEI)消息中的帧封装布置,并且在3D视频H.264/AVC经编码位流内传送所述帧封装布置。因此,关于帧封装格式的SEI消息在3D视频位流的解码过程期间进行提取和解析。解码器侧对帧进行常规解码,解封来自解码器的输出帧的两个构成帧,执行上采样以便恢复编码器侧的下采样过程并且使构成帧再现在3D显示器上。
在暂态交错中,视频在原始视频的双倍帧率下编码。每一对随后的图片构成立体对(左侧视图和右侧视图)。编码器侧按照H.264/AVC标准中规定的使用辅助增强信息(SEI)来指示使用过的时间交错格式并且在3D视频H.264/AVC经编码位流内传送所述交错格式。因此,关于帧封装格式的SEI消息在3D视频位流的解码过程期间进行提取和解析。时间交错立体视频的再现通常是在高帧率下执行的,其中主动式(快门式)眼镜用于遮盖每只眼睛处的不正确的视图。这需要眼镜与屏幕之间的精确同步。
多视图视频编码(MVC)是作为H.264/AVC标准的扩展(附件)规范化的。在MVC中,来自不同摄像机的视图被编码成单个位流,所述位流与单视图H.264/AVC向后兼容。视图中的一者被编码为“基础视图”。单视图H.264/AVC解码器可以解码并且输出不同配置文件下(例如,受限基线或渐进式高配置文件)的MVC位流的基础视图。MVC引入视图之间的视图间预测。MVC能够以向后兼容方式压缩立体视频而不会损害视图分辨率。如果服务器察觉到用户设备(UE)能力,那么它可以省略将非基础视图的视图分量发送到并不支持3D或并不具有足够位率来输送两个视图的装置中。
MIME是最初开发用于包含除电子邮件的纯文本主体之外的电子邮件消息中的内容的标准。MIME可以用于将单独的文件捆绑在一起。根据RFC 2557“集合文档的MIME封装”被称为“集合文档的MIME封装”的MIME的扩展允许向客户端指示出消息的所有部分都涉及彼此并且可以指代彼此。在图6中说明了如在RFC 2557中规定的MIME封装消息600的一个实例。
<Content-Type>向接收客户端指示出消息的单独部分是相关的并且可以指代彼此。对所有多部分消息常见的<boundary>向客户端指示出将分离消息的每个部分的字符串。在每个边界之间的是消息601、602、603本身。每个消息601、602、603还含有描述消息类型的<Content-Type>。第一消息601仅示出了来自HTML的摘录。第二消息602和第三消息603省略了图像的实际主体并且仅示出了与它们在多部分/相关消息中的聚集相关的信息。
HTML消息可以通过其规定的<Content-ID>(cid)或<Content-Location>指代包含的图像。这些是独特地识别消息的部分的两种方法,因此消息的其他部分可以指代它们。
了解到HTML是多部分/相关消息的一部分的读取实例HTML的客户端在查找网络之前首先在URL的消息部分内查找。
根据“用户代理配置文件版本2.0”的UAProf,Open Mobile AllianceTM是处理终端能力和偏好信息(CPI)的表示和端到端流动的开放移动联盟(OMA)规范。UAProf使用通过万维网联盟的(W3C's)复合能力/偏好配置文件(CC/PP)定义的框架来表示能力和偏好信息(CPI)并且是使用资源描述框架(RDF)模式和词汇定义的。规范还提供了应该如何使用无线会话协议(WSP)和超文本传送协议(HTTP)将信息传输到服务器的细节。UAProf在描述符的以下类别中进行划分:硬件平台、软件平台、浏览器用户代理、网络特征和无线应用协议(WAP)特征。终端的UAProf说明可以提供URL,其中可以在网络上检索CPI或者可以明确地提供它们。此第一选项被称作静态UAProf并且允许传输CPI所需的带宽显著减小。被称作动态UAProf的第二选项允许发送动态能力(例如,改变网络条件)。
服务器负责解析UAProf信息。此特征使动态UAProf在终端和服务器二者上的实施相当复杂。举例来说,在终端侧上,静态UAProf实施方案仅需要终端传输表示其能力的恒定字符串,或者更常见的是,服务器可以从中检索它们的URL。此类字符串在终端中可以是硬接线的。相比之下,动态UAProf将需要终端监控其能力的变化(例如,提供新的MIME类型支持的安装的新软件),并且生成、追踪来自参考配置文件的差值并且将所述差值发送给服务器。这解释了为何大部分制造商目前已经决定仅支持静态UAProf的原因。
RDF的使用允许针对基于CC/PP方案的扩展性机制,其提出新类型装置的演进和应用。3GPP PSS基础词汇是UAProf的扩展并且被定义为RDF模式。3GPP中的装置功能配置文件是遵循CC/PP构架的结构和CC/PP应用UAProf的RDF文档。属性用于规定装置能力和偏好。一组属性名称、容许值和语义构成CC/PP词汇,所述词汇是由RDF模式定义的。对于PSS,再使用UAProf词汇并且定义了额外的PSS专用词汇。属性的语法定义在词汇模式中,而且在一定程度上定义了语义。PSS装置能力配置文件是模式(UAProf和/或PSS专用模式)的一个实例。
根据“http://www.w3.org/TR/2005/REC-SMIL2-20050107/”的同步多媒体集成语言(SMIL)定义了目标在于描述交互多媒体演示的基于XML的语言。使用SMIL,可以描述多媒体演示的暂态行为,超链接与媒体对象的关联以及屏幕上的演示的布局。
SMIL被定义为一组标记模块,其界定了用于SMIL功能的某些区域的语义和XML语法。SMIL定义了10个模块:动画模块、内容控制模块、布局模块、链接模块、媒体对象模块、间位信息模块、结构模块、定时和同步模块、时间操纵模块以及过渡效果模块。
第三代移动通信标准化伙伴项目(3GPP)在3GPP TS 26.246中定义了3GPP SMIL语言配置文件:“透明的端到端的包交换流媒体服务(PSS);3GPP SMIL语言配置文件”,也称为“3GPP PSS SMIL语言配置文件”或仅仅称为“3GPP SMIL”。3GPP SMIL语言配置文件是根据“http://www.w3.org/TR/2005/REC-SMIL2-20050107/”基于SMIL 2.0基础配置文件的。
主要从订阅者以及服务供应商的视角来看,3GPP彩信服务(MMS)详细说明确保提供非实时彩信服务的一组要求。3GPP MMS允许针对不同类型的媒体的非实时传输,包含例如以下功能:每单个消息的多个媒体元素、消息元素的个体处理、每个消息元素的不同输送方法、协商不同的终端和网络彩信(MM)能力、通知和确认MM相关事件以及个性化MMS配置。
因此3GPP MMS允许整合了不同种类的媒体(例如,结合额外移动要求的文本、语音、图像或视频)的组成、储存、接入和输送的统一应用。3GPP MMS使用根据3GPP TS 26.246的3GPP SMIL语言配置文件:用于媒体同步和场景说明的“透明的端到端的包交换流媒体服务(PSS);3GPP SMIL语言配置文件”。图7示出了针对MMS消息的同步多媒体集成语言(SMIL)700的示意图。
SMIL消息主体703封闭在<smil></smil>标记中并且文档含有眉头701部分和主体703部分。眉头部分701含有应用于整个消息的信息。间位字段,例如“标题”和“作者”不是必选的。眉头部分701内的布局部分<layout></layout>详细说明消息中的所有幻灯片的总体布局。在图7中描绘的实例中,幻灯片将被显示为160像素宽和120像素高。图7的实例中的布局进一步分成两个较小区域:“图像”(或“视频”)和“文本”。主体部分703描述消息中的实际幻灯片。这些幻灯片通过<par>标记表示。此标记内的所有元素将会同时显示。用于每个幻灯片的<dur>属性是幻灯片展示中幻灯片的持续时间。在图7的实例中,每个幻灯片含有三个元素:用于在图像(或视频)区域中显示的一个元素,用于在文本区域中显示的一个元素,以及将在观看幻灯片时播放的音频元素。
根据3GPP TS 23.140的MMS网络架构800:“彩信服务(MMS);功能说明;2级”在图8中示出,其由向用户提供完整的MMS所需的所有元素组成。
如果MMS用户代理A 811和MMS用户代理B 831属于相同网络,那么呈现在图8中的系统A 801和系统B 803组分可以是相同的实体。MMS中继器/服务器815位于3GPP MMS架构800的核心处。除其他之外,MMS中继器/服务器815可以根据3GPP TS 23.140:“彩信服务(MMS);功能说明;2级”提供以下功能:接收和发送彩信(MM);到MMS用户代理811的MM通知;消息的临时存储817;终端能力的协商;应用数据的传送;基于用户配置文件信息将MMS个性化;基于用户配置文件或滤波信息的MM删除;媒体类型转化;以及媒体格式转化。
MMS用户代理(UA)811驻存在用户设备(UE)上或连接到UE的外部装置上。应用层功能向用户提供观看、构成和处理MM的能力(例如,提交、接收、删除MM)。
MMS增值服务(VAS)应用823为MMS用户提供增值服务。可以存在包含在MMS架构800中或连接到MMS架构800上的若干MMS VAS应用823。
MMS用户数据库819元素可以由一个或多个实体组成,所述实体含有用户相关信息,例如,订购和配置(例如,UAProf)。
在图8中描绘的MMS用户代理A 811发送彩信900,如图9中所说明,方法是将消息900提交到其归属MMS服务器/中继器A 815。多个媒体元素应被组合到复合的单个MM中,方法是使用如在IETF RFC 2046:“多用途网络邮件扩展(MIME)部分二:媒体类型”中定义的MIME多部分格式。单个MM元素的媒体类型应通过其适当的MIME类型识别,而媒体格式应通过其适当的MIME亚型指示。消息必须具有接收方的地址和MIME内容类型。可以设置用于消息的若干其他参数,包含所希望的消息到期时间和消息优先级。在接收消息900之后,接收方归属MMS服务器/中继器B 835将消息标识分配给消息900。MMS服务器/中继器B 835还可以储存消息900的复本,随后朝向接收方,即MMS用户代理B 831路由消息900。图9是用于从MMS用户代理A 811向MMS服务器/中继器A 815传输MMS的多部分MIME的一个实例。消息900包括视频内容901、音频内容903和文本内容905。
图10示出了MMS服务器/中继器B 1001与MMS用户代理B 1003之间的消息顺序图,MMS服务器/中继器B 1001对应于在图8中描绘的MMS服务器/中继器B 835,MMS用户代理B1003对应于根据技术规范3GPP TS 23.140的在图8中描绘的MMS用户代理B 831。在接收消息(例如,在图9中描绘的消息900)之后,接收方MMS服务器/中继器B 1001验证接收方(MMS用户代理B 1003)的配置文件(UAProf)并且向接收方MMS用户代理B 1003生成通知,即M-Notification.ind 1011。它还存储消息至少直至以下事件中的一者发生:达到了相关联的到期时间;输送了消息;接收方MMS用户代理B 1003请求消息被转发;所述消息被拒绝。当接收方MMS用户代理B 1003接收通知1011时,它使用通知1011中的消息参考(统一资源识别符,uri)以立即或在稍后的时间人工地或自动地拒绝或检索消息,如同由操作者配置和用户配置文件所确定的。MMS使用具有发信号通知的uri的HTTP GET请求消息1012进行检索。
在用于输送消息1012的请求内,接收方MMS用户代理B 1003可以指示其能力,例如,支持的媒体类型以及指示其UAProf的媒体格式的列表,用于接收方MMS服务器/中继器B1001。当接收到输送请求1012时,接收方MMS服务器/中继器B 1001使用关于接收方MMS用户代理B 1003的能力的信息以准备用于输送到接收方MMS用户代理B 1003的消息。此准备可以涉及不支持的媒体类型和媒体格式的删除或适配。MMS服务器/中继器B 1001也可以基于由储存在网络中的接收方装置(MMS用户代理B 1003)的UAProf信息指示的能力来执行内容适配。
在OMA-TS-MMS-CONF-V1_3-20110913-A,“MMS一致性文档”、Open MobileAllianceTM中,需要进行解决以便确保由不同制造商生产的终端之间的MMS功能性的互操作性的问题得到识别。根据文档,MMS用户代理1003应根据用于MMS用户代理能力协商的“用户代理配置文件版本2.0”,Open MobileAllianceTM支持UAProf。类似地,MMS服务器/中继器1001应支持用于MMS用户代理能力协商的UAProf。
互操作性是用户体验和服务的成功所必需的。当发送消息时,用户期望消息到达其目的地并且适当地呈现。否则的话,用户会停止使用服务,因为他们并不信任该服务。操作者要求互操作性,因为如果MM无法以合理地可接受的方式输送并且呈现给接收方的话,那么他们就不应该对MM收费。
目前,MMS服务器/中继器B 1001仅基于MMS接收方的UAProf信息执行内容适配,而无需根据图10中描绘的消息顺序咨询装置/用户。在此情况下,其中装置并不支持3D而是连接到外部3D显示器上的且因此能够正确地显示3D视频的情境不能够接收MMS的3D视频内容。这种情况是由于外部装置未包含在装置的UAProf信息中且MMS服务器/中继器B 1001总是执行内容适配并且将MMS 3D内容转化为2D内容的原因。类似地,相反的情况,例如,其中想要限制使用的带宽且因此仅下载MMS的2D版本的3D可用装置也是不可能的。
如上文所述,3D视频可以各种编码格式进行编码。帧兼容H.264/AVC和时间交错H.264/AVC使用传统的AVC文件格式,其中关于立体布置的信息携带在经编码3D视频位流内部的SEI消息中。因此,MMS服务器/中继器B在经编码位流上执行额外处理,即,解码位流以提取关于MMS的3D视频内容的信息,以便执行适当的内容适配。另一方面,多视图视频编码H.264/MVC使用AVC文件格式的扩展和元数据中的单独的信令,即,在经编码3D视频位流外部。因此,MMS服务器/中继器B并不需要执行额外的解码来提取信息并且按与H.264/AVC经编码3D视频内容的情况相同的方式,所以额外的复杂性减小。
在帧兼容或时间交错帧封装格式中使用3GPP MMS规范的当前版本输送3D视频确保UE将能够正确地解码位流,前提是所述UE具有对应的解码能力。然而,规范并不能确保UE正确地再现3D视频。举例来说,未察觉指示出位流表示帧兼容3D或时间交错3D的SEI消息的UE简单地将视频帧再现为具有两个并排(顶部底部)视图的一个2D帧或表示3D视频的两个单独的视图的连续的2D帧。因此这引起了降级的用户体验。目前,如上所述的UAProf或3GPP中的装置能力配置文件都无法提供关于装置的3D再现能力的信息,即,关于装置支持的帧封装格式的信息。因此,MMS服务器/中继器B并不具有全部信息来执行适当的内容适配以及确保装置互操作性。
发明内容
本发明的目标是改进网络输送3D视频中(尤其是根据3GPP MMS规范的网络中)的用户设备的互操作性。
此目标是通过独立权利要求的特征实现的。根据从属权利要求、说明书和附图,其他实施形式是显而易见的。
本发明是基于如下发现的:通过使用用于输送3GPP彩信服务的新方法,尤其是MMS服务器/中继器B与MMS用户代理B之间的新信令,互操作性得到了改进。此新方法是基于在执行内容适配之前通过MMS服务器/中继器B向MMS用户代理B提供MMS 3D内容的多个替代的选择或选项,例如,2D、3D,这两者等来确定的。由于此新方法,内容适配不会受限于UAProf信息,而且还会考虑到终端用户偏好。此外,通过应用关于包含在MMS中的3D视频内容的后解码器要求的新信令信息,互操作性得到了改进。信令信息是在元数据中发送的,也就是说,在3D视频经编码位流外部。由于额外信息,可以在MMS服务器/中继器B或接收方MMS用户代理B上引入用于解决3D MMS互操作性问题的多个彩信(MM)适配机构,由此改进用户设备与网络的互操作性。另外,UAProf的新词汇,即,PSS词汇的扩展允许MMS服务器/中继器B为3D可用装置的适当的后解码器能力正确地执行内容适配。
通过应用如将在下文中呈现的用于输送3GPP彩信服务的此类方法,互操作性得到了显著改进。
为了详细描述本发明,将使用以下术语、缩写和符号:
3D:三维,
MM:彩信,
MMS:彩信服务,
AVC:高级视频编码,
SEI:辅助增强信息,
MVC:多视图视频编码,
UE:用户设备,
MIME:根据RFC2046的多用途网络邮件扩展,
HTML:超文本标记语言,
UAProf:用户代理配置文件,
OMA:开放移动联盟,
CPI:能力和偏好信息,
W3C:万维网联盟,
CC/PP:复合能力/偏好配置文件,
RDF:资源描述框架,
WSP:无线会话协议,
HTTP:超文本传送协议,
WAP:无线应用协议,
URL:统一资源定位符,
PSS:包交换流媒体服务,
SMIL:同步多媒体集成语言,
UA:用户代理,
VAS:增值服务,
URI:统一资源识别符。
出于支持彩信的目的,应将术语“多媒体网络或网络”视为包含移动运营商的网络和可以存在于移动运营商的网络外部的任何功能,例如,固定的互联网和多媒体技术等,以及该功能提供的对于彩信的支持。
根据第一方面,本发明涉及一种用于从服务器或中继器向多媒体网络中的用户代理提供彩信服务(MMS)的方法,所述方法包括:通过服务器或中继器确定视频内容的视频内容特征;确定用户代理的显示和/或解码能力;发信号通知用户代理视频内容的选项;以及根据显示和/或解码能力并且根据经由用户代理选定的选项从视频内容的发信号通知的选项提供视频内容。
通过使用输送彩信服务的新方法,尤其是服务器或中继器之间的新的信令,用户代理互操作性得到了改进。
在根据第一方面的方法的第一可能实施形式中,多媒体网络是根据3GPP彩信服务规范的网络,例如,根据3GPP TS 22.140:“技术规范组服务和系统方面;彩信服务(MMS);1级(版本10)”;3GPP TS 22.140:“技术规范组组核心网络和终端;彩信服务(MMS);功能说明;2级(版本6)”或稍后译本和/或版本。
根据第一实施形式的新方法增强了根据3GPP MMS标准化的网络中的互操作性。
在照此根据第一方面或根据第一方面的第一实施形式的方法的第二可能的实施形式中,服务器或中继器是根据3GPP彩信服务规范的MMS服务器/中继器B,例如,根据3GPPTS 22.140:“技术规范组核心网络和终端;彩信服务(MMS);功能说明;2级(版本6)”或稍后译本和/或版本;其中用户代理是根据3GPP彩信服务规范的MMS用户代理B,例如,3GPP TS22.140:“技术规范组核心网络和终端;彩信服务(MMS);功能说明;2级(版本6)”或稍后译本和/或版本;并且其中视频内容是根据3GPP彩信服务规范的MMS视频内容。
所述新方法可以根据3GPP彩信服务规范应用于MMS服务器/中继器B和MMS用户代理B。在消息协议中仅需要较小的提高,而这对旧版终端是透明的。
在照此根据第一方面或根据第一方面的任何前述实施形式的方法的第三可能的实施形式中,到用户代理的视频内容的信令选项包括将视频内容的所有可能的选项发信号通知给用户代理。
因此用户可以在发信号通知给用户代理的可用的选项之间进行选择。
在照此根据第一方面或根据第一方面的任何前述实施形式的方法的第四可能的实施形式中,视频内容的选项包括以下项中的一者:2D、3D,这二者等等。
服务器或中继器可以执行3D视频文件的适配以将它编码为用于旧版装置的2D内容,或转码为用于支持根据第四实施形式的方法的装置支持的3D格式。
在照此根据第一方面或根据第一方面的任何前述实施形式的方法的第五可能的实施形式中,视频内容特征是基于外部元数据确定的。
当视频内容特征基于外部元数据确定时,不需要解码来获取视频内容特征。
在根据第一方面的第五实施形式的方法的第六可能的实施形式中,外部元数据包括指示3D视频位流的3D帧封装格式的呈现类型消息字段。
3D视频位流的3D帧封装格式可以通过使用可供使用的信令协议传送,仅需要不显著的变化。因此,实施是具有计算效率的。
在根据第一方面的第六实施形式的方法的第七可能的实施形式中,3D视频位流的3D帧封装格式包括以下格式中的一者:并排、顶部-底部、时间交错。
通过引入这些格式,服务器不需要解码视频内容来获得视频内容特征。
在照此根据第一方面或根据第一方面的任何前述实施形式的方法的第八可能的实施形式中,确定显示和/或解码能力包括基于用户代理的分析信息,尤其是基于根据开放移动联盟规范的UAProf信息确定显示和/或解码能力。
UAProf的新词汇,即,PSS词汇的扩展允许MMS服务器/中继器B正确地对3D可用装置的适当的后解码器能力执行内容适配。
在照此根据第一方面或根据第一方面的任何前述实施形式的方法的第九可能的实施形式中,到用户代理的视频内容的信令选项是从服务器或中继器中提供的,尤其是通过使用根据开放移动联盟规范的M-NOTIFICATION.IND消息,例如根据“彩信服务封装协议”。
增强型消息M-NOTIFICATION.IND可以根据3GPP彩信服务规范应用于MMS服务器/中继器B和MMS用户代理B。对于旧版终端,新信令选项是透明的,由此不会影响它们的操作模式。
在照此根据第一方面或根据第一方面的任何前述实施形式的方法的第十可能的实施形式中,所述方法包括:告知用户关于发信号通知给用户代理的视频内容的选项。
因此用户可以给出关于所希望选项的反馈。这改进了体验质量。
在根据第一方面的第十实施形式的方法的第十一可能的实施形式中,所述方法包括:从用户代理向服务器或中继器指示来自视频内容的选项的选定选项,尤其通过使用根据HTTP标准的GET REQUEST消息的标题字段,例如,根据IETF RFC 2616:“超文本传送协议--HTTP/1.1”或稍后版本。
新方法进一步与HTTP标准化兼容。
在根据第一方面的第十一实施形式的方法的第十二可能的实施形式中,所述方法包括:将用户代理重新定向到支持选定选项的终端,尤其通过使用根据HTTP标准的REDIRECT消息,例如,根据IETF RFC 2616:“超文本传送协议--HTTP/1.1”或稍后版本。
重新定向仅仅是针对根据第十二实施形式的装置执行的;重新定向对于旧版装置是透明的。因此,根据第十二实施形式的装置的互操作性得到了改进并且旧版装置的操作未受到影响。
在根据第一方面的任何实施形式的或照此根据第一方面的方法的第十三可能的实施形式中,其中所述方法进一步包括在提供视频内容之前:通过或经由用户代理向用户显示发信号通知的选项,并且通过用户代理由用户从发信号通知的选项中选择一个选项。
在根据第一方面的任何实施形式的或照此根据第一方面的方法的第十四可能的实施形式中,其中所述视频内容是3D视频。
根据第二方面,本发明涉及一种用户代理装置,尤其是根据3GPP彩信服务规范的MMS用户代理B装置,包括处理电路,其配置用于确定用户代理装置的显示和/或解码能力;接收由服务器或中继器发信号通知的视频内容的选项,尤其通过根据3GPP彩信服务规范的MMS服务器/中继器B装置;并且根据显示和/或解码能力以及根据根据用户偏好的视频内容的选项来提供视频内容。
应用用于输送3GPP彩信服务的新方法,尤其是在MMS服务器/中继器B与MMS用户代理B之间的新信令的用户代理装置可以改进它们在MMS网络中的互操作性。MMS 3D内容的多个替代的选择或选项,例如,2D、3D、这两者等在执行内容适配之前被提供到MMS用户代理B。内容适配未受UAProf信息的限制,而且还考虑到终端用户偏好。此外,通过应用关于包含在MMS中的3D视频内容的后解码器要求的新信令信息,互操作性得到了改进。
根据第三方面,本发明涉及一种服务器或中继器装置,尤其是根据3GPP彩信服务规范的MMS服务器/中继器B装置,包括处理电路,其配置用于确定视频内容特征;向用户代理装置,尤其是向根据3GPP彩信服务规范的MMS用户代理B装置发信号通知视频内容的选项;以及根据用户的偏好根据用户代理装置的显示和/或解码能力并且根据视频内容的选项提供视频内容。
服务器或中继器装置可以类似地改进它们在MMS网络中的互操作性,如同上述用户代理装置。
本文中所描述的方法可以实施为数字信号处理器(DSP)、微控制器或任何其他辅助处理器中的软件或实施为专用集成电路(ASIC)内的硬件电路。
本发明可以在数字电子电路中实施,或在计算机硬件、固件、软件或其组合中实施。
附图说明
将参考以下附图描述本发明的其他实施例,其中:
图1示出了根据一个实施形式的用于提供彩信服务的方法的示意图;
图2示出了根据一个实施形式的服务器或中继器装置与用户代理装置之间的消息协议200的示意图;
图3示出了根据一个实施形式的指示3D视频位流的3D帧封装格式的呈现类型消息字段的示意图;
图4示出了根据一个实施形式的包括呈现类型信息的MMS信令信息的示意图;
图5示出了根据一个实施形式的用户代理的分析信息的示意图;
图6示出了常规的MIME(多部分互联网邮件扩展)封装消息的示意图;
图7示出了常规的SMIL(同步多媒体集成语言)消息的示意图;
图8示出了根据技术规范3GPP TS 23.140的常规的MMS架构的框图;
图9示出了根据3GPP规范的常规彩信的框图;
图10示出了根据技术规范3GPP TS 23.140的MMS服务器/中继器B与MMS用户代理B之间的消息顺序图。
具体实施方式
图1示出了根据一个实施形式的用于提供彩信服务的方法100的示意图。
方法100从服务器或中继器向多媒体网络中的用户代理提供彩信服务。方法100包括通过服务器或中继器确定101视频内容特征。方法100包括确定103用户代理的显示和/或解码能力。方法100包括将视频内容的选项发信号通知105给用户代理。方法100包括根据用户的偏好根据显示和/或解码能力并且根据视频内容的选项提供107视频内容。
服务器或中继器可以对应于如参考图8描述的MMS服务器/中继器B835。用户代理可以对应于如参考图8描述的MMS用户代理B 831。向用户代理发信号通知105视频内容的选项可以通过使用如参考图2说明的M-Notification-ind消息211来执行,其中如图2中所说明的M-Notification-ind消息211通过包括选项的额外的选项字段扩展。服务器或中继器可以对应于在图2中描绘的MMS服务器/中继器B 201,并且用户代理可以对应于在图2中描绘的MMS用户代理B 203,其中MMS服务器/中继器B 201和MMS用户代理B 203用于提供并且接收此额外的选项字段。用户可以根据用户代理的显示和/或解码能力在视频内容的发信号通知的可用选项之间进行选择。根据用户的偏好,视频内容将被输送。
图2示出了根据一个实施形式的服务器或中继器装置201与用户代理装置203之间的消息协议200的示意图。基础消息协议对应于如参考图10描述的消息协议。也就是说,无需额外选项字段的M-Notification.ind消息211对应于图10中描绘的M-Notification.ind消息1011,无需额外选项字段的HTTP Get.req消息212对应于图10中描绘的HTTP Get.req消息1012,无需选定的URI字段的M-retrieve.conf消息215对应于在图10中描绘的M-retrieve.conf消息1015,并且无需选定的URI字段且无需额外的选项字段的M-NotifyResp.ind消息216对应于在图10中描绘的M-NotifyResp.ind消息1016。
如图2中所描绘的用于输送3GPP彩信服务的新方法200引入额外的步骤,其中有可能选择MMS内容编码的不同选项221的信息在M-Notification.ind消息211中通过MMS服务器/中继器B 201提供给MMS用户代理B 203。用于M-Notification.ind PDU 211的新选项标题字段如下文中所定义。所述过程在图2中呈现。首先,MMS服务器/中继器B 201向MMS用户代理B 203发布具有3D视频的URI的通知211。此外,提供M-Notification.ind PDU 211中的新“选项”字段221。通过该字段通知支持的终端:该终端可以决定并且指示它是否需要3D或2D内容或这两种版本或不同的支持3D的解码/显示格式。“选项”字段221是被旧版MMS用户代理忽略的并且内容是使用以标准方式提供的URI通过旧版终端提取的。
支持新标题字段的MMS用户代理向MMS服务器/中继器B 201发布指示用户所选择的(意味着根据用户的偏好)编码方法的具有新“选项”标题字段221的GET请求212。通过MMS用户代理B 203发布的GET请求212中的“选项”字段可以根据RFC 2616(http://www.ietf.org/rfc/rfc2616.txt)被规定为新的请求标题字段。在支持的终端包含GET请求212中的新“选项”标题字段的情况下,随后MMS服务器/中继器B 201相应地作用并且与具有指示新的selected_uri的重新定向消息213的MMS用户代理B 203相对应。此后,MMS用户代理B发布具有新selected_uri的Get.req消息214。在MMS用户代理B 203经重新定向到selected_uri之后,它开始以标准方式但是通过使用selected_uri和选择的选项字段223提取MMS内容。
图3示出了根据一个实施形式的指示3D视频位流的3D帧封装格式的呈现类型消息字段300的示意图。
在MMS规范中,帧封装格式是在辅助增强信息(SEI)消息中指示的。因此,MMS服务器/中继器必须执行额外处理以获取接收到的内容是3D内容的信息。额外处理需要解码步骤。在图3中描绘的实施形式中,提供关于MIME多部分格式的3D视频的后解码器信令信息。指示3D视频位流的3D帧封装格式的呈现类型消息字段包括不同的可能呈现类型,即,类型“并排”301、“顶部-底部”302、“时间交错”303等的信令信息。
图4示出了根据一个实施形式的包括呈现类型信息的MMS信令信息400的示意图。
MMS包括如图4中说明的新定义的“呈现类型”信息。识别新信令信息的MMS服务器/中继器能够识别3D内容和其编码形式而无需解码位流。MMS信令信息400可以对应于如图9中所描绘的MMS信令信息,但是在图9中描绘的视频内容901通过额外的呈现类型信息401增强,所述额外的呈现类型信息在此处是类型“并排”的。当然,此额外的呈现类型信息401可以是在图3中所说明的呈现类型消息字段300中定义的任何其他类型,例如,顶部-底部、时间交错等。
图5示出了根据一个实施形式的用户代理的分析信息500的示意图。引入了指示装置的再现能力的UAProf中的新词汇。图5示出了此类新词汇的示例性定义。
新词汇提供了名称为“3DRenderingSupport”的新属性。其法定值是“并排”、“顶部-底部”和“时间交错”。
基于在UAProf中指示的或在接收方MMS用户代理B和MMS服务器/中继器B的能力协商期间获取的后解码器信令和接收方能力,MMS服务器/中继器B执行3D视频文件的适配以将它编码为用于旧版装置的2D内容,或转码到提供UAProf中的新词汇的支持3D格式的装置中。
服务器/中继器B和MMS服务器/中继器B可以对应于在图8中描绘的装置835、831或当被增强以提供UAProf中的新词汇时对应于在图10中描绘的装置1001和1003。
根据上文,提供关于录音媒体的各种方法、系统、计算机程序以及类似者对于所属领域的技术人员而言是显而易见的。
本发明还支持包含计算机可执行代码或者计算机可执行指令的计算机程序产品,当执行时所述计算机可执行代码或所述计算机可执行指令引起至少一个计算机执行本文中所描述的执行和计算步骤。
本发明还支持用于执行本文中所描述的执行和计算步骤的系统。
根据上述教示,许多替代方式、修改和变型对于所属领域的技术人员而言将是显而易见的。当然,所属领域的技术人员容易认识到,除了本文中所描述的那些应用之外,存在许多本发明的应用。尽管已参考一个或多个特定实施例描述本发明,但是所属领域的技术人员将认识到,在不脱离本发明的精神和范围的情况下可以对本发明作出许多改变。因此,应理解,在所附权利要求书及其等效物的范围内,可以以不同于如本文中所具体描述的方式实践本发明。
本发明的实施例可以尤其在UMTS(通用移动电信系统)和LTE(长期演进)网络中实施。

Claims (14)

1.一种用于从服务器或中继器(201)向多媒体网络中的用户代理(203)提供彩信服务(MMS)的方法(100、200),所述方法(100、200)包括:
通过所述服务器或中继器(201)确定(101)视频内容的视频内容特征;
将所述视频内容的选项(221)发信号通知(105)给所述用户代理(203),其中所述视频内容的所述发信号通知的选项(221)包括以下项中的一者:2D、3D、或2D和3D;以及
根据显示和/或解码能力并且根据通过所述用户代理从所述视频内容的发信号通知的选项(221)中选择的选项(223)提供(107)所述视频内容。
2.根据权利要求1所述的方法(100、200),其中所述多媒体网络是根据3GPP彩信服务规范的网络(803)。
3.根据权利要求1或权利要求2所述的方法(100、200),其中所述服务器或中继器(201)是根据3GPP彩信服务规范的MMS服务器/中继器B;其中所述用户代理(203)是根据所述3GPP彩信服务规范的MMS用户代理B;并且其中所述视频内容是根据所述3GPP彩信服务规范的MMS视频内容。
4.根据前述权利要求1或2所述的方法(100、200),其中将视频内容的选项(221)发信号通知给所述用户代理(203)包括将所述视频内容的所有可能的选项发信号通知给所述用户代理(203)。
5.根据前述权利要求1或2所述的方法(100、200),其中所述视频内容特征是基于外部元数据确定的。
6.根据权利要求5所述的方法(100、200),其中所述视频内容是3D视频并且所述外部元数据包括指示所述3D视频位流的3D帧封装格式的呈现类型消息字段(300)。
7.根据权利要求6所述的方法(100、200),其中所述3D视频位流的所述3D帧封装格式包括以下格式中的一者:并排(301)、顶部-底部(302)、时间交错(303)。
8.根据前述权利要求1,2,6和7中的任一项所述的方法(100、200),其中所述方法进一步包括:
确定(103)所述用户代理(203)的显示和/或解码能力;并且其中所述确定(103)显示和/或解码能力包括基于所述用户代理(203)的分析信息,具体是基于根据开放移动联盟规范的UAProf信息确定所述显示和/或解码能力。
9.根据前述权利要求1,2,6和7中的任一项所述的方法(100、200),其中发信号通知给所述用户代理(203)的所述视频内容的选项是由所述服务器或中继器(201)提供,具体是通过使用根据开放移动联盟规范的M-NOTIFICATION.IND消息(211)提供的。
10.根据前述权利要求1,2,6和7中的任一项所述的方法(100、200),其包括:告知所述用户发信号通知给所述用户代理(203)的所述视频内容的所述选项(221)。
11.根据权利要求10所述的方法(100、200),其包括:由所述用户代理(203)向所述服务器或中继器(201)指示从所述视频内容的发信号通知的选项(221)中选择的选项(223),具体是通过使用根据HTTP标准化的GET REQUEST消息(212)的标题字段来指示。
12.根据权利要求11所述的方法(100、200),其包括:将所述用户代理(203)重新定向到支持所述选择的选项(223)的终端,具体是通过使用根据HTTP标准的REDIRECT消息(213)来重定向。
13.一种用户代理装置(203),具体是根据3GPP彩信服务规范的MMS用户代理B装置,其包括处理电路(203a),所述处理电路配置用于
确定(103)所述用户代理装置(203)的显示和/或解码能力;
接收通过服务器或中继器(201),具体通过根据3GPP彩信服务规范的MMS服务器/中继器B装置发信号通知的视频内容的选项(221);并且
根据所述显示和/或解码能力并且根据用户的偏好的所述视频内容的所述选项(221)提供(107)所述视频内容,其中所述视频内容的所述发信号通知的选项(221)包括以下项中的一者:2D、3D、或2D和3D。
14.一种服务器或中继器装置(201),具体是根据3GPP彩信服务规范的MMS服务器/中继器B装置,其包括处理电路(201a),所述处理电路配置用于
将视频内容的选项(221)发信号通知(105)给用户代理装置(203),具体是根据3GPP彩信服务规范的MMS用户代理B装置,其中所述视频内容的所述发信号通知的选项(221)包括以下项中的一者:2D、3D、或2D和3D;并且
根据所述用户代理装置(203)的显示和/或解码能力并且根据通过所述用户代理装置(203)从所述视频内容的发信号通知的选项(221)中选择的选项提供(107)所述视频内容。
CN201280074975.8A 2012-08-06 2012-08-06 用于提供彩信服务的方法 Active CN104509139B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2012/065374 WO2014023330A1 (en) 2012-08-06 2012-08-06 Method for providing a multimedia message service

Publications (2)

Publication Number Publication Date
CN104509139A CN104509139A (zh) 2015-04-08
CN104509139B true CN104509139B (zh) 2018-07-20

Family

ID=46724368

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201280074975.8A Active CN104509139B (zh) 2012-08-06 2012-08-06 用于提供彩信服务的方法

Country Status (4)

Country Link
US (1) US10116921B2 (zh)
EP (1) EP2859742B1 (zh)
CN (1) CN104509139B (zh)
WO (1) WO2014023330A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3017605B1 (en) 2013-07-03 2022-12-07 Koninklijke KPN N.V. Streaming of segmented content
TWI676389B (zh) * 2013-07-15 2019-11-01 美商內數位Vc專利控股股份有限公司 至少一種色彩轉換之編碼方法和編碼器、解碼器、顯示裝置、編碼視訊訊號、電腦程式製品及處理器可讀式媒體
WO2015113608A1 (en) * 2014-01-30 2015-08-06 Huawei Technologies Co., Ltd. Method for recognizing objects
EP3105903B1 (en) 2014-02-13 2019-08-07 Koninklijke KPN N.V. Requesting multiple chunks from a network node on the basis of a single request message
US10523723B2 (en) 2014-06-06 2019-12-31 Koninklijke Kpn N.V. Method, system and various components of such a system for selecting a chunk identifier
EP3371992B1 (en) * 2015-11-02 2021-10-06 Telefonaktiebolaget LM Ericsson (PUBL) Handling device capabilities
CN107197395B (zh) * 2017-05-05 2019-08-20 中广热点云科技有限公司 一种为视频终端提供增强服务的方法
US10736070B2 (en) * 2017-07-26 2020-08-04 Blackberry Limited Method and system for use of a relay user equipment in an internet protocol multimedia subsystem
FR3099862B1 (fr) * 2019-08-08 2022-05-20 Airbus Ds Slc Dispositif d’interopérabilité pour interconnecter plusieurs réseaux de communication, système et procédé associés
CN112929209B (zh) * 2021-01-25 2023-05-16 重庆华联众智科技有限公司 一种基于代理模型按需定制改善网络服务质量的方法
WO2025029626A1 (en) * 2023-07-28 2025-02-06 Qualcomm Incorporated Backward-compatible 3d messaging

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002043414A2 (en) * 2000-11-22 2002-05-30 Nokia Corporation Multimedia messaging services
CN1711786A (zh) * 2002-11-14 2005-12-21 诺基亚公司 多媒体消息接发服务中媒体内容的流式传输
CN102365869A (zh) * 2009-01-26 2012-02-29 汤姆森特许公司 用于视频编码的帧打包

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7631037B2 (en) 2001-02-08 2009-12-08 Nokia Corporation Data transmission
DE10351961B4 (de) * 2003-11-07 2008-01-10 Siemens Ag Verfahren zum Übertragen von verschlüsselten Nutzdatenobjekten
CA2461638A1 (en) * 2004-03-22 2005-09-22 Impatica Inc. Mobile multimedia delivery
US20060031369A1 (en) * 2004-07-01 2006-02-09 Marc Caron Method, system, and edge multimedia messaging service (MMS) relay/server for multi-staged MMS
US8849950B2 (en) * 2011-04-07 2014-09-30 Qualcomm Incorporated Network streaming of video data using byte range requests
US9351028B2 (en) * 2011-07-14 2016-05-24 Qualcomm Incorporated Wireless 3D streaming server
US9357272B2 (en) * 2012-08-03 2016-05-31 Intel Corporation Device orientation capability exchange signaling and server adaptation of multimedia content in response to device orientation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002043414A2 (en) * 2000-11-22 2002-05-30 Nokia Corporation Multimedia messaging services
CN1711786A (zh) * 2002-11-14 2005-12-21 诺基亚公司 多媒体消息接发服务中媒体内容的流式传输
CN102365869A (zh) * 2009-01-26 2012-02-29 汤姆森特许公司 用于视频编码的帧打包

Also Published As

Publication number Publication date
CN104509139A (zh) 2015-04-08
US20150201179A1 (en) 2015-07-16
WO2014023330A1 (en) 2014-02-13
US10116921B2 (en) 2018-10-30
EP2859742B1 (en) 2020-04-29
EP2859742A1 (en) 2015-04-15

Similar Documents

Publication Publication Date Title
CN104509139B (zh) 用于提供彩信服务的方法
AU2023200083B2 (en) Signaling important video information in network video streaming using mime type parameters
CN103493499B (zh) 提供使用表示的流媒体内容的装置及方法
KR101594351B1 (ko) 다수의 소스들로부터의 멀티미디어 데이터의 스트리밍
EP2597884A2 (en) Apparatus and method for providing streaming contents
CN101300810A (zh) 用于将svg内容嵌入进iso基本媒体文件格式以便渐进地下载或流式传输富媒体内容的方法
JP5121935B2 (ja) LASeRベースの端末のためのステレオスコピック3D映像コンテンツの提供装置及び方法
US10887645B2 (en) Processing media data using file tracks for web content
CN110832872B (zh) 使用用于文件格式方框的通用描述符处理媒体数据
CN106134146A (zh) 处理连续的多周期内容
EP3504878B1 (en) System level signaling of sei tracks for media data streaming
CN106063279A (zh) 用于播放使用dash视频的位深表现方法
CN110832878B (zh) 增强区域取向包封及视区独立高效视频译码媒体配置文件
CN101997841A (zh) 富媒体场景的生成方法、系统和动态场景生成装置
US20110265138A1 (en) Method and apparatus for transmitting and receiving service discovery information in multimedia transmission system and file structure for the same

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant