没有合适的资源?快使用搜索试试~ 我知道了~
首页OC-SP-AMD-I01-130502:开放有线电视测量规范
OC-SP-AMD-I01-130502:开放有线电视测量规范
需积分: 5 0 下载量 47 浏览量
更新于2024-07-09
收藏 1.58MB PDF 举报
OC-SP-AMD-I01-130502是Cable Television Laboratories, Inc. (Cable Labs) 发布的一份开放电缆(OpenCable)规格文档,旨在推动有线电视行业的技术创新和客户利益。这份标准专注于受众测量(Audience Measurement),即对观众观看行为数据的收集、分析和应用,以帮助服务提供商更好地理解用户喜好,优化内容提供,并进行市场策略调整。 该文档明确了它是一个合作项目的成果,反映了行业内的共同努力。然而,值得注意的是,由于可能引用了Cable Labs并不拥有或控制的其他技术文档,使用这份规范可能需要获取第三方知识产权许可,特别是对于文档中提及的相关技术。因此,在基于此文档设计、制造、分发产品,或提供相关服务时,必须确保对这些技术的合规使用。 Cable Labs及其成员公司不对因使用或依赖本规范及其中所引用的任何文档而产生的任何责任承担任何保证,无论是明示的还是暗示的,包括但不限于准确性、完整性或不侵犯他人权利的保证。文档提供“按现状”基础,意味着它既没有经过充分的校验,也没有进行修改,以适应特定的应用环境。 OC-SP-AMD-I01-130502规范关注的核心是通过标准化的受众测量方法,帮助有线电视行业提升服务质量,优化用户体验,同时提醒读者在实施过程中要重视知识产权法律问题,确保业务操作的合法性。这份文档对于有线电视运营商、技术提供商和服务供应商来说,是一份重要的参考和技术指南。
资源详情
资源推荐
![](https://csdnimg.cn/release/download_crawler_static/36980073/bg10.jpg)
OC-SP-AMD-I01-130502 OpenCable™ Specifications
8 CableLabs
05/02/13
There are three fundamental entities involved:
• Affiliates – Service providers may send a variety of data products to any number of affiliates, including
content owners, audience measurement firms, research firms, agencies/advertisers, and programmers.
Ideally, the affiliates consume data in Audience Measurement Interface (AMI) format, accessing it through
the enterprise-level interfaces.
• Data Collection and Processing Platforms – The essential role is to store, aggregate, and process low-
level event streams from Media Delivery Platforms. This role is the responsibility of a service provider,
although agents of a service provider may implement some of these logical functions. Ideally, these
platforms collect Media Event Data Model (MEDM) data elements, process it, and deliver Media
Measurement Data Model (MMDM) data elements.
• Media Delivery Platforms – A device or system that supports navigation/discovery, processing, or
presentation of media to viewers, including traditional STBs, DVRs, VOD servers, and emerging platforms
such as IP streaming servers servicing video gateways, PCs, mobile, and tablet devices. Media Delivery
Platforms also include interactive environments, such as EBIF, tru2way, and other application platforms.
Ideally, these platforms generate MEDM data elements.
These entities process data in well-defined ways and share information through specified interfaces. The four areas
of specification are:
• Enterprise-level Measurement Interfaces – These are formats and interfaces that serve to provide access
to data at the enterprise level, between service providers and the affiliates of their choosing. Data access
may be via a data representation, encoded format, or other means.
• Processing Rules – This is a set of rules governing how media event data is processed to support
enterprise-level interfaces and data products. Requirements on data collection and processing platforms in
support of these rules, such as data retention, auditing, security, and privacy, may be included here.
• Media Event Data Model (MEDM) – Media Delivery Platforms generate low-level events that should
conform to a well-defined MEDM in order to support cross-platform comparability. Media Delivery
Platforms may evolve to support the MEDM directly, or “adapters” may transform existing proprietary
formats into these well-known models. Media Event Data Models will be developed for linear, non-linear,
and interactive service delivery models. Included in these specifications are “cap and edit” rules that define
some level of business logic applied to the low-level events.
• Media Measurement Data Model (MMDM) – Media events are collected, filtered, enriched,
transformed, and correlated, resulting in data ready for making measurement calculations. This processing
is unique to each service provider, and the details relating to the internal collection and processing of the
media events into measurement data are outside the scope of this document. However, consistent
definitions of measurements are necessary, as this data is foundational to deriving data products including
metrics.
• Audience Measurement Interface (AMI) – Further aggregation and processing of measurements results
in metrics that can be delivered to affiliate consumers and can be used to determine effectiveness and
revenue models.
• Platform Interfaces – Platform Interface specifications, including transport protocol and data format
definitions, will be developed for many Media Delivery Platforms. These interfaces can ensure data quality
and comparability, and all implementations should conform to the MEDM. Conformance can lead to cost-
effective product implementations and integrations. For those Media Delivery Platforms that do not
implement a well-defined interface, a proprietary adapter should be developed to define conformance with
the MEDM. An adapter defines how a data format maps to the MEDM. In practice, a Data Collection and
Processing Platform may physically store data in an implementation-specific way. The Data Collection and
Processing Platform should conform to the MEDM so Processing Rules can result in deterministic results
independent of the source or format of the data collected via the Platform Interfaces.
![](https://csdnimg.cn/release/download_crawler_static/36980073/bg11.jpg)
Audience Measurement Data Specification OC-SP-AMD-I01-130502
05/02/13 CableLabs
9
5.2 MEDM and MMDM, within Audience Measurement Context
The following diagram shows another perspective on the data models. To summarize, traversing the figure from left
to right, devices generate media events (MEDM). These events are processed by the service provider systems (MSO
Event Processing) resulting in measurement data (MMDM). Further processing of the measurement data results in
metrics data (AMI) that is made available via the enterprise-level interfaces, to affiliates and other users in business
decision making (consumers of AM Products).
Figure 4 - AM Data Context
![](https://csdnimg.cn/release/download_crawler_static/36980073/bg12.jpg)
OC-SP-AMD-I01-130502 OpenCable™ Specifications
10 CableLabs
05/02/13
6 EVENTS - MEDIA EVENT DATA MODEL (MEDM)
The Media Event Data Model (MEDM) defines a model for events related to the delivery, processing, or
presentation of media to viewers, such as tuning to a broadcast channel, selecting and controlling an on-demand
asset, or recording to a DVR. The data model is generalized to express any linear and non-linear service, including
but not limited to DVR and home networking, mobile, and online content delivery.
The Media Event Data Model is defined by contextual, conceptual, and logical models describing increasing levels
of detail of the model. The conceptual and logical models are described by a UML entity-relationship diagram with
accompanying narrative description of the entities. The logical model is presented in a subsequent section.
Many encoding formats and transport protocols may be defined that conform to the model. Differing circumstances
will dictate optimal interfaces for gathering or sharing measurement data. For instance, an enterprise-level interface
that exports huge volumes of data from a service provider to an affiliate can look very different from the mechanism
used to log and transmit events from an embedded device on a constrained legacy cable network. Regardless of the
encoded formats of the data, they should conform to this data model to support cross-platform comparability.
6.1 Conceptual Data Model
Figure 5 is the conceptual level entity-relationship diagram for media events. No attributes are presented in this
diagram; the discussion below is of entities only. Full discussion of these entities and associated attributes is
included in the detailed logical data model defined below.
The base entity is the MediaEvent. The various event entities all extend the base MediaEvent entity. For clarity,
MediaEvent is not shown in the diagram. In practice, a stream of MediaEvents is generated by a device that delivers
processes or presents media. MediaEvents are then collected by a service provider or designated agent. Data coming
from a specific device, such as a set-top box or VOD server, may not fully populate the data model, and some
attributes may be sourced from service-provider Reference or Enrichment data. For instance, a set-top box interface
may not include any information about a viewer. The association of data from a set-top box and the viewer
information may be made by the service provider after the data is collected from the set-top box or when exposing
data via the Media Event Data Model.
Figure 5 - MEDM Conceptual Data Model
![](https://csdnimg.cn/release/download_crawler_static/36980073/bg13.jpg)
Audience Measurement Data Specification OC-SP-AMD-I01-130502
05/02/13 CableLabs
11
6.1.1 MEDM Entities
Table 1 - MEDM Entity Descriptions and Relationships
MEDM Entity Entity Description Entity Relationships
Media Viewer
The MediaViewer entity represents a viewer of media
content. Media viewers may be known to the service
provider, in which case an associated Media Viewer
Type is referenced.
A MediaViewer belongs to a single
household. The MediaViewer has
many media events associated with
it.
Media Viewer
Type
The MediaViewerType entity provides descriptive
information about known Media Viewers.
The MediaViewerType may
represent either an entire
household or a specific viewer in a
household and has MediaViewers
assigned to it.
Session Start
Event
The SessionStartEvent is a specialization of MediaEvent
and inherits all of its attributes.
Session is a general term indicating a linear TV channel
or a non-linear video segment.
Session start is a generalized representation of the
initiation of media processing, which may indicate
selection of a linear broadcast channel, or the start of a
non-linear session. Non-linear sessions may be
supported by many environments, such as traditional
cable VOD, Digital Video Recorder (DVR), Web-based
video playout, home networked streaming, or any other
non-broadcast media processing environment. Every
SessionStartEvent SHALL be paired with a
SessionEndEvent, grouping all intermediate events into
a logical session sequence.
An instance of a SessionStartEvent
is associated with a MediaViewer
whose actions generated the event.
It is also associated with the single
MediaDevice that actually
generated the event.
Session End Event
SessionEndEvent is a specialization of MediaEvent that
represents the termination of media processing. Session
termination may represent tuning away from a linear
channel, the end of a DVR recording, or the termination
of a non-linear session.
An instance of a SessionEndEvent
is associated with a MediaViewer
whose actions generated the event.
Is also associated with the single
MediaDevice that actually
generated the event.
Presentation State
Event
PresentationStateEvent is a specialization of
MediaEvent that represents a change in the presentation
attributes of a media presentation. Examples include a
switch from the main display to picture-in-picture (PiP)
on a TV, scaling the video window on a TV, muting
audio, bringing an active DVR recording to the
foreground, or another such change.
PresentationStateEvents SHALL be generated with
every SessionStartEvent.
An instance of a
PresentationStateEvent is
associated with a MediaViewer
whose actions generated the event.
Is also associated with the single
MediaDevice that actually
generated the event.
![](https://csdnimg.cn/release/download_crawler_static/36980073/bg14.jpg)
OC-SP-AMD-I01-130502 OpenCable™ Specifications
12 CableLabs
05/02/13
MEDM Entity Entity Description Entity Relationships
Segment Event
SegmentEvent is a specialization of MediaEvent that
represents the processing of a logical segment of
content. For example, as the boundaries between
entertainment and advertising segments are crossed,
SegmentEvents MAY be generated to indicate these
boundary crossings. The MediaOffset attribute found in
all MediaEvents between SegmentEvents are offsets
within the ContentID identified by the SegmentEvent.
Boundaries may be identified by in-band signals, such
as SCTE 35 markers, or by schedule metadata.
An instance of a SegmentEvent is
associated with a MediaViewer
whose actions generated the event.
Is also associated with the single
MediaDevice that actually
generated the event.
Play Control Event
PlayControlEvent is a specialization of MediaEvent that
represents a trick mode event during presentation of
non-linear content. A transition from presenting linear
content live to presenting from a time-shift buffer is
considered a transition to non-linear content. Trick
modes include pause and skip. Skip can be used to
model forward and backward play at any speed.
An instance of a PlayControlEvent
is associated with a MediaViewer
whose actions generated the event.
Is also associated with the single
MediaDevice that actually
generated the event.
App State Event
AppStateEvent is a specialization of MediaEvent that
represents the loading, launching, suspension, or
termination of an interactive application. Examples of
interactive applications are ETV or OCAP applications.
Not addressed here is application instrumentation, which
is the collection of application level clickstream events
used to interpret viewer behavior within the context of
an application (for example, companion applications).
An instan
ce of an AppStateEvent is
associated with a MediaViewer
whose actions generated the event.
Is also associated with the single
MediaDevice that actually
generated the event.
Media Device
The MediaDevice entity represents a media delivery,
processing, or presentation platform. Examples include
cable set-top boxes, televisions, tablets, PCs, mobile
devices, and any other devices that present media to a
viewer.
The MediaDevice is associated
with one or more MediaEvents. In
practice, this means that each
MediaEvent must be associated
with a device.
剩余136页未读,继续阅读
![bz2](https://img-home.csdnimg.cn/images/20210720083646.png)
![zip](https://img-home.csdnimg.cn/images/20210720083736.png)
![-](https://csdnimg.cn/download_wenku/file_type_lunwen.png)
![-](https://csdnimg.cn/download_wenku/file_type_column_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://profile-avatar.csdnimg.cn/672471f7ccea470fb00a6e95fba0da3a_len_wang.jpg!1)
len_wang
- 粉丝: 1
- 资源: 1394
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助
![](https://csdnimg.cn/release/wenkucmsfe/public/img/voice.245cc511.png)
最新资源
- 中国微型数字传声器:技术革新与市场前景
- 智能安防:基于Hi3515的嵌入式云台控制系统设计
- 手机电量低时辐射真增千倍?解析手机使用谣言
- 56F803型DSP驱动的高精度大功率超声波电源控制策略研究
- ARM与GPRS结合的远程监测系统设计
- GPS与RFID技术结合的智能巡检系统设计
- CPLD驱动的低功耗爆炸场温度测试系统设计
- 基于FPGA的智能驱动控制系统:可扩展设计与工业网络协议
- 基于ATmega128和CH374的嵌入式USB接口设计
- 基于AT89C52的温度补偿超声波测距仪:高精度设计与应用
- MSP430F448单片机在交流数字电压表中的应用
- 提升变频器应用效率的12项实用技巧
- STM32F103在数字电镀电源并联均流系统中的应用
- PSpice仿真下的升压开关电源设计:拓扑分析与CCM稳定性提升
- 轻巧高效:MSP430主导的低成本无线传感器网络节点设计
- FPGA在EDA/PLD中实现LVDS接口的应用解析
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035111.png)
安全验证
文档复制为VIP权益,开通VIP直接复制
![](https://csdnimg.cn/release/wenkucmsfe/public/img/green-success.6a4acb44.png)