INGEST & METADATA PARTITIONING: REQUIREMENTS FOR
`TELEVISION ON DEMANDTM
`
`Robert G. Scheffler, Chief Architect
`Broadbus Technologies, Inc.
`
`ABSTRACT
`
` On demand video services, such as
`today’s Video on Demand (VOD),
`Subscription Video on Demand (SVOD), and
`the fast-approaching Television on
`DemandTM (TOD®) are enhancing the
`consumer television experience and creating
`new, exciting revenue opportunities and
`increased cash flow for cable operators and
`content owners alike. However, the
`technical requirements to support these
`services are becoming more demanding and
`complex. In VOD, cable operators are
`seeing solid buy-in rates, repeat purchase
`patterns, and concurrency rates of 3%-10%
`with limited marketing and promotional
`support. With recent trials of SVOD and an
`increased number of popular titles,
`concurrency rates have ‘smoothed’ the peak
`usage rates throughout the week to numbers
`that often approach 10%-20%. However,
`with Television on Demand (TOD) services,
`consumers will have considerably more
`programming choices including movies,
`subscription-based content, and the most
`popular broadcast content. It is anticipated
`that concurrency rates of TOD may steadily
`climb to levels that approach 30%-65% --
`rates that mirror the total concurrent U.S.
`television viewing audience as measured by
`rating services such as Nielson.
`
` Increased service usage, additional
`content, and new business models are
`challenging MSOs to conduct unprecedented
`network architecture preparation and
`planning. In addition, decisions related to
`
`asset distribution, content propagation,
`network loading, metadata and rules issues
`need to be addressed to make Television on
`Demand a commercial reality.
`
` This paper will address the issues and
`requirements associated with server ingest
`of broadcast content and content
`propagation. It will also discuss the
`architectural implications for the VOD
`server and propose a new class of server to
`support TOD requirements. The paper will
`also discuss how TOD content is managed
`through the creation and distribution of
`enhanced metadata formats in an
`environment that is controlled by studios,
`distributors, and cable operators.
`
` New video server architectures and
`rules-based content control and propagation
`systems become integral contributors to the
`success of future on-demand services.
`
`VOD/TOD CONTENT INGEST
`
` The issue of the ingest of broadcast
`television content is one that will become
`more and more important for advanced
`video services such as Television on
`Demand to become a reality. As more
`content is made available and concurrency
`rates increase, architectural decisions will
`have to be made to support these increased
`demands on the network. A new architecture
`comprised of higher density VOD/TOD
`servers with the capability to ingest
`
`
`
`
`DISH Ex. 1060, p. 1
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`

`

`

`

`

`

`Specific applications with unique
`1
`requirements.
`
`IcS
`
`ummary of Content, Streams and Inges
`
`+
`
`oI
`
`As needs grow and new business models
`>
`=oO _!SS5.cQOoOion
`fnDpoO g
`5el MNQ rat)=Sp
`© -y
`SQ|+—
`sS
`oa
`VOD streaming servers are being tested.
`Content
`libraries are increasing and greater
`=
`aae)
`oncurrency1s leading to higher and
`IQ
`tream counts (see Figure 2-6). With
`the
`mntroduction of TOD,the added ability to
`ingest broadcast television with
`low-latency
`tie
`
`balance between hardware and transport
`osts. As the needs of
`the network change
`the placement of system components can
`ange as Well,
`
`
`
`
`
`
`Content Storage
`
`Figure 2-5 Content Ingest
`TOD servers
`
`for TOD using
`
`A
`
`flexible architecture that can handle
`
`ow-latency live-ingest as well
`
`as pitcher-
`
`=> je)oO aDp
`
`even the most demanding TOD applications
`see Figure 2-5). The future of VOD]
`VOD,and TOD are dependent on a new
`architecture where scale can be controlled
`
`and each environment can be tailored for
`
`SS=&5|52BLPets15o|s5[i aloBkSleoreBig"oOWN=.5
`
`oO=iQacq)
`
`perceivable dclay.
`
`onventional VODservers are being
`axed to the limit with only a modest
`library
`wn
`ange rate per month. As content
`librarie
`erow, to prevent
`libraries from becomin
`stale’ with old content, an increased
`Klemand is being placed on off-line ingest.
`ven now, conventional VOD serversare
`reaching their limits in being able to keep up
`with SVOD and VODapplications.
`Regardless of
`how much
`streaming
`requirements increase as TOD beginsto
`proliierate, the cable operator will
`be forced
`0 add additional servers just to handle
`ingest tasks. Even then, the resulting system
`will not adequately address the problem 0
`broadcast ingest to streaming latency. The
`early superior solution 1s to use a new
`ass of specialized TOD server capable o
`oo) =QoQoo
`ca 2D> oo)
`y streaming with no
`
`DISH Ex. 1060, p. 5
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`Application Movie
`Library
`150-300
`200-400
`1,000
`
`VOD
`SVOD/VOD
`TOD/SVOD
`VOD
`
`Library
`Change
` 15/month
` 40/month
`100/month
`
`Concurrency
`Real-Time
`Rate
`TV Ingest
` 0 streams 5%-10%
` 0 streams 10%-20%
`100 streams 30%-65%
`
`Stream
`Count
`1,000-3,000
`3,000-6,000
`20,000-40,000
`
`Figure 2-6 System Capacities for VOD, SVOD, and TOD
`
`METADATA AND CONTROL
`
`Rules are needed
`
` The business of broadcast television
`today is very complex. The participants are
`numerous -- content owners, content
`aggregators, content distributors, broadcast
`and cable networks, MSOs -- and the
`relationships between the players are
`dynamic. What keeps content flowing from
`creators to consumers is the execution and
`enforcement of detailed contracts. These
`contracts determine the rules of “how”,
`“when”, and “by whom” content may be
`viewed. Whether it’s a re-run episode of
`“Friends” that airs in syndication on TBS or
`a live broadcast of the New York Knicks on
`ESPN 2, there are specific contract-based
`rules that govern the manner in which
`content is handled. Therefore, it should be
`no surprise that a system of contract-based
`rules will continue to govern (and perhaps
`with greater emphasis) in a business that
`combines broadcast television content with
`on-demand content.
`
` When VOD was initially deployed, the
`rules were relatively simple. MSOs would
`license a window of time when a movie
`would be made available to its subscribers.
`During the licensing window, the movie
`would be placed on the VOD Server and be
`available to subscribers. After the window
`
`was over, the movie would be deleted from
`the server. A set of rules, or metadata,
`capturing the pre-negotiated License
`Window Start and End Times would be read
`and enforced by the VOD server.
`
` As the industry moves towards SVOD
`and ultimately TOD, the same set of
`complex rules and attributes must be applied
`to each piece of content. Examples of
`additional rules for handling television
`content could include:
`• Specific days of week when content
`is available
`• One or more timeslots during the day
`• Time range that the program is
`available on a particular day
`• Specific commercials that must be
`carried with the program
`• Trick-mode rules and attributes
`(specific speeds, enabled/disabled
`functions)
`• Specific customer groups by
`demographic or geographic regions
`
` Rules should be entered and applied as
`early in the process as possible. There are
`rules from many levels. Examples include:
`• Content owner or studio
`• Studio distribution arm
`• Content aggregator
`• Television network
`• Local television station
`
`
`
`
`DISH Ex. 1060, p. 6
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`• Cable MSO
`• Cable local unit
`Some of the rules apply to VOD, some to
`SVOD, and some only to TOD. The key is
`that there are many rules that can come from
`any number of places. While it can seem
`daunting, it is quite easy to create and
`manage these rules.
`
`title, rating, description, time, actors,
`directors and crew, category, trailer file
`names, poster file names, etc. This type of
`metadata does not change, no matter who,
`what, when, or where it is distributed. This
`metadata could clearly be embedded in the
`actual content file and would stay with the
`file no matter where it goes.
`
`Partitioning Metadata
`
`2. Rules-specific Metadata
`
` The Video-on-Demand Content
`Specification as published by CableLabs has
`become the de-facto standard of how
`metadata is created and how it can
`incorporate many of the rules necessary to
`describe how on-demand content is to be
`handled. Initially written to support VOD
`(movies), it has been expanded to support
`SVOD. Moving forward, it is likely that the
`specification will need to be expanded to
`support all forms of on-demand content,
`including broadcast television.
`
` Some metadata rules pertain to the
`specific content itself, while others apply to
`how that content is distributed and sold. One
`piece of content from a studio can be sent to
`many cable systems across the country. If
`the studio had to regenerate the content
`metadata each time, it would become a
`painful process that nobody would want to
`use. However, if the content specific
`metadata were attached or imbedded in the
`content itself, and the distribution specific
`metadata was separate, then the same
`content with metadata attached could be sent
`to many locations, with a different version
`of the distribution metadata. Thus, the
`content metadata and the rules-specific
`metadata has been partitioned.
`
`1. Content Metadata
`
` Content metadata includes program
`specific things such as a unique identifier,
`
` The rules-specific metadata starts at the
`content creation studio. The studio decides if
`there are any specific restrictions on the
`distribution and sale of this content and
`passes those rules along to the content
`distributors. For example, there may be a
`requirement to restrict a specific category of
`commercial - A “Friends” episode may
`require Coke commercials, but not Pepsi.
`From there, the studio distribution arm may
`require more specific rules. “Friends” may
`be allowed from Monday through Friday
`anytime, but not Thursday from 8-9 pm, to
`prevent intruding on first-run episodes.
`Further downstream, the television network
`may decide to allow viewing anytime on
`Tuesday and Wednesday because those are
`non-peak days. The local television station
`may want to restrict viewing from 10-11pm
`during the local news hour.
`
`Figure 3-1 Rules-specific Metadata Flow
`
`
`
`
`DISH Ex. 1060, p. 7
` DISH v. BBiTV
` IPR2020-01267
`
`

`

` At each step along the way, the rules can
`become more restricted, but cannot be less
`restricted. In this manner, the content rules
`become more and more defined as they
`propagate downstream to the network
`operator and eventually the consumer (see
`Figure 3-1). Each system along the path is
`responsible for obeying the rules imposed
`upstream, and can expect each system
`downstream to obey the rules it passes on.
`When they reach the cable system, the TOD
`menu or EPG is built using these rules for
`the content received. By using this approach,
`the menus for the STB can be automatically
`and dynamically constructed.
`
`Figure 3-2 Metadata Flow to Multiple
`Downstream Paths
`
` At each step in the process, there can be
`multiple downstream paths (see Figure 3-2)
`to both multiple distributors and cable
`systems. For example, the studio could sell a
`“Seinfeld” episode to the WB for certain
`nights in a specific week, and TBS on other
`nights. From each step facing down, the
`metadata can fragment, meaning there is a
`one-to-many relationship at each step of the
`way. This is important because at each level,
`a seller can sell to multiple customers.
`However, it would be inconvenient to have
`to re-record and re-master content each time
`
`it was sold. An improved solution would be
`to ship the exact same content to each
`downstream customer, but each would be
`supplied with unique rules-specific metadata
`which can be changed or updated at any
`time without requiring the entire piece of
`content to be resent.
`
`Creating Metadata
`
` With the two distinct types of metadata,
`appropriate software will be required to
`author and control its creation. A key
`ingredient is a unique identifier used to tie
`the asset together with both forms of
`metadata.
`
`1. Content Metadata
`
` The content specific metadata is created
`at the earliest possible point in the
`production and distribution chain. The best
`place for this is at the studio or encoding
`provider. In cases where the content is
`broadcast television, the content metadata
`could originate from the television network,
`or other production company supplying the
`network feed.
`
`2. Rules-specific metadata
`
` The rules-specific metadata can be
`created and adjusted at any point in the
`production and distribution chain, but would
`typically be originated at the same point the
`content is generated. For live television
`events, the rules could and should precede
`the actual content transmission. By sending
`the rules ahead first, the STB EPG can be
`populated, or other similar guide related
`decisions can be made.
`
`Propagating Metadata
`
` Both forms of metadata need to be sent
`along the same path as the actual content.
`
`
`
`
`DISH Ex. 1060, p. 8
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`When any piece of content is sold or
`distributed downstream, the content
`metadata is included with the actual content
`along with an edited copy of the rules-
`specific metadata. Every copy of
`downstream content could have a unique set
`of rules-specific metadata, but the content
`metadata would stay the same. This allows
`each downstream provider to receive
`different rules, and allows them to be
`changed at a later time. When the rules
`change only the rules-specific metadata need
`be resent, not the content metadata or the
`entire program content. With this approach,
`any distributor in the chain can revise and
`update their rules-specific metadata as
`necessary.
`
`Enforcing Rules-specific metadata
`
`1. Asset Distribution
`
` To make this system viable, each video
`server or file server along the asset
`distribution path must receive and obey rules
`encoded in the metadata. Typically in the
`role of asset distribution, all that is required
`is to pass-on the rules given to us. At any
`point in the path, the rules can be edited to
`become more restricted, but never less
`restricted. As assets are moved downstream
`to the cable plant, appropriate TOD software
`will pick-up the rules-specific metadata. The
`TOD software will use this rules-based data
`to build the availability matrix of programs,
`and associate a local time-slot for the
`consumer. The TOD server software is then
`responsible for ensuring that the
`studio/distribution/network rules and
`permissions are obeyed.
`
`2. Content Propagation
`
` When propagating content throughout the
`cable system, there can exist specific rules
`related to perishable content, or content that
`
`has a limited availability window. When this
`type of rule is implemented, it is important
`that the system remove such content and
`make the storage and streaming space
`available as quickly as possible. Another
`situation where the propagation of content is
`important is when a known high-
`concurrency program arrives and needs to be
`propagated to many places in a large
`network to facilitate the expected high
`demand.
`
`CONCLUSION
`
` In this paper, we have examined how
`conventional VOD servers are limited in
`their ability to ingest content and support the
`increasing stream requirements of TOD.
`There is a considerable impact in the output
`stream count as a VOD server is asked to
`ingest more content. With most existing
`systems, there is a non-linear loss of
`streaming capability while ingesting content.
`Specifically, many output streams may be
`lost for each single stream ingested. As the
`number of titles increases in VOD libraries
`the problem becomes more and more
`apparent. To reduce the impact on a VOD
`server, ingest of new content can occur
`after-hours. However this is just a temporary
`solution and won’t scale as ingestion
`requirements continue to increase. With the
`upcoming everything on demand revolution,
`including Television on Demand, the ingest
`limitation of existing VOD server
`architectures becomes catastrophic. The
`more bandwidth consumed by ingest, the
`less bandwidth is available for streaming
`functions. Therefore more servers are
`required to keep the same stream count. As
`more servers are added, ingest and
`propagation becomes more and more
`complex. Elaborate ingest servers with
`content propagation services are a short-
`term solution but problematic longer term as
`
`
`
`
`DISH Ex. 1060, p. 9
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`unacceptable latencies are introduced to the
`distribution of broadcast television.
`
` A new breed of servers designed
`specifically for Television on Demand is
`required. These servers need to handle over
`100 streams of live ingest while
`simultaneously redistributing the ingested
`content to over 20,000 output streams. The
`server must not suffer any performance
`degradation in output streams while
`ingesting live or non-live content. The
`latency through such systems must be low
`enough to enable live television with trick-
`mode functionality similar to that of DVD.
`The streaming elements and the storage
`elements must be separately scalable and
`movable within the network.
`
` With the plethora of ingested content
`from VOD, SVOD, and TOD, new means
`for authoring and propagating metadata
`must be implemented. In addition to content
`metadata, a new class of rules-based
`metadata will be required to protect revenue
`streams by allowing a rules-based
`distribution and STB presentation of
`content. The metadata must be partitioned
`
`and carried separately from the actual
`content to allow updating as well as
`customization depending on the MSO and
`region that the content is destined for.
`
` A new breed of specialized, high
`performance TOD server with low-latency
`and live content ingest capabilities, plus a
`new metadata methodology, is a requirement
`to realize the potential of Television on
`Demand for cable operators.
`
`About the Author
`
`Robert Scheffler is Chief Architect at
`Broadbus Technologies, a provider of next-
`generation server systems that enable cable
`operators to effectively scale and migrate
`their networks from Video on Demand to
`Television on DemandTM – (TOD®)
`
`Robert can be reached at:
`
`(978) 264.7900
`Robert.Scheffler@broadbus.com
`http://www.broadbus.com
`
`TOD and the Broadbus logo are registered trademarks of Broadbus Technologies, Inc. All rights
`reserved. Other trademarks used herein are property of the respected companies.
`
`
`
`
`DISH Ex. 1060, p. 10
` DISH v. BBiTV
` IPR2020-01267
`
`