Note: Descriptions are shown in the official language in which they were submitted.
DYNAMIC CHUNKING FOR DELIVERY INSTANCES
FIELD OF THE INVENTION
[0001] This invention relates generally to the field of media streaming
using a data
network and, more particularly, to systems and methods for media streaming.
BACKGROUND OF THE INVENTION
[0001a] The delivery of media over networks such as the Internet can be
accomplished in
many ways, including progressive downloading or streaming. Streaming a media
file typically
involves downloading "chunks," or small segments, of the media file.
Information including
where chunks may be accessed can be stored in an index file (also known as a
"manifest"
file). This index file can be delivered to a client, such as a media player
application, for use in
streaming. Additional information may also be provided, which can alter the
appearance of
the client.
BRIEF SUMMARY OF THE INVENTION
[0002] Systems and methods disclosed provide a technical solution improving
quality of
service of video streaming based on a determined state of a client media
player application.
The disclosed systems and methods provide for dynamically executing
syndication services
are provided that automatically implement business rules for syndication based
on contextual
data associated with a media file, a request for a media file, or both. These
systems and
methods may be part of a larger media servicing network that can be used to,
among other
things, process uploaded media content, provide it for streaming/downloading,
and collect and
distribute metric information regarding the streaming/downloading. The
disclosed systems
and methods provide for receiving a request having a Uniform Resource Locator
(URL) or
other content indicator and providing an index file in accordance with
business rules based on
contextual data associated with the request, the content, or both. Embodiments
further enable
media content owners to distribute a single URL or other content indicator
corresponding to a
particular media file among many media providers, enabling a single media
delivery and
analytics service to provide comprehensive metric information regarding
content syndication
and usage for all requests for the content across all media providers.
1
CA 2867161 2019-05-07
[0003] According to one embodiment, there is provided a server for
providing a media
file with a data network, the server comprising: a network interface for
communicating with
the data network; a memory; and a processor communicatively coupled with the
memory and
the network interface, the processor further configured to perform functions
including:
receiving, via the network interface, a first request having a universal
source locator (URL),
wherein the URL includes information indicative of a requested media file;
determining one
or more factors related to the first request, wherein the one or more factors
related to the first
request includes information regarding an end user device that requested the
media file;
determining a first chunking strategy based on the one or more factors related
to the first
request; determining an advertisement strategy based on the one or more
factors related to the
first request; generating a first index file having information for streaming
the requested
media file via the data network, wherein generating the first index file is
based, at least in
part, on the first chunking strategy and the advertisement strategy;
providing, via the network
interface, the first index file; receiving, via the network interface, a
second request having the
URL; determining one or more factors related to the second request, wherein
the one or more
factors related to the second request are different than the one or more
factors related to the
first request; determining a second chunking strategy based on the one or more
factors related
to the second request; generating a second index file having information for
streaming the
requested media file via the data network, wherein: generating the second
index file is based,
at least in part, on the second chunking strategy; and content of the second
index file is
different from content of the first index file; and providing, via the network
interface, the
second index file.
[0004] According to another embodiment, there is provided a method for
providing
media with a data network, the method comprising: receiving a first request
having a
universal source locator (URL), wherein the URL includes information
indicative of a
requested media file; determining one or more factors related to the first
request, wherein the
one or more factors related to the first request includes information
regarding an end user
device that requested the media file; determining a first chunking strategy
based on the one or
more factors related to the first request; determining an advertisement
strategy based on the
one or more factors related to the first request; generating, with a
processor, a first
2
Date Recue/Date Received 2021-04-09
index file having information for streaming the requested media file via the
data network,
wherein generating the first index file is based, at least in part, on the
first chunking strategy
and the advertisement strategy; providing the first index file; receiving a
second request
having the URL; determining one or more factors related to the second request,
wherein the
one or more factors related to the second request are different than the one
or more factors
related to the first request; determining a second chunking strategy based on
the one or more
factors related to the second request; generating, with a processor, a second
index file having
information for streaming the requested media file via the data network,
wherein: generating
the second index file is based, at least in part, on the first chunking
strategy; and content of
the second index file is different from content of the first index file; and
providing the first
index file.
[0005]
According to yet another embodiment, there is provided a system for providing
a
media file with a data network, the system comprising: communication means
for: receiving a
first request having a universal source locator (URL), wherein the URL
includes information
indicative of a requested media file; and sending a first index file via the
data network; and
processing means for: determining one or more factors related to the first
request, wherein the
one or more factors related to the first request includes information
regarding an end user
device that requested the media file; determining a first chunking strategy
based on the one or
more factors related to the first request; determining an advertisement
strategy based on the
one or more factors related to the first request; and generating the first
index file having
information for streaming the requested media file via the data network,
wherein generating
the first index file is based, at least in part, on the first chunking
strategy and the
advertisement strategy; wherein the communication means further comprises
means for:
receiving a second request having the URL; and sending a second index file via
the data
network; and wherein the processing means further comprise means for:
determining one or
more factors related to the second request, wherein the one or more factors
related to the
second request are different than the one or more factors related to the first
request;
determining a second chunking strategy based on the one or more factors
related to the second
request; generating the second index file having information for streaming the
requested
media file via the data network, wherein: generating the second index file is
based, at least in
2a
Date Recue/Date Received 2021-04-09
part, on the second chunking strategy; and content of the second index file is
different from
content of the first index file.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The present disclosure is described in conjunction with the
appended figures:
[0007] FIG. 1 illustrates a block diagram of a media servicing system.
[0008] FIG. 2A illustrates a block diagram of an embodiment of a kernel
application
center connected with application centers.
2b
Date Recue/Date Received 2021-04-09
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
[0009] FIG. 2B illustrates a block diagram of an alternative embodiment of a
kernel
application center.
[0010] FIG. 3 illustrates a block diagram of an embodiment of an application
center.
[0011] FIG. 4 illustrates a block diagram of processes and objects utilized by
a cloud-
hosted integrated multi-node pipelining system for media ingestion.
[0012] FIG. 5A illustrates a simplified block diagram of an embodiment of a
system
configured to provide dynamic indexing and chunking for media streaming.
[0013] FIG. 5B illustrates a simplified block diagram of another embodiment of
a system
configured to provide dynamic indexing and chunking for media streaming.
[0014] FIG. 5C illustrates a simplified block diagram of another embodiment of
a system
configured to provide dynamic indexing and chunking for media streaming,
utilizing a
redirector.
[0015] FIG. 6 illustrates a simplified flowchart of an embodiment of a method
for
implementing a dynamic index for media streaming.
[0016] FIG. 7 illustrates a simplified flowchart of an embodiment of a method
for
dynamically chunking a media file for streaming.
[0017] FIG. 8 illustrates a simplified swim lane flowchart describing the
interaction of
components in a system configured to provide dynamic indexing and chunking for
media
streaming, according to one embodiment.
[0018] FIG. 9 illustrates a simplified flow chart providing a basic method for
adapting
chunking techniques for each delivery instance.
[0019] In the appended figures, similar components and/or features may have
the same
reference label. Further, various components of the same type may be
distinguished by
following the reference label by a dash and a second label that distinguishes
among the
similar components. If only the first reference label is used in the
specification, the
description is applicable to any one of the similar components having the same
first
reference label irrespective of the second reference label.
3
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
DETAILED DESCRIPTION OF THE INVENTION
100201 The ensuing description provides preferred exemplary embodiment(s)
only, and is
not intended to limit the scope, applicability or configuration of the
disclosure. Rather, the
ensuing description of the preferred exemplary embodiment(s) will provide
those skilled in
the art with an enabling description for implementing a preferred exemplary
embodiment.
It is understood that various changes may be made in the function and
arrangement of
elements without departing from the spirit and scope as set forth in the
appended claims.
100211 The increased availability of media content over data communications
networks
such as the Internet has mirrored the increased bandwidth for these networks.
Because
media has recently taken a more prominent role in data communications, the
distribution of
media and the data associated with such distribution has become increasingly
important,
particularly to media providers. Media streaming has become a widely-used
method of
media distribution, but the preprocessing associated with streaming can be
burdensome.
Certain protocols, including forms of Hypertext Transfer Protocol (HTTP)
streaming,
require chunking and storing media assets, and generating a corresponding
index files.
These requirements can deprive a media provider of the ability to dynamically
insert
additional media such as advertisements into a media stream, and can consume a
large
amount of storage space to store chunks of media for a media asset, including
chunks for
any alternative sub-streams (e.g., streams with alternative bitrates,
captions, alternative
languages, etc.). Certain systems and methods can be utilized, however, to
introduce the
desired functionality back into the system.
100221 A traditional approach to preprocessing media for streaming involves
chunking
and storing media assets, then creating corresponding index files to indicate
where chunks
may be located to download for streaming. Streaming protocols often provide
for
frequently updating an index file for instances where the corresponding media
is frequently
updated, such as during live streaming. Thus, an index file does not need to
contain all
chunks for a requested media asset. In addition, because media files are
frequently stored in
a format that requires little additional processing to chunk, the chunks can
be created in real
time, during the streaming of a media file. The systems and methods disclosed
herein take
advantage of these features to enable dynamic index file creation and dynamic
media file
chunking.
4
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
[0023] For instance, rather than preprocess media assets for streaming by
chunking and
indexing all files with relevant sub-streams prior to streaming the media, a
server can
dynamically create and update an index file during streaming. The dynamically-
created
index file can contain information regarding a next chunk of media in the
various available
sub-streams. The next chunk of media may not be cached at a location specified
in the
index file, in which case a chunk may be dynamically created by pulling all or
part of the
media file of interest from a media file origin, chunking it, and making it
available for
download. The chunk also may be cached, thereby eliminating the need to create
the chunk
again if it is requested at some later time.
[0024] Because the chunks are created during streaming, a media provider
and/or media
distributer can have more information and control during the streaming
process. Rather
than generate single index file for a given media asset, an instance of the
index file
generator may be created at the beginning of the media streaming to provide
individualized
media content to a particular end user and unique information regarding the
streaming
session to a media provider. The file index generator can vary the length of
each chunk by,
for example, indicating starting and ending points in the index file. Thus,
the file index
generator may determine a uniform chunk length for a media asset, varying the
length of the
chunks for different media assets, or the file index generator may adjust the
length of the
chunks within a single media asset. The index file generator can further
insert additional
media, such as an advertisement, at any time during the streaming by
specifying the location
of the additional media in the index file. The determination to insert
advertisements can be
based on any information, including data collected during the streaming
session.
[0025] As the index file generator receives requests for and generates index
files, it can
further gather data regarding the streaming session for reporting to a media
provider. Media
providers often rely on beaconing data collected from media player
applications to
determine when an end user stops, plays, pauses, skips, etc., the streaming
media content.
Such information can be vital in determining the value of the media.
[0026] Because not all media player applications provide this beaconing data,
the data
gathered by the index file generator can serve as a substitute for or
complement to the
beaconing data. For example, if a request is made for a chunk that does not
immediately
follow a previously-requested chunk, a skip was made. If the amount of time
elapsed
between a previous request and a subsequent request exceeds the time for
playback of the
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
previously-requested chunk, a pause was made. If a request is not received
within a certain
time since a prior request, it can be determined that a stop was made.
[0027] As illustrated above, the state of a client may be determined from a
variety of
factors. This can include when the request for the index file is received,
when the index file
is provided, a length of time to play back the segment of media for streaming,
and/or the
starting and/or ending point of the segment of media for streaming. The
determined state of
a client may also be based on whether the request for the index file has been
received within
a certain amount of time since receipt of a previous request for an index
file, whether the
segment of media for streaming includes media other than the media file, and
more. The
state of a client and/or the data from which it was determined, may be used to
create
reporting data to serve as a substitute or complement to beaconing data from a
client media
player application. Because the index file generator can determine the length
of the chunks,
it therefore can determine the frequency of subsequent index file requests and
the resolution
of the reporting data based on the requests. The index file generator may log
the reporting
data and/or transmit the reporting data over a network during streaming.
[0028] The determined state of a client may be used by the index file
generator and/or
other services for various purposes. For example, it may be used in behavioral
advertisement targeting and enforcement of session advertisement behavior,
adjusting
advertisement content and playback based on the behavior of a user as
determined by the
stated of a client. The state of a client further may be used to support
resume features on a
per client basis, allowing a user to continue playback of a media asset from a
point at which
the user had previously stopped playback. The state of a client also may be
used to support
individual encryption keys in an encryption scheme and allow the index file
generator to
return secure URLs (e.g., time expiring or Internet Protocol (IP) allowed) for
chunks to
support functions such as payment services.
[0029] Additionally or alternatively, the tasks of generating the index file
and providing a
location a requested chunk can be split up, thereby enabling the system to
determine which
chunks are actually requested. For example, a system may be configured to
dynamically
create an index file having links to one or more redirectors on the system.
These redirectors
can be configured to issue the location of the chunk, which can be created
dynamically.
The redirectors can further determine which chunk is actually requested,
thereby enabling,
among other things, calculation of Quality of Service (QOS) metrics, an
increase the
6
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
accuracy of reporting data, a decrease the frequency of index file generation
if efficient to
do so, and the ability to more easily handle keys of an encryption scheme.
[0030] While the above embodiments may be implemented in a variety of
different
systems, some particular embodiments may be implemented as part of a media
service
system. FIG. 1 is a block diagram illustrating a media servicing system 100,
according to
some embodiments of the present invention. The system may deliver media
content to the
end user device 140 through a network such as the Internet 120. The end user
device 140
can be one of any number of devices configured to receive media over the
Internet 120,
such as a mobile phone, tablet computer, personal computer, portable media
device, etc. A
media asset provided by a media provider 130 can be processed and indexed by
cloud-
hosted integrated multi-node pipelining system (CHIMPS) 110, and further
stored on media
file delivery service provider (MFDSP) 150. Additionally or alternatively, the
CHIMPS
110 may also be adapted to store the media asset.
[0031] The media servicing system further enables a media provider 130 or
other entity to
gather information regarding user behavior during media playback. For example,
a media
provider 130 can be provided with data indicating that end users tend to stop
watching a
video at a certain point in playback, or that users tended to follow links
associated with
certain advertisements displayed during playback. With this data, a media
provider 130 can
adjust factors such as media content, advertisement placement and content,
etc., to increase
revenue associated with the media content and provide the end user device 140
with a more
desirable playback experience.
[0032] End user device 140 can request a media asset to stream with a client
program
executed by the end user device 140. The client program can be, for example, a
media
player, browser, or other application adapted to request and/or play media
assets. In
response to a request for a media asset, the CHIMPS 110 can utilize any number
of
application centers 112 and/or kernel application center(s) 111 to provide the
client program
with a data object concerning the requested media asset. The data object can
include
information about the media asset, including where the media asset can be
located, such as
within the MFDSP 150 or within the CHIMPS 150 itself. Location information may
be
provided by Universal Resource Indicator (URI), a Universal Resource Locator
(URL) or
other indicator. During playback of the media asset, the CHIMPS 150 can
collect data
regarding the playback through beaconing provided by a client program executed
by the end
7
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
user device 140 and/or indexing service from within the CHIMPS and/or MFDSP.
The
CHIMPS 150 can subsequently provide the data and/or any analytics information
derived
from the data to the media provider 130.
[0033] FIG. 2A is a block diagram illustrating an embodiment of a kernel
application
111-1 center connected with application centers from within the CHIMPS 110-1.
The
kernel application center 111-1 and application centers 112 can be
geographically distant
and can be connected via the Internet 120, wide area network (WAN), and/or
other data
communication network. Because application centers can be geographically
separated,
DNS services (not shown) can be used to allow an end user device 140 to
connect to the
nearest available application center 112. The kernel application center 111-1
can connect
with application centers 112 within the CHIMPS 110-1 through an internal
interface 270,
thereby enabling the application centers 112 access to the various components
within the
kernel application center 111-1.
[0034] Components within the kernel application center 111-1 can communicate
through
network 260 such as a local area network (LAN) and can include one or more
origin servers
240 and a storage array 230 with which data objects and/or media assets may be
stored and
distributed. The storage array 230 may also be utilized by services running on
processing
server(s) 220 and/or transcoding server(s) 250 that may require temporary or
long-term
storage. Kernel server 210 can utilize processing server(s) 220, transcoding
server(s) 250 to
provide various functional capabilities to the CHIMPS 110.
100351 For example, as described in more detail below, the CHIMPS 110-1 can
provide
transcoding service for media assets provided by a media provider 130 for
syndication.
Such a service can allow a media provider 130 to upload a media asset to an
application
center 112, after which the application center 112 would notify the kernel
server 210 that
the media asset has been uploaded. The kernel server can then notify services
running on
the processing server(s) 220 of the upload. These services can utilize
transcoding server(s)
to transcode the media asset, which can then be moved to a MFDSP and/or stored
locally by
storage array 230 and origin server(s) 240. Services running on the processing
server(s) 220
can also update the associated data object stored by the storage array 230 and
origin
server(s) 240.
[0036] FIG. 2B is a block diagram illustrating an alternative embodiment of a
kernel
application center 111-2. In addition to the components of the embodiment of
FIG. 2A, this
8
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
embodiment incorporates an application center 112 within the kernel
application center 111-
2. The application center 112 incorporated within kernel application center
111-2 may be
located at or near the other components of the kernel application center 111-
2, and can be
communicatively connected to the other components via network 260. The
incorporated
application center 112 can therefore have faster access to kernel application
center
functionality because it does not need to communicate over long distances. In
consideration
of this advantage, it will be understood that the CHIMPS 110 can include
multiple kernel
centers with one or more application centers incorporated therein.
Additionally or
alternatively, components of the kernel application center may be incorporated
into one or
more application centers 112 in the CHIMPS 110 to provide quicker access to
certain
functionality.
[0037] FIG. 3 is a block diagram illustrating an embodiment of an application
center 112.
The application center 112 can include caching server(s) 330 and a storage
array 310 for
storing and distributing data objects of media assets requested by end user
devices through
end user interface 360. Caching server(s) 330 and storage array 310 can also
be used to
collect, process, and/or store metrics information from beaconing data, media
chunk
requests, and/or other data sources, including data collected through end user
interface 360.
The application center can further include ingest server(s) 320 for ingesting
uploaded media
assets from a media provider 130 through a media provider interface 370. The
media assets
may be stored on the storage array 310. As with the kernel application center
111, the
components of the application center 112 can be communicatively linked through
a network
340, such as a LAN. The application center can further include an internal
interface 350,
providing a communication link from the application center to the rest of the
CHIMPS. It is
through internal interface 350, for example, that media assets stored on
storage array 310
can be made available to a kernel application center 111 for services such as
transcoding.
[0038] FIG. 4 is a block diagram 400 of processes and objects utilized by the
CHIMPS
110 for media ingestion, according to some embodiments. Although FIG. 4
further
indicates the physical systems in which my execute or store these processes
and objects, it
will be understood that the processes and objects disclosed may be executed or
stored on
more than one system, including systems not disclosed in FIG. 4. In other
words, the
processes and objects shown in FIG. 4 allow for a variety of implementations
through one
or more of hardware, software, firmware, microcode, etc.
9
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
[0039] Media can be ingested into the CHIMPS 110 when a media provider 130
uploads a
media asset to ingestion server(s) 410 in an application center 112 by
utilizing a client 405.
The client 405 can be a stand-alone application or browser based, for example,
and can
communicate with ingest server(s) 410 through an application programming
interface (API)
configured for the ingestion of media assets.
[0040] Ingest server(s) 410 can communicate with devices in the kernel
application center
111 executing programs such as kernel server 425 and file replication service
430. The
kernel server 425 can be configured organize the workflow among services such
as
transcoding 440 file system manager 435, and other services 445 (e.g.,
analytics, dynamic
API, etc.) Upon a particular event, for example, the kernel server can be
configured to
notify the relevant services of the event, causing the services to process
tasks associated
with the event.
[0041] The file replication service 430, under direction of the kernel server
425, can
coordinate the movement of the media assets between services. For example,
retrieving the
uploaded media asset from the ingest server(s) 410 and storing it on the file
archive 450, or
retrieving transcoded media assets from transcoding server(s) 460 and storing
them in the
media asset origin.
[0042] The data object updater 420 keeps the data object origin 415 up to date
in response
to any changes in the system. When, for example, a file is uploaded,
transcoded, and stored
in media asset origin 455, the location and other metadata concerning the
transcoded media
assets need to be created or updated in the data object origin 415 to ensure
an end user
device that accesses the object in the data object origin 415 has the correct
information
regarding the related media asset. Because the data object updater 420
receives updates
from the kernel server 425 (which is notified when a transcoded media asset is
stored in the
media asset origin 455, the system ensures the data objects in the data object
origin are
constantly up to date.
[0043] The upload of a media asset to the ingest server(s) 410, as described
above, can
provide an example of how the kernel server 425 may coordinate workflow. For
instance,
in response to the upload, the ingest server(s) 410 can notify the kernel
server 425 that a
media asset has been uploaded. The kernel server 425 informs the file
replication service
430 of the uploaded media asset, and the file replication service 430 moves
the uploaded
media asset into the file archive 450 and notifies the kernel server 425 of
the move. In
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
response, the kernel server 425 notifies the file replication service 430, the
file system
manager 435, and the transcoding master 440 of the move. The file replication
service 430
then will know it can delete the uploaded media asset from the ingest
server(s) 410, the file
system manager 435 will update the file system accordingly, and the
transcoding master 440
will notify transcoding service(s) 460 of different transcoding tasks to be
performed. The
transcoding service(s) 460 can then retrieve the uploaded media asset from the
file archive
450 to create transcoded media assets. The transcoding service(s) 460 notify
the kernel
server 425 once transcoding is complete, and the kernel server 425 relays this
information to
the file replication service 430. The file replication service 425 then takes
the transcoded
media assets from the transcoding services 460 and moves them to the media
asset origin
455. Once the file replication service 430 notifies the kernel server 425 of
the move, the
kernel server 425, in turn, notifies the file replication service 430 and the
data object updater
420. The data object updater 420 which updates the data object origin 415
accordingly, and
the file replication service 430 deletes the transcoded media assets from the
transcoding
services 460.
[0044] The modular nature of the system enables all tasks associated with an
event to be
completed quickly. As illustrated in the example above, workflow relating to a
particular
event, such as a media asset upload, can be spread among the various services
simultaneously. Moreover, because the system's modularity enables it to be
scaled to
accommodate differing hardware capacities, and because the system can be
configured to
dynamically allocate hardware to different services according to the needs of
the system, the
speed of completing tasks relating to a particular event can further be
increased. For
example, a server of the CHIMPS 110 can be configured to dynamically switch
its purpose
based on external conditions such as load and overall system performance,
providing
functions such as transcodc, upload, metrics collection, application web
service, and more,
on an as-needed basis.
[0045] Embodiments of such systems may include other systems that manage
various
requests from end users. For example, a system for dynamic index file
generation and
media file chunking. Referring to FIG. SA, shows an embodiment of such a
system 500-1.
Media may be streamed to end user device 140 though a client 510. As mentioned
above,
the client 510 can be stand-alone media player, a plug-in, a browser, or other
application,
which can be executed on a personal computer or other electronic device.
11
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
[0046] An index file generator 530, as discussed previously, can be a program
instantiated
for media streaming to a particular client 510. The index file generator 530
can be executed
on a server or other computing device within an application center 112 of the
CHIMPS 110.
Index files generated by the index file generator can include a wide variety
of information
such as starting, ending, and or run times for media chunks and locations for
media chunks.
This information can be embedded in a single string of data, such as a URI or
a URL. If
media includes various sub-streams (e.g., streams with alternative bitrates,
captions,
alternative languages, etc.) the index file can include data for chunks
corresponding to each
of the alternative sub-streams, as well as information regarding the bitrate
and/or other
unique information for each stream. Alternatively or in addition, index files
indicating
alternative sub-streams may be separate from index files indicating one or
more media
chunks for streaming.
[0047] It should be understood that the index file can further comprise a wide
variety of
formats, which can depend on the particular protocol. HTTP streaming may, for
example,
require index files to comprise one or more of M3U, M3U8, XML, and XML-based
formats. Of course, other formats can be used in accordance with relevant
streaming
protocols.
[0048] Table 1 illustrates a simplified example of a generated index file in
M3U9 format,
indicating chunk of media for streaming. The index file in this example
provides a URI for
a chunk of media. The URI indicates the chunk is to be generated by dynamic
segmentor
550, the chunk being 10 seconds long, starting at 9 seconds into the media
file and ending
19 seconds into the media file.
Table 1: Example Index File Contents
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:10
#EXTINF:10,
http://video.example.com/seg/9/19/seg1.ts
[0049] Referring again to FIG. 5A, the index file generator 530 can also
include an
indicator within an index file to indicate whether a chunk of media is to be
dynamically
created. If, for example, it is determined that a requested media asset has
not been chunked
and that the asset will be chunked dynamically, the index file generator can
include the
indicator in data corresponding to a chunk of media to be created. The
indicator, which can
12
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
be as simple as including the term "/segl" in a URL, will indicate that a
requested chunk of
media needs to be generated.
[0050] The chunks of media can be generated during media streaming by a
dynamic
segmentor 550, which can be incorporated into an HTTP service 540. The HTTP
service
540, as well as the media asset origin 560 can be located within a kernel
application center
111 of the CHIMPS 110 on, for example, a media asset origin server. The system
500-1
can be configured such that the kernel application center 111 provides
dynamically-created
chunks of media to a MFDSP 150 for delivery to client 510. The MFDSP 150 can
store the
chunks locally in, for example, a media asset cache 520, thereby forgoing the
need to
dynamically create a chunk again if the same chunk is requested in the future.
[0051] In sum, the system for dynamic index file generation and media asset
chunking
500-1 can, after receiving a request for an index file from a client 510,
dynamically generate
an index file with an index file generator 530. The index file can, among
other things,
indicate where a next chunk of media may be located. A client can then request
the chunk
from the location indicated by the index file, which can comprise a media
asset cache 520 in
a MFDSP 150. If the chunk is not found in the media asset cache 520, the cache
miss can
redirect the request to a segmentor 550 of an HTTP service 540, which can
dynamically
generate the requested chunk of media by accessing the corresponding media
asset in the
media asset origin 560. The requested media chunk can then be provided to the
MFDSP
150 for storage in the media asset cache 520 and delivery to the client 510.
If the same
chunk is requested at a later point in time, the MFDSP 150 can deliver the
chunk from the
media asset cache 520, thereby forgoing the need to redirect the request to
the segmentor
550 to regenerate the chunk.
[0052] FIG. 5B illustrates an alternative embodiment 500-2 of a system for
dynamic
index file generation and media file chunking. Rather than utilize a MFDSP,
this
embodiment 500-2 includes a media caching server within an application center
112 of the
CHIMPS 110. The media caching server can receive chunk requests from and
provide the
corresponding chunks to a client. It will be understood that such a media
caching server(s)
or similar device(s) can be located anywhere within the CHIMPS and/or in a
system(s)
communicatively linked to the CHIMPS.
[0053] FIG. SC illustrates an embodiment 500-3 of a system for index file
generation
used in conjunction with a redirector 590. As discussed above, an index file
generator 530
13
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
may create an index file having one or more URIs or other location information
directing
the client 510 to one or more redirectors 590. Redirector 590, can then
provide the URI of
the requested chunk with a redirect, such as a redirect under HTTP status code
302. The
URI can be located on a MFDSP 520 or other location (such as a media caching
server 570)
and/or dynamically created by the dynamic segmentor 550. It will be understood
that there
can be any number of redirectors 590, which can be at any location, including
locations of
the CHIMPS 110 such as the application center 112 (as shown in FIG. 5C) or the
kernel
application center 111. It also will be understood that the URI or other
location information
provided by redirector 590 can be generated by or provided to the redirector
590 in any
number of ways. The URI can be generated, for example, based on the request
received by
redirector 590 from client 510. Finally, it will be understood that the CHIMPS
110 can be
configured to dynamically implement any combination of embodiments 500-1, 500-
2, and
500-3, further choosing whether to utilize one or more redirectors based on
factors such as,
for example, a detected type of client 510.
[0054] Embodiments utilizing one or more redirectors can have several
advantages. For
example, and not by way of limitation, if a certain client were implemented in
such a way
that it "reads ahead" to request chunks, it could result in incorrect
reporting data. Thus, it
would be advantageous to determine which chunk is actually requested by the
client.
Additionally or alternatively, where chunks are available in various sub-
streams with
different bitrates, determining the actual requested chunk can be useful in
calculating
Quality of Service (QOS) metrics. Furthermore, it there may be scenarios in
which it is
more efficient to create larger index files having many chunks comprising
large segments of
media, reducing the number of index files required to stream a media asset,
and thereby
reducing the processing requirements to create the index files. If encryption
is used having,
for example, a rotating key or a per client key encryption scheme in which a
valid key might
change during playback of a media asset, it also may be advantageous to
incorporate
redirector(s) for handling legacy keys for some period of time.
[0055] FIG. 6 illustrates a simplified flowchart of an embodiment of a method
600 for
implementing a dynamic index for media streaming. The method 600, which can be
executed by the index file generator 530, begins at block 610, where a request
for an index
file is received from a client 510. According to media streaming protocols
contemplated by
this embodiment, if data regarding a chunk of media is not provided in an
initial index file,
the client will continue to request or refresh an index file until it reaches
an indicator in the
14
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
index file that signals the end of a stream. Thus, the method can be assured
to receive more
than one request for an index file from a client provided that an initial
index file does not
include an indicator signaling the end of the stream.
[0056] At block 615, the method 600 additionally provides for receiving input
from an
advertising service. According to some embodiments, this input could be the
availability of
an advertisement, and can be provided by a service inside or outside the
CHIMPS. In other
embodiments, the input could come from a service that factors in any of a
variety of factors
to indicate that a specific advertisement or type of advertisement should be
shown. Or that
any advertisement should be shown.
[0057] At block 620, a determination is made whether to include an
advertisement in the
next chunk. According to some embodiments, this determination can be made with
or
without input from an advertisement service. It should be known that this
determination can
include the factors used by an advertisement service to provide the input of
block 615.
Whether the determination includes input from an advertisement service of
block 615 or
not, the determination can still include factors such as information about an
end user
collected before or during streaming of the media. This can include behavior
of the end
user during streaming of the media (as determined, for example, by machine-
based logic
through beaconing data and/or requested chunks of media provided by a client
510).
Factors can also include information regarding the media asset used for
streaming (such as
type of content or preferred points within the media for an advertisement),
preference(s)
and/or selection(s) of an end user, when a previous advertisement was shown,
time of day,
and more. It can further include information regarding the source of a media
asset, such as
who created and/or provided the asset for viewing by an end user. It will be
understood that
other embodiments contemplate include secondary media, other than
advertisements into
the media stream in this manner. Moreover, the secondary media and/or
advertisement can
be of any length and also may be chunked. Thus, it may be determined that the
next chunk
includes all, or a select portion, of an advertisement of any specific length.
[0058] An index file is created based on the request as well as the
determination of
whether media, such as an advertisement, should be streamed, indicated by
block 625. As
discussed above, the index file can assume a variety of formats and include
any amount of
information regarding a next chunk of media for streaming. For example, HTTP
streaming
can utilize index files having the URLs of available chunks of media.
Information can be
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
embedded in these URLs to indicate a location to download the corresponding
chunk of
media, starting point and/or ending point of a chunk of media, an indicator to
indicate
whether the chunk is to be dynamically created by a segmentor 550, a location
of an
advertisement to be streamed, and more. This information is included in the
index file and
sent to the client at block 630.
[0059] At block 635, reporting data can be created based on information
included in the
index file. As previously discussed, information included in an index file
and/or index file
request can indicate the behavior of an end user device 140 during streaming,
such as a
pause, stop, skip, play, etc. of the media. According to some embodiments,
this information
can be extracted from requests for an index file and/or providing the
requested index file.
The information can be gathered in addition to or as a substitute for
beaconing data
provided by a client 510. Moreover, if beaconing data is provided, the
creation of reporting
data may be omitted altogether.
[0060] Reporting data can include any amount of information regarding end user
behavior, as indicated through index File requests and/or provided index
files. This can
include a particular action and when it was performed. Additionally or
alternatively, the
data may be kept in a more rudimentary form, depending on the application or
embodiment,
indicating the data included in an index file request and/or an index file.
This reporting data
may be stored in a log file for reporting after streaming and/or transmitted
during streaming
to a relevant service that collects such metrics.
[0061] As indicated by block 640, the reporting data may be sent to a metrics
collector for
analytics. A metrics collector, according to certain embodiments, may be an
application
executed by a server from within the application center 112 in which the index
file
generator 530 is executed, or it may be executed elsewhere, such as in a
kernel application
center 111 or in a system outside the CHIMPS 110. Depending on the form of the
reporting
data, the metrics collector can further process and store the information.
[0062] FIG. 7 illustrates a simplified flowchart of an embodiment of a method
for
dynamically chunking a media file for streaming 700. This method can be
employed by a
variety of systems and/or programs. For example, it may be executed by a
dynamic
segmentor 550 of an HTTP service 540 running on a server located in a kernel
application
center 111 of the CHIMPS 110.
16
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
[0063] The method 700 can begin at block 710, when a request for a chunk of
media is
received from a MFDSP 150. As discussed above, this request may be made in
response to
a cache miss at the MFDSP 150 and/or because an indicator was included in the
request for
the chunk of media that the chunk was to be created dynamically. As discussed
herein, if
the MFDSP 150 has the requested chunk cached from a prior request, the MFDSP
150 can
provide the requested chunk and preclude the need to send the request to a
dynamic
segmentor 550 to generate the chunk. It should be understood that the request
may come
from sources other than a MFDSP 150 according to alternative embodiments. One
such
source includes the media caching server 570 of embodiment 500-2, as shown in
FIG. 5B.
[0064] The starting and ending points of a requested chunk of media are then
determined
at block 715. This information can be included directly in the request or
derived from the
request, a previous request, and/or other sources. At block 720, the
information, as well as
information identifying the requested chunk of media, can be used to retrieve
all or part of
the relevant media asset from a media asset origin 560. The retrieved portion
will include at
least the relevant media from the starting point to the ending point of the
requested chunk of
media.
[0065] At block 725, the requested media chunk is generated by converting the
relevant
portion of the media asset into a deliverable chunk. The media asset, as
stored in the media
asset origin, may not be chunked; it may be stored in its entirety as a media
file (or group of
alternative files corresponding to alternative sub-streams). Generating the
chunk therefore
can require determining the starting and ending points from the retrieved
portion of the
media asset and converting the resulting segment of media into a deliverable
chunk.
[0066] Although the generation of the deliverable chunk may involve
transcoding, it may
not. The media asset can be stored in a format where transcoding may not be
needed,
thereby reducing the processing requirements for creating chunks of media
during
streaming. For example, media assets may be stored such as H.264 or MF'EG-4
video
format and/or AAC, HE-AAC, or MP3 audio format. According to some streaming
protocols, such as some forms of HTTP streaming, chunks of media in these
formats would
not need transcoding before being wrapped in an MPEG-2 transport stream
container
format. Instead, such a conversion essentially would require the addition of
metadata to
create the streaming format from the format of the stored media asset. In
other words,
generating a deliverable chunk of media may only require identifying the
stored media
17
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
asset, extracting the relevant segment of the media from the media asset, and
adding certain
metadata in accordance with a container format. This process requires little
processing
power and can be easily performed on the fly during streaming. Once the
deliverable chunk
of media is generated, it is sent to the MFDSP 150 or other requesting entity,
at block 730.
[0067] FIG. 8 illustrates a simplified swim lane flowchart describing the
interaction of
components in a system configured to provide dynamic indexing and chunking for
media
streaming, according to one embodiment. In this embodiment, a client can send
a request
for an index file 805, the request received by an index file generator 810. A
particular
request may be made to initiate the streaming of a media asset, or it may be
during
streaming. Depending on the streaming protocol, the request may be made while
a client
plays a chunk of media previously downloaded during streaming.
[0068] The index file generator generates an index file to indicate the next
chunk of media
815. As described above, this chunk may include an advertisement, and the
index file can
include any amount of information about a chunk of media, including
information regarding
alternative sub-streams for streaming. The dynamic index file generator can
include
information regarding existing chunks of media, and, when used in conjunction
with a
dynamic segmentor may also include information regarding chunks of media that
may need
to be created. As detailed above, if a chunk of media is to be generated
dynamically, the
index file generator may indicate this by including an indicator in the
generated index file,
such as in a URL for one or more chunks described within the index file. Once
the index
file is generated, the index file generator sends the index file 820, which is
received by the
client 825.
[0069] Alternative embodiments may provide for the generation of index files
containing
more than a next chunk of media. For example, an index file generator may
generate an
index file containing information regarding several chunks of media, in which
case the
chunks of media can be dynamically generated by a dynamic segmentor when
requested by
the client. The determination of whether to include information regarding more
than a next
chunk of media can include factors such as whether the index generator is
generating
reporting data, the desired frequency of such reporting data, and more.
[0070] Using information contained in the index file, the client can then
request the next
chunk of media 830, and this request can be received by a MFDSP 835. The MFDSP
then
checks to see if the chunk is already stored in the cache 840. If so. the
MFDSP can provide
18
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
the requested chunk to the client, blocks 845 and 850. The requested chunk may
be found
in a MFDSP's cache if the chunk was created and stored in the MFDSP during
preprocessing or if the chunk was dynamically created and stored in the MFDSP
from an
earlier request.
[0071] If the chunk is not found on the MFDSP, the chunk can be requested of
the
dynamic segmentor, which receives the request 855 and retrieves the
corresponding media
asset from an asset origin server 860. As discussed above, the entirety of the
relevant media
asset does not need to be retrieved as long as at least the portion containing
the relevant
segment for the requested chunk is retrieved. It will be understood that
alternative
embodiments can provide for the media asset being stored in a variety of
locations
accessible, directly or indirectly, to the dynamic segmentor.
[0072] Thc dynamic scgmcntor can then generate the requested chunk by
converting the
retrieved media into a deliverable chunk. That is, the dynamic segmentor
converts the
retrieved media into an acceptable format for streaming, which can vary
depending on the
streaming protocol utilized. The dynamic segmentor can then return the
requested chunk
870 to the MFDSP, which can cache the chunk and return it to the client 875.
Once the
chunk is received by the client 880, the client can play the chunk to an end
user.
[0073] The techniques for creating index files and/or creating corresponding
chunks of
media can be adapted for each request. This allows the CHIMPS 110 (or
similarly-enabled
system) to provide optimal chunking for each delivery instance, which can
differ even
among similar devices, depending on any of a variety of factors. For example,
a new
version of a particular device type (e.g., a particular smart phone, set-top
box, tablet, etc.)
may have the same operating system and/or browser as an older version of the
device type,
but with a larger buffer than the older version. As such, optimized chunking
for delivery
instances involving the old and new versions of the device type may differ in
that delivery
to the new version can include using chunk sizes that would cause a buffer
overflow in the
older version. By dynamically determining and implementing a chunking strategy
for each
delivery instance in this manner, the CHIMPS 110 (or similarly-enabled system)
can help
provide the optimal user experience under any of a variety of circumstances.
[0074] FIG. 9 is a simplified flow chart illustrating a basic method 900 for
adapting
chunking techniques for each delivery instance. At block 910, a request for a
media file is
received. In other embodiments, the request may be for a live stream or other
media asset
19
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
not stored as a media file. At block 920, one or more chunking considerations
are
determined. Because the streaming of a media file can involve multiple
requests (and,
correspondingly, multiple index files), the method 900 may be performed
multiple times
during the playback of a media file.
[0075] Chunking considerations are factors that can impact any aspect of the
chunking of
a media file and/or advertisements included in the delivery of the media file.
Such
considerations can include, but are not limited to, bandwidth, codec,
processor type, buffer
size, memory and/or processor utilization, battery, network type, geographic
location,
whether a device is moving, a location in the playback of the media file, and
the like.
[0076] The bandwidth of a device, for example, can impact the size of the
chunks
delivered to the device. For a relatively low bandwidth, the chunk size may be
reduced so
that chunks arc downloaded more quickly, which may reduce the chance that a
media player
would need to interrupt playback to while waiting for the next chunk to be
delivered.
Conversely, chunk size can be increased for higher bandwidths. Similarly, the
chunks may
be adapted to accommodate a particular network type (e.g., WiFi, mobile
wireless network,
land line (wired), etc.), which can determine, or be indicative of, an
available bandwidth.
[0077] Different aspects of the hardware of a device can also be considered
when
chunking a media file. In addition to the buffer size, as indicated above, a
processor type
can also impact how a file is chunked¨such as the size of the chunk and/or the
codec used.
Additionally or alternatively, QOS metrics can indicate memory and/or
processor
utilization, including during playback of the requested media file, which can
impact the
chunking of the media file.
[0078] Chunking considerations further can include a variety of factors
related to mobile
devices. For example, whether a device is situated in a particular geographic
location, at a
particular event (where large numbers of mobile devices may be located),
and/or the device
is moving can impact the available bandwidth to the device. The battery level
of a mobile
device may also impact the bandwidth in certain circumstances. The CHIMPS 110
(or other
chunking system) can anticipate changes in bandwidth by determining such
chunking
considerations and adjusting the chunking accordingly. Moreover, QOS,
bandwidth, and/or
other information from multiple devices can be aggregated to help the CHIMPS
110 further
adapt media chunking for related delivery instances. Thus, the chunking
considerations for
streaming to one device may include information regarding one or more other
devices. For
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
example the CHIMPS 110 may anticipate a sudden reduced bandwidth for a
particular
delivery instance related to a cell phone where it is determined that other
cell phones nearby
on the same carrier have had sudden drops in bandwidth.
[0079] Chunking considerations further can include a type of codec used and/or
a location
in the playback of the media file. Certain codecs, for example, may require or
prohibit the
use of certain-sized chunks. Also, for example, if the playback of the media
file has just
started, smaller chunks may be used to help ensure that playback begins
quickly, without
the need to wait for larger chunks to be delivered. Also, chunk sizes can be
altered to
accommodate ad insertion or similar interleaving of media content at
particular point(s) in
the playback of the media file.
[0080] Chunking considerations may be determined from information included in
the
request, a database, and/or other sources, which may disclose data such as a
URL, client ID,
globally-unique identifier (GUID) or other identifier, a network type, a
device type and/or
capability, an operating system executed by the end user device, an
application, application
identifier, application state, or other application information, a location
associated with the
device, information associated with a user of the end user device 140,
information regarding
the requested media file (e.g., genre, length, rating(s), ownership, artist,
etc.). Additionally
or alternatively, the request may simply include information that enables one
or more of
these items to be determined. Additionally or alternatively, a repository may
be stored,
maintained or derived, and queried for authorization, authentication,
validation, or selection;
for example, a repository of application identifiers may be maintained and
queried to
determine whether an application is authorized to request the content and if
so, to select
further aspects of or for processing the content request. Additionally or
alternatively, such
stored or derived repository data may be used in conjunction with other data,
either
internally or externally identified, such as a secret key, shared key, public
key, stored
certificate, other stored data, or other data for authorization,
authentication, validation, or
selection, including data stored on another digital service, on another
server, on the client
device, in a device associated with the client device, in the operating
system, in the
application, in another application, in a network, or in another location from
which it may
be retrieved.
[0081] As indicated previously, the determination of chunking considerations
can include
utilizing information other than the information provided in the request. This
may involve
21
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
accessing information stored in one or more a databases or other data
structures internal or
external to the CHIMPS 110. It may also involve communicating with other
entities and/or
systems, such as a content owner or media provider 130. Additionally or
alternatively,
chunking considerations can be gathered using data independent of information
provided in
the request, such as the time at which the request was received.
[0082] At block 930, a chunking strategy based on chunking considerations is
determined.
And at block 940, the corresponding index file and chunks are provided
accordingly. As
indicated above, the chunking strategy (i.e., the way in which the chunks are
created and
delivered) can be impacted by the chunking considerations, including the size
of the chunks,
the length of the playback of the chunks, and the choice of codec used.
Furthermore,
multiple considerations can be taken into account to determine the chunking
strategy.
[0083] This chunking strategy can bc implemented on the fly (i.e., immediately
before or
during playback of the media file) utilizing the dynamic indexing and chunking
techniques
discussed above. For example, an index file generator 530 can incorporate the
chunking
strategy into a dynamically-generated index file, and the dynamic segmentor
550 can
produce the requested chunks accordingly. Because the contextual data and
chunking
strategies can vary for each delivery instance, the content of the index files
corresponding to
requests for the same media file can be different (e.g., indicate different
chunk sizes, codecs
to use, etc.), based on differing chunking strategies.
[0084] It should be noted that the methods, systems, and devices discussed
above are
intended merely to be examples. It must be stressed that various embodiments
may omit,
substitute, or add various procedures or components as appropriate. For
instance, it should
be appreciated that, in alternative embodiments, the methods may be performed
in an order
different from that described, and that various steps may be added, omitted,
or combined.
Also, features described with respect to certain embodiments may be combined
in various
other embodiments. Different aspects and elements of the embodiments may be
combined
in a similar manner. Also, it should be emphasized that technology evolves
and, thus, many
of the elements are examples and should not be interpreted to limit the scope
of the
invention.
[0085] Specific details are given in the description to provide a thorough
understanding of
the embodiments. However, it will be understood by one of ordinary skill in
the art that the
embodiments may be practiced without these specific details. For example, well-
known
22
CA 02867161 2014-09-11
WO 2013/147983 PCT/US2013/023181
circuits, processes, algorithms, structures, and techniques have been shown
without
unnecessary detail in order to avoid obscuring the embodiments. This
description provides
example embodiments only, and is not intended to limit the scope,
applicability, or
configuration of the invention. Rather, the preceding description of the
embodiments will
provide those skilled in the art with an enabling description for implementing
embodiments
of the invention. Various changes may be made in the function and arrangement
of
elements without departing from the spirit and scope of the invention.
[0086] Also, it is noted that the embodiments may be described as a process
which is
depicted as a flow diagram or block diagram. Although each may describe the
operations as
a sequential process, many of the operations can be performed in parallel or
concurrently.
In addition, the order of the operations may be rearranged. A process may have
additional
steps not included in the figure. Furthermore, embodiments of the methods may
be
implemented by hardware, software, firmware, middleware, microcode, hardware
description languages, or any combination thereof. When implemented in
software,
firmware, middleware, or microcode, the program code or code segments to
perform the
necessary tasks may be stored in a non-volatile computer-readable medium such
as a
storage medium. Processors may perform the necessary tasks.
[0087] Having described several embodiments, it will be recognized by those of
skill in
the art that various modifications, alternative constructions, and equivalents
may be used
without departing from the spirit of the invention. For example, the above
elements may
merely be a component of' a larger system, wherein other rules may take
precedence over or
otherwise modify the application of the invention. Also, a number of steps may
be
undertaken before, during, or after the above elements are considered.
Accordingly, the
above description should not be taken as limiting the scope of the invention.
23
