WO2014193996A2 - Diffusion vidéo en continu sur un réseau, avec trick play basé sur des fichiers trick play séparés - Google Patents

Diffusion vidéo en continu sur un réseau, avec trick play basé sur des fichiers trick play séparés Download PDF

Info

Publication number
WO2014193996A2
WO2014193996A2 PCT/US2014/039852 US2014039852W WO2014193996A2 WO 2014193996 A2 WO2014193996 A2 WO 2014193996A2 US 2014039852 W US2014039852 W US 2014039852W WO 2014193996 A2 WO2014193996 A2 WO 2014193996A2
Authority
WO
WIPO (PCT)
Prior art keywords
trick play
video
files
stream
playlist
Prior art date
Application number
PCT/US2014/039852
Other languages
English (en)
Other versions
WO2014193996A3 (fr
Inventor
Abhishek Shivadas
Stephen R. BRAMWELL
Original Assignee
Sonic Ip, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/905,867 external-priority patent/US20140359678A1/en
Priority claimed from US13/905,852 external-priority patent/US9094737B2/en
Application filed by Sonic Ip, Inc. filed Critical Sonic Ip, Inc.
Publication of WO2014193996A2 publication Critical patent/WO2014193996A2/fr
Publication of WO2014193996A3 publication Critical patent/WO2014193996A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/78—Television signal recording using magnetic recording
    • H04N5/782—Television signal recording using magnetic recording on tape
    • H04N5/783—Adaptations for reproducing at a rate different from the recording rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47217—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for controlling playback functions for recorded or on-demand content, e.g. using progress bars, mode or play-point indicators or bookmarks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection

Definitions

  • Distribution of multimedia video (also referred to herein as “media” and/or “program(s)”), such as movies and the like, from network services to a client device, may be achieved through adaptive bitrate streaming of the video.
  • the video Prior to streaming, the video may be encoded at different bitrates and resolutions into multiple bitrate streams that are stored in the network services.
  • each of the bitstreams includes time-ordered segments of encoded video.
  • Adaptive bitrate streaming includes determining an available streaming bandwidth at the client device, and then downloading a selected one of the different bitrate streams from the network services to the client device based on the determined available bandwidth. While streaming, the client device downloads and buffers the successive encoded video segments associated with the selected bitstream. The client device decodes the buffered encoded video segments to recover the video therein, and then plays back the recovered video on the client device, e.g., in audio-visual form.
  • the client device plays back the video recovered from each of the buffered segments in the order in which the video was originally encoded, i.e., in a forward direction.
  • the client device may offer playback modes or features in addition to normal playback. Such additional playback features may include rewind, fast forward, skip, and so on, as is known.
  • trick play features The additional playback features are referred to herein as trick play features.
  • trick play features such as rewind
  • the client device requires access to video that has already been played. Therefore, the client device may be required to store large amounts of already downloaded and played video in order to meet the demands of a selected trick play feature.
  • client devices especially small, hand-held devices, have limited memory capacity and, therefore, may be unable to store the requisite amount of video.
  • FIG. 1 is a block diagram of an example network environment that supports adaptive bitrate streaming of multimedia content, such as video, with trick play features.
  • FIG. 2 is an illustration of an example encoded multimedia video program generated by and stored in network services of FIG. 1 .
  • FIG. 3A is an illustration of an example adaptive bitrate frame structure of an encoded video block of FIG. 2.
  • FIG. 3B is an illustration of an example trick play frame structure of an encoded video block of FIG. 2.
  • FIG. 4 is a sequence diagram of example high-level interactions between network services and a client device used to initiate streaming, implement normal streaming and playback, and implement trick play features in streaming embodiments.
  • FIG. 5 is an example Profile message used in streaming.
  • FIG. 6 is an example Playlist message used in streaming.
  • FIG. 7 is a flowchart of an example network-side method of multimedia content streaming with trick play support based on trick play files, which may be implemented in the network services of FIG. 1 .
  • FIG. 8 is a flowchart of an example client-side method of multimedia content streaming with trick play support based on trick play files, which may be implemented in the client device of FIG. 1 .
  • FIG. 9A is a block diagram of an example computer system.
  • FIG. 9B is a block diagram of network/server-side application instructions which may execute in on a processor system similar to that of FIG. 9A.
  • FIG. 10 is a block diagram of an example computer system corresponding to any of the network servers in the environment of FIG. 1 .
  • FIG. 1 1 is a block diagram of an example system representing a client device of FIG. 1 .
  • the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears.
  • FIG. 1 is a block diagram of an example network environment 100 that supports adaptive bitrate streaming of multimedia content with trick play features.
  • Network services 102 encode multimedia content, such as video, into multiple adaptive bitrate streams of encoded video and a separate trick play stream of encoded video to support trick play features.
  • the trick play stream may be encoded at a lower encoding bitrate and a lower frame than each of the adaptive bitrate streams.
  • the adaptive bitrate and trick play streams are stored in network services 102.
  • a client device 104 downloads a selected one of the adaptive bitrate streams from network services 102 for playback at the client device.
  • a trick play feature such as rewind
  • the client device 104 downloads the trick play stream from network services 102 for trick play playback.
  • Environment 100 supports trick play features in different adaptive bitrate streaming embodiments, including on-demand streaming, live streaming, and real-time streaming embodiments.
  • On-demand streaming includes encoding the content of a program from start to end in its entirety and then, after the entire program has been encoded, streaming, i.e., downloading, the encoded program to a client device.
  • An example of on-demand streaming includes streaming a movie from a Video-on-Demand (VOD) service to a client device.
  • VOD Video-on-Demand
  • Live streaming includes encoding successive blocks of live content, i.e., a live program, as they are received from a content source, and then streaming each encoded block as it becomes available for download.
  • Live streaming may include streaming live scenes, i.e., video, captured with a video camera.
  • Real-time streaming is similar in most aspects to live streaming, except that the input to real-time streaming is not a live video feed. Rather, the input, or source, may include successive encoded blocks, or input blocks, that have a format not suitable for streaming (e.g., for a given system) and must, therefore, be decoded and re-encoded (i.e., transcoded) into an encoded format that is suitable for streaming (in the given system). Real-time streaming handles the successive incompatible input blocks similar to the way live streaming handles the successive blocks of live content.
  • Network environment 100 includes server-side or network services 102 (also referred to simply as "services 102") and client-side device 104.
  • Network services 102 may be implemented as Internet cloud-based services.
  • Network services 102 interact and cooperate with each other, and with client device 104, to manage and distribute, e.g., stream, multimedia content from content sources 108 to the client devices, over one or more communication network 106, such as the Internet.
  • Network services 102 communicate with each other and with client devices 104 using any suitable communication protocol, such as an Internet protocol, which may include Transmission Control Protocol/Internet Protocol (TCP/IP), Hypertext Transfer Protocol (HTTP), etc., and other non-limiting protocols described herein.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • HTTP Hypertext Transfer Protocol
  • Content sources 108 may include any number of multimedia content sources or providers that originate live and/or pre-recorded multimedia content (also referred to herein simply as "content”), and provide the content to services 102, directly, or indirectly through communication network 106.
  • Content sources 108 such as Netflix®, HBO®, cable and television networks, and so on, may provide their content in the form of programs, including, but not limited to, entertainment programs (e.g., television shows, movies, cartoons, news programs, etc.), educational programs (e.g., classroom video, adult education video, learning programs, etc.), and advertising programs (e.g., commercials, infomercials, or marketing content).
  • Content sources 108 such as, e.g., video cameras, may capture live scenes provide the resulting real-time video to services 102.
  • Content sources may also include live broadcast feeds deployed using protocols such as Real-time Transport Protocol (RTP), and Real-time Messaging Protocol (RTMP).
  • RTP Real-time Transport Protocol
  • RTMP Real-time Messaging Protocol
  • Network services 102 include, but are not limited to: an encoder 1 10 to encode content from content sources 108; a content delivery network (CDN) 1 12 (also referred to as a “download server 1 12") to store the encoded content, and from which the stored, encoded content may be streamed or downloaded to client device 104; and a real-time service (RTS) 1 14 (also referred to as a “real-time server (RTS) 1 14”) to (i) control services 102, and (ii) implement an RTS streaming control interface through which client device 104 may initiate and then monitor both on-demand, live, and realtime streaming sessions.
  • Each of services 102 may be implemented as one or more distinct computer servers that execute one or more associated server-side computer program applications suited to the given service.
  • Encoder 1 10 may be implemented as a cloud encoder accessible over communication network 106. Encoder 1 10 encodes content provided thereto into a number of alternative bitstreams 120 (also referred to as encoded content) to support adaptive bitrate streaming of the content. For increased efficiency, encoder 1 10 may be implemented as a parallel encoder that includes multiple parallel encoders. In such an embodiment, encoder 1 10 divides the content into successive blocks or clips each of a limited duration in time. Each block may include a number of successive picture frames, referred to collectively as a group of pictures (GOPs). Encoder 1 10 encodes the divided blocks or GOPs in parallel to produce alternative bitstreams 120. Encoder 1 10 may also include transcoders to transcode input files from one encoded format to another, as necessary.
  • GEPs group of pictures
  • bitstreams 120 encode the same content in accordance with different encoding parameters/settings, such as at different encoding bitrates, resolutions, frame rates, and so on.
  • each of bitstreams 120 comprises a large number of sequential (i.e., time-ordered) files of encoded content, referred to herein as container files (CFs), as will be described further in connection with FIG. 2.
  • container files CFs
  • the encoder uploads the encoded content to CDN 1 12 for storage therein.
  • CDN 1 12 includes one or more download servers (DSs) to store the uploaded container files at corresponding network addresses, so as to be accessible to client device 104 over communication network 106.
  • DSs download servers
  • RTS 1 14 acts as a contact/control point in network services 102 for client device 104, through which the client device may initiate and then monitor its respective on-demand, live, and real-time streaming sessions. To this end, RTS 1 14 collects information from services 102, e.g., from encoder 1 10 and CDN 1 12, that client device 104 may use to manage its respective streaming sessions, and provides the collected information to the client device via messages (described below) when appropriate during streaming sessions, thus enabling the client device to manage its streaming sessions.
  • services 102 e.g., from encoder 1 10 and CDN 1 12
  • the information collected by RTS 1 14 (and provided to client device 104) identifies the encoded content, e.g., the container files, stored in CDN 1 12, and may include, but is not limited to, network addresses of the container files stored in the CDN, encoding parameters use to encode the container files, such as their encoding bitrates, resolutions, and video frame rates, and file information, such as file sizes, and file types.
  • Client device 104 may be capable of wireless and/or wired communication with network services 102 over communication network 106, and includes processing, storage, communication, and user interface capabilities sufficient to provide all of the client device functionality described herein. Such functionality may be provided, at least in part, by one or more client applications 107, such as computer programs, that execute on client device 104. Client applications 107 may include:
  • GUI Graphical User Interface
  • client device 104 may request/select (i) programs to be streamed from services 102, and (ii) trick play features to control trick play playback of the streamed programs; b. streaming and playback applications to stream/download the selected programs from the services, and playback, i.e., present, the streamed programs on client device 104, under user control, through the GUI; and c. a trick play application, integrated with the GUI and the streaming and playback applications, to implement the trick play features as described herein.
  • GUI Graphical User Interface
  • encoder 1 10 encodes multimedia content from content sources 108, and CDN 1 12 stores the encoded content.
  • encoder 1 10 encodes the content at multiple encoding levels, where each level represents a distinct combination of an encoding bitrate, a video resolution (for video content), and a video frame rate, to produce (i) multiple adaptive bitrate streams for the content, and (ii) a trick play stream for the content.
  • the multiple streams may be indexed according to their respective encoding levels.
  • client device 104 may switch between streams, i.e., levels (and thus encoded bitrates and resolutions), according to conditions at the client device.
  • client device 104 may download portions of the trick play stream from CDN 1 12 to implement trick play features in the client device.
  • FIG. 2 is an illustration of an example encoded multimedia video program 200 generated by encoder 1 10 and stored in CDN 1 12.
  • Encoded video program 200 includes:
  • ABR adaptive bitrate
  • the trick play stream corresponds to, i.e., encodes the same video as, the two ABR streams 1 , 2.
  • Each of encoding levels L1 -L3 corresponds to a distinct combination of an encoding bitrate (Rate), a video resolution (Res), and a video frame rate (FR).
  • encoding levels L1 , L2, L3 correspond to encoder settings Rate1/Res1/FR1 , Rate2/Res2/FR2, Rate3/Res3/FR3, respectively.
  • the encoding bitrate Rate3 and the video frame rate FR3 used to encode the trick play stream are less than the encoding bitrates Ratel , Rate2 and the frame rates FR1 , FR2, respectively, used to encode adaptive bitrate streams 1 , 2.
  • FIG. 2 includes only two encoding levels for the
  • an encoded video program typically includes many more than two levels of encoding for ABR streaming, such as 8 to 15 levels of encoding.
  • Each of streams 1 -3 includes a distinct, time-ordered, sequence of container files CF (i.e., successive container files CF), where time is depicted in FIG. 2 as increasing in a downward vertical direction.
  • Each of the successive container files CF, of each of streams 1 -3 includes (i.e., encodes) a block or segment of video (also referred to herein as an encoded video block or segment) so that the successive container files encode successive contiguous encoded video blocks.
  • Each of container files CF includes a time code TC to indicate a duration of the video encoded in the block of the container file, and/or a position of the container file in the succession of container files comprising the corresponding stream.
  • the time code TC may include a start time and end time for the corresponding encoded video block.
  • time codes TC1 , TC2, and TC3 may represents start and end times of 0s (seconds) and 2s, 2s and 4s, and 4s and 6s, respectively, and so down the chain of remaining successive container files.
  • the encoded blocks of the container files CF in a given stream may encode the same content (e.g., video content) as corresponding blocks in the other streams.
  • the stream 1 block corresponding to time code TC1 has encoded therein the same video as that in the stream 2 block corresponding to TC1 .
  • Such corresponding blocks encode the same content and share the same time code TC, i.e., they are aligned or coincide in time.
  • a program stream index 204 may be associated with encoded video program 200 to identify each of the streams therein (e.g., the ABR streams 1 , 2, and the trick play stream).
  • RTS 1 14 may create (and store) program stream index 204 based on the information collected from encoder 1 10 and CDN 1 12, as described above in connection with FIG. 1 . Then, during a live streaming session, for example, RTS 1 14 may provide information from program stream index 204 to client device 104 so as to identify appropriate container file addresses to the client device.
  • Program stream index 204 may include:
  • a. address pointers e.g., network addresses, such as Uniform Resource Locators (URLs)
  • URLs Uniform Resource Locators
  • encoder parameters/settings associated with the encoded streams including, but not limited to, encoding levels L1 , L2, L3 (also referred to as "Video ID" in FIG. 2, and including the encoding bitrates and resolutions Rate1/Res1 , Rate2/Res2, Rate3/Res3), encoding techniques/standards, and file types and sizes of the container files CF; and
  • TP flag a trick play flag associated with URL 210-3 that, when set, indicates the associated stream is a trick play stream.
  • Address pointers 210-1 , 210-2, 210-3 may point to respective lists of addresses A1 , A2, A3 of the container files CF comprising each of streams 1 , 2, 3.
  • Address lists A1 , A2, A3 may each be represented as an array or linked list of container file network addresses, e.g., URLs. Accordingly, access to the information in program stream index 204 results in possible access to all of the container files associated with streams 1 , 2, 3.
  • each of container files CF depicted in FIG. 2 represents a relatively small and simple container structure, larger and more complicated container structures are possible.
  • each container file may be expanded to include multiple clusters of encoded media, each cluster including multiple blocks of encoded media, to thereby form a larger container file also suitable for embodiments described herein.
  • the larger container files encode an equivalent amount of content as a collection of many smaller container files.
  • Container files may encode a single stream, such as a video stream (as depicted in FIG. 2), an audio stream, or a text stream (e.g., subtitles).
  • each container file may encode multiple multiplexed streams, such as a mix of video, audio, and text streams.
  • a container file may encode only a metadata stream at a relatively low bitrate.
  • the container files may be Matroska (MKV) containers based on Extensible Binary Meta Language (EBML), which is a derivative of Extensible Binary Meta Language (XML), or files encoded in accordance with the Moving Picture Experts Group (MPEG) standard;
  • the program stream index may be provided in a Synchronized Multimedia Integration Language (SMIL) format;
  • client device 104 may download container files from CDN 1 14 over networks 106 using the HTTP protocol.
  • the container file formats may include OGG, flash video (FLV), Windows Media Video (WMV), or any other format.
  • Exemplary, non-limiting, encoding bitrates for different levels may range from below 125 kilo-bits-per-second (kbps) up to 15,000 kbps, or even higher, depending on the type of encoded media (i.e., content).
  • Video resolutions Res 1 - Res 4 may be equal to or different from each other.
  • the container files may support adaptive streaming of encoded video programs across an available spectrum bandwidth that is divided into multiple, i.e., n, levels.
  • Video having a predetermined video resolution for each level may be encoded at a bitrate corresponding to the bandwidth associated with the given level.
  • n the number of bandwidth levels is eleven (1 1 ).
  • Each bandwidth level encodes a corresponding video stream, where the maximum encoded bitrate of the video stream (according to a hypothetical reference decoder model of the video coding standard H.264) is set equal to the bandwidth/bitrate of the given level.
  • the 1 1 levels are encoded according to 4 different video resolution levels, in the following way: mobile (2 levels), standard definition (4 levels), 720p (2 levels), and 1080p (3 levels).
  • FIG. 3A is an illustration of an example frame structure 300 of an encoded video block for container files from adaptive bitrate streams 1 and 2 of FIG. 2.
  • Video encoding by encoder 1 10 includes capturing a number of successive picture frames, i.e., a GOP, at a predetermined video frame rate, and encoding each of the captured frames, in accordance with an encoding standard/technique, into a corresponding encoded video frame.
  • Exemplary encoding standards include, but are not limited to, block encoding standards, such as H.264 and Moving Picture Experts Group (MPEG) standards.
  • MPEG Moving Picture Experts Group
  • Collectively, the encoded video frames form an encoded video block, such as an encoded video block in one of container files CF. The process repeats to produce contiguous encoded video blocks.
  • the encoding process may encode a video frame independent of, i.e., without reference to, any other video frames, such as preceding frames, to produce an encoded video frame referred to herein as a key frame.
  • the video frame may be intra-encoded, or intra-predicted.
  • key frames are referred to as l-Frames in the H.264/MPEG standard set. Since the key frame was encoded independent of other encoded video frames, it may be decoded to recover the original video content therein independent of, i.e., without reference to, any other encoded video frames.
  • the key frame may be downloaded from CDN 1 12 to client device 104, decoded independent of other encoded frames, and the recovered (decoded) video played back, i.e., presented, on the client device.
  • the encoding process may encode a video frame based on, or with reference to, other video frames, such as one or more previous frames, to produce an encoded video frame referred to herein as a non-key frame.
  • the video frame may be inter-encoded, i.e., inter-predicted, to produce the non-key frame.
  • Such non-key frames include P-Frames and B-frames in the H.264/MPEG standard set.
  • the non-key frame is decoded based on one or more other encoded video frames, e.g., key-frames, reference frames, etc.
  • the non-key frame may be downloaded from CDN 1 12 to client device 104, decoded based on other encoded frames, and the recovered video played back.
  • frame structure 300 of the encoded video block for container files in the adaptive bitrate streams includes, in a time-ordered sequence, a first set of successive non-key frames 304, a key frame 306, and a second set of successive non-key frames 308.
  • key frame 306 is interspersed among the encoded video frames of the encoded video block.
  • the position of key frame 306 relative to the non-key frames in block 300 may vary, e.g., the position may be at the top, the middle, the bottom, or elsewhere in the block.
  • multiple key frames may be interspersed among the encoded video frames of the encoded video block, and separated from each other by multiple non-key frames.
  • a key/non-key (K/NK) flag associated with each of the frames 304, 306, and 308 indicates whether the associated frame is a key-frame or a non-key frame.
  • Each of the key and the non-key frames may include a predetermined number of bytes of encoded video.
  • the frame structure includes 60 encoded video frames, which may include N (i.e., one or more) interspersed key frames, and 60-N non-key frames. Typically, the number of non-key frames exceeds the number of key frames.
  • FIG. 3B is an illustration of an example frame structure 320 of an encoded video block for container files from the trick play stream of FIG. 2.
  • Trick play frame structure 320 includes, in a time-ordered sequence, key frames 322.
  • trick play frame structure 320 includes only key frames, i.e., key frames without non-key frames.
  • the encoded video block represented by frame structure 300 encodes 2 seconds of video captured at a video frame rate of 30 frames per second (fps)
  • the encoded video block represented by frame structure 320 also encodes 2 seconds of video.
  • the video frame rate for structure 320 is reduced to 5 fps, which yields 10 encoded video frames (key frames) every 2 seconds.
  • FIG. 4 is a sequence diagram of example high-level interactions 400 between network services 102 and client device 104 used to initiate, i.e.., start-up, streaming, implement normal streaming and playback, and implement trick play features in on-demand, live, and real-time streaming embodiments. Interactions 400 progress in time from top-to-bottom in FIG. 4, and are now described in that order. It is assumed that prior to startup, encoder 1 10 is in the process of, or has finished, encoding video content into multiple adaptive bitrate streams and a corresponding trick play stream, and storing the resulting container files in CDN 1 12 for subsequent download to client device 104. 3.1 Start-up
  • a user of client device 104 selects content, such as a video program, to be streamed using the client device GUI.
  • client device 104 sends a "Start" message (also referred to as a "begin playback” message) to RTS 1 14 to start a streaming session.
  • the Start message includes an identifier (ID) of the content to be streamed and a current time stamp.
  • ID identifies content from a content source that is to be streamed to client 104, and may indicate, e.g., a channel, program name, and/or source originating the content to be streamed.
  • the current time stamp (also referred to as "current time”) indicates a current time, such as a Universal Time Code (UTC).
  • UTC Universal Time Code
  • RTS 1 14 sends an encoding profile message (referred to as a "Profile" message) to client 104.
  • the Profile message lists different encoding profiles used to encode the identified content, e.g., as available from the program stream index for the identified content.
  • Each of the profiles specifies encoding parameters/settings, including, but not limited to: content type (e.g., audio, video, or subtitle); an encoding level corresponding to an encoding bitrate, resolution, and video frame rate (e.g., levels L1 , L2, L3); and a container file type, e.g., a Multipurpose Internet Mail Extensions (MIME) type.
  • the Profile message also indicates which encoding level among the multiple encoding levels e.g., encoding level L3, represents or corresponds to a trick play stream.
  • client device 104 selects an appropriate encoding level (e.g., an appropriate combination of an encoding bitrate and a resolution) among the levels indicated in the Profile message (not including the level indicating the trick play stream) for normal streaming and playback of the identified content.
  • Client device 104 may determine the appropriate encoding level based on a communication bandwidth at the client device.
  • the client device sends a GetPlaylist message to RTS 1 14 to request a list of any new container files that have been uploaded since the client device last downloaded container files (if any) from CDN 1 12.
  • the GetPlaylist message includes selection criteria for uploaded container files, namely, a current time and the selected encoding level.
  • the current time represents a time code associated with the last container file downloaded by client device 104 (if any) in the current streaming session.
  • RTS 1 14 In response to the GetPlaylist message, RTS 1 14: a. selects the uploaded container files, as identified to the RTS that meet the criteria specified in the GetPlaylist message.
  • the selected, uploaded container files are those container files that have (i) a time code greater than the current time, and (ii) an encoding level that matches the level specified in the GetPlaylist message from the client device; b. generates a Playlist message identifying the selected container files; and c. at 433, sends the Playlist message to client device 104.
  • the Playlist message includes the following information: the type of content encoded in the container file (e.g., video, audio, or subtitle); an address (e.g., URL) of the container file in CDN 1 12 (e.g., a subset of the addresses A1 or A2); a time code, e.g., a start time and an end time, associated with the content block encoded in the container file; and a file size of the container file.
  • the type of content encoded in the container file e.g., video, audio, or subtitle
  • an address e.g., URL
  • CDN 1 12 e.g., a subset of the addresses A1 or A2
  • time code e.g., a start time and an end time
  • client device 104 downloads container files from addresses in CDN 1 12 based on, i.e., as identified in, the Playlist message.
  • client device 104 decodes all of the key frames and the non-key frames of the encoded content block from each of the downloaded container files to recover the original content therein, and then presents the recovered content, whether in audio, visual, or in other form, on client device 104.
  • the process of decoding the encoded content from the key and non-key frames and then presenting the recovered content on client device 104 is referred to as "normal playback" on the client device.
  • normal playback the content recovered from successive downloaded container files is played back on client device 104 in a forward (play) direction, i.e., in an order of increasing time code.
  • play forward
  • the content is played back from container files CF in the time code order of 0s-2s, 2s-4s, 4s-6s, and so on.
  • the decoded video frames are presented at a frame rate equal to the frame rate at which the video was original captured and encoded, e.g., at a rate of 30 fps.
  • the normal streaming and playback sequence repeats. Therefore, in summary, in the streaming and playback sequence, client device 104 periodically requests and downloads Playlist messages, downloads container files indicated in the Playlist messages, and plays back the content from the downloaded container files in the forward direction.
  • Trick play features include, but are not limited to, rewind and fast forward, in which client device 104 rewinds and fast forwards through previously played back content.
  • client device 104 sends a GetPlaylist message to RTS 1 14 to solicit appropriate trick play video (container files) from network services 102. Therefore, in this case, the GetPlaylist message may also be referred to as a "GetTrickPlayPlaylist" message.
  • the GetPlaylist message sent at 442 includes the following trick play file selection criteria:
  • RTS 1 14 in response to the GetPlaylist message sent at 442, RTS 1 14 generates and sends a trick play Playlist message to client device 104.
  • the trick play Playlist message identifies those container files from the trick play stream (e.g., the stream associated with encoding level L3 in the example of FIG. 2) that meet the selection criteria, namely, that are associated with (i) successive time code less than the trick play time because the trick play direction is RWD, and (ii) an encoding level that matches the specified level (e.g., encoding level L3).
  • the Playlist message lists URLs of the appropriate trick play container files.
  • client device 104 downloads the trick play container files identified in the Playlist message from 444. For example, client device 104 downloads the trick play container files from their corresponding URLs.
  • client device 104 plays back video from the downloaded trick play container files, i.e., the client device decodes the key frames from each of the trick play container files and then presents the decoded video in a rewind play direction, i.e., in an order of decreasing time codes beginning with the trick play time.
  • the video from the key frames may be played back at a reduced video frame rate relative to that used for normal playback.
  • the trick play playback video frame rate may be 5 fps, instead of 30 fps.
  • key frames may be skipped, e.g., every other key frame may be played back.
  • key frames in each of the downloaded trick play container files may be used in trick play playback.
  • the above described trick play sequence results when the user selects RWD at 440.
  • the user may select fast forward (FFWD) at 440.
  • the trick play sequence that results when the user selects FFWD is similar to that for RWD, except that the GetPlaylist message at 442 indicates FFWD instead of RWD.
  • RTS 1 14 returns a Playlist message identifying trick play files associated with successive time codes greater than (not less than) the trick play time. Then, at 448, client device 104 plays back the downloaded trick play files in the forward direction. 4 Profile and Playlist Messages
  • FIG. 5 is an example Profile message 500.
  • the user is a user
  • Profile message format is in accordance with the World Wide Web Consortium (W3C) recommended Extensible Markup Language (XML) markup language, Synchronized Multimedia Integration Language (SMIL) 3.0 Tiny profile. This profile is well-suited to descriptions of web-based multimedia. However, other protocols may be used to format the Profile message.
  • W3C World Wide Web Consortium
  • XML Extensible Markup Language
  • SMIL Synchronized Multimedia Integration Language
  • Profile message 500 includes a header 501 to specify the base profile as SMIL 3.0 (Tiny), and a body including video encoding (VE) profiles 502, 504, 505 and an audio encoding (AE) profile 506.
  • Profile message 500 corresponds to a requested program ID, such as encoded program 200 of FIG. 2, and includes information from the associated index, e.g., index 204.
  • VE profiles 502, 504, 505 specifies the following encoding settings or parameters:
  • a content type e.g., video
  • bitrate 400000 bps, 600000 bps, or 150000 bps
  • ii. video resolution e.g., Res1 , Res2, or Res3 in terms of, e.g., pixel width and height dimensions (e.g., 768 x 432);
  • AE profile 506 specifies:
  • a a content type e .g., audio
  • b an encoding bitrate/reserved bandwidth value (e.g., 192000); and c a MIME type.
  • the Profile message may also include a video frame rate at which each level was encoded.
  • Profile message 500 also includes a field 510 to indicate which of encoding profiles 502-505, if any, represents a trick play stream. In the example of FIG. 5, the stream associated with level 3 (similar to FIG. 2) is indicated as the trick play stream.
  • FIG. 6 is an example Playlist message 600 generated in response to a GetPlaylist message selection criteria including a current time of 40 (seconds) and specifying a level 1 encoding level.
  • the example Playlist message is formatted in accordance with SMIL 3.0.
  • Playlist message 600 includes a header 601 to specify the base profile as 3.0, and a body that includes sequential records or elements 602-610, each of which is defined as a seq element ⁇ seq>.
  • each seq element 602-610 corresponds to an uploaded container file.
  • RTS 1 14 is able to specify a sequence of real-time media streams for playback.
  • a sequence tag is used with each element to indicate one of ⁇ video>, ⁇ audio> or ⁇ subtitle/text> encoded content for streaming.
  • Elements 602-610 identify respective uploaded elements (e.g., container files) that meet the Playlist message criteria (i.e., encoding level 1 and a time code equal to or greater than 40).
  • elements 602-608 identify three container files containing successive or time-ordered two second blocks of encoded video.
  • Element 610 identifies a container file containing a two second segment of encoded audio.
  • Each of the Playlist message records 602-610 includes:
  • a content type identifier e.g., video or audio
  • the URLs correspond to container file addresses from the list of addresses A1 or A2 from FIG. 2;
  • a time code in seconds e.g., a start time and an end time, referred to as "ClipBegin” and "ClipEnd,” respectively, associated with the segment encoded in the identified container file.
  • the example time codes for each of the container files are 40-42, 42-44, and 46-48); and d. a file size of the identified container file (e.g., 3200 kilobits).
  • FIG. 7 is a flowchart of an example network-side method 700 of multimedia content streaming with trick play support based on trick play files, which may be implemented in network services 102.
  • Method 700 may be executed in accordance with sequence 400 of FIG. 4.
  • the multimedia content includes video, and may also include audio and/or text (e.g., subtitles).
  • Method 700 may be implemented in any of the contexts of on-demand, live, and real-time streaming.
  • [0083] 715 includes encoding video into (i) multiple adaptive bitrate streams, and (ii) a corresponding trick play stream in accordance with corresponding distinct sets of encoder settings or levels, such as an encoding bitrate, a resolution, and a video frame rate.
  • Each of the streams comprises container files of encoded video associated with successive time codes.
  • [0084] 720 includes storing (i) the container files for each stream at corresponding addresses, such as network addresses, e.g., URLs, in a download server, e.g., in CDN 1 14, and (ii) an index identifying the container files of each stream in RTS 1 14.
  • addresses such as network addresses, e.g., URLs
  • [0085] 725 includes receiving a playlist request (e.g., a GetPlaylist message) from a client device, e.g., over a communication network, for a selected one of the adaptive bitrate streams.
  • the playlist request includes container file selection criteria, including a current time, an encoding level.
  • [0086] 730 includes sending, to the client device over the communication network, a playlist (e.g., a Playlist message) identifying the stored files of the selected stream that meet the selection criteria, i.e., that are associated with time codes greater than the current time.
  • the playlist may list URLs where the identified container files are stored and sizes of the files.
  • 735 includes receiving, from the client device, a playlist request (e.g., another GetPlaylist message) for the trick play stream corresponding to the selected stream.
  • the trick play playlist request includes a trick play time code, a trick play encoding level, and a trick play direction, e.g., fast forward or rewind.
  • [0088] 740 includes sending, to the client device, a trick play playlist (e.g., another Playlist message) identifying the stored files (e.g., URLs of the stored files) of the trick play stream that are associated with successive time codes that are (i) less than the trick play time if the trick play direction is rewind, and (ii) greater than the trick play time if the trick play direction is fast forward.
  • a trick play playlist e.g., another Playlist message
  • the stored files e.g., URLs of the stored files
  • FIG. 8 is a flowchart of an example client-side method 800 of multimedia content streaming with trick play support based on trick play files, which may be implemented in client device 104.
  • Method 800 is a client side method complementary to network side method 700.
  • Method 800 may be executed in accordance with sequence 400 of FIG. 4.
  • the multimedia content includes video, and may also include audio and/or text (e.g., subtitles).
  • Method 700 may be implemented in any of the contexts of on-demand, live, and real-time streaming.
  • operations 802-815 described below are considered precursor, or initialization, operations that lead to subsequent downloading of an adaptive bitrate stream.
  • 802 includes requesting to stream a video program from network services over a communication network and, in response, receiving a Profile message over the communication network identifying multiple adaptive bitrate streams of encoded video and a trick play stream of encoded video that are stored in, and available for streaming from, network services.
  • the streams may be identified according to their respective encoding levels (e.g., encoding bitrate, resolution, frame rate, etc.).
  • Each of the streams comprises container files of the encoded video.
  • the container files of each stream are associated with successive time codes.
  • 805 includes selecting an adaptive bitrate stream from among the multiple adaptive bitrate streams.
  • a client device may select an adaptive bitrate stream based an available communication bandwidth.
  • [0093] 810 includes sending, to the network services over the communication network, a playlist request (e.g., a GetPlaylist message) for (container) files from the selected stream.
  • the playlist request includes file selection criteria that includes a current time and specifies an encoding level corresponding to, e.g., an encoding bitrate and a resolution, of the selected stream.
  • [0094] 815 includes receiving, from the network services over the communication network, a playlist (e.g., a Playlist message) identifying the files from the selected stream that meet the file selection criteria, i.e., that are associated with successive time codes greater than the current time.
  • a playlist e.g., a Playlist message
  • [0095] 820 includes downloading, from the network services over the communication network, files of encoded video from the selected stream as identified in the playlist, e.g., from URLs listed in the playlist.
  • [0096] 825 includes playing back video from the downloaded files in an order of increasing time codes. This includes playing back video from both key and non-key frames at a normal video frame rate, such as 30 fps.
  • [0097] 830 includes receiving a trick play feature request, such as a video rewind request, from a user of the client device. Next operations 835-850 are performed in response to the trick play request received at 830.
  • a trick play feature request such as a video rewind request
  • [0098] 835 includes sending, to the network services over the communication network, a trick play playlist request (e.g., a GetTrickPlayPlayist message) for appropriate trick play files from the trick play stream corresponding to the selected stream.
  • the request includes a trick play time (corresponding to a time when the user selected the trick play feature), a trick play encoding level as indicated in the Profile message received earlier by the client device at 802 (e.g., level L3), and a trick play direction (e.g., rewind or fast forward).
  • [0099] 840 includes receiving, from the network services over the communication network, a trick play playlist (e.g., a Playlist message) identifying files from the trick play stream that meet the file selection criteria, i.e., that are associated with successive time codes (i) less than the trick play time if the direction is rewind, and (ii) greater than the trick play time if the direction is fast forward.
  • a trick play playlist e.g., a Playlist message
  • [00100] 845 includes downloading the trick play files identified in the playlist from 840, e.g., from URLs listed in the playlist.
  • [00101] 850 includes playing back video from the downloaded files in either the rewind direction, i.e., in an order of decreasing time codes, or in the forward direction, as appropriate. This includes playing back video only from key frames at a trick play video frame rate, such as 5 fps, which is reduced relative to the normal frame rate.
  • FIG. 9A is a block diagram of a computer system 900 configured to support/perform streaming and trick play features as described herein.
  • Computer system 900 includes one or more computer instruction processing units and/or processor cores, illustrated here as processor 902, to execute computer readable instructions, also referred to herein as computer program logic.
  • Computer system 900 may include memory, cache, registers, and/or storage, illustrated here as memory 904, which may include a non-transitory computer readable medium encoded with computer programs, illustrated here as computer program 906.
  • Memory 904 may include data 908 to be used by processor 902 in executing computer program 906, and/or generated by processor 902 during execution of computer program 906.
  • Data 908 may include container files 908a from adaptive bitrate streams and trick play streams, and message definitions 908b for GetPlaylist, Playlist, and Profile messages, such as used in the methods described herein.
  • Computer program 906 may include: [00107] Client application instructions 910 to cause processor 902 to perform client device functions as described herein. Instructions 910 include:
  • GUI instructions 912 to implement a GUI through which a user may select to stream a program and select trick play features
  • streaming and playback instructions 914 to download, decode, and playback streamed video content
  • trick play instructions 916 to implement trick play features
  • message protocol instructions 918 to implement client side message exchange protocols/sequences (sending and receiving of messages) as described in one or more examples above.
  • Instructions 910-918 cause processor 902 to perform functions such as described in one or more examples above.
  • FIG. 9B is a block diagram of network/server-side application instructions 960 which may execute in a processing environment similar to that of computer system 900, and which may be hosted in encoder 1 10, RTS 1 14, and/or CDN 1 12, as appropriate.
  • Network/server-side application instructions 960 cause a processor to perform network-side (network services) functions as described herein. Instructions 960 have access to adaptive bitrate streams, trick play streams, indexes identifying the streams, and message definitions as described in one or more example above. Instructions 960 include:
  • encoder instructions 962 to encode multimedia content into adaptive bitrate streams and trick play streams, as described in one or more example above;
  • message protocol instructions 964 including RTS instructions, to implement network side message exchange protocols/sequences (sending and receiving of messages) in support of adaptive bitrate streaming and trick play streaming, e.g., between RTS 1 14, client device 104, encoder 1 10, and CDN 1 12, as described in one or more examples above.
  • instructions 964 include instructions to create and send Profile and Playlist messages, and to respond to GetPlaylist messages.
  • Methods and systems disclosed herein may be implemented with respect to one or more of a variety of systems including one or more consumer systems, such as described below with reference to FIGs. 10 and 1 1 . Methods and systems disclosed herein are not, however, limited to the examples of FIGs. 10 and 1 1 .
  • FIG. 10 is a block diagram of an example computer system 1000 corresponding to any of network services 102, including encoder 1 10, CDN 1 12, and RTS 1 14.
  • Computer system 1000 which may be, e.g., a server, includes one or more processors 1005, a memory 1010 in which instruction sets and databases for computer program applications are stored, a mass storage 1020 for storing, e.g., encoded programs, and an input/output (I/O) module 1015 through which components of computer system 1 100 may communicate with communication network 106.
  • processors 1005 includes one or more processors 1005, a memory 1010 in which instruction sets and databases for computer program applications are stored, a mass storage 1020 for storing, e.g., encoded programs, and an input/output (I/O) module 1015 through which components of computer system 1 100 may communicate with communication network 106.
  • I/O input/output
  • FIG. 1 1 is a block diagram of an example system 1 100 representing, e.g., client device 104, and may be implemented, and configured to operate, as described in one or more examples herein.
  • System 1 100 or portions thereof may be implemented within one or more integrated circuit dies, and may be implemented as a system-on-a-chip (SoC).
  • SoC system-on-a-chip
  • System 1 100 may include one or more processors 1 104 to execute client- side application programs stored in memory 1 105.
  • System 1 100 may include a communication system 1 106 to interface between processors 1 104 and communication networks, such as networks 106.
  • Communication system 1 106 may include a wired and/or wireless communication system.
  • System 1 100 may include a stream processor 1 107 to process program (i.e., content) streams, received over communication channel 1 108 and through communication system 1 106, for presentation at system 1 100.
  • Stream processor 1 107 includes a buffer 1 107a to buffer portions of received, streamed programs, and a decoder 1 107b to decode and decrypt the buffered programs in accordance with encoding and encryption standards, and using decryption keys.
  • decoder 1 107b may be integrated with a display and graphics platform of system 1 100.
  • Stream processor 1 107 together with processors 1 104 and memory 1 105 represent a controller of system 1 100. This controller includes modules to perform the functions of one or more examples described herein, such as a streaming module to stream programs through communication system 1 106.
  • System 1 100 may include a user interface system 1 1 10.
  • User interface system 1 1 10 may include a monitor or display 1 132 to display information from processor 1 104, such as a client-side GUI.
  • User interface system 1 1 10 may include a human interface device (HID) 1 134 to provide user input to processor 1 104.
  • HID 1 134 may include, for example and without limitation, one or more of a key board, a cursor device, a touch-sensitive device, and or a motion and/or image sensor.
  • HID 1 134 may include a physical device and/or a virtual device, such as a monitor-displayed or virtual keyboard.
  • User interface system 1 1 10 may include an audio system 1 136 to receive and/or output audible sound.
  • System 1 100 may correspond to, for example, a computer system, a personal communication device, and/or a television set-top box.
  • System 1 100 may include a housing, and one or more of communication system 1 106, processors 1 104, memory 1 105, user interface system 1 1 10, or portions thereof may be positioned within the housing.
  • the housing may include, without limitation, a rack-mountable housing, a desk-top housing, a lap-top housing, a notebook housing, a net-book housing, a set-top box housing, a portable housing, and/or other conventional electronic housing and/or future-developed housing.
  • communication system 1 102 may be implemented to receive a digital television broadcast signal
  • system 1 100 may include a set-top box housing or a portable housing, such as a mobile telephone housing.
  • Methods and systems disclosed herein may be implemented in circuitry and/or a machine, such as a computer system, and combinations thereof, including discrete and integrated circuitry, application specific integrated circuitry (ASIC), a processor and memory, and/or a computer-readable medium encoded with instructions executable by a processor, and may be implemented as part of a domain-specific integrated circuit package, a system-on-a-chip (SOC), and/or a combination of integrated circuit packages.
  • ASIC application specific integrated circuitry
  • SOC system-on-a-chip

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Des services réseau encodent un contenu multimédia, vidéo par ex., dans une pluralité de flux de débit adaptatif de vidéo encodée et un flux trick play séparé de vidéo encodée pour prendre en charge des fonctions trick play. Le flux trick play est encodé à un débit d'encodage et un débit de trames inférieurs à ceux de chacun des flux de débit adaptatif. Les flux de débit adaptatif et les flux trick play sont stockés dans des services réseau. Lors d'une diffusion en continu normale de contenu et la lecture, un dispositif client télécharge un des flux de débit adaptatif sélectionné, du réseau desservi pour la lecture, au dispositif client. Pour implémenter une fonction trick play, le dispositif client télécharge le flux trick play, des services réseau, pour la lecture trick play.
PCT/US2014/039852 2013-05-30 2014-05-28 Diffusion vidéo en continu sur un réseau, avec trick play basé sur des fichiers trick play séparés WO2014193996A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US13/905,867 US20140359678A1 (en) 2013-05-30 2013-05-30 Device video streaming with trick play based on separate trick play files
US13/905,867 2013-05-30
US13/905,852 2013-05-30
US13/905,852 US9094737B2 (en) 2013-05-30 2013-05-30 Network video streaming with trick play based on separate trick play files

Publications (2)

Publication Number Publication Date
WO2014193996A2 true WO2014193996A2 (fr) 2014-12-04
WO2014193996A3 WO2014193996A3 (fr) 2015-02-19

Family

ID=51989522

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/039852 WO2014193996A2 (fr) 2013-05-30 2014-05-28 Diffusion vidéo en continu sur un réseau, avec trick play basé sur des fichiers trick play séparés

Country Status (1)

Country Link
WO (1) WO2014193996A2 (fr)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9621522B2 (en) 2011-09-01 2017-04-11 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US9712890B2 (en) 2013-05-30 2017-07-18 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
US9883204B2 (en) 2011-01-05 2018-01-30 Sonic Ip, Inc. Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol
US9967305B2 (en) 2013-06-28 2018-05-08 Divx, Llc Systems, methods, and media for streaming media content
US10212486B2 (en) 2009-12-04 2019-02-19 Divx, Llc Elementary bitstream cryptographic material transport systems and methods
US10225299B2 (en) 2012-12-31 2019-03-05 Divx, Llc Systems, methods, and media for controlling delivery of content
US10264255B2 (en) 2013-03-15 2019-04-16 Divx, Llc Systems, methods, and media for transcoding video data
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
US10437896B2 (en) 2009-01-07 2019-10-08 Divx, Llc Singular, collective, and automated creation of a media guide for online content
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
US10687095B2 (en) 2011-09-01 2020-06-16 Divx, Llc Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US10878065B2 (en) 2006-03-14 2020-12-29 Divx, Llc Federated digital rights management scheme including trusted systems
USRE48761E1 (en) 2012-12-31 2021-09-28 Divx, Llc Use of objective quality measures of streamed content to reduce streaming bandwidth
US11457054B2 (en) 2011-08-30 2022-09-27 Divx, Llc Selection of resolutions for seamless resolution switching of multimedia content
CN116781951A (zh) * 2023-08-24 2023-09-19 湖南快乐阳光互动娱乐传媒有限公司 一种清晰度调节方法、装置和服务器

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9247312B2 (en) * 2011-01-05 2016-01-26 Sonic Ip, Inc. Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol
US8451905B1 (en) * 2011-02-25 2013-05-28 Adobe Systems Incorporated Efficient encoding of video frames in a distributed video coding environment
US8856283B2 (en) * 2011-06-03 2014-10-07 Apple Inc. Playlists for real-time or near real-time streaming
US8925021B2 (en) * 2011-07-11 2014-12-30 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for trick play in over-the-top video delivery

Cited By (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11886545B2 (en) 2006-03-14 2024-01-30 Divx, Llc Federated digital rights management scheme including trusted systems
US10878065B2 (en) 2006-03-14 2020-12-29 Divx, Llc Federated digital rights management scheme including trusted systems
US10437896B2 (en) 2009-01-07 2019-10-08 Divx, Llc Singular, collective, and automated creation of a media guide for online content
US10212486B2 (en) 2009-12-04 2019-02-19 Divx, Llc Elementary bitstream cryptographic material transport systems and methods
US11102553B2 (en) 2009-12-04 2021-08-24 Divx, Llc Systems and methods for secure playback of encrypted elementary bitstreams
US10484749B2 (en) 2009-12-04 2019-11-19 Divx, Llc Systems and methods for secure playback of encrypted elementary bitstreams
US10368096B2 (en) 2011-01-05 2019-07-30 Divx, Llc Adaptive streaming systems and methods for performing trick play
US11638033B2 (en) 2011-01-05 2023-04-25 Divx, Llc Systems and methods for performing adaptive bitrate streaming
US9883204B2 (en) 2011-01-05 2018-01-30 Sonic Ip, Inc. Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol
US10382785B2 (en) 2011-01-05 2019-08-13 Divx, Llc Systems and methods of encoding trick play streams for use in adaptive streaming
US11457054B2 (en) 2011-08-30 2022-09-27 Divx, Llc Selection of resolutions for seamless resolution switching of multimedia content
US10244272B2 (en) 2011-09-01 2019-03-26 Divx, Llc Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US10687095B2 (en) 2011-09-01 2020-06-16 Divx, Llc Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US11683542B2 (en) 2011-09-01 2023-06-20 Divx, Llc Systems and methods for distributing content using a common set of encryption keys
US10341698B2 (en) 2011-09-01 2019-07-02 Divx, Llc Systems and methods for distributing content using a common set of encryption keys
US11178435B2 (en) 2011-09-01 2021-11-16 Divx, Llc Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US10225588B2 (en) 2011-09-01 2019-03-05 Divx, Llc Playback devices and methods for playing back alternative streams of content protected using a common set of cryptographic keys
US10856020B2 (en) 2011-09-01 2020-12-01 Divx, Llc Systems and methods for distributing content using a common set of encryption keys
US9621522B2 (en) 2011-09-01 2017-04-11 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
USRE49990E1 (en) 2012-12-31 2024-05-28 Divx, Llc Use of objective quality measures of streamed content to reduce streaming bandwidth
USRE48761E1 (en) 2012-12-31 2021-09-28 Divx, Llc Use of objective quality measures of streamed content to reduce streaming bandwidth
US10805368B2 (en) 2012-12-31 2020-10-13 Divx, Llc Systems, methods, and media for controlling delivery of content
US11785066B2 (en) 2012-12-31 2023-10-10 Divx, Llc Systems, methods, and media for controlling delivery of content
US10225299B2 (en) 2012-12-31 2019-03-05 Divx, Llc Systems, methods, and media for controlling delivery of content
US11438394B2 (en) 2012-12-31 2022-09-06 Divx, Llc Systems, methods, and media for controlling delivery of content
US10264255B2 (en) 2013-03-15 2019-04-16 Divx, Llc Systems, methods, and media for transcoding video data
US10715806B2 (en) 2013-03-15 2020-07-14 Divx, Llc Systems, methods, and media for transcoding video data
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
US11849112B2 (en) 2013-03-15 2023-12-19 Divx, Llc Systems, methods, and media for distributed transcoding video data
US10462537B2 (en) 2013-05-30 2019-10-29 Divx, Llc Network video streaming with trick play based on separate trick play files
US9712890B2 (en) 2013-05-30 2017-07-18 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9967305B2 (en) 2013-06-28 2018-05-08 Divx, Llc Systems, methods, and media for streaming media content
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
US10321168B2 (en) 2014-04-05 2019-06-11 Divx, Llc Systems and methods for encoding and playing back video at different frame rates using enhancement layers
US11711552B2 (en) 2014-04-05 2023-07-25 Divx, Llc Systems and methods for encoding and playing back video at different frame rates using enhancement layers
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
US11343300B2 (en) 2017-02-17 2022-05-24 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
CN116781951B (zh) * 2023-08-24 2023-12-05 湖南快乐阳光互动娱乐传媒有限公司 一种清晰度调节方法、装置和服务器
CN116781951A (zh) * 2023-08-24 2023-09-19 湖南快乐阳光互动娱乐传媒有限公司 一种清晰度调节方法、装置和服务器

Also Published As

Publication number Publication date
WO2014193996A3 (fr) 2015-02-19

Similar Documents

Publication Publication Date Title
US11470405B2 (en) Network video streaming with trick play based on separate trick play files
US9247317B2 (en) Content streaming with client device trick play index
US20140359678A1 (en) Device video streaming with trick play based on separate trick play files
WO2014193996A2 (fr) Diffusion vidéo en continu sur un réseau, avec trick play basé sur des fichiers trick play séparés
US20140297804A1 (en) Control of multimedia content streaming through client-server interactions
RU2652099C2 (ru) Устройство передачи, способ передачи, устройство приема и способ приема
KR102190364B1 (ko) 비디오 콘텐트를 인코딩하기 위한 시스템 및 방법
Sodagar The mpeg-dash standard for multimedia streaming over the internet
US9351020B2 (en) On the fly transcoding of video on demand content for adaptive streaming
EP2577486B1 (fr) Procédé et appareil de transmission en continu adaptative sur la base de plusieurs éléments pour déterminer une qualité de contenu
US9462024B2 (en) System and method of media content streaming with a multiplexed representation
US20180063590A1 (en) Systems and Methods for Encoding and Playing Back 360° View Video Content
CN107634930B (zh) 一种媒体数据的获取方法和装置
EP2754301A1 (fr) Diffusion en continu de données multimédia provenant de multiples sources
US11647252B2 (en) Identification of elements in a group for dynamic element replacement
CN106789976A (zh) 媒体文件的播放方法、服务端、客户端及系统
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
KR101690153B1 (ko) Http 기반 무버퍼링 영상전송 방법을 이용한 실시간 스트리밍 시스템
KR101568317B1 (ko) Ip 카메라에서 hls 프로토콜을 지원하는 시스템 및 그 방법
Sodagar et al. Reinventing multimedia delivery with MPEG-DASH
US12015805B2 (en) Method, an apparatus and a computer program product for video streaming
US20230107615A1 (en) Dynamic creation of low latency video streams in a live event
Sodagar Industry and standards
WO2015064384A1 (fr) Appareil et procédé de transmission et appareil et procédé de réception
Bechqito High Definition Video Streaming Using H. 264 Video Compression

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14804692

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2014804692

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14804692

Country of ref document: EP

Kind code of ref document: A2