WO2009095385A1 - System and method for advertising multiplex content - Google Patents

System and method for advertising multiplex content Download PDF

Info

Publication number
WO2009095385A1
WO2009095385A1 PCT/EP2009/050891 EP2009050891W WO2009095385A1 WO 2009095385 A1 WO2009095385 A1 WO 2009095385A1 EP 2009050891 W EP2009050891 W EP 2009050891W WO 2009095385 A1 WO2009095385 A1 WO 2009095385A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
multiplex
multiplex content
video
information indicating
Prior art date
Application number
PCT/EP2009/050891
Other languages
French (fr)
Inventor
Jean-Baptiste Henry
Stéphane Gouache
Original Assignee
Thomson Licensing
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
Application filed by Thomson Licensing filed Critical Thomson Licensing
Publication of WO2009095385A1 publication Critical patent/WO2009095385A1/en

Links

Classifications

    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • 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/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]

Definitions

  • the present invention relates generally to multimedia content distribution and in particular to the distribution of information relative to a multimedia session.
  • MPEG2 standards define a method to multiplex various component parts of a multimedia program, and several multimedia programs altogether.
  • a program may comprise various components, such as audio, video and control data. These components are transported in different transport stream packets, called TS packets, all having the same identifier for the same component.
  • the identifier is also called packet identifier or PID.
  • PID packet identifier
  • the PID is used to uniquely identify the component to which the packet belongs.
  • a receiver determines the PID being used. Then it filters packets that have a matching PID value. To help the receiver identify which PID corresponds to which component from which program, signaling tables are transmitted with a description of each program carried within the MPEG-2 Transport Stream.
  • MPEG signaling tables Program Specific Information
  • MPEG2-System ISO IEC 13818-1
  • ISO IEC 13818-1 Information technology - Generic coding of moving pictures and associated audio information: Systems
  • MPEG-PSI and DVB-SI define information data which allows the user to be provided with information to assist in selection of services and/or events within the bitstream. This is specified in the standard document ETSI EN 300 468: “Digital Video Broadcasting (DVB); Specification for Service Information (Sl) in DVB systems” (DVB-SI).
  • DVD Digital Video Broadcasting
  • Sl Specification for Service Information
  • DVB-SI DVB-SI
  • a terminal needs to process several MPEG-PSI tables to get the PID (Packet Identifier) that corresponds to a specific component of a specific program within a Transport Stream. The terminal also needs to track any change in the tables.
  • PID Packet Identifier
  • a MPEG2 Transport Stream can therefore carry one or more programs, each individual program holding a set of one or more components, of the same or different types.
  • the type of a component is video, audio, subtitle or private data.
  • the MPEG-PSI and DVB-SI tables provide all relevant information concerning those programs and components. But those tables are only accessible by a receiver when connecting to the Transport Stream. It would be advantageous to retrieve such information prior to connecting to the stream. Unfortunately, generally the only information available is that the content is using MPEG2 Transport stream multiplexing technology, and no additional information is provided on elements such as programs, or components.
  • the present invention attempts to remedy at least some of the concerns connected with the prior art, by providing a method enabling to advertise content that comprises a multiplex of several services.
  • the invention concerns a server adapted for advertising multiplex content comprising a plurality of programs and a plurality of components.
  • the server comprises means for sending a session description comprising a first information indicating the presence of multiplex content and at least one second information indicating the composition of the multiplex content.
  • a session description is a well-defined format for conveying sufficient information to discover and participate in a multimedia session.
  • the multiplex content and the composition of the multiplex content are announced through the session description. This simplifies the announcement between the server and the receivers.
  • the at least one second attribute indicates the composition of the multiplex content as a set of programs and/or components.
  • the multimedia content is carried into an MPEG-2 transport stream.
  • the invention also concerns a method at a server for advertising multiplex content comprising a plurality of programs and a plurality of components.
  • the method comprises the step of sending a session description comprising a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content.
  • the invention also concerns a receiver device comprising communicating means for receiving a session description comprising a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content; and analysis means for identifying the composition of the multiplex content indicated in the session description.
  • the receiver comprises playing means for receiving the multiplex content.
  • the invention also concerns a method at a receiver for receiving multiplex content comprising a plurality of programs and a plurality of components.
  • the method comprises the step of receiving, in a session description, a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content; identifying the composition of the multiplex content indicated in the session description; and receiving the multiplex content.
  • Another object of the invention is a computer program product comprising program code instructions for executing the steps of the process according to the invention, when that program is executed on a computer.
  • computer program product it is meant a computer program support, which may consist not only in a storing space containing the program, such as a diskette or a cassette, but also in a signal, such as an electrical or optical signal.
  • Figure 1 represents two MPEG2-TS services; and - Figure 2 represents a system according to the embodiments.
  • Session Description Protocol but the invention is not limited to this particular protocol and may be applied within other frameworks enabling to advertise multimedia sessions. Moreover the embodiments are not limited to the
  • MPEG2 Transport Stream (MPEG2-TS).
  • MPEG2-TS MPEG2 Transport Stream
  • the MPEG2- TS stream of the example comprises two services, as illustrated in figure 1. It should be noted that the terms program and service are used hereinafter to designate the same entity.
  • the first service is called "First Service”. It has a PMT (Program Map Table) PID 0x200. It comprises two video components and two audio components:
  • the first video component is a SD (Standard Definition) MPEG2 one (PID 0X210)
  • the second video component is a HD (High Definition) H264 one (PID 0X211 ) -
  • the first audio components is English in MPEG1 Layer Il (PID
  • the second audio component is French in AC3 at 48kHz and 6 channels (PID 0X221 )
  • the second service is called "Second Service”. It has a PMT PID
  • the video component is a SD H264 one (PID 0X310)
  • the audio component is AAC coding (0X320)
  • SDP Session Description Protocol
  • SDP Session Description Protocol
  • SDP Session Description Protocol
  • SDP Session Description Protocol
  • SDP is a format that permits to describe content and multimedia sessions in an ASCII string; ASCII standing for American Standard Code for Information Interchange.
  • SDP is a format for session description. It doesn't define any transport protocol; it is intended to use different transport protocols as appropriate.
  • the purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session.
  • An SDP session description includes a session name and purpose, the time the session is active, the media comprising the session, and information needed to receive those media (addresses, ports, formats, etc.).
  • the SDP fields described hereinafter are indicated using a generic notation, where ⁇ field> is the SDP field.
  • An example of a SDP file is illustrated below:
  • TTL is 127; Audio is sent on port 49170, and is coded thanks to static payload type 0, meaning implicitly that the audio is encoded with PCMU at 8kHz;
  • Video is sent on port 51372, and is coded thanks to dynamic payload type 99, so the rtpmap attributes provides more information, which is H263-1998 at 90kHz.
  • media is the media type, such as "audio”, “video”, “text”, "application” port is the TCP or UDP port where this media is sent (UDP or TCP depends on the proto field) proto is the underlying transport protocol.
  • “audio”, “video”, “text” port is the TCP or UDP port where this media is sent (UDP or TCP depends on the proto field) proto is the underlying transport protocol.
  • RTP/AVP the most used one for multimedia content.
  • fmt is the format of the media.
  • the semantics of fmt is linked to the proto field.
  • the proto field has to be "RTP/AVP". Consequently the fmt field reflects the payload type of RTP.
  • the payload type is "33". It indicates the MIME type "MP2T", as defined in RFC3551 , RTP Profile for Audio and Video Conferences with Minimal Control, July 2003.
  • MP2T designates the use of MPEG2 transport streams, for either audio and/or video.
  • MPEG2-TS does not necessarily mean that MPEG2 video and MPEG2 audio are carried inside.
  • SDP extensions are defined hereinafter. They define various possibilities to carry all relevant information in SDP about what is comprised inside a multiplexed content stream.
  • the advertised information is the transport layer, the services and for each of them the coding formats of elementary components.
  • the standard "RTP/AVP” and “udp” transport protocols are used.
  • the mux technology has first to register to IANA in order to provide a registered value for this mux technology, e.g. video/NEW_MUX.
  • IANA e.g. video/NEW_MUX.
  • RTP/AVP there are two possibilities.
  • the first one is to define and register (thanks to an RFC) a static RTP Payload Type.
  • the "MP2T/H2221/UDP” or “RAW/RAW/UDP” are used as transport protocol for UDP streaming. They are not registered with IANA, but as indicated in RFC4566 section 8.2.2, it is not mandated to do so. However, in case they would be registered, the ⁇ fmt> field has to be defined, it can be "33", i.e. the same as for the RTP/AVP transport; or "MP2T", i.e. the same as the "udp" transport, or something else.
  • a "mux” media type with standard transport is used.
  • RTP/AVP RTP/AVP
  • UDP UDP
  • This parameter it is possible to bring the first information on the content. More precise information is then announced by other SDP lines.
  • the target is to announce the MPEG services inside the TS.
  • a fmtp:33
  • the media format is similar to an rtpmap line.
  • the media parameter is similar to an fmtp line.
  • sub-media lines can be used to describe the components.
  • a submedia section is defined below the media section. This submedia section defines the media type for each stream inside a multiplex media. It enables to declare the media using the standard naming convention and reuse standard attributes.
  • the SDP file is also cleaner because it is possible to clearly separate programs within the multiplex, and components within each program, on specific attribute lines.
  • the corresponding submedia tracks are defined, respectively "528, 529, 544, 545" and "784, 785".
  • n ⁇ mediatype> SPACE ⁇ media id> SPACE ⁇ mime media type>/ ⁇ clock rate>[/ ⁇ nb channels>].
  • Any standard media attributes can be used to describe a media stream embedded as a submedia in a multiplex.
  • the shown attributes are format specific parameters.
  • attributes for controlling the individual streams can be added.
  • m video 4002 MP2T/RTP/AVP
  • 33 a fmtp : 33 MP2T 512;
  • new media type and new transport parameters are defined.
  • This new media type reflects the multiplexed format of MPEG2-TS: "mux”.
  • This embodiment enables to define new attribute line.
  • the SDP file enables to clearly separate services within the multiplex, and components within each service, on specific attribute lines.
  • the proto field is "MP2T/UDP" instead of “MP2T/RTP/UDP", the rest of the SDP file remaining the same.
  • the second level is addressing the services advertised by the first level, the reference is the PMT PID parameter of the first level.
  • the third level is addressing the coding specific parameters, so this is an equivalent of the fmtp attribute line.
  • the reference is the component PID as advertised in the second level.
  • the system according to the embodiments is indicated in figure 2. It comprises a server 1 connected to a client 2 through an Internet network 3.
  • the server comprises a multiplex content description module 11. It is adapted to advertise the multiplex content as indicated hereinabove.
  • the client according to the embodiment is an electronic device adapted to receive multimedia programs in a manner well known per se; it comprises the following modules, not represented, such as communicating module 22 for receiving and sending data to the IP network, processing means 23 and a memory 24.
  • the client comprises a multiplex content analysis module 21. It is adapted to analyze the advertised multiplex content as indicated hereinabove.
  • the client also comprises a playing module 25, not represented, for receiving and playing the multiplex content as announced in the session description.
  • the playing module is well known in the art of client devices receiving multimedia content.

Abstract

The present invention concerns a server adapted for advertising multiplex content comprising a plurality of programs and a plurality of components. The server comprises means for sending a session description comprising a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content. The invention also concerns a receiver for being advertised of the multiplex content.

Description

SYSTEM AND METHOD FOR ADVERTISING MULTIPLEX CONTENT
FIELD OF THE INVENTION
The present invention relates generally to multimedia content distribution and in particular to the distribution of information relative to a multimedia session.
BACKGROUND OF THE INVENTION
This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
MPEG2 standards define a method to multiplex various component parts of a multimedia program, and several multimedia programs altogether. A program may comprise various components, such as audio, video and control data. These components are transported in different transport stream packets, called TS packets, all having the same identifier for the same component. The identifier is also called packet identifier or PID. The PID is used to uniquely identify the component to which the packet belongs. In order to receive a particular component stream, a receiver determines the PID being used. Then it filters packets that have a matching PID value. To help the receiver identify which PID corresponds to which component from which program, signaling tables are transmitted with a description of each program carried within the MPEG-2 Transport Stream. At a receiver it is necessary to perform the loading and parsing of MPEG signaling tables (Program Specific Information) in order to navigate in the TS structure. This is defined in MPEG2-System, ISO IEC 13818-1 , "Information technology - Generic coding of moving pictures and associated audio information: Systems". MPEG-PSI and DVB-SI define information data which allows the user to be provided with information to assist in selection of services and/or events within the bitstream. This is specified in the standard document ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (Sl) in DVB systems" (DVB-SI). In particular, a terminal needs to process several MPEG-PSI tables to get the PID (Packet Identifier) that corresponds to a specific component of a specific program within a Transport Stream. The terminal also needs to track any change in the tables.
A MPEG2 Transport Stream can therefore carry one or more programs, each individual program holding a set of one or more components, of the same or different types. The type of a component is video, audio, subtitle or private data. The MPEG-PSI and DVB-SI tables provide all relevant information concerning those programs and components. But those tables are only accessible by a receiver when connecting to the Transport Stream. It would be advantageous to retrieve such information prior to connecting to the stream. Unfortunately, generally the only information available is that the content is using MPEG2 Transport stream multiplexing technology, and no additional information is provided on elements such as programs, or components.
SUMMARY OF THE INVENTION
The present invention attempts to remedy at least some of the concerns connected with the prior art, by providing a method enabling to advertise content that comprises a multiplex of several services.
The invention concerns a server adapted for advertising multiplex content comprising a plurality of programs and a plurality of components. The server comprises means for sending a session description comprising a first information indicating the presence of multiplex content and at least one second information indicating the composition of the multiplex content. A session description is a well-defined format for conveying sufficient information to discover and participate in a multimedia session. The multiplex content and the composition of the multiplex content are announced through the session description. This simplifies the announcement between the server and the receivers.
According to an embodiment, the at least one second attribute indicates the composition of the multiplex content as a set of programs and/or components.
According to an embodiment, the multimedia content is carried into an MPEG-2 transport stream.
The invention also concerns a method at a server for advertising multiplex content comprising a plurality of programs and a plurality of components. The method comprises the step of sending a session description comprising a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content.
The invention also concerns a receiver device comprising communicating means for receiving a session description comprising a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content; and analysis means for identifying the composition of the multiplex content indicated in the session description.
According to an embodiment, the receiver comprises playing means for receiving the multiplex content.
The invention also concerns a method at a receiver for receiving multiplex content comprising a plurality of programs and a plurality of components. The method comprises the step of receiving, in a session description, a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content; identifying the composition of the multiplex content indicated in the session description; and receiving the multiplex content.
Another object of the invention is a computer program product comprising program code instructions for executing the steps of the process according to the invention, when that program is executed on a computer. By
"computer program product", it is meant a computer program support, which may consist not only in a storing space containing the program, such as a diskette or a cassette, but also in a signal, such as an electrical or optical signal.
Certain aspects commensurate in scope with the disclosed embodiments are set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of certain forms the invention might take and that these aspects are not intended to limit the scope of the invention. Indeed, the invention may encompass a variety of aspects that may not be set forth below.
BRIEF DESCRIPTION OF THE DRAWINGS The invention will be better understood and illustrated by means of the following embodiment and execution examples, in no way limitative, with reference to the appended figures on which:
Figure 1 represents two MPEG2-TS services; and - Figure 2 represents a system according to the embodiments.
In Figure 2, the represented blocks are purely functional entities, which do not necessarily correspond to physically separate entities. Namely, they could be developed in the form of hardware or software, or be implemented in one or several integrated circuits. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
The exemplary embodiments come within the framework of
Session Description Protocol but the invention is not limited to this particular protocol and may be applied within other frameworks enabling to advertise multimedia sessions. Moreover the embodiments are not limited to the
MPEG2-TS multiplexing technology.
Each embodiment described hereinafter is illustrated with the help of one example of an MPEG2 Transport Stream (MPEG2-TS). The MPEG2- TS stream of the example comprises two services, as illustrated in figure 1. It should be noted that the terms program and service are used hereinafter to designate the same entity.
The first service is called "First Service". It has a PMT (Program Map Table) PID 0x200. It comprises two video components and two audio components:
The first video component is a SD (Standard Definition) MPEG2 one (PID 0X210)
The second video component is a HD (High Definition) H264 one (PID 0X211 ) - The first audio components is English in MPEG1 Layer Il (PID
0X220)
The second audio component is French in AC3 at 48kHz and 6 channels (PID 0X221 )
The second service is called "Second Service". It has a PMT PID
0X300. It comprises one video component and one audio component: The video component is a SD H264 one (PID 0X310) The audio component is AAC coding (0X320)
The content is advertised to the receivers as described hereinafter. This is performed based on the Session Description Protocol, defined in RFC4566, SDP: Session Description Protocol, July 2006. SDP is a format that permits to describe content and multimedia sessions in an ASCII string; ASCII standing for American Standard Code for Information Interchange. SDP is a format for session description. It doesn't define any transport protocol; it is intended to use different transport protocols as appropriate. The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. An SDP session description includes a session name and purpose, the time the session is active, the media comprising the session, and information needed to receive those media (addresses, ports, formats, etc.).
According to SDP, a multimedia session is composed of a set of multimedia streams, each one being described with "c=" and "m=" lines as defined hereinafter. The SDP fields described hereinafter are indicated using a generic notation, where <field> is the SDP field. A SDP session description consists of a session-level section followed by zero or more media-level sections. Each line comprises a one letter parameter followed by the equal sign "=" and then one or more parameters. An example of a SDP file is illustrated below:
v=0 o=jdoe 2890844526 2890842807 IN IP4
10.47.16.5
S=SDP Seminar i=A Seminar on the session description protocol u=http : //www . example . com/seminars/sdp . p df e=j . doe@example . com (Jane Doe)
C=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000
The meaning of such a SDP file is basically:
Multicast address where to find the streams is 224.2.17.12,
TTL is 127; Audio is sent on port 49170, and is coded thanks to static payload type 0, meaning implicitly that the audio is encoded with PCMU at 8kHz;
Video is sent on port 51372, and is coded thanks to dynamic payload type 99, so the rtpmap attributes provides more information, which is H263-1998 at 90kHz.
The "c=" line is providing information on the connection to the media. The "m=" line is providing information on the media itself. The definition of those lines is specified in RFC4566 as follows: c=<nettype> <addrtype> <connection-address> nettype is "IN" for internet addrtype is "IP4" for lPv4 connection-address is the address where to find the content. It can be a multicast address (then followed by the TTL) or a unicast address, the one of the server.
m=<media> <port> <proto> <fmt> ... media is the media type, such as "audio", "video", "text", "application" port is the TCP or UDP port where this media is sent (UDP or TCP depends on the proto field) proto is the underlying transport protocol. Defined values are:
- "RTP/AVP", the most used one for multimedia content. - "udp", for unspecified protocol over UDP layer.
- "RTP/SAVP", for secure RTP streams. fmt is the format of the media. The semantics of fmt is linked to the proto field.
According to RFC4566, when using the RTP layer, the proto field has to be "RTP/AVP". Consequently the fmt field reflects the payload type of RTP. This payload type field is coded on 7 bits, which provide then 127 values. Values between 0 and 95 provide static payload type; i.e. the payload type number identifies precisely the content format transported. Values between 96 and 127 provide dynamic payload type. In this case, it is just a pointer to other SDP lines ("a=rtpmap:" and "a=fmtp:" attributes) that convey more information about the coding format used. "a=rtpmap:" attribute maps from an RTP payload type number (as used in an "m=" line) to an encoding name denoting the payload format to be used. "a=fmtp:" attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. When sending content encapsulated within MPEG2-TS over RTP, the payload type is "33". It indicates the MIME type "MP2T", as defined in RFC3551 , RTP Profile for Audio and Video Conferences with Minimal Control, July 2003. MP2T designates the use of MPEG2 transport streams, for either audio and/or video. This is a static payload, and there is no more information about how many services are carried in this MPEG2-TS stream, nor about the coding format which is carried inside that MPEG2-TS layer (MPEG2-TS does not necessarily mean that MPEG2 video and MPEG2 audio are carried inside).
In order to advertise content that is containing a multiplex of several services and components, SDP extensions are defined hereinafter. They define various possibilities to carry all relevant information in SDP about what is comprised inside a multiplexed content stream. The advertised information is the transport layer, the services and for each of them the coding formats of elementary components.
According to the embodiment, the "m=" line of multiplexed content may be defined through multiple manners.
According to a first mode, the standard "RTP/AVP" and "udp" transport protocols are used. The following "m=" lines correspond to the MPEG2-TS mux following standard parameters (RFC4566): m=video 4002 RTP/AVP 33 // 33 means MPEG2-TS as payload type m=video 4002 udp MP2T // MP2T is the media type for MPEG2-TS
It is not necessary to use the "a=rtpmap:" attribute for RTP here since "33" is defining the MPEG2-TS layer. Then the description of the multiplexed content is done starting with the "a=fmtp:" attribute: m=video 4002 RTP/AVP 33 a=fmtp:33 <specific parameters for
MPEG2-TS> m=video 4002 udp MP2T a=fmtp:MP2T <specific parameters for
MPEG2-TS>
For a mux technology other than MPEG2-TS, the mux technology has first to register to IANA in order to provide a registered value for this mux technology, e.g. video/NEW_MUX. For RTP/AVP there are two possibilities.
The first one is to define and register (thanks to an RFC) a static RTP Payload Type. For example, "35" is unassigned and could be used for this video/NEW_MUX IANA registered media type: m=video 4002 RTP/AVP 35 a=fmtp:35 <specific parameters for mux technology 35>
The second one is to use a dynamic payload type and the "a=rtpmap:" attribute to identify it thanks to the MIME type: m=video 4002 RTP/AVP 97 a=rtpmap:97 <MIME type of mux technology>/<encoding rate> a=fmtp:97 <specific parameters for mux technology>
For udp then this new MIME type, video/NEW_MUX, will be used instead of MP2T, as indicated in RFC4456. m=video 4002 udp NEW_MUX a=fmtp:NEW MUX <specific parameters for mux technology> Whatever the transport protocol, the multiplexed content can then be described starting from the "a=fmtp:" attribute.
According to a second mode, the "MP2T/H2221/UDP" or "RAW/RAW/UDP" are used as transport protocol for UDP streaming. They are not registered with IANA, but as indicated in RFC4566 section 8.2.2, it is not mandated to do so. However, in case they would be registered, the <fmt> field has to be defined, it can be "33", i.e. the same as for the RTP/AVP transport; or "MP2T", i.e. the same as the "udp" transport, or something else. The <fmt> provides a reference for the "a=fmtp:" attribute. m=video 4002 MP2T/H2221/UDP MP2T a=fmtp:MP2T <specific parameters for : MPEG2-TS>
Of course this transport value cannot be used for mux technology other than MPEG2-TS, since "MP2T" is part of the transport parameter.
According to a third mode, a "mux" media type with standard transport is used. For standard RTP ("RTP/AVP") streaming and UDP ("udp") streaming, as well as for the "MP2T/H2221/UDP" transport protocol, the "m=" line is then: m=mux 4002 RTP/AVP 33 J m=mux 4002 udp MP2T m=mux 4002 MP2T/H2221/UDP MP2T
All what is described for the other two modes apply in this mode as well. The multiplexed content is described starting from the "a=fmtp:" attribute. In this mode it is clearly announced that the content is multiplexed, instead of the "video" media type which does not necessarily reflects the actual content. The following table indicates the different possibilities available for the "m=" line announcing multiplexed content.
Figure imgf000013_0001
The multiplexed content is now described. The description of the multiplexed content starts with the "a=fmtp:" attribute. This is a standard parameter, specified in RFC4566 by: a=fmtp : <format> <format specific parameters>
With this parameter, it is possible to bring the first information on the content. More precise information is then announced by other SDP lines. This line is of course dependent on the mux technology used, since it refers to the <fmt> defined in the "m=" line.
As an example, the "a=fmtp:" attribute for MPEG2-TS content is defined as follows. The target is to announce the MPEG services inside the TS. a=fmtp:33 |MP2T 512; "First Service";528, 529, 544, 545 768;"Second Service";784, 785
The general format is: a=fmtp:"33" or "MP2T" SPACE <service 1 > SPACE <service 2> ... - <service description>=<PMT PID>";"<service name>";"<components PIDs>
<Components PIDs>=<component 1 PID>","<component 2 PID>","... Then some more lines are needed to describe more precisely the components for each service. This comprises their type, their coding format, and their name if available. For example, an attribute line is defined to describe the components. It is called muxmap attribute line. It is illustrated in the table below. a=muxmap : 528 video MPV/90000 a=muxmap : 529 video H264/90000 profile- level-id=6EA01E a=muxmap : 544 audio audio/MPA a=muxmap : 545 audio AC3/48000/6 a=muxmap : 784 video H264/90000 profile- level-id=42A015 a=muxmap : 785 audio mpeg4-generic/44100 streamtype=5 ; profiIe-level- id=15;mode=AAC-hbr;config=1210
The structure of the muxmap attribute is: a=muxmap:<component PID> SPACE <media type> SPACE <media format> [SPACE <media parameters>] media format=<encoding name>/<clock rate> [encoding parameters] media parameters=<format specific parameters> The media format is similar to an rtpmap line. The media parameter is similar to an fmtp line.
Alternatively, sub-media lines can be used to describe the components. A submedia section is defined below the media section. This submedia section defines the media type for each stream inside a multiplex media. It enables to declare the media using the standard naming convention and reuse standard attributes. The SDP file is also cleaner because it is possible to clearly separate programs within the multiplex, and components within each program, on specific attribute lines.
This submedia declaration takes the form "n=*" and is similar to a media declaration.
The following table presents such a SDP file:
! m=video 4002 MP2T/RTP/AVP 33 \ a=fmtp:33 MP2T 512; "First
Service";528, 529, 544, 545; 768 ; "Second
Service";784, 785 n=video 528 MPV/90000 n=video 529 H264/90000 a=fmtp: 529 profile-level-id=6EA01E n=audio 544 MPA n=audio 545 AC3/48000/6 n=video 784 H264/90000 a=fmtp:784 profiIe-level-id=42AO 15 n=audio 785 mpeg4-generic/44100 a=fmtp : 785 streamtype=5 ; profiIe-level- id=15;mode=AAC-hbr;config=1210
The fmt parameters at the end of the "m=" line is a pointer to the description of services inside the MPEG2-TS. For each service "512 and 768", the corresponding submedia tracks are defined, respectively "528, 529, 544, 545" and "784, 785".
The submedia definitions are similar to media definitions. The syntax is n=<mediatype> SPACE <media id> SPACE <mime media type>/<clock rate>[/<nb channels>].
Following each submedia definition, there can be any number of attributes applying only to this media.
Any standard media attributes can be used to describe a media stream embedded as a submedia in a multiplex. In the above example, the shown attributes are format specific parameters.
Another usage for attributes is that each submedia can be controlled individually, like media tracks in a RTSP session. If the session in the above example is served by a RTSP server, attributes for controlling the individual streams can be added. m=video 4002 MP2T/RTP/AVP 33 a=fmtp : 33 MP2T 512; "First
Service ";528 ,529, 544, 545; 768; "Second
Service " ; 784 ,785 n=video 528 MPV/90000 a=control:rtsp://foo/FirstService/video
/528 n=video 529 H264/90000 a=control:rtsp://foo/FirstService/video
/529 a=fmtp: 529 profile-level-id=6EA01E n=audio 544 MPA a=control:rtsp: //foo/FirstService/audio
/544 n=audio 545 AC3/48000/6 a=control:rtsp: //foo/FirstService/audio
/545 n=video 784 H264/90000 a=control:rtsp://foo/FirstService/video
/784 a=fmtp:784 profiIe-level-id=42AO 15 n=audio 785 mpeg4-generic/44100 a=control:rtsp: //foo/FirstService/audio
/785 a=fmtp : 785 streamtype=5 ; profiIe-level- id=15;mode=AAC-hbr;config=1210
According to another embodiment, new media type and new transport parameters are defined. This new media type reflects the multiplexed format of MPEG2-TS: "mux".
This embodiment enables to define new attribute line. The SDP file enables to clearly separate services within the multiplex, and components within each service, on specific attribute lines.
The following example presents such a SDP file: m=mux 4002 MP2T/RTP/UDP 1 2 a=muxmap : 1 512; "First Service" a=muxmap : 2 768; "Second Service" a=muxmap: 512 528 ; video/MPV/90000 529; video/H264/90000 544 ; audio/MPA 545; audio/AC3/48000/6 a=muxmap:768 784 ; video/H264/90000 785; audio/mpeg4-generic/44100 a=muxmap: 529 profile-level-id=6EA01E a=muxmap : 784 profiIe-level-id=42A015 a=muxmap : 785 streamtype=5;profile- level-id=15;mode=AAC-hbr;config=1210
In case of UDP streaming, the proto field is "MP2T/UDP" instead of "MP2T/RTP/UDP", the rest of the SDP file remaining the same. The fmt parameters at the end of the "m=" line are pointers to services inside the MPEG2-TS. Such pointers are referring to muxmap attribute lines for more information. There are 3 types of muxmap attribute lines, depending on their level in the information discovery:
The first level is a direct reference to the fmt parameter. Its format is: a=muxmap:<fmt> SPACE <PMT PID>[;<service name>]
The second level is addressing the services advertised by the first level, the reference is the PMT PID parameter of the first level. The format is: a=muxmap:<PMT PID> SPACE <Component PID>;<component media type/subtype/clockrate/[encoding parameters]>
The third level is addressing the coding specific parameters, so this is an equivalent of the fmtp attribute line. The reference is the component PID as advertised in the second level. The format is: a=muxmap:<Component PID> SPACE <format specific parameters>
The system according to the embodiments is indicated in figure 2. It comprises a server 1 connected to a client 2 through an Internet network 3. Of course the network might be any kind of network enabling to transport advertisement messages according to the embodiment. The server comprises a multiplex content description module 11. It is adapted to advertise the multiplex content as indicated hereinabove. The client according to the embodiment is an electronic device adapted to receive multimedia programs in a manner well known per se; it comprises the following modules, not represented, such as communicating module 22 for receiving and sending data to the IP network, processing means 23 and a memory 24. In particular, the client comprises a multiplex content analysis module 21. It is adapted to analyze the advertised multiplex content as indicated hereinabove. The client also comprises a playing module 25, not represented, for receiving and playing the multiplex content as announced in the session description. The playing module is well known in the art of client devices receiving multimedia content.
References disclosed in the description, the claims and the drawings may be provided independently or in any appropriate combination. Features may, where appropriate, be implemented in hardware, software, or a combination of the two.
Reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one implementation of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

1. A server (1 ) adapted for advertising multiplex content comprising a plurality of programs and a plurality of components, said server comprising means (11 ) for sending a session description comprising: a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content.
2. A server according to claim 1 , said at least one second information indicating the composition of the multiplex content as a set of programs and/or components.
3. A server according to claims 1 or 2, said multimedia content being carried into an MPEG-2 transport stream.
4. Method at a server (1 ) for advertising multiplex content comprising a plurality of programs and a plurality of components, said method comprising the step of sending a session description comprising: a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content.
5. A receiver device (2) comprising: communicating means (22) for receiving a session description comprising a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content; and analysis means (21 ) for identifying the composition of the multiplex content indicated in said session description.
6. A receiver according to the preceding claim, comprising playing means (25) for receiving said multiplex content.
7. Method at a receiver for receiving multiplex content comprising a plurality of programs and a plurality of components, said method comprising the step of: receiving, in a session description, a first information indicating the presence of multiplex content; and at least one second information indicating the composition of the multiplex content; identifying the composition of the multiplex content indicated in said session description; and receiving said multiplex content.
8. Computer program product, characterized in that it comprises program code instructions for executing the steps of the method according to claim 7 when said program is executed on a computer.
PCT/EP2009/050891 2008-01-28 2009-01-27 System and method for advertising multiplex content WO2009095385A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP08300056.2 2008-01-28
EP08300056 2008-01-28

Publications (1)

Publication Number Publication Date
WO2009095385A1 true WO2009095385A1 (en) 2009-08-06

Family

ID=40559888

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/050891 WO2009095385A1 (en) 2008-01-28 2009-01-27 System and method for advertising multiplex content

Country Status (1)

Country Link
WO (1) WO2009095385A1 (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0964581A1 (en) * 1998-06-10 1999-12-15 NOKIA TECHNOLOGY GmbH Method and device for transmitting information to the DVB network
GB2396444A (en) * 2002-12-18 2004-06-23 Nokia Corp A Method of Announcing Sessions
JP2004228850A (en) * 2003-01-22 2004-08-12 Matsushita Electric Ind Co Ltd Receiving/reproducing method, and receiving/reproducing apparatus
WO2005069624A2 (en) * 2004-01-06 2005-07-28 Thomson Licensing Method of transmitting digital services over a network and device implementing the method
US20060062200A1 (en) * 2003-01-09 2006-03-23 Wang Charles C Method and an apparatus for mapping an mpeg transport stream into ip packets for wlan broadcast
US7296091B1 (en) * 1999-06-18 2007-11-13 The Trustees Of Columbia University In The City Of New York System and method for receiving over a network a broadcast from a broadcast source

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0964581A1 (en) * 1998-06-10 1999-12-15 NOKIA TECHNOLOGY GmbH Method and device for transmitting information to the DVB network
US7296091B1 (en) * 1999-06-18 2007-11-13 The Trustees Of Columbia University In The City Of New York System and method for receiving over a network a broadcast from a broadcast source
GB2396444A (en) * 2002-12-18 2004-06-23 Nokia Corp A Method of Announcing Sessions
US20060062200A1 (en) * 2003-01-09 2006-03-23 Wang Charles C Method and an apparatus for mapping an mpeg transport stream into ip packets for wlan broadcast
JP2004228850A (en) * 2003-01-22 2004-08-12 Matsushita Electric Ind Co Ltd Receiving/reproducing method, and receiving/reproducing apparatus
WO2005069624A2 (en) * 2004-01-06 2005-07-28 Thomson Licensing Method of transmitting digital services over a network and device implementing the method

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG) European B roadcasting U nion U nion E uropéenne de R adio-Télévision EB UÜER; ETSI TS 102 471", ETSI STANDARDS, LIS, SOPHIA ANTIPOLIS CEDEX, FRANCE, vol. BC, no. V1.2.1, 1 November 2006 (2006-11-01), XP014039808, ISSN: 0000-0001 *
"Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems; ETSI EN 300 468", ETSI STANDARDS, LIS, SOPHIA ANTIPOLIS CEDEX, FRANCE, vol. BC, no. V1.5.1, 1 May 2003 (2003-05-01), XP014001579, ISSN: 0000-0001 *
"Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks European B roadcasting Union U nion Européenne de R adio-Télévision EB UÜER; ETSI TS 102 034", ETSI STANDARDS, LIS, SOPHIA ANTIPOLIS CEDEX, FRANCE, vol. BC, no. V1.3.1, 1 October 2007 (2007-10-01), XP014039760, ISSN: 0000-0001 *
"MPEG-2, systems part, 2nd edition", JOINT VIDEO TEAM (JVT) OF ISO/IEC MPEG & ITU-T VCEG(ISO/IEC JTC1/SC29/WG11 AND ITU-T SG16 Q6), XX, XX, no. 13818-1:2000, 1 February 2000 (2000-02-01), XP030001501 *
EBU-UER: "Digital Video Broadcasting (DVB); Architectural framework for the delivery of DVB-services over IP-based networks", 20020201; 20020200, 1 February 2002 (2002-02-01), pages 1 - 19, XP002303715 *
P LIEFOOGHE: "A Scalable Internet Program Guide Architecture", 2003 AUSTRALIAN TELECOMMUNICATIONS, NETWORKS AND APPLICATIONS CONFERENCE (ATNAC), 8 December 2003 (2003-12-08) - 10 December 2003 (2003-12-10), XP007908466, ISBN: 0-646-42229-4, Retrieved from the Internet <URL:http://atnac2003.atcrc.com/ORALS/Liefooghe.pdf> [retrieved on 20090508] *

Similar Documents

Publication Publication Date Title
JP6441521B2 (en) Control message composition apparatus and method in broadcast system
US11317138B2 (en) Method and apparatus for transmitting or receiving service signaling for broadcasting service
KR102019101B1 (en) Method of transferring media contents over single port or multiple port and apparatus for performing the same
CN101924742B (en) Media transmission method and equipment, and media storage method and equipment
CN112154672B (en) Method, device and readable storage medium for retrieving media data
JP2003037623A (en) Direct rtp delivery method and system over mpeg network
US20080189754A1 (en) Pod Identification Method in Digital Content Providing System
CN104040993A (en) Method for sending respectively receiving media stream
Herpel et al. MPEG-4 Systems: Elementary stream management
US9998798B2 (en) Reception device, reception method, transmission device, and transmission method
JP2007043739A (en) Method and system for providing content description information and connection information
Park et al. Delivery of ATSC 3.0 services with MPEG media transport standard considering redistribution in MPEG-2 TS format
JP2007507942A (en) Method and apparatus for transmitting DVB service over IP network
US20030069930A1 (en) Service information multicasting method and system
US8296444B2 (en) Medium resource reservation method, service package information obtaining method and apparatus
JP4391412B2 (en) Dynamic multiplexing method of digital stream
WO2009095385A1 (en) System and method for advertising multiplex content
CN103959796A (en) Digital video code stream decoding method, splicing method and apparatus
CN110719244B (en) Method and system for transmitting media in heterogeneous network
MX2011007905A (en) Method, apparatus and system for improving tuning in receivers.
KR20080023902A (en) Internet protocol packet re-transporting apparatus for digital multimedia broadcasting service
Kang et al. Method of DASH segments into a MMTP stream for switching contents under a hybrid broadcasting environment
Terry An Open, Standards-Based Framework for Audio Metadata Transport in Live Content Workflows
Binh et al. Design and implementation of an embedded multimedia live streaming decoder system
Lim et al. A path control architecture for receiving various multimedia contents

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: 09705030

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09705030

Country of ref document: EP

Kind code of ref document: A1