US20180332094A1

US20180332094A1 - Systems, Methods, and Media for Streaming Media Content

Info

Publication number: US20180332094A1
Application number: US15/972,841
Authority: US
Inventors: Jason A. Braness
Original assignee: Divx LLC
Current assignee: Divx LLC
Priority date: 2013-06-28
Filing date: 2018-05-07
Publication date: 2018-11-15
Also published as: US20150006662A1; US9967305B2

Abstract

Methods, systems, and computer readable media for streaming media content are provided. In some embodiments, the methods comprise: receiving top level index data from a server; caching the top level index data in an index file; receiving header data associated with a first media content file from the server; caching the header data in a header file; receiving a first segment of the first media content file based at least in part on the index file; caching the first segment of the first media content file in a first file; updating the index file to include information about the first file; and causing the first fragment to be displayed based at least in part on the index file and the header file.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 13/931,198 entitled “Systems, Methods, and Media for Streaming Media Content” to Jason A. Braness, filed Jun. 28, 2013, the disclosure of which is expressly incorporated by reference herein in its entirety.

TECHNICAL FIELDS

Methods, systems, and media for streaming media content are provided. More particularly, the disclosed subject matter relates to adaptive bitrate streaming.

BACKGROUND OF THE INVENTION

There are many conventional approaches to streaming media content, such as television programs, pay-per-view programs, on-demand programs, Internet content, movies, etc. For example, media content can be encoded at multiple bit rates. The encoded media content can then be transmitted using a suitable protocol, such as the Hypertext Transfer Protocol (HTTP), the Real-time Transport Protocol (RTP), the Real Time Streaming Protocol (RTSP), etc. However, conventional approaches do not provide users with the capabilities to stream, store, and playback media content at variable bitrates.
Accordingly, new mechanisms for streaming media content are desirable.

SUMMARY OF THE INVENTION

In view of the foregoing, systems, methods, and media for streaming media content are provided.
In some embodiments, methods for streaming media content are provided, the methods comprising: receiving top level index data from a server; caching the top level index data in an index file; receiving header data associated with a first media content file from the server; caching the header data in a header file; receiving a first segment of the first media content file based at least in part on the index file; caching the first segment of the first media content file in a first file; updating the index file to include information about the first file; and causing the first fragment to be displayed based at least in part on the index file and the header file.
In some embodiments, systems for streaming media content are provided, the systems comprising at least one hardware processor that is configured to: receive top level index data from a server; cache the top level index data in an index file; receive header data associated with a first media content file from the server; cache the header data in a header file; receive a first segment of the first media content file based at least in part on the index file; cache the first segment of the first media content file in a first file; update the index file to include information about the first file; and cause the first fragment to be displayed based at least in part on the index file and the header file.
In some embodiments, non-transitory media containing computer-executable instructions that, when executed by a hardware processor, cause the hardware processor to streaming media content are provided, the method comprising: receiving top level index data from a server; caching the top level index data in an index file; receiving header data associated with a first media content file from the server; caching the header data in a header file; receiving a first segment of the first media content file based at least in part on the index file; caching the first segment of the first media content file in a first file; updating the index file to include information about the first file; and causing the first fragment to be displayed based at least in part on the index file and the header file.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

FIG. 1 shows a generalized block diagram of an example of an architecture of hardware that can be used to stream media content in accordance with some embodiments of the invention;

FIG. 2 shows examples of a top level index file and Matroska container files in accordance with some embodiments of the invention;

FIG. 3 shows an example of a structure of a Matroska container file in accordance with some embodiments of the invention;

FIG. 4 shows a flow chart of an example of a process for streaming media content in accordance with some embodiments of the invention;

FIG. 5 shows a flow chart of an example of a process for rendering media content in accordance with some embodiments of the invention;

FIG. 6 shows an example of a top level index file in accordance with some embodiments of the invention; and

FIG. 7 shows an example of Matroska container files containing cached media content in accordance with some embodiments of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

This invention generally relates to mechanisms (which can be systems, methods, media, etc.) for streaming media content. The mechanisms can be used in many applications. For example, the mechanisms can be used to stream, store, and/or playback media content having different versions (e.g., such as video content encoded at multiple bit rates, resolutions, frame rates, etc.).
In some embodiments, media content (e.g., such as video content, audio content, subtitles, etc.) can be stored in one or more Matroska container files on a server. The Matroska container is a media container developed as an open standard project by the Matroska non-profit organization of Aussonne, France. The Matroska specification (which can be retrieved from the Internet: http://matroska.org/technical/specs/index.html) is hereby incorporated by reference herein in its entity. In some embodiments, for example, the server can store multiple Matroska container files containing encoded video content having different bit rates, resolutions, frame rates, etc.
In some embodiments, a user device can request a top level index file from the server. For example, the user device can send one or more requests containing information relating to resources that can provide the top level index file under a suitable protocol (e.g., such as a Hypertext Transfer Protocol (HTTP), a Transmission Control Protocol (TCP), etc.). In a more particular example, the user device can request the top level index file via one or more HTTP requests containing one or more Uniform Resource Identifiers (URI) associated with the top level index file.
In some embodiments, the user device can receive the requested top level index file via one or more responses sent by the server. In the example where multiple HTTP requests are used to request the top level index file, the top level index file can be received via one or more HTTP responses corresponding to the HTTP requests. In some embodiments, the top level index file can be received in any suitable format. For example, the top level index file can be received as a Synchronized Multimedia Integration Language (SMIL) file, an Extensible Markup Language (XML) file, etc.
In some embodiments, upon receiving the top level index file, the user device can cache the top level index file in a suitable manner. For example, the top level index file can be cached in the form of one or more SMIL files, XML files, etc.
In some embodiments, the user device can request one or more headers associated with one or more Matroska container files based on the cached top level index file. For example, the user device can parse the cached top level index file and obtain one or more URIs corresponding to the headers. The user device can then request the headers by sending one or more requests containing the URIs to the server and/or another server.
In some embodiments, the user device can receive the requested headers through one or more responses that are sent by the server in response to the requests. In some embodiments, the user device can also cache the received headers in a suitable manner. For example, each of the headers can be cached as an Extensible Binary Meta Language (EBML) file.
In some embodiments, the user device can request one or more media content fragments from the server. For example, the user device can request one or more cluster elements of one or more Matroska container files stored on the server. In a more particular example, the user device can request a cluster element of a Matroska container file (e.g., a video file containing suitable video data) based on the streaming conditions (e.g., such as the bandwidth, the hardware capacity, etc. that can be utilized to stream media content) that is experienced by the user device.
In some embodiments, upon receiving the requested media content fragments from the server, the user device can cache the media content fragments. For example, the user device can cache each media content fragment in an EBML file upon receiving the media content fragment. In some embodiments, the user device can also update the cached top level index file to include information about the cached media content fragments. For example the cached top level index file can be updated to include one or more URIs corresponding to each EBML file that stores the cached media content fragment.
In some embodiments, after one or more media content fragments are cached (e.g., in multiple EBML files, respectively), the user device can cause the cached media content to be rendered. For example, the user device can cause cached video content, audio content, subtitles, etc. to be rendered based on the cached top level index file, the cached headers, and/or any other suitable information. In a more particular example, the user device can retrieve multiple EBML files that store the cached media content fragments based on the top level index file (e.g., using the URIs corresponding to each EBML file). The user device can then extract the media content stored in the EBML files, decode the media content, and cause the decoded media content to be rendered.
In some embodiments, the cached media content can be rendered at any suitable time. For example, the cached media content can be rendered when the user device is streaming and/or downloading media content from the server. As another example, the cached media content can be rendered after the user device has finished streaming and/or caching media content from the server. In a more particular example, the user device can cause the cached media content to be rendered in response a user requesting a playback of part or all of the cached media content at any time with or without a live communication connection with the server.
Turning to FIG. 1, a generalized block diagram of an example 100 of an architecture of hardware that can be used to stream media content in accordance with some embodiments is shown. As illustrated, architecture 100 can include a media content source 102, one or more servers 104, a communications network 106, one or more user devices 108, and communications paths 110, 112, 114, and 116.
Media content source 102 can include any suitable device that can provide media content. For example, media content source 102 can include any suitable circuitry that is capable of encoding media content, such as one or more suitable video encoders, audio encoders, video decoders, audio decoders, etc. In a more particular example, media content source 102 can include one or more suitable video encoders that are capable of encoding video content into different versions, each of which can have a particular bit rate, a particular resolution, a particular frame rate, a particular bit depth, etc.
As another example, media content source 102 can include one or more types of content distribution equipment for distributing any suitable media content, including television distribution facility equipment, cable system head-end equipment, satellite distribution facility equipment, programming source equipment (e.g., equipment of television broadcasters, such as NBC, ABC, HBO, etc.), intermediate distribution facility equipment, Internet provider equipment, on-demand media server equipment, and/or any other suitable media content provider equipment. NBC is a trademark owned by the National Broadcasting Company, Inc., ABC is a trademark owned by the ABC, INC., and HBO is a trademark owned by the Home Box Office, Inc.
Media content source 102 may be operated by the originator of content (e.g., a television broadcaster, a Webcast provider, etc.) or may be operated by a party other than the originator of content (e.g., an on-demand content provider, an Internet provider of content of broadcast programs for downloading, etc.).
Media content source 102 may be operated by cable providers, satellite providers, on-demand providers, Internet providers, providers of over-the-top content, and/or any other suitable provider(s) of content.
Media content source 102 may include a remote media server used to store different types of content (including video content selected by a user) in a location remote from any of the user equipment devices. For example, media content source 102 can include one or more content delivery networks (CDN).
As referred to herein, the term “media content” or “content” should be understood to mean one or more electronically consumable media assets, such as television programs, pay-per-view programs, on-demand programs (e.g., as provided in video-on-demand (VOD) systems), Internet content (e.g., streaming content, downloadable content, Webcasts, etc.), movies, films, video clips, audio, audio books, and/or any other media or multimedia and/or combination of the same. As referred to herein, the term “multimedia” should be understood to mean media content that utilizes at least two different content forms described above, for example, text, audio, images, video, or interactivity content forms. Media content may be recorded, played, displayed or accessed by user equipment devices, but can also be part of a live performance. In some embodiments, media content can include over-the-top (OTT) content. Examples of OTT content providers include YOUTUBE, NETFLIX, and HULU, which provide audio and video via IP packets. Youtube is a trademark owned by Google Inc., Netflix is a trademark owned by Netflix Inc., and Hulu is a trademark owned by Hulu, LLC.
Media content can be provided from any suitable source in some embodiments. In some embodiments, media content can be electronically delivered to a user's location from a remote location. For example, media content, such as a Video-On-Demand movie, can be delivered to a user's home from a cable system server. As another example, media content, such as a television program, can be delivered to a user's home from a streaming media provider over the Internet.
Server(s) 104 can be and/or include any suitable device that is capable of receiving, storing, processing, and/or delivering media content, and/or communicating with one or more user devices and/or other components of architecture 100 under one or more suitable protocols. For example, server(s) 104 can include any suitable circuitry that can receive requests, process requests, send responses, and/or perform other functions under a Hypertext Transfer Protocol (HTTP), a Transmission Control Protocol (TCP), etc.
In some embodiments, server(s) 104 can store media content that can be delivered to one or more components of architecture 100 in a suitable manner. For example, the media content can be stored in one or more suitable multimedia containers, such as Matroska media containers, Audio Video Interleaved (AVI) media containers, MPEG-4 Part 14 (MP4) media containers, etc.
In a more particular example, as illustrated in FIG. 2, server(s) 104 can store one or more Matroska container files 210 and one or more top level index file 220.
Matroska container files 210 can include any suitable files containing data about suitable media content, such as video content, audio content, subtitles, etc. For example, Matroska container files 210 can include one or more MKV files that can include data about video content, audio content, subtitles, etc. As another example, Matroska container files 210 can include one or more MKA files that can include audio data. As yet another example, Matroska container files 210 can include one or more MKS files that can include data about subtitles. As yet another example, Matroska container files 210 can include one or more MK3D files that can include data about stereoscopic video content.
In a more particular example, Matroska container files 210 can include one or more video files, such as video files 212 and 214 as illustrated in FIG. 2. In some embodiments, each of video files 212 and 214 can include data about video content having a particular bit rate, a particular resolution, a particular frame rate, etc. In some embodiments, each of video files 212 and 214 can contain a version of particular video content. More particularly, for example, video file 212 can contain a version of the particular video content including encoded video content having a first bit rate (and/or a first frame rate, a first resolution, etc.). Video file 214 can contain a version of the particular video content including encoded video content having a second bit rate (and/or a second frame rate, a second resolution, etc.).
Although two video files are shown in FIG. 2 to avoid over-complicating the drawing, any suitable number of these video files can be used in some embodiments. For example, Matroska container files 210 can include multiple video files (e.g., nine files or any suitable number of files), where each video file contains a version of particular video content (e.g., encoded video content having a particular bit rate, a particular resolution, a particular frame rate, etc.).
In another more particular example, Matroska container files 210 can include one or more audio files, such as an audio file 216. In some embodiments, audio file 216 can contain audio content that is associated with the video content contained in one or more video files, such as video files 212 and 214.
In yet another more particular example, Matroska container files 210 can include one or more files that contain subtitles associated with suitable video content and/or audio content, such as a subtitle file 218. In some embodiments, subtitle file 218 can contain data about subtitles that relate to the video content contained in video files 212 and 214 and/or the audio content contained in audio file 216.
In some embodiments, each of Matroska container files 210 can have a structure as illustrated in FIG. 3. As shown, Matroska container file 300 can include a header element 310, one or more cluster elements 320, an index element 330, and/or any other suitable components.
Header element 310 can include any suitable information relating to Matroska container file 300, such as a description of file 300, the version of file 300, etc. Header element 310 can also include any suitable information relating to the media content stored in file 300, such as the bit rate, the resolution, the frame rate, etc. of the media content.
In some embodiments, header element 310 can include an Extensible Binary Meta Language (EBML) element 311, one or more segment elements 312, and/or any other suitable components.
In some embodiments, EBML element 311 can include information about EBML version of the file, the type of EBML file (e.g., a Matroska file), etc.
Segment element 312 can contain any suitable data about media content, header, etc. In some embodiments, segment element 312 can include a seekhead element 313, a segmentinfo element 314, a tracks element 315, and/or any other suitable components.
In some embodiments, seekhead element 313 can include any suitable information about one or more components of segment element 312, such as a list of the positions of the components of segment element 312 (e.g., such as segmentinfo element 314, tracks element 315, etc.). Segmentinfo element 314 can include any suitable information about segment element 312 and/or file 300, such as the duration of the media content contained in segment element 312, an identification number corresponding to segment element 312 (e.g., a randomly generated unique number that can be used to identify segment element 312), a title of segment element 312 and/or file 300, etc. Tracks element 316 can include any suitable information about one or more media tracks that are stored in segment element 312, such as the type of each of the tracks (e.g., audio, video, subtitles, etc.), the codec used to generate each of the tracks, the resolution of video content, the frame rate of video content, the bit depth of video content, etc.
Cluster element 320 can contain any suitable information relating to media content, such as video content, audio content, subtitles, etc. For example, cluster element 320 can contain video data, audio data, or subtitles corresponding to media content having a particular duration (e.g., two seconds, or any suitable duration). As another example, cluster element 320 can also contain a timecode element that can indicate the start time of the media content contained in cluster element 320.
In a more particular example, cluster element 320 can include one or more blockgroup elements 322. Blockgroup element 322 can include any suitable information relating to a part of or all of the media content data contained in cluster element 320. For example, blockgroup element 322 can contain one or more block elements 324, each of which can contain a block of media content data (e.g., video data, audio data, subtitles, etc.) that can be rendered by a user device.
As another example, blockgroup element 322 can also contain any suitable information relating to the block of media content data, such as the start time of the media content, the duration of the media content, the type of media content data contained in blockgroup element 322 (e.g., video, audio, subtitles, etc.), etc. In a more particular example, blockgroup element 322 can include one or more suitable timecodes corresponding to the start time, the end time, the duration, and/or other suitable information of the media content contained in blockgroup element 322.
In some embodiments, file 300 can include multiple cluster elements 320 (e.g., cluster element 321, cluster element 326, . . . , and cluster element 328). In some embodiments, for example, each of the cluster elements can contain data about a portion of a piece of media content. In a more particular example, each cluster element can contain a portion of the piece of media content having the same duration (e.g., such as two seconds, or any other suitable duration). More particularly, for example, cluster elements 321 and 326 can contain data about a first portion of the piece of media content (e.g., the first two seconds of the media content), a second portion of the piece of media content (e.g., the second two seconds of the media content), respectively.
In some embodiments, multiple Matroska container files can contain cluster elements corresponding to the same portion of the piece of media content. For example, in the example where video file 212 and video file 214 (FIG. 2) contain different versions of the same source media content, the first cluster element of video file 212 (e.g., cluster element 321 of FIG. 3) and the first cluster element of video file 214 (e.g., cluster element 321 of FIG. 3) can contain different versions of the first portion of the piece of media content (e.g., encoded video content having different bit rates, resolutions, frame rates, etc.). In some embodiments, the first cluster element of audio file 216 and the first cluster element of subtitle file 218 can contain audio data and subtitles corresponding to the first portion of the media content.
Referring back to FIG. 3, index element 330 can include any suitable information relating to identifying one or more cluster elements 320 or any suitable portions of the cluster elements. For example, index element 330 can include one or more Cues elements 332 that can contain any suitable information that can be used to identify and/or seek one or more cluster elements, block elements, etc. In a more particular example, Cues element 332 can include one or more timecodes containing information about the duration, the start time, the end time, etc. of the media content contained in one or more cluster elements, block elements, video frames, etc. In another more particular example, cues element 332 can include a list of positions of multiple cluster elements, block elements, video frames, etc. More particularly, for example, the list of positions can include the positions of the cluster elements, block elements, video frames, etc. associated with a particular timecode.
Referring back to FIG. 2, top level index file 220 can be any suitable file containing any suitable information relating to one or more of Matroska container files 210. In some embodiments, for example, top level index file 220 can be a Synchronized Multimedia Integration Language (SMIL) file, an Extensible Markup Language (XML) file, a HyperText Markup Language (HTML) file, etc.
In some embodiments, for example, top level index file 220 can include any suitable information concerning the media content contained in one or more of Matroska container files 210. In a more particular example, top level index file 220 can include information about the bit rates, frames rates, resolutions, etc. of the video content contained in video files 212 and 214.
In some embodiments, top level index file 220 can also include any suitable information that can be used to identify and/or seek one or more of Matroska container files 210 and/or any suitable portions of Matroska container files 210. For example, top level index file 220 can include information that can be used to identify one or more resources from which one or more of Matroska container files 210 can be obtained, such as the names of the resources, the locations of the resources, etc. In a more particular example, top level index file 220 can include one or more uniform resource identifiers (URIs) associated with one or more of Matroska container file 220 (e.g., such as video file 212, video file 214, audio file 216, subtitle file 218, etc.). In another more particular example, top level index file 210 can also include one or more URIs associated with one or more header elements, cluster elements, block elements, segment elements, index elements, etc. of one or more Matroska container files 210.
Referring back to FIG. 1, system 100 can also include one or more user devices 108. Each user device 108 can be any suitable device that is capable of receiving, processing, converting, and/or rendering media content, and/or performing any other suitable functions. For example, system 100 can include a desktop computer, a laptop computer, a tablet computer, a mobile phone, a television device, a set-top box, a streaming media player, a digital media receiver, a DVD player, a BLU-RAY player, a game console, etc., and/or any other suitable combination of the same.
In some embodiments, communications network 106 may be any one or more networks including the Internet, a mobile phone network, a mobile voice, a mobile data network (e.g., a 3G, 4G, or LTE network), a cable network, a satellite network, a public switched telephone network, a local area network, a wide area network, a fiber-optic network, any other suitable type of communications network, and/or any suitable combination of these communications networks.
In some embodiments, media content source 102, server(s) 104, communications network 106, and user device(s) 108 can be implemented in any suitable hardware. For example, each of media content source 102, server(s) 104, communications network 106, and user device(s) 108 can be implemented in any of a general purpose device such as a computer or a special purpose device such as a client, a server, mobile terminal (e.g., mobile phone), etc. Any of these general or special purpose devices can include any suitable components such as a hardware processor (which can be a microprocessor, digital signal processor, a controller, etc.). In some embodiments, each of media content source 102, server(s) 104, communications network 106, and user device(s) 108 can include a suitable storage device, such as random-access memory, read-only memory, hard drives, optical drives, digital video disc (DVD) recorders, compact disc (CD) recorders, BLU-RAY disc (BD) recorders, BLU-RAY 3D disc recorders, digital video recorders (DVR, sometimes called a personal video recorder, or PVR), solid state devices, quantum storage devices, gaming consoles, gaming media, or any other suitable fixed or removable storage devices, and/or any combination of the same.
In some embodiments, each of media content source 102, server(s) 104, communications network 106, and user device(s) 108 can be implemented as a stand-alone device or integrated with other components of architecture 100.
In some embodiments, media content source 102 can be connected to server(s) 104 and communications network 106 through communications paths 110 and 112, respectively. In some embodiments, communications network 106 can be connected to server(s) 104 and user device(s) 108 through communications paths 114 and 116, respectively.
Communications paths 110, 112, 114, and 116 may separately or together include one or more communications paths, such as, a satellite path, a fiber-optic path, a cable path, a path that supports Internet communications (e.g., IPTV), free-space connections (e.g., for broadcast or other wireless signals), or any other suitable wired or wireless communications path or combination of such paths, in some embodiments.
Turning to FIG. 4, an example 400 of a process for streaming and storing media content in accordance with some embodiments of the disclosure is shown. In some embodiments, process 400 can be implemented in a suitable user device (such as user device 108 of in FIG. 1).
As illustrated, process 400 can begin by requesting a top level index file at 402. The top level index file can be requested in any suitable manner. For example, the user device can request the top level index file by sending one or more requests containing information about the name of the top level index file, the resources from which the top level index file can be obtained, the location of the top level index file, etc. under a suitable protocol (e.g., such as HTTP, TCP, etc.). In a more particular example, the user device can send to the server one or more HTTP requests containing information about one or more URIs associated with the top level index file to the server.
Next, at 404, the user device can receive a top level index file from the server. The top level index file can be received in any suitable manner. For example, the top level index file can be received via one or more responses that are sent by the server. In a more particular example, in the example described above where one or more HTTP requests are used to request the top level index file, the user device can receive the top level index file via one or more HTTP responses that are sent by the server in response to the HTTP requests.
In some embodiments, the top level index file can include any suitable information relating to one or more media content files (e.g., such as Matroska container files, etc.). In a more particular example, top level index file 220 as described above in connection with FIG. 2 can be received at 404.
In some embodiments, the top level index file can be received in any suitable format. For example, the received top level file can be a SMIL file, an XML file, etc.
At 406, the user device can store the received top level index file. The top level index file can be stored in any suitable manner. For example, the top level index file can be cached in a suitable format (e.g., as an index file 710 of FIG. 7 that can be a SMIL file, an XML file, etc.). In a more particular example, as shown in FIG. 6, the cached top level index file 710 can include any suitable portions of SMIL file 600 as shown in FIG. 6.
At 408, the user device can request one or more headers associated with one or more Matroska container files. Each of the headers can contain any suitable information relating to the version of its corresponding Matroska container file, the media content contained in the Matroska container file, the components of the Matroska container file, etc. For example, each of the headers can include one or more header elements of a Matroska container file (e.g., such as video files 212 or 214, audio file 216, subtitle file 218, etc. as illustrated in FIG. 2). In a more particular example, as described above in connection with FIG. 3, each of the headers can include an EBML element, a segment element, a seekhead element, a segmentinfo element, a tracks elements, and/or any other suitable components.
In some embodiments, the headers can be requested in any suitable manner. For example, the headers can be requested based on the top level index file received at 404. In a more particular example, the user device can parse the top level index file and obtain information relating to one or more URIs corresponding to the headers. The user device can then send one or more requests (e.g., HTTP requests, etc.) containing the URIs to the server.
At 410, the user device can receive one or more headers associated with one or more Matroska container files. The headers can be received in any suitable manner. For example, the headers can be received via one or more responses that are sent by the server. In a more particular example, in the example described above where one or more HTTP requests are used to request the headers, the user device can receive the headers via one or more HTTP responses that are sent by the server in response to the HTTP requests.
More particularly, for example, one or more of a header of a video file (e.g., video file 212 and/or video file 214 of FIG. 2), a header of an audio file (e.g., audio file 216 of FIG. 2), and a header of a subtitle file (e.g., subtitle file 218 of FIG. 2) can be received in response to the requests sent at 408.
Next, at 412, the user device can store the received headers and update the top level index file. The headers can be stored in any suitable manner. For example, each of the received headers can be cached as a Matroska container file. In a more particular example, as illustrated in FIG. 7, each of the header of the video file (e.g., video file 212 of FIG. 2), the header of the audio file (e.g., audio file 216 of FIG. 2), and the header of the subtitle file (e.g., subtitle file 218 of FIG. 2) can be cached as an EBML file, i.e., header file 722, header file 732, and header file 742, respectively. In some embodiments, each of header files 722, 742, and 752 can have a structure similar to header element 310 of FIG. 3.
In some embodiments, in response to caching the header file(s), the user device can update the top level index file. The top level index file can be updated in any suitable manner. For example, the top level index file can be updated to include information relating to the one or more headers that have been received and cached, such as the location of the header file(s), the size of the header file(s), etc.
At 414, the user device can request fragment index information. Any suitable fragment index information can be requested. For example, the user device can request one or more index elements associated with one or more Matroska container files as described above in connection with FIGS. 2 and 3. Alternatively or additionally, the user device can request one or more suitable portions of the index elements from the server.
The fragment index information can be requested in any suitable manner. For example, the user device can request the fragment index information based on the top level index file received at 404. In a more particular example, the user device can parse the top level index file and obtain information relating to one or more URIs corresponding to the fragment index information. The user device can then send one or more requests (e.g., HTTP requests, etc.) containing the URIs to the server.
As another example, the user device can request the fragment index information based on one or more of the headers received at 410. In a more particular example, the user can make such requests based on information relating to the location of the fragment index information (e.g., such as a seekhead element of a header).
At 416, the user device can receive the requested fragment index information. The fragment index information can be received in any suitable manner. For example, the fragment index information can be received via one or more responses that are sent by the server. In a more particular example, in the example described above where one or more HTTP requests are used to request the fragment index information, the user device can receive the fragment index information via one or more HTTP responses that are sent by the server in response to the HTTP requests. In some embodiments, the user device does not need to cache or store the received fragment index information.
At 418, the user device can request one or more media content fragments from the server. Any suitable media content fragments can be requested. For example, the user device can request one or more cluster elements of one or more Matroska container files containing media content corresponding to a particular timecode (e.g., such as a particular start time and/or a particular end time). In a more particular example, the user device can request one or more cluster elements of a video file (e.g., video file 212 and/or 214 of FIG. 2), an audio file (e.g., audio file 216 of FIG. 2), a subtitle file (e.g., subtitle file 218 of FIG. 2) that contain media content corresponding to the particular timecode.
As another example, the user device can request one or more media content fragments containing media content having a particular version. In a more particular example, the user device can request a Cluster element of a video file that contains encoded video content having a particular bit rate, a particular frame rate, a particular resolution, etc.
In some embodiments, the media content fragments can be requested in any suitable manner. For example, the user device can request the media content fragment(s) based on the streaming conditions experienced by the user device, such as the network bandwidth, the processor capacity, etc. that can be utilized to transmit media content, one or more user preferences (e.g., such as a desired resolution, a desired bit rate, etc.), etc. In a more particular example, upon determining the network bandwidth that can be utilized to transmit media content, the user device can request a cluster of a video file (e.g., video file 212, video file 214, etc. as illustrated in FIG. 2) containing encoded video content having a suitable bit rate that can be transmitted using the network bandwidth.
As another example, the user device can send to the server one or more requests containing information relating to the names of the media content fragments, the resources from which the media content fragments can be obtained, and/or other suitable information relating to the media content fragments using a suitable protocol (e.g., such as HTTP, TCP, etc.). In a more particular example, the requests can contain one or more URIs corresponding to the media content fragments to be requested. In some embodiments, the URIs can be obtained based on the top level index file. More particularly, for example, the user device can parse the top level index file received at 404 and obtain one or more URIs corresponding to one or more cluster elements to be requested.
At 420, the user device can receive one or more media content fragments. The media content fragments can be received in any suitable manner. For example, the media content fragments can be received via one or more responses that are sent by the server. In a more particular example, in the example described above where one or more HTTP requests are used to request the media content fragments, the user device can receive the media content fragments via one or more HTTP responses that are sent by the server in response to the HTTP requests.
In some embodiments, in response to receiving the media content fragment, the user device can extract media content data (e.g., such as video data, audio data, subtitles, etc.) from the media content fragments. The user device can then decode the media content data and cause the decoded media content to be rendered. For example, in response to receiving a cluster of a video file as described above, the user device can extract encoded video data from the block elements of the cluster element. The user device can then decode the encoded video data and cause the decoded video data to be displayed on a suitable display. In a more particular example, the decoded video data can be displayed based on one or more timecodes associated with the cluster element.
Next, at 422, the user device can store the received media content fragments and update the top level index file. The media content fragments can be stored in any suitable manner. For example, upon receiving a cluster element of a Matroska container file (e.g., such as Matroska container files 210 of FIG. 2), the user device can cache the cluster element as a Matroska container file. In a more particular example, in response to receiving a cluster element of video file 212 of FIG. 2 (e.g., cluster element 321 as shown in FIG. 3), the user device can cache the received cluster element as an EBML file 724 as shown in FIG. 7. In another more particular example, in response to receiving a cluster of an audio file (e.g., audio file 216 of FIG. 2), the user device can cache the cluster element as an EBML file 734 as shown in FIG. 7. In yet another more particular example, in response to receiving a cluster of a subtitle file (e.g., subtitle file 218 of FIG. 2), the user device can cache the cluster element as an EBML file 744 as shown in FIG. 7.
In some embodiments, in response to caching the media content fragments, the user device can update the top level index file that has been stored in the user device. The top level index file can be updated in any suitable manner. For example, the user device can edit the top level index file to include information relating to the EBML file that stores the media content fragments.
In a more particular example, in the example described above where a cluster of video file 212 (FIG. 2) is cached as EBML file 724, the user device can include a video element 610 in top level index file 600 of FIG. 6 corresponding to EBML file 724. As shown, video element 610 can include a URI element 612, a start-time element 614, an end-time element 616, and a param element 618. URI element 612 can include any suitable information relating to the name of the cached EBML file, the location of the EBML file, and/or any other suitable information about the cached EBML file. In a more particular example, URI element 612 can include a file path through which EBML file 724 can be retrieved.
In some embodiments, start-time element 614 and end-time element 616 can contain information about the start time and the end time of the media content contained in the cached cluster element, respectively.
In some embodiments, param element 618 can include any suitable information about the cached EBML file. For example, param element 618 can include information about the size of the cached EBML file. As another example, param element 618 can include information about the bit rate, the resolution, the frame rate, etc. of the media content contained in the cached EBML file.
In some embodiments, in response to receiving and/or caching the media content fragment, the user device can extract media content data (e.g., such as video data, audio data, subtitles, etc.) from the media content fragments. The user device can then decode the media content data and cause the decoded media content to be rendered. For example, in response to receiving a cluster of a video file as described above, the user device can extract encoded video data from the block elements of the cluster element. The user device can then decode the encoded video data and cause the decoded video data to be displayed on a suitable display. In a more particular example, the decoded video data can be displayed based on one or more timecodes associated with the cluster element.
Referring back to FIG. 4, in some embodiments, after step 422 is performed, process 400 can loop back to 418. That is, process 400 can request, receive, and/or cache one or more media content fragments. The media content fragments can be requested in any suitable manner. For example, process 400 can request a Cluster element corresponding to a particular timecode. In a more particular example, in the example where cluster 321 (FIG. 3) of audio file 216 (FIG. 2) has been cached as EBML file 734, the user device can request and receive cluster element 326 (FIG. 3) of audio file 216 (FIG. 2) and cache the received cluster element as an EBML file 736 as illustrated in FIG. 7.
In another more particular example, in the example where cluster 321 (FIG. 3) of subtitle file 218 (FIG. 2) has been cashed as EBML file 744, the user device can request and receive cluster element 326 (FIG. 3) of subtitle file 218 (FIG. 2) and cache the received Cluster element as an EBML file 746 as illustrated in FIG. 7.
As another example, process 400 can also request a cluster element of a Matroska container file that contains a particular version of a piece of media content based on the streaming conditions experienced by the user device and/or user preferences. More particularly, for example, the user device can determine the bandwidth, the processor capacity, etc. that can be utilized to transmit media content. Alternatively or additionally, the user device can determine a particular frame rate, a particular resolution, and/or other parameters about the media content to be rendered that are preferred by a user. The user device can then request a cluster element containing video data having a suitable bit rate, a suitable frame rate, a suitable resolution, etc. based on the streaming conditions and/or user preferences.
In a more particular example, in the example where cluster 321 (FIG. 3) of video file 212 (FIG. 2) has been cashed as EBML file 724, the user device can request and receive cluster element 326 (FIG. 3) of video file 212 (FIG. 2) in response to determining that video file 214 (FIG. 2) contains video content having the suitable bit rate, frame rate, and/or resolution. The user device can also cache the received Cluster element as an EBML file 726 of FIG. 7.
In some embodiments, upon caching EBML file 726 (FIG. 7), the user device can also update top level index file 600 to include suitable information relating to EBML file 726. In a more particular example, as illustrated in FIG. 6, the user device can include a video element 620 in top level index file 600 corresponding to EBML file 726. As shown, video element 620 can include any suitable information relating to the name of the cached EBML file, the location of the EBML file, and/or any other suitable information about the cached EBML file, such as a file path through which EBML file 726 can be retrieved.
In some embodiments, each of the top level index file, the header file(s), the media content fragments, and other media content files (e.g., the EBML files as illustrated in FIG. 7) can be stored/cached for any suitable period of time. For example, a suitable cache duration can be specified for each of the stored/cached files, such as seconds, minutes, hours, days, weeks, months, or any suitable period of time. As another example, no particular cache duration needs to be specified for the stored/cached files. In such an example, the content stored/cached in the files can be stored for an indefinite duration and will not expire by time.
In some embodiments, upon caching/storing one or more EBML files as described above, the user device can cause the cached media content contained in the EBML files to be rendered. The cached media content can be rendered at any suitable time. For example, the cached media content can be rendered when the user device is streaming media content from the server (e.g., using process 400 or other suitable processes). In a more particular example, upon receiving one or more media content fragments, the user device can simultaneously cache the media content fragment(s) and render the media content contained in the media content fragment(s). In another more particular example, the user device can request, receive, and/or cache one or more media content fragments as fast as it can (e.g., by utilizing the available bandwidth, hardware capacity, etc.). The user device can then render the media content fragment(s).
As another example, the media content can be rendered after the user device has finished streaming and/or caching media content from the server. In a more particular example, the user device can cause the cached media content to be rendered upon a user requesting a playback of the cached media content at any time with or without a live communication connection with the server.
For example, the user device can retrieve the EBML files based on the cached top level index file. The user device can then extract the media content data (e.g., video data, audio data, subtitles, etc.) contained in the EBML files, decode the media content data, and cause the media content to be rendered based on the top level index file and/or one or more of the header files.
In a more particular example, as illustrated in FIG. 5, media content contained in multiple cashed/stored media content fragments can be rendered based on process 500. In some embodiments, process 500 can be implemented in a suitable user device (e.g., such as user device 108 of FIG. 1).
As shown, process 500 can begin by retrieving a first cached media content fragment at 502. For example, the user device can retrieve the first cached media content fragment based on the cached top level index file. More particularly, for example, the user device can parse the cached top level index file and extract data about the location of the media content file that contains the first cached media content fragment.
In a more particular example, as described above in connection with FIGS. 4, 6, and 7, the cached top level index file can include URI element 612 that is associated with EBML file 724 (FIG. 7) containing the first cached media content fragment. In such an example, the user device can locate EBML file 724 based on URI element 612 (e.g., by converting the URI into one or more files paths corresponding to the location of EBML file 724).
In some embodiments, upon retrieval of the first cached media content fragment, the user device can render the first cached media content fragment at 504. The first cached media content fragment can be rendered in any suitable manner. For example, the user device can extract and decode the media content data (e.g., video data, audio data, subtitles, etc.) from the retrieved EBML file. The user device can then cause the decoded media content data to be rendered. In a more particular example, the decoded content data can be rendered based on the cached header file (e.g., header file 722 of FIG. 7).
Next, at 506, the user device can determine whether the retrieved media content fragment is the last cached media content fragment to be retrieved and/or rendered. Such determination can be made in any suitable manner. For example, the user device can check the cached top level index file (e.g., top level index file 600 of FIG. 6) and determine whether all the cached media content files linked to the cached top level index file have been retrieved and/or rendered. As another example, a user can select one or more cached media content fragments to be rendered (e.g., one or more cached media content fragments corresponding to a scene of a movie, etc.). In such an example, the user device can determine whether all of the selected cached media content fragments have been retrieved and/or rendered at 506.
In some embodiments, in response to determining that the retrieved media content fragment is the last cached media content fragment to be retrieved and/or rendered, process 500 can end at 508.
In some embodiments, in response to determining that the retrieved media content fragment is not the last cached media content fragment to be retrieved and/or rendered, the user device can retrieve the next cached media content fragment at 510. For example, the user device can retrieve the second cached media content fragment based on the cached top level index file. More particularly, for example, the user device can parse the cached top level index file and extract data about the location of the media content file that contains the second cached media content fragment. In a more particular example, as described above in connection with FIGS. 4, 6, and 7, the cached top level index file can include URI element 622 associated with EBML file 726 (FIG. 7) that contains the second cached media content fragment. In such an example, the user device can locate EBML file 726 based on URI element 622 (e.g., by converting the URI into one or more files paths corresponding to the location of EBML file 726).
In some embodiments, in response to retrieval of the second cached media content fragment, the user device can render the second cached media content fragment at 512. The second cached media content fragment can be rendered in any suitable manner. For example, the user device can extract and decode the media content data (e.g., video data, audio data, subtitles, etc.) from the retrieved EBML file (e.g., EBML file 726 of FIG. 7). The user device can then cause the decoded media content data to be rendered. In a more particular example, the decoded content data can be rendered based on the cached header file (e.g., header file 722 of FIG. 7).
In some embodiments, after 512 is performed, process 500 can loop back to 506.
In some embodiments, the user device can cause a cached media content fragment to be rendered upon retrieval of the cached media content fragment. In some embodiments, the user device can retrieve multiple cached media content fragments and cause some or all of the retrieved media content fragments to be rendered in a suitable order.
It should be noted that process 400 of FIG. 4 and process 500 of FIG. 5 can be performed concurrently in some embodiments. It should also be noted that the above steps of the flow diagrams of FIGS. 4-5 may be executed or performed in any order or sequence not limited to the order and sequence shown and described in the figures. Furthermore, it should be noted, some of the above steps of the flow diagrams of FIGS. 4-5 may be executed or performed substantially simultaneously where appropriate or in parallel to reduce latency and processing times. And still furthermore, it should be noted, some of the above steps of the flow diagrams of FIGS. 4-5 may be omitted.
In some embodiments, any suitable computer readable media can be used for storing instructions for performing the mechanisms and/or processes described herein. For example, in some embodiments, computer readable media can be transitory or non-transitory. For example, non-transitory computer readable media can include media such as magnetic media (such as hard disks, floppy disks, etc.), optical media (such as compact discs, digital video discs, Blu-ray discs, etc.), semiconductor media (such as flash memory, electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), etc.), any suitable media that is not fleeting or devoid of any semblance of permanence during transmission, and/or any suitable tangible media. As another example, transitory computer readable media can include signals on networks, in wires, conductors, optical fibers, circuits, any suitable media that is fleeting and devoid of any semblance of permanence during transmission, and/or any suitable intangible media.
The above described embodiments of the present disclosure are presented for purposes of illustration and not of limitation, and the present disclosure is limited only by the claims which follow.

Claims

What is claimed is:

1. A method for streaming media content, the method comprising:

receiving top level index data from a server;

caching the top level index data in an index file;

receiving header data associated with a first media content file from the server;

caching the header data in a header file;

receiving a first segment of the first media content file based at least in part on the index file;

caching the first segment of the first media content file in a first file;

updating the index file to include information about the first file; and

causing the first fragment to be displayed based at least in part on the index file and the header file.

2. The method of claim 1, further comprising:

receiving a second segment of a second media content file based at least in part on the index file;

caching the second segment of the second media content file in a second file;

updating the index file to include information about the location of the second file; and

causing the second segment to be displayed based at least in part on the updated index file and the header file.

3. The method of claim 2, wherein the second media content file and the first media content file contain encoded video data having different bit rates.

4. The method of claim 2, wherein the second media content file and the first media content file contain encoded video data having different frame rates.

5. The method of claim 2, wherein the second media content file and the first media content file contain encoded video data having different resolutions.

6. The method of claim 2, further comprising retrieving the second file based on the updated index file.

7. The method of claim 1, further comprising:

obtaining at least one Uniform Resource Identifier (URI) corresponding to the first segment based on the index file; and

requesting the first segment from a server based on the at least one URI.

8. The method of claim 7, further comprising:

obtaining at least one URI corresponding to the second segment based on the index file; and

requesting the second segment from the server based on the at least one URI.

9. The method of claim 1, further comprising:

requesting fragment index data based at least in part on the top level index file; and

receiving the fragment index data from the server.

10. The method of claim 1, further comprising retrieving the first file based on the updated index file.

11. The method of claim 1, further comprising simultaneously caching the first segment of the first media content file and causing the first fragment to be displayed.

12. The method of claim 1, wherein the first file is a Matroska container file.

13. A system for streaming media content, the system comprising:

at least one hardware processor that is configured to:

receive top level index data from a server;

cache the top level index data in an index file;

receive header data associated with a first media content file from the server;

cache the header data in a header file;

receive a first segment of the first media content file based at least in part on the index file;

cache the first segment of the first media content file in a first file;

update the index file to include information about the first file; and

cause the first fragment to be displayed based at least in part on the index file and the header file.

14. The system of claim 13, wherein the at hardware processor is further configured to:

receive a second segment of a second media content file based at least in part on the index file;

cache the second segment of the second media content file in a second file;

update the index file to include information about the location of the second file; and

cause the second segment to be displayed based at least in part on the updated index file and the header file.

15. The system of claim 14, wherein the second media content file and the first media content file contain encoded video data having different bit rates.

16. The system of claim 14, wherein the second media content file and the first media content file contain encoded video data having different frame rates.

17. The system of claim 14, wherein the second media content file and the first media content file contain encoded video data having different resolutions.

18. The system of claim 14, wherein the hardware processor is further configured to retrieve the second file based on the updated index file.

19. The system of claim 13, wherein the hardware processor is further configured to:

obtain at least one Uniform Resource Identifier (URI) corresponding to the first segment based on the index file; and

request the first segment from a server based on the at least one URI.

20. The system of claim 19, wherein the hardware processor is further configured to:

obtain at least one URI corresponding to the second segment based on the index file; and

request the second segment from the server based on the at least one URI.