WO2011003231A1 - 一种可伸缩视频编码文件的传输方法、接收方法及装置 - Google Patents

一种可伸缩视频编码文件的传输方法、接收方法及装置 Download PDF

Info

Publication number
WO2011003231A1
WO2011003231A1 PCT/CN2009/072650 CN2009072650W WO2011003231A1 WO 2011003231 A1 WO2011003231 A1 WO 2011003231A1 CN 2009072650 W CN2009072650 W CN 2009072650W WO 2011003231 A1 WO2011003231 A1 WO 2011003231A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
decoding
enhanced
files
decoding dependency
Prior art date
Application number
PCT/CN2009/072650
Other languages
English (en)
French (fr)
Inventor
张园园
刘光远
乐培玉
石腾
田永辉
袁卫忠
张楚雄
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP09846982.8A priority Critical patent/EP2453652B1/en
Priority to CN2009801487267A priority patent/CN102165776B/zh
Priority to PCT/CN2009/072650 priority patent/WO2011003231A1/zh
Publication of WO2011003231A1 publication Critical patent/WO2011003231A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/37—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability with arrangements for assigning different transmission priorities to video input data or to video coded data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding

Definitions

  • the present invention relates to a file transmission technology, and in particular to a transmission method, a receiving method and a device for a scalable video encoded file. Background technique
  • the current MTV service is mainly mobile phone business.
  • the mainstream screen resolution of mobile phone is QVGA (Quarter Video Graphics Array), which is 320 X 240, but the mobile phone is developing towards HD video.
  • QVGA Quadrater Video Graphics Array
  • notebooks with wireless Internet access PDA (Personal Digital Assistant, personal digital assistant) and other terminals with a screen resolution greater than QVGA are also the object of MTV service. Therefore, MTV operators need to consider how to provide audio and video file download services to terminals with QVGA equivalent and terminals larger than QVGA based on broadcast/multicast.
  • SVC Scalable Video Coding
  • SVC Scalable Video Coding
  • the enhancement layer is used to enhance the video viewing effect. It cannot be decoded independently. It needs to be combined with the base layer and the previous enhancement layer to decode, and obtain video with specific bit rate, frame rate and resolution.
  • the base layer and one or more enhancement layers are stored in a certain format to obtain an SVC file. As the number of enhancement layers increases, SVC files can support a variety of bit rates, frame rates, and resolutions.
  • the inventors have found that the prior art has at least the following problems: Since the existing FLUTE-based SVC file transmission or reception technology requires the mobile phone to completely receive a complete SVC file including the base layer and all enhancement layers, or even SVC.
  • the file group therefore, causes a waste of the buffer space of the mobile phone and the like, and receiving the file including the base layer and all the enhancement layers causes the mobile phone to download files for a long time and consumes a large amount of power.
  • An embodiment of the present invention provides a method, a receiving method, and a device for transmitting a scalable video encoded file, which avoids waste of buffering of a user terminal by receiving one or more files of multiple files obtained by dividing the SVC file, and Reduces file reception time and saves power.
  • An embodiment of the present invention provides a method for transmitting a scalable video encoded file, including:
  • the scalable video encoding SVC file is divided into a basic file and at least one enhanced file; wherein the basic file includes at least basic layer media data, and the enhanced file includes some or all of the enhanced layer media data;
  • Each of the files obtained by the segmentation is transmitted through a transmission object
  • the embodiment of the invention further provides a file receiving method, including:
  • the target file is a basic file or an enhanced file
  • the basic file includes at least basic layer media data
  • the enhanced file includes some or all of the enhanced layer media data
  • a file to be received Determining, according to the decoding dependency information, a file to be received, where the file to be received is a basic file, or a basic file and at least one enhanced file;
  • An embodiment of the present invention further provides an SVC file transmission apparatus, including:
  • a splitting unit configured to divide the scalable video encoded SVC file into a basic file and at least one enhanced file; wherein the basic file includes at least basic layer media data, and the enhanced file includes some or all of the enhanced layer media data. ;
  • a transmission unit configured to transmit each file obtained by the segmentation through a different transmission object Transmitting and transmitting the description information of the one basic file and the at least one enhanced file and the decoding dependency information of each file, so that the terminal determines one or more files to be received according to the received decoding dependency information, and according to the The description information of one or more files receives the one or more files.
  • the embodiment of the invention further provides a file receiving device, comprising:
  • an obtaining unit configured to obtain decoding dependency information of the target file, where the target file is a basic file or an enhanced file, where the basic file includes at least basic layer media data, and the enhanced file includes part or all of the enhanced layer media data;
  • a determining unit configured to determine, according to the decoding dependency information, a file to be received, where the file to be received is a basic file, or a basic file and at least one enhanced file;
  • a first receiving unit configured to receive description information of the file to be received
  • a second receiving unit configured to receive the file to be received according to the description information of the file to be received.
  • Figure 1 is a schematic diagram of the format of an SVC file
  • FIG. 2 is a schematic structural diagram of a FLUTE session
  • FIG. 3 is a schematic diagram of a method for transmitting an SVC file according to Embodiment 1 of the present invention.
  • FIG. 4 is a schematic flow chart of step 120 in FIG. 3;
  • FIG. 5 is a schematic diagram of a file receiving method according to Embodiment 1 of the present invention.
  • FIG. 6 is a schematic diagram of a method for transmitting an SVC file according to Embodiment 2 of the present invention.
  • FIG. 7 is a schematic diagram of referring to media data from an enhanced file in metadata in a basic file according to an embodiment of the present invention.
  • step 320 in FIG. 7 is a schematic flow chart of step 320 in FIG. 7;
  • Embodiment 9 is a flowchart of a file receiving method in Embodiment 2 of the present invention.
  • FIG. 10 is a schematic flow chart of step 405 in FIG. 9;
  • FIG. 11 is a structural block diagram of a file transfer apparatus according to an embodiment of the present invention.
  • Figure 12 is a schematic diagram of the transmission unit of Figure 11;
  • Figure 13 is a second schematic view of the transmission unit of Figure 11;
  • Figure 14 is a third schematic view of the transmission unit of Figure 11;
  • FIG. 15 is a structural block diagram of a file receiving apparatus according to an embodiment of the present invention. detailed description
  • a heterogeneous scenario requiring QVGA and VGA can be used to obtain a basic layer and an enhancement layer by using SVC technology.
  • the base layer is decoded into QVGA format video.
  • the base layer and the enhancement layer are decoded together to obtain a VGA. Formatted video.
  • the base layer can be used as the base track of the SVC file trackl, and the base layer and the enhancement layer are combined as the enhancement track track2 of the SVC file.
  • the complete base layer + enhancement layer samples (here the sample is the video frame) are not stored in track2, but the enhancement layer samples and pointers to the base layer samples are stored.
  • the file reader can synthesize a complete sample based on the pointer, so the required storage space and A single VGA format file is close.
  • moov represents a movie box for storing metadata, that is, a description of media data
  • mdat is a media data box for storing media data
  • BL stands for Base Layer
  • EL stands for Enhancement Layer
  • E stands for extractor
  • SO stands for sample numbered 0
  • sample is a set of related samples
  • ) is a sample of a track that is physically stored together in succession.
  • the FLUTE protocol is a point-to-multipoint file transfer protocol based on the IP protocol.
  • a file is carried by a TO (Transport Object), and the transport object is transported with a TOI (Transport Object Identifier). Identification) Identification.
  • TO Transport Object
  • TOI Transport Object Identifier
  • Identification Identification
  • an FDT (Fi le Delivery Table) instance can be used to describe the files currently or to be transferred in the session.
  • FDT Fi le Delivery Table
  • description information of the file a set of description information (hereinafter referred to as description information of the file) of the file is provided in the FDT instance, and the description information includes the following parameters:
  • Content_ location indicates the identifier of the file, in the form of a URI (Uniform Resource Identifier) format, hereinafter referred to as Fi leURI, which is a mandatory parameter;
  • URI Uniform Resource Identifier
  • T0I indicates the transmission object identifier, which is a mandatory parameter.
  • Content-length indicates the size of the file, which is an optional parameter.
  • Transfer-length which indicates the size of the transport object, which is an optional parameter.
  • Content-Type The MIME (Multipurpose Internet Mai Extensions) type of the file is optional.
  • Content-Encoding indicates the content encoding mode of the file, which is an optional parameter.
  • Content-MD5 indicates the MD5 digest of the file, which is an optional parameter
  • FEC-0TI-FEC- Encoding- ID FEC-0TI-FEC- Instance- ID, FEC - OTI - Maximum - Source - Block - Length, FEC - 0TI - Encoding - Symbol - Length, FEC - OTI - Max - Number - of - Encoding - Symbol s, FEC - OTI - Scheme - Specific - Info: Represents FEC OTI (FEC Object Transmission Information, forward error correction coding object transmission information) information, which is an optional parameter;
  • GroupID Indicates the file group ID of the file, which is optional.
  • the FLUTE protocol states that an FDT instance is an XML document and can be expanded arbitrarily. If the XML parser does not recognize the extended elements/attributes, these elements and attributes are skipped directly.
  • the terminal needs to receive the entire file or even the entire file group: The receiving end considers that it has received a data packet after recovering the complete file, and then considers that a file is received; To receive a file from a filegroup, you must receive all the files in the filegroup, unless the receiving end is preconfigured to ignore the filegroup, at which point the receiver only receives the file.
  • an embodiment of the present invention provides an SVC file transmission method and a receiving method, which can reduce terminal storage consumption and power consumption when providing an SVC file download service to a heterogeneous terminal based on broadcast or multicast.
  • the embodiment provides a method for transmitting an SVC file.
  • the method includes: Step 110: The sending end divides the scalable video encoding SVC file into a basic file and at least one enhanced file.
  • an SVC file includes a base layer and media data of one or more enhancement layers. Their decoding dependencies are different.
  • the base layer is the lowest and can be decoded independently.
  • the enhancement layer cannot be decoded independently, needs to be decoded together with the base layer, or combined with the enhancement layer with lower base layer and decoding dependency, ie
  • the enhancement layer relies on the base layer or enhancement layer decoding that relies on the base layer and lower decoding dependencies.
  • the SVC file Before the SVC file is transmitted, the SVC file can be divided into multiple (ie, two or more) files according to the adaptation requirements, one of which is called a basic file, and the other is called an enhanced file.
  • the basic file includes a base layer and media data of the first 0 to the plurality of enhancement layers, and the basic file may be independent of any other files.
  • the data is independently decoded, that is, the decoding dependency of the basic file is the lowest.
  • the enhancement layers not included in the base file may be further divided into at least one group in descending order of decoding dependencies, each group including one or more enhancement layers, and each enhancement file includes one group of media data, ie Media data of one to more enhancement layers, that is, media data including all or part of the enhancement layer.
  • the adaptation requirements include, but are not limited to, supporting a certain screen resolution, supporting a certain transmission code rate, supporting a certain frame rate, and the like.
  • the operator can set the adaptation requirement collection function entity on the network side to collect the adaptation requirements, or manually configure the adaptation requirements. Since operators provide services in a heterogeneous environment, there are often multiple adaptation requirements.
  • Each file obtained by dividing the SVC file corresponds to an adaptation requirement, that is, the number of files into which the SVC file is divided is equal to the number of adaptation requirements.
  • Each file obtained by splitting the SVC file may contain one to multiple layers of media data according to the adaptation requirements of the file.
  • the adaptation requirement is a terminal that supports three screen resolutions of QVGA, HVGA, and VGA, that is, there are three adaptation requirements;
  • the SVC file includes a base layer, an enhancement layer 1, an enhancement layer 2, an enhancement layer 3, an enhancement layer 4, and an enhancement. Layer 5.
  • the decoding dependency of the enhancement layer 1 to the enhancement layer 5 increases from low to high, the resolution of the enhancement layer 1 is QVGA, the resolution of the enhancement layer 3 is HVGA, and the resolution of the enhancement layer 5 is VGA, wherein the resolution of the enhancement layer is The rate refers to the resolution of the resulting video after the enhancement layer is combined with the enhancement layer of the base layer and the decoding dependency.
  • the SVC file is divided into three files according to the adaptation requirements: basic file, enhanced file 1, and enhanced file 2.
  • the basic file includes the media data of the base layer and the enhancement layer 1, and the enhancement layers 2 to 5 not included in the basic file can be divided into two groups according to the adaptation requirements, the group 1 includes the enhancement layer 2 and the enhancement layer 3, and the group 2 includes the enhancement. Layer 4 and enhancement layer 5.
  • the enhanced file 1 includes the media data of the group 1, that is, the enhancement layer 2 and the enhancement layer 3, and the enhancement file 3 includes the media data of the group 2, that is, the enhancement layer 4 and the enhancement layer 5.
  • the decoding can be performed.
  • the enhanced file split in this step will also depend on at least the base file for decoding. Specifically, it is possible that the enhanced file can be decoded only in conjunction with the basic file, or it may be required to be combined with the basic file and other enhanced files to complete the decoding. The lower the decoding dependency of the enhancement layer included in the enhancement file, the less other enhancement files the enhanced file decoding depends on, and the lower the decoding dependency of the enhancement file.
  • the decoding dependency of the base layer and/or the enhancement layer included in the file obtained after the division can be determined as the decoding dependency of the file, and the number of files on which the enhanced file with low decoding dependency depends is relatively small.
  • the sender can obtain the SVC file structure by reading and parsing the metadata contained in the SVC file.
  • the partitioning method can be different depending on the structure of the SVC file.
  • File splitting can be done either by track or by a subset of tracks, ie sub-tracks.
  • tier refers to multiple groups of samples (media data) in a track divided into groups according to defined grouping rules, each group containing one or more scalable layers.
  • Grouping rules can be defined in a variety of ways, including but not limited to, based on resolution, frame rate, and a combination of resolution and frame rate.
  • a file identifier such as Fi leURI, can be assigned to the split file.
  • Step 120 Each file obtained by the segmentation is respectively carried and transmitted through a transmission object (TO).
  • TO transmission object
  • step 120 is subdivided into:
  • each file is divided into blocks.
  • the file is physically divided into a number of source blocks, each of which is identified by SBN (Source Block Number). The relative position in TO.
  • Step 120-2 performing FEC encoding on the chunked file. It can be encoded using a variety of FEC schemes, including Compact No-Code FEC scheme, Compact FEC Scheme, Smal l Block Systematic FEC Scheme (small block system forward error correction coding scheme) and so on.
  • FEC encoded data is encapsulated into a data packet.
  • Step 120-4 sending the encapsulated data packet.
  • Step 130 Transmit description information of the one basic file and the at least one enhanced file and decoding dependency information of each file, so that the terminal determines one or more files to be received according to the received decoding dependency information, and according to the The description information of one or more files receives the one or more files.
  • An FDT instance may be generated according to a plurality of files to be transmitted, and the FDT instance includes description information of each file, such as a file identifier of each file, a transfer object identifier, and the like.
  • the decoding dependency information of each file may be set to be transmitted in an FDT instance, or may be transmitted through a separate file.
  • the decoding dependency information of the file is used to indicate the file information on which the file is decoded, and the decoding dependency relationship with other files is embodied.
  • the SVC file may be divided into multiple files according to the adaptation requirement.
  • the user equipment may only receive the divided file corresponding to the adaptation requirement and the decoding device thereof.
  • Dependent files without receiving the entire SVC file or file group, thereby avoiding the waste of user device side cache space, and reducing the time for file reception, saving power.
  • the embodiment of the present invention further provides a file receiving method, which can be completed by a terminal as a receiving end.
  • the method includes:
  • Step 210 Acquire decoding dependency information of the target file.
  • the target file may be a basic file or an enhanced file after the scalable video encoded SVC file is divided into a basic file and at least one enhanced file, where the basic file includes at least basic layer media data, and the enhanced file includes a partial or All enhancement layer media data.
  • the terminal first receives an ESG (Electronic Service Guide), and the user or the terminal selects the target file through the ESG, and the ESG application transmits the file identifier FileURI of the target file to the file receiving device, and the file receiving device can
  • ESG Electronic Service Guide
  • the ESG application transmits the file identifier FileURI of the target file to the file receiving device
  • the file receiving device can
  • a file receiving method receives a file.
  • the target file is a basic file obtained by dividing the SVC file or one of the enhanced files.
  • the ESG provides description information of the file, and describes the terminal capability for the file.
  • the specific delivery method may be a text description for the user to understand and select; or an XML (Extensible Markup Language) description for the terminal to understand and select.
  • the user or terminal usually selects a file that matches the capabilities of the terminal, that is, the target file.
  • the terminal capabilities include, but are not limited to, the screen resolution of the terminal, the codec algorithm supported by the terminal, the network access bandwidth supported by the terminal, the buffer capacity of the terminal, and the like.
  • the SVC file is divided into a basic file and two enhanced files.
  • the resolution of the basic file is QVGA, and the resolutions of the two enhanced files are HVGA and VGA, respectively.
  • the resolution of the enhanced file refers to the enhanced file and the enhanced file.
  • the resolution of the video obtained by decoding the decoded base file and other enhancement files together.
  • ESG provides description information for three files, indicating the resolution of the three files or the screen resolution of the terminals for the three files are QVGA, HVGA, and VGA.
  • a user or terminal with a screen resolution of QVGA can select a basic file as a target file, and a user or terminal having a screen resolution of HVGA or VGA can select one of two enhanced files as a target file.
  • the description of the three files provided by ESG can also indicate that the size of the three files is 100MB, 200MB, 400MB, and the user or terminal with a cache capacity of 500MB can select the basic file as the target file, and the user or terminal with the cache capacity of 4GB. You can select one of the two enhancement files as the target file.
  • Step 220 Determine, according to the decoding dependency information, a file to be received, where the file to be received is a basic file, or a basic file, and at least one enhanced file.
  • the target file has a decoding dependent file according to the decoding dependency information, determining that the target file and the decoding dependent file of the target file are files to be received;
  • the target file does not have a decoding dependent file based on the decoding dependency information, it is determined that the target file is a file to be received.
  • the decoding dependent file refers to a file dependent on the target file decoding, and the decoding of the target file is completed by combining the target file and the decoding dependent file of the target file.
  • Step 230 Receive description information of the file to be received.
  • the description information of the file to be received may be respectively obtained from an FDT instance of a file to be received, and the description information includes at least a transmission object identifier.
  • Step 240 Receive the file to be received according to the description information of the file to be received.
  • a data packet for carrying the file to be received may be received according to the transport object identifier in the description information of the file to be received.
  • the receiving end transmits the received file to the upper application device, such as a player, and the application device completes decoding and displaying the file.
  • the upper application device such as a player
  • the terminal receives one or more of a plurality of files (one basic file and at least one enhanced file) obtained by dividing the complete SVC file according to different target files selected by the user or the terminal.
  • the target file is a basic file
  • the terminal only needs to receive the target file;
  • the target file is an enhanced file
  • the terminal only needs to receive the target file, the decoding dependent file of the target file (ie, the target file depends on the base file and 0 to many other enhancements) File), does not need to receive other enhancement files that the target file does not depend on, thereby avoiding waste of the user terminal cache, reducing the time for file reception, and saving power.
  • Example 2
  • This embodiment further provides a file transmission method. As shown in FIG. 6, the method includes:
  • Step 310 The sender splits the scalable video coding SVC file into a basic file and at least one enhanced file according to an adaptation requirement.
  • the adaptation requirements include, but are not limited to, supporting multiple screen resolutions, supporting multiple transmission code rates, supporting multiple frame rates, and the like.
  • the operator can set the adaptation requirement collection function entity on the network side to collect the adaptation requirements, or manually configure the adaptation requirements.
  • the sender can obtain the SVC file structure by reading and parsing the metadata contained in the SVC file.
  • the split mode can be different depending on the structure of the SVC file.
  • This splitting method may be split by track, or it may be split by Tier (layer's operating point, subset of track).
  • Tier refers to a plurality of groups in which a sample (media data) in a track is divided according to a certain grouping rule, and each group includes one or more scalable layers.
  • Grouping rules can be defined in a variety of ways, including but not limited to, based on resolution, frame rate, and a combination of resolution and frame rate.
  • the grouping rule can be: Group 1 The resolution is QVGA, the resolution of group 2 is VGA; the frame rate of group 1 is 15 frames/second, the frame rate of group 2 is 30 frames/second; or, the resolution of group 1 is QVGA and the frame rate is 15 frames. / sec, Group 2 has a resolution of VGA and a frame rate of 30 frames per second.
  • the example of dividing by track is as follows: For example, the adaptation requirement is a terminal that supports three screen resolutions of QVGA, HVGA, and VGA.
  • the SVC file structure is as follows, including a base track, and the corresponding resolution is QVGA; two enhancement track, corresponding The resolutions are HVGA and VGA respectively. Then press track to divide SVC into one basic file and two enhanced files.
  • splitting by tier are as follows:
  • the adaptation requirement is a terminal that supports three screen resolutions of QVGA, HVGA, and VGA.
  • the SVC file structure is as follows, including a track, the track contains three tiers, and the resolution corresponding to Tierl is divided into The resolution corresponding to QVGA and Tier2 is HVGA, and the resolution of Tier3 is VGA.
  • the resolution of Tier2 is the resolution of the video obtained by jointly decoding Tierl and Tier2; the resolution of Tier2 is the resolution of the video obtained by jointly decoding Tierl, Tier2, Tier3, then the SVC file can be divided into a basic file by Tier and Two enhanced files.
  • the basic layer and/or the enhancement layer media data corresponding to the adaptation requirements are extracted from the complete SVC file to form a plurality of files, one of which is called a basic file, and the other is called an enhanced file.
  • the basic file includes a base layer and media data of 0 to a plurality of enhancement layers
  • the enhancement file includes media data of one or more enhancement layers not included in the base file.
  • the split file After splitting the SVC into multiple files, the split file can be assigned a Fi leURI and the decoding dependency information of the file can be recorded.
  • the decoding dependency information may be, for example:
  • the so-called dependency means that the file and the file to be relied on need to be combined to decode the file.
  • metadata is also included.
  • the metadata describes the physical structure and temporal structure of all media data contained in a plurality of files obtained by dividing the complete SVC file, wherein the metadata for describing the temporal structure of the media data includes the decoding time of the media data.
  • the file format adopted by the complete SVC file is based on the SVC file format, and the SVC file format is defined based on the ISO (International Standards Organization) file format.
  • ISO International Standards Organization
  • Figure 7 depicts a complete SVC file.
  • "ftyp”, “mvhd”, “trak” means fi le type box
  • “mvhd” means movie header box
  • Trak represents track box
  • “ftyp” is used to store the protocol version used by the file, etc.
  • “mvhd” is used to store the global description of the movie, such as the production time and modification of the movie. Information such as time, duration, etc.
  • metadata in " trak " is used to store a single track, including a description of the physical structure and temporal structure of the media data in the track.
  • the complete SVC file includes a plurality of video tracks and at least one other track.
  • Other tracks may be audio tracks, subtitle tracks, etc.; multiple video tracks include one basic track and at least one enhanced track.
  • the basic track and each enhanced track respectively contain video media data corresponding to a certain adaptation requirement.
  • the video media data storage in each enhanced track is extracted from the complete SVC file to form each enhanced file.
  • the media data such as the video data of the basic track, the audio or subtitle of other tracks, and the metadata storage are extracted from the complete SVC file to form a basic file.
  • the file format used by the base file is still based on the ISO file format.
  • the enhanced file uses the file format without an absolute definition. In a specific application of the present invention, the developer can define the format of the enhanced file by itself, such as storing the extracted media data in binary order to store the dat file.
  • the metadata in the base file is used to describe multiple packages obtained after splitting the complete SVC file.
  • Metadata describing the physical structure of the media data in the base file needs to be modified to point to the new physical storage location.
  • the metadata describing the physical structure of the media data includes the Fi leURI of the file containing the media data and the storage location of the media data in the file.
  • Fi leURI modifies the storage location to the storage location in the base file or enhancement file containing the media data after the split. Point it to the new physical storage location.
  • the metadata before the segmentation is stored in the SVC file, wherein the metadata describing the physical storage location of the media data points to the physical storage location in the complete SVC file, after the segmentation
  • the metadata is contained in the base file, and the metadata describing the physical storage location of the media data is modified to point to the physical storage location in the enhanced file.
  • the metadata is stored in the basic file.
  • the metadata is dispersed in the basic file and each enhanced file, that is, the metadata is included in the basic file or the enhanced file, and the metadata in the file is only used.
  • the metadata describes the physical structure and temporal structure of the media data contained in this file, wherein the metadata used to describe the temporal structure of the media data includes the decoding time of the media data.
  • the media data stored in the enhanced track is composed of pointers and enhancement layer media data, and the base layer and the media data of the enhancement layer with lower decoding dependency can be referred to by the pointer.
  • the prior art defines pointers as follows:
  • the track-ref-index in the pointer can be used to find the identifier of the track corresponding to the base layer to be referenced and the enhancement layer media data with lower decoding dependency in the metadata of the current track. Metadata for these tracks can be found based on the identity of the track, which points to the physical storage location of the base layer and the enhanced layer media data with lower decoding dependencies. Thereby, the enhancement layer media data with lower base layer and lower decoding dependency can be cited.
  • the trackID is used as the identifier of the track in the prior art, and the trackID uniquely identifies the track in only one presentation (referring to the combination of the video track and other tracks described by the file metadata), the prior art can only implement the reference.
  • a media data in the show since the trackID is used as the identifier of the track in the prior art, and the trackID uniquely identifies the track in only one presentation (referring to the combination of the video track and other tracks described by the file metadata), the prior art can only implement the reference. A media data in the show.
  • the basic file and the enhanced file in the method 2 are differently displayed, so the prior art needs to be extended.
  • the track corresponding to the media data to be referenced can be jointly identified by the Fi leURI and the trackID, thereby implementing the reference.
  • the decoding time of the media data in the basic track and the decoding time of the media data of the enhanced track may be obtained from the metadata of the SVC file, and the media data in the basic track and the media of the enhanced track are synchronized according to the decoding time.
  • Data, in the method 2 the decoding time of the enhanced file, the media data of the basic file, and the media data of the basic file and the media data of the enhanced file may be synchronously obtained from the metadata of the enhanced file and the basic file, respectively.
  • step 320 file transfer is performed. As shown in Figure 8, this step is subdivided into:
  • Step 320-1 Each split file is carried by a transport object (TO) to generate an FDT instance, where the FDT instance carries description information of each file and decoding dependency information of each file.
  • TO transport object
  • Step 320-2 transmitting the FDT instance and each transmission object.
  • the first method The description information of each file in the FDT instance is extended, and the file identifier of a group (0 to more) files dependent on the file decoding is added in the description of the file to indicate the decoding dependency of the file with other files.
  • the FDT instance may further include a decoding dependency type identifier, which is used to indicate a reason for the decoding dependency.
  • a decoding dependency type identifier is used to indicate a reason for the decoding dependency.
  • the value of the decoding dependent type identifier is lay, indicating decoding dependency. It is caused by layered coding. If the decoding dependency is caused by other reasons, such as a key file and a media file, the media file depends on the key file for decoding, and can be set to other values.
  • the corresponding XML definition for the FDT instance can be:
  • the base file has a Fi leURI of http : //www. example. com/SVCf i le/trackK
  • the Fi leURI of the enhanced file is http : // www. example. Com/SVCf i le/ tracks.
  • the base file http //www. example. com/SVCfile /trackl does not depend on other file decoding;
  • the enhanced file http //www. example. com/SVCfi le / ⁇ &. 1 ⁇ 2 depends on the base file ⁇ 1 :// 3 ⁇ 4 ⁇ . example. com/SVCf i le/trackl decoding.
  • the description information of the basic file and the enhanced file in the FDT instance may be, for example:
  • the basic file does not depend on any other file decoding, so the description information of the basic file contains the file identifier of 0 decoding dependent files; the enhanced file http: ⁇ www. example. com/SVCf i le /track2 depends on the basic file http : // Li. example. com/SVCf i le/trackl decoding, the description of the enhanced file contains a file identifier of a decoding dependent file http: ⁇ www. example, com /SVCfi le/trackl o ( 2 ) 2 Method
  • all the files obtained by dividing the complete SVC file can be regarded as a logical combination, that is, a file group.
  • the description of the file group contains: group ID and multiple sets of description information.
  • Each set of description information consists of a file identifier of a file and a file identifier of a file on which the file is to be decoded, and is used to describe a decoding dependency between the file and other files.
  • the file group description information may further include a group type identifier, which is used to indicate whether there is a decoding dependency between the files in the group, for example, a group type.
  • the value of the identifier is DDP (decoding dependency), indicating that there is a decoding dependency between files in the group.
  • the FDT instance may further include a decoding dependency type identifier, which is used to indicate a reason for decoding dependencies between files.
  • the value of the decoding dependent type identifier is lay, indicating decoding.
  • Dependencies are caused by hierarchical coding. If the decoding dependency is caused by other reasons, such as a key file and a media file, and the media file depends on the key file for decoding, it can be set to other values.
  • the XML definitions described by the filegroup can be as follows.
  • the svc file is divided into a basic file and an enhanced file.
  • the Fi leURI of the basic file is http: ⁇ stomach. example. com/SVCfi le/trackl
  • the Fi leURI of the enhanced file is http: ⁇ Www. example. com/SVCf i le/track2.
  • Two files make up groupl.
  • the description of the basic files, enhancement files, and file groups in the FDT instance can be, for example:
  • the description of the file group contains a set of description information indicating that the enhanced file http : //www. example. eom/SVCfi le/t:rack2 depends on the basic file http: ⁇ www. example. com/SVCfi le/trackl decoding .
  • the description information of the basic file may not include the file group identifier. In this way, when the target file received by the receiving end user equipment that meets certain adaptation requirements is the basic file, the receiving end user equipment does not need to first obtain the description of the file group according to the file group identifier, and then find the target in the description of the file group.
  • the decoding dependency information corresponding to the file can directly determine that the target file does not have a decoding dependent file, thereby simplifying the processing and saving resources.
  • all the files obtained by dividing the complete SVC file are taken as one logical combination, that is, one file group.
  • the description of all files contains the same group ID (groupID) field.
  • the decoding dependency size identifier of the file is added to the description information of the file to indicate the decoding dependency size of the file.
  • files rely on files with smaller decoding dependencies in the same filegroup for decoding.
  • decoding dependency information basic file, corresponding to QVGA format resolution, independent of other files, independent decoding; enhanced file 1, corresponding to HVGA format resolution, depending on the basic file can be decoded; enhanced file 2, corresponding VGA format resolution, depending on the base file and enhanced file 1 can be decoded.
  • the decoding dependency size identifier (dependency1D) of the basic file may be 0, and the decoding dependency size identifier of the enhanced file 1 may be 1, and the decoding dependency size identifier of the enhanced file 2 may have a value of 2.
  • the corresponding XML definition can be:
  • the SVC file is divided into multiple files according to the adaptation requirement.
  • the user equipment may only receive the divided file corresponding to the adaptation requirement and the decoding device thereof.
  • Dependent files without receiving the entire SVC file or file group, thereby avoiding the waste of user device side cache space, reducing the time for file reception, and saving power.
  • the embodiment further provides a file receiving method, which can be completed by a terminal as a receiving end.
  • the method includes the following process:
  • Step 401 Obtain a file identifier FileURI of the target file.
  • the file identifier FileURI of the target file is usually transmitted from the upper application device to the receiving end.
  • the user selects an object file through an ESG (Electronic Service Guide) application device, and the file URI of the target file is transmitted by the ESG application device.
  • ESG Electronic Service Guide
  • Step 402 Obtain a description of the file transfer session where the target file is located.
  • the description of the file transfer session includes: a source IP address, a Transport Session Identifier (TSI, the TSI and the source IP address together uniquely identify a FLUTE session), a destination IP address, a port, and the like.
  • TSI Transport Session Identifier
  • a description of the file transfer session is usually available from the SDP (Session Description Protocol) file.
  • the terminal first obtains the ESG, and the ESG contains the acquisition address of the SDP file, or directly inserts the SDP file. After the terminal selects the target file, the SDP file can be obtained and stored. That is, the SDP file is pre-stored on the terminal before the step 402, so that the terminal can obtain the description of the file transfer session from the SDP file.
  • Step 403 Join the file transfer session.
  • the file transfer session can be added according to the description of the file transfer session obtained in step 402, which belongs to the prior art and will not be described in detail.
  • Step 404 Obtain an FDT instance.
  • Cause This step can include:
  • Step 404-2 determining whether sufficient data packets for recovering the complete FDT instance are received.
  • Step 404-3 parsing the received data packet, and restoring the FDT instance.
  • Step 405 Receive a decoding dependent file of the target file and the target file. As shown in FIG. 10, the step specifically includes:
  • Step 405-1 Find the description information of the target file in the FDT instance.
  • Step 405-2 Determine whether the target file is dependent on other files for decoding.
  • the method of determining whether the target file depends on other file decoding is different, for example:
  • step 320-2 If the first method in step 320-2 is used to carry the decoding dependency between files, if the description information of the target file contains the FileURI of the file to which the decoding target file depends, the target file depends on other files for decoding.
  • step 320-2 If the second method in step 320-2 is used to carry the decoding dependency between the files, the description of the file group is obtained from the FDT instance, and if the description of the file group contains a set of files to be decoded by the decoding target file.
  • FileURI the target file depends on other files for decoding.
  • step 320-2 If the decoding dependency between files is carried in the third method in step 320-2, if the decoding dependency size identifier in the description information of the target file is greater than 0, the target file is decoded depending on other files.
  • Step 405-3 Receive the target file according to the description information of the target file, and the receiving of the target file may be the same as the receiving step of the prior art. For example, it may specifically include;
  • T0I field in the receiving header is the same as the recorded T0I, and these packets are cached together.
  • the description information of the target file includes FEC 0TI information, and according to the FEC 0TI information, the number of source blocks into which the target file is divided and each source block can be calculated.
  • the target file depends on other files for decoding, you need to receive the decoding dependencies of the target file and the target file. That is, the decoding dependent file of the target file and the target file is the file to be received. Go to step 405-4.
  • Step 405-4 Determine the file to which the decoding target file depends, that is, the decoding dependent file of the target file.
  • the file to be received is a decoding dependent file of the target file and the target file, and the file to be received is recorded.
  • the method of determining the decoding dependent file of the target file is also different.
  • the FileURI of the decoding dependent file of the target file can be obtained from the description of the target file or the file group, and the target file is obtained by searching for the target file according to the Fi leURI in the FDT instance. Decoding the description information of the dependent file, from which the T0I of the decoding dependent file of the target file is obtained.
  • step 320-2 If the third method in step 320-2 is adopted, the FDT instance needs to be scanned, and the file containing the same groupID but the decoding dependency size identifier smaller than the decoding dependency identifier of the target file is the decoding dependent file of the target file. .
  • Step 405-5 Receive and buffer a data packet for carrying a file to be received, that is, receive the TOI in the packet header.
  • the value of the field is the same as the recorded TOI packet.
  • Step 405-6 For each file to be received, judge whether the data packet sufficient to recover the file is received according to the FEC 0TI information in the description information of the file; if not, go to step 405-5; if yes, go to step 405-7.
  • Step 405-7 Parse the received data packet and restore the file.
  • Step 405-8 It is judged whether all the files to be received are received; if yes, the process ends; if not, go to step 405-5.
  • the receiving end transmits the file to the upper application device, such as the player, and the application device decodes and displays the file.
  • the terminal receives the decoding dependent file of the target file and the target file, instead of the complete SVC file, avoiding waste of the user terminal cache and reducing power consumption.
  • Example 3
  • the embodiment further provides a method for transmitting an SVC file.
  • the difference between this embodiment and the embodiment 2 is that the embodiment further carries the decoding dependency between the files through an independent file instead of the FDT instance, so that the method can further Improve the flexibility of the program.
  • This file is called a decoding dependency declaration file, and the format of the file can be XML, SVG, and so on.
  • the decoding dependency declaration file may be transmitted in multiple ways, for example:
  • the decoding dependency declaration file is transferred in the same FLUTE session as the split file.
  • a dependency description (DependencyDescription) element is added to the description of the file split in the FDT instance, and the value is the FileURI of the decoding dependency declaration file.
  • the receiving end when the receiving end receives the target file, it first obtains the FileURI of the decoding dependency declaration file according to the DependencyDescription element in the description information of the target file, and then The FDT instance obtains the description information of the decoding dependency declaration file, receives the decoding dependency declaration file from the FLUTE session according to the description information of the decoding dependency declaration file, determines which files the target file depends on according to the decoding dependency declaration file, and receives the target. Decode dependent files for files and object files.
  • the receiving end When the receiving end receives the target file, it also obtains the Fi leURI of the decoding dependency declaration file according to the content fragment used in the ESG to describe the target file or the DependencyDescription element in the Access fragment, and then obtains the decoding dependency declaration from the FDT instance.
  • the description information of the file receives the decoding dependency declaration file from the FLUTE session, parses the decoding dependency declaration file, determines which files the target file depends on for decoding, and receives the decoding dependent file of the target file and the target file.
  • Embodiment 1 of the present invention it is also possible to carry decoding dependencies between files in the ESG instead of in the FDT instance.
  • it can be used in the ESG to describe the content fragment of the target file or the file identifier of the Access fragment to add a set of files to which the target file depends. Therefore, the target file decoding dependency relationship can be obtained from the ESG content fragment or the Access fragment, and the decoding dependent file of the target file is determined.
  • This embodiment further provides a method for transmitting an SVC file.
  • the difference between this embodiment and the previous embodiment is that the present embodiment carries the decoding dependency between files by using T0I.
  • a transport object is identified by T0I, and a transport object is used to carry a file.
  • the TOI is divided into two parts. The first part is still used to identify the transport object, and the second part consists of the file group identifier and the decoding dependency size identifier, which is used to describe the decoding dependencies between the files.
  • a specific implementation is as follows:
  • Basic file corresponding to QVGA format resolution, independent of other files, independent decoding
  • Enhanced file 1 corresponding to HVGA format resolution, depends on the basic file to decode
  • Enhanced file 2 corresponding to VGA format resolution, depends on the basic file and Enhanced file 1 can be decoded.
  • Enhanced files 1 form a file group with a file group ID of 1.
  • the decoding dependency size of the base file is identified as 0, the decoding dependency size of the enhanced file 1 is identified as 1, and the decoding dependency size of the enhanced file 2 is identified as 2.
  • the embodiment provides a SVC file transmission device.
  • the device includes: a segmentation unit 510, configured to divide the scalable video coding SVC file into a basic file and at least one enhanced file;
  • the basic file includes at least basic layer media data, and the enhanced file includes some or all of the enhancement layer media data.
  • the splitting unit may divide the scalable video coding SVC file into a basic file and at least one enhanced file according to an adaptation requirement.
  • the transmitting unit 520 is configured to separately transmit each of the files obtained by the splitting by using different transport objects, and transmit description information of the one basic file and the at least one enhanced file and decoding dependency information of each file, so that the terminal is configured according to the The received decoding dependency information determines one or more files to receive and receives the one or more files based on the description information of the one or more files.
  • the transmitting unit 520 is further configured to transmit description information of the one basic file and the at least one enhanced file and decoding dependency information of each file by using a file transfer table FDT instance.
  • the transmission unit 520 further transmits the description information of the one basic file and the at least one enhanced file by using a file transfer table instance, and transmits the decoding dependency information of each file by using a set bit of the transfer object identifier. .
  • the transmission unit 520 includes:
  • a first transmission unit 521 configured to transmit decoding dependency information of each file by decoding a dependency declaration file
  • the second transmission unit 522 is configured to transmit description information of each file and an address of the decoding dependency declaration file by using a file transfer table instance.
  • the transmission unit 520 further includes:
  • the third transmission unit 523 is configured to transmit description information of each file by using a file transfer table instance.
  • the fourth transmission unit 524 is configured to transmit, by using an electronic service guide, an address of the decoding dependency declaration file. In another embodiment of the present invention, the fourth transmission unit 524 transmits the address of the decoding dependency declaration file through the content fragmentation or the access fragment of the electronic service guide.
  • the fifth transmission unit 525 is configured to transmit decoding dependency information of each file by using the decoding dependency declaration file.
  • the transmission unit 520 includes:
  • a third transmission unit configured to transmit description information of each file by using a file transfer table instance
  • a sixth transmission unit configured to transmit, by using an electronic service guide, a file identifier of a decoding dependent file of each file.
  • the sixth transmission unit transmits the file identifier of the decoding dependent file of each file by content fragmentation or access fragmentation of the electronic service guide.
  • the embodiment of the present invention further provides a file receiving apparatus 600, as shown in FIG. 15, comprising: an obtaining unit 610, configured to acquire decoding dependency information of an object file, where the target file is a basic file or an enhanced file,
  • the basic file includes at least basic layer media data
  • the enhanced file includes Part or all of the enhancement layer media data
  • a determining unit 620 configured to determine, according to the decoding dependency information, a file to be received, where the to-be-received file is a basic file, or a basic file, and at least one enhanced file;
  • the first receiving unit 630 is configured to receive description information of the file to be received.
  • the second receiving unit 640 is configured to receive the file to be received according to the description information of the file to be received.
  • the determining unit 620 determines that the target file and the decoding dependent file are files to be received when determining that the target file has a decoding dependent file according to the decoding dependency information.
  • the decoding dependency information determines that the target file does not have a decoding dependent file, it is determined that the target file is a file to be received.
  • the file receiving apparatus 600 further includes:
  • a third receiving unit 650 configured to receive decoding dependency declaration file address information
  • the obtaining unit 610 is further configured to receive, according to the decoding dependency declaration file address information, the decoding dependency declaration file, and obtain decoding dependency information of the target file.
  • the terminal receives one or more files in multiple files (one basic file and at least one enhanced file) obtained by dividing the complete SVC file, thereby avoiding waste of buffering of the user terminal, and Reduced reception time and saved power consumption.
  • the embodiment of the present invention further provides a video encoding file, where the video encoding file is a basic file or an enhanced file after the scalable video encoding SVC file is divided into a basic file and at least one enhanced file; wherein the basic file includes at least Base layer media data, the enhancement file includes some or all of the enhancement layer media data, and the enhancement file is at least dependent on the base file for decoding.
  • the basic file further includes metadata
  • the metadata includes a description of respective media data of the basic file and the enhanced file.
  • the basic file further includes metadata, where the metadata includes a description of the media data corresponding to the basic file
  • the enhanced file further includes metadata, where the metadata includes the enhanced file.
  • the enhancement file also includes a pointer to the dependent A pointer to the file.
  • the receiving end user equipment can decode the obtained video by receiving only as few files as possible in the video encoding file, thereby avoiding waste of the user terminal buffer, reducing the receiving time, and saving power consumption.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Description

种可伸缩视频编码文件的传输方法、 接收方法及装置
技术领域
本发明涉及文件传输技术， 具体地， 涉及一种可伸缩视频编码文件的传输 方法、 接收方法及装置。 背景技术
随着近年来技术的发展， TV系统都面临同样的问题： 需要在一个异构的环 境中提供业务， 这里的异构包括终端能力的差异、 网络带宽的差异等。
以 MTV为例， 目前使用 MTV业务的主要是手机业机， 手机主流的屏幕分辨率 为 QVGA (Quarter Video Graphics Array, 四分之一 VGA) ， 即 320 X 240， 但是 手机正在向高清视频方向发展；此外，带无线上网功能的笔记本、 PDA (Personal Digital Assistant , 个人数字助手） 等屏幕分辨率大于 QVGA的终端也都是 MTV 服务的对象。 因此 MTV运营商需要考虑如何基于广播 /组播同时向屏幕分辨率等 于 QVGA的终端和大于 QVGA的终端提供影音文件下载业务。
SVC (Scalable Video Coding, 可伸缩视频编码） 是能够解决出现于异构 环境中的网络的带宽差异、 接收终端的性能差异、 分辨率差异等各种问题的编 码技术。 在使用 SVC技术时， 可以通过作一次编码得到一个基本层和一个或多 个增强层。 增强层用于提高视频观看效果， 它不能独立解码， 需要与基本层以 及之前的增强层合在一起才能解码， 得到特定比特率、 帧速率和分辨率的视频。 将基本层和一个或多个增强层按一定的格式进行存储， 获得 SVC文件。 随着增 强层数量的增加， SVC文件可支持各种比特率、 帧速率和分辨率。
在实现本发明过程中， 发明人发现现有技术至少存在如下问题： 由于现有 的基于 FLUTE协议的 SVC文件传输或接收技术需要手机全部接收包括基本层和 全部增强层的完整的 SVC文件甚至 SVC文件组， 因此会造成手机等终端缓存空 间的浪费， 并且接收包括基本层和全部增强层的文件导致手机下载文件的时间 变长， 电力消耗大。 发明内容
本发明的实施例提供一种可伸缩视频编码文件的传输方法、 接收方法及装 置， 通过接收分割 SVC文件得到的多个文件中的一个或多个文件， 避免了对用户 终端缓存的浪费， 并且减少了文件接收的时间， 节省了电力。
本发明实施例提供一种可伸缩视频编码文件的传输方法， 包括：
将所述可伸缩视频编码 SVC文件分割为一个基本文件和至少一个增强文件； 其中， 所述基本文件至少包括基本层媒体数据， 所述增强文件包括部分或全部 增强层媒体数据；
将分割得到的每一个文件各自通过一个传输对象进行传输；
传输所述一个基本文件和至少一个增强文件的描述信息及各文件的解码依 赖性信息， 以使得终端根据所接收到的解码依赖性信息确定要接收的一个或多 个文件以及根据所述一个或多个文件的描述信息接收所述一个或多个文件。 本发明实施例另提供一种文件接收方法， 包括：
获取目标文件的解码依赖性信息， 所述目标文件为基本文件或增强文件， 所述基本文件至少包括基本层媒体数据， 所述增强文件包括部分或全部增强层 媒体数据；
根据所述解码依赖性信息确定待接收的文件， 所述待接收的文件为一个基 本文件， 或一个基本文件以及至少一个增强文件；
接收所述待接收的文件的描述信息；
根据所述待接收的文件的描述信息接收所述待接收的文件。
本发明实施例还提供一种 SVC文件传输装置， 包括：
分割单元， 用于将所述可伸缩视频编码 SVC文件分割为一个基本文件和至少 一个增强文件； 其中， 所述基本文件至少包括基本层媒体数据， 所述增强文件 包括部分或全部增强层媒体数据；
传输单元， 用于将分割得到的每一个文件各自通过不同的传输对象进行传 输， 并传输所述一个基本文件和至少一个增强文件的描述信息及各文件的解码 依赖性信息， 以使得终端根据所接收到的解码依赖性信息确定要接收的一个或 多个文件以及根据所述一个或多个文件的描述信息接收所述一个或多个文件。 本发明实施例另提供一种文件接收装置， 包括：
获取单元， 用于获取目标文件的解码依赖性信息， 所述目标文件为基本文 件或增强文件， 所述基本文件至少包括基本层媒体数据， 所述增强文件包括部 分或全部增强层媒体数据；
确定单元， 用于根据所述解码依赖性信息确定待接收的文件， 所述待接收 的文件为一个基本文件， 或一个基本文件以及至少一个增强文件；
第一接收单元， 用于接收所述待接收的文件的描述信息；
第二接收单元， 用于根据所述待接收的文件的描述信息接收所述待接收的 文件。 本发明实施例通过对 SVC文件进行分割， 可以只接收分割得到的多个文件中 的一个和多个文件， 避免了对用户终端缓存的浪费， 并且减少了文件接收的时 间， 节省了电力。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施 例描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅 仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳 动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为 SVC文件的格式示意图；
图 2为 FLUTE会话的结构示意图；
图 3为本发明实施例 1中 SVC文件传输方法的示意图；
图 4为图 3中步骤 120的流程示意图； 图 5为本发明实施例 1中文件接收方法的示意图；
图 6为本发明实施例 2中 SVC文件传输方法的示意图；
图 7为本发明实施例中基本文件中的元数据从增强文件中引用媒体数据的 示意图；
图 8为图 7中步骤 320的流程示意图；
图 9为本发明实施例 2中文件接收方法流程图；
图 10为图 9中步骤 405的流程示意图；
图 11为本发明实施例中文件传输装置的结构框图；
图 12为图 11中传输单元的示意图之一；
图 13为图 11中传输单元的示意图之二；
图 14为图 11中传输单元的示意图之三；
图 15为本发明实施例中文件接收装置的结构框图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清 楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是 全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有作出创造 性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
为了便于理解本发明实施例， 首先对现有的 SVC文件格式和 FLUTE协议进 行说明。
以需要 QVGA和 VGA的异构场景为例， 可以采用 SVC技术通过一次编码得到 一个基本层和一个增强层， 基本层解码后是 QVGA格式的视频， 基本层和增强层 合在一起解码后得到 VGA格式的视频。 存储时可以将基本层作为 SVC文件的基 本轨道 （base track ) trackl , 基本层和增强层合起来作为 SVC文件的增强轨 道 (enhancement track) track2。 track2 中并不存储完整的基本层 +增强层样 本 （这里样本即视频帧） ， 而是存储增强层样本和到基本层样本的指针。 在使 用 SVC文件时， 文件阅读器可根据指针合成完整的样本， 因此所需存储空间和 单个 VGA格式文件接近。
在图 1所示的 SVC文件格式中， moov代表 movie box (影片包） ， 用于存 储元数据， 即对媒体数据的描述； mdat代表 media data box (媒体数据包） ， 用于存储媒体数据； BL代表基本层（Base Layer )； EL代表增强层（Enhancement Layer ) ； E代表指针 ( extractor ) ； SO代表编号为 0的样本 ( sample ) ； track (轨道） 是一组相关的样本； chunk (块） 是一个 track 中物理上连续地存储在 一起的多个样本。
FLUTE协议是基于 IP协议的点到多点的文件传输协议， 在 FLUTE协议中， 一个文件用一个 TO (Transport Object , 传输对象） 承载， 传输对象用传输端 分配的 TOI (Transport Object Identifier, 传输对象标识） 标识。 一个 FLUTE 会话中有很多数据包在传输， 数据包的包头都有一个 T0I字段， 所有 T0I相同 的数据包组成一个传输对象。
多个传输对象在一个 FLUTE会话中传输， 可用 FDT (Fi le Del ivery Table, 文件传输表） 实例说明会话中当前或将要传输的文件。 对于每个文件， 在 FDT 实例中提供该文件的一组描述信息 （后面简称为文件的描述信息） ， 该描述信 息包括如下参数：
Content— location： 表示文件的标识， 采用 URI ( Uniform Resource Identifier, 统一资源标识符） 格式， 后面称为 Fi leURI , 为必选参数；
T0I : 表示传输对象标识， 为必选参数；
Content-length: 表示文件的大小， 为可选参数；
Transfer-length, 表示传输对象的大小， 为可选参数；
Content-Type:表不文件的 MIME(Multipurpose Internet Mai l Extensions , 多功能因特网邮件扩充协议） 类型， 为可选参数；
Content-Encoding: 表示文件的内容编码方式， 为可选参数；
Content-MD5: 表示文件的 MD5摘要， 为可选参数；
FEC-0TI-FEC- Encoding- ID 、 FEC-0TI-FEC- Instance- ID 、 FEC - OTI - Maximum - Source - Block - Length、 FEC - 0TI - Encoding - Symbol - Length、 FEC - OTI - Max - Number - of - Encoding - Symbol s、 FEC - OTI - Scheme - Specific - Info: 表示 FEC OTI (FEC Object Transmission Information, 前向纠错编码对象传 输信息） 信息， 为可选参数；
GroupID: 表示文件所在的文件组标识， 为可选参数。
FLUTE协议规定，默认传输对象标识 T0I = 0的传输对象用于传输 FDT实例， 如图 2所示。
FLUTE协议规定， FDT实例是一个 XML文档， 并且可以任意扩展。 如果 XML 解析器不能识别扩展的元素 /属性， 将直接跳过这些元素和属性。
现有的基于 FLUTE协议的文件传输 /接收技术中终端需要接收整个文件甚至 整个文件组： 接收端在判断出已经接收到了足够恢复完整文件的数据包后， 才 认为接收到了一个文件； 如果接收端要接收文件组中的一个文件， 就必须接收 文件组中所有的文件， 除非接收端预先被配置为忽略文件组， 此时接收端只接 收该文件。
基于此， 本发明实施例提供一种 SVC文件传输方法及接收方法， 可以实现 基于广播或组播向异构终端提供 SVC文件下载业务时， 减少终端存储消耗和电 力消耗。
下面对结合附图对本发明进行更详细地说明。 实施例 1
本实施例提供一种 SVC文件的传输方法， 如图 3所示， 该方法包括： 步骤 110， 发送端将可伸缩视频编码 SVC文件分割为一个基本文件和至少一 个增强文件。
例如， SVC文件包括一个基本层与一到多个增强层的媒体数据。 它们的解码 依赖性不同。 基本层最低， 可以独立解码。 增强层不能独立解码， 需要与基本 层合在一起解码， 或者与基本层和解码依赖性更低的增强层合在一起解码， 即 增强层依赖于基本层或者依赖于基本层和解码依赖性更低的增强层解码。 在传 输 SVC文件之前， 可根据适配需求将 SVC文件分为多个 （即两个以上） 文件， 其 中一个称为基本文件， 其他的称为增强文件。 将一个基本层与一到多个增强层 按解码依赖性由低到高排列， 基本文件包括基本层以及前 0到多个增强层的媒体 数据， 该基本文件可以不依赖于其余任何文件中的数据独立解码， 即基本文件 的解码依赖性最低。 未包含在基本文件中的增强层又可按解码依赖性由低到高 的顺序分为至少一组， 每组包括一到多个增强层， 每个增强文件包括其中一组 的媒体数据， 即一到多个增强层的媒体数据， 也即包括全部或部分增强层的媒 体数据。
本发明实施例中， 所述适配需求包括但不限于支持某种屏幕分辨率、 支持 某种传输码率、 支持某种帧速率等。 运营商可在网络侧设置适配需求收集功能 实体来收集适配需求， 也可手工配置适配需求。 由于运营商是在一个异构的环 境中提供业务， 因此通常有多个适配需求。 分割 SVC文件得到的每个文件对应一 种适配需求， 即将 SVC文件分为的文件的个数等于适配需求的个数。 根据该文件 对应的适配需求，分割 SVC文件得到的每个文件可以包含一到多层媒体数据。 例 如， 适配需求是支持 QVGA、 HVGA、 VGA三种屏幕分辨率的终端， 即有三个适配需 求； SVC文件包含基本层、 增强层 1、 增强层 2、 增强层 3、 增强层 4、 增强层 5。 增强层 1到增强层 5的解码依赖性由低到高依次增加， 增强层 1的分辨率为 QVGA、 增强层 3的分辨率为 HVGA、 增强层 5的分辨率为 VGA, 其中增强层的分辨率指将增 强层与基本层及解码依赖性更低的增强层合起来解码后， 得到的视频的分辨率。 则根据适配需求将 SVC文件分为三个文件： 基本文件、 增强文件 1、 增强文件 2。 基本文件包括基本层和增强层 1的媒体数据， 未包含在基本文件中的增强层 2〜5 根据适配需求可以分为两组， 组 1包括增强层 2和增强层 3， 组 2包括增强层 4和增 强层 5。 增强文件 1包括组 1， 即增强层 2和增强层 3的媒体数据， 增强文件 3包括 组 2， 即增强层 4和增强层 5的媒体数据。
由于增强层的媒体数据需要至少结合基本层的媒体数据才能进行解码， 因 此本步骤中分割得到的增强文件也会至少依赖于基本文件进行解码。 具体地， 增强文件有可能仅和基本文件联合在一起就能够完成解码， 也有可能需要和基 本文件以及其他增强文件联合在一起才能完成解码。 增强文件包括的增强层的 解码依赖性越低， 该增强文件解码要依赖的其他增强文件就越少， 该增强文件 的解码依赖性就越低。
即根据分割后得到的文件中包括的基本层和 /或增强层的解码依赖性可以 确定该文件解码依赖性的高低， 解码依赖性低的增强文件所依赖的文件数相对 较少。
在根据适配需求分割 SVC文件时， 发送端通过读取和解析 SVC文件包含的元 数据可获取 SVC文件结构。 根据 SVC文件结构的不同， 分割方式可以不同。 既可 以按轨道 （track) 进行文件分割， 也可以按 track的子集 （tier ) ， 即子轨道， 进行文件分割。 其中， tier是指按照定义的分组规则将一个 track中的样本 （媒 体数据） 分成的多个组， 每组包含一或多个可伸缩层。 分组规则可以有多种定 义方式， 包括但不限于基于分辨率、 帧率以及分辨率和帧率的组合进行定义。
分割完成后， 可给分割得到的文件分配文件标识， 如 Fi leURI。
步骤 120， 将分割得到的每一个文件各自通过一个传输对象 （TO) 承载并进 行传输。
在本发明另一实施例中， 如图 4所示， 步骤 120细分为：
步骤 120-1， 对每一个文件进行分块。 例如， 根据 FEC ( Forward Error Correction , 前向纠错） 算法的要求把文件物理分割为若干个源块 （source block) ， 每个源块用 SBN (Source Block Number , 源块编号） 标识， 表示在 TO 中的相对位置。
步骤 120-2，对分块后的文件进行 FEC编码。可以采用多种 FEC方案（scheme ) 进行编码， 包括 Compact No-Code FEC scheme (压缩无编码前向纠错编码方案） 、 Compact FEC Scheme (压缩前向纠错编码方案) 、 Smal l Block Systematic FEC Scheme (小块系统前向纠错编码方案） 等。 步骤 120-3， 将 FEC编码后的数据封装到数据包中。
步骤 120-4， 发送封装好的数据包。
步骤 130， 传输所述一个基本文件和至少一个增强文件的描述信息及各文件 的解码依赖性信息， 以使得终端根据所接收到的解码依赖性信息确定要接收的 一个或多个文件以及根据所述一个或多个文件的描述信息接收所述一个或多个 文件。
根据待传输的多个文件可产生 FDT实例， 该 FDT实例中包含各文件的描述信 息， 例如各文件的文件标识、 传输对象标识等等。 本发明实施例中， 所述各文 件的解码依赖性信息可以设置在 FDT实例中传输， 也可以通过单独的文件进行传 输。 本发明实施例中， 文件的解码依赖性信息用于指示该文件解码所依赖的文 件信息， 体现了与其他文件的解码依赖关系。
本发明实施例中， 可以根据适配需求分割 SVC文件为多个文件， 在需要满足 某种适配需求的数据时， 用户设备可仅接收该适配需求对应的分割后的文件及 其解码所依赖的文件， 而无需接收整个 SVC文件或文件组， 从而避免了用户设备 端缓存空间的浪费， 并且减少了文件接收的时间， 节省了电力。
相应地， 本发明实施例还提供一种文件接收方法， 该方法可由作为接收端 的终端来完成， 如图 5所示， 该方法包括：
步骤 210， 获取目标文件的解码依赖性信息。
其中， 所述目标文件可以为可伸缩视频编码 SVC文件分割为一个基本文件和 至少一个增强文件后的基本文件或增强文件， 所述基本文件至少包括基本层媒 体数据， 所述增强文件包括部分或全部增强层媒体数据。
在本发明具体应用中， 终端首先接收 ESG (Electronic Service Guide, 电 子业务指南） ， 用户或者终端通过 ESG选择目标文件， 由 ESG应用将目标文件的 文件标识 FileURI传给文件接收装置， 文件接收装置可根据本发明实施例提供的 文件接收方法接收文件。 该目标文件为分割 SVC文件得到的基本文件或其中一个 增强文件。 ESG提供文件的描述信息， 说明文件针对的终端能力， 具体提供方式可以是 文本描述， 供用户理解选择； 也可以是 XML ( Extensible Markup Language , 可 标记扩展语言） 描述， 供终端理解选择。 用户或终端通常选择与终端能力匹配 的文件， 即为目标文件。 其中终端能力包括但不限于终端的屏幕分辨率、 终端 支持的编解码算法、 终端支持的网络接入带宽、 终端的缓存容量等等。 例如， SVC文件被分割为一个基本文件和两个增强文件， 基本文件的分辨率为 QVGA, 两 个增强文件的分辨率分别为 HVGA、 VGA, 其中增强文件的分辨率指将增强文件和 增强文件解码依赖的基本文件和其他增强文件合在一起解码后得到的视频的分 辨率。 ESG提供三个文件的描述信息， 说明三个文件的分辨率或者三个文件针对 的终端的屏幕分辨率分别为 QVGA、 HVGA、 VGA。 屏幕分辨率为 QVGA的用户或终端 可选择基本文件作为目标文件， 屏幕分辨率为 HVGA或 VGA的用户或终端可选择两 个增强文件中的一个作为目标文件。 ESG提供的三个文件的描述信息， 还可说明 三个文件的大小分别为 100MB、 200MB、 400MB , 缓存容量为 500MB的用户或终端 可选择基本文件作为目标文件， 缓存容量为 4GB的用户或终端可选择两个增强文 件中的一个作为目标文件。
步骤 220， 根据所述解码依赖性信息确定待接收的文件， 所述待接收的文件 为一个基本文件， 或一个基本文件以及至少一个增强文件。
例如， 如果根据所述解码依赖性信息确定所述目标文件存在解码依赖文件， 确定所述目标文件和目标文件的解码依赖文件为待接收的文件；
如果根据所述解码依赖性信息确定所述目标文件不存在解码依赖文件， 确 定所述目标文件为待接收的文件。
本实施例中， 所述解码依赖文件指目标文件解码依赖的文件， 将目标文件 和目标文件的解码依赖文件结合在一起才能完成目标文件的解码。
步骤 230， 接收所述待接收的文件的描述信息。
所述待接收的文件的描述信息可以分别从待接收的文件的 FDT实例中获得， 该描述信息至少包括传输对象标识。 步骤 240， 根据所述待接收的文件的描述信息接收所述待接收的文件。
根据所述待接收的文件的描述信息中的传输对象标识便可以接收到用于承 载所述待接收的文件的数据包。
文件接收完毕后， 接收端将接收的文件传输给上层应用设备， 如播放器， 由应用设备完成文件的解码和展示。
本发明实施例中， 根据用户或终端选择的目标文件的不同， 终端接收的是 对完整的 SVC文件分割后得到的多个文件 （一个基本文件和至少一个增强文件） 中的一个或多个。 如果目标文件为基本文件， 终端只需要接收目标文件； 如果 目标文件为增强文件， 终端只需要接收目标文件、 目标文件的解码依赖文件（即 目标文件解码依赖的基本文件和 0到多个其他增强文件） ， 不需要接收目标文件 解码不依赖的其他增强文件， 从而避免了对用户终端缓存的浪费， 并减少了文 件接收的时间， 节省了电力。 实施例 2
本实施例另提供一种文件传输方法， 如图 6所示， 该方法包括：
步骤 310， 发送端根据适配需求将所述可伸缩视频编码 SVC文件分割为一个 基本文件和至少一个增强文件。
本发明实施例中， 所述适配需求包括但不限于支持多种屏幕分辨率、 支持 多种传输码率、 支持多种帧速率等。 运营商可在网络侧设置适配需求收集功能 实体来收集适配需求， 也可手工配置适配需求。
发送端通过读取和解析 SVC文件包含的元数据可获取 SVC文件结构。 根据 SVC 文件结构的不同， 分割方式可以不同。 该分割方式可能是按 track进行分割， 也 可能是按 Tier (层的操作点， track的子集） 进行分割。 其中， tier是指按照某 种分组规则将一个 track中的样本 （媒体数据） 分成的多个组， 每组包含一或多 个可伸缩层。 分组规则可以有多种定义方式， 包括但不限于基于分辨率、 帧率 以及分辨率和帧率的组合进行定义。 以分为两组为例， 分组规则可以是： 组 1的 分辨率为 QVGA、 组 2的分辨率为 VGA; 组 1的帧率为 15帧 /秒、 组 2的帧率为 30帧 / 秒； 或者， 组 1的分辨率为 QVGA且帧率为 15帧 /秒、 组 2的分辨率为 VGA且帧率为 30帧 /秒。
按 track进行分割的例子如下： 比如适配需求是支持 QVGA、 HVGA、 VGA三种 屏幕分辨率的终端， SVC文件结构如下， 包含一个 base track, 对应的分辨率为 QVGA; 两个 enhancement track, 对应的分辨率分别为 HVGA、 VGA。 则按 track将 SVC分为一个基本文件和两个增强文件。
按 tier进行分割的例子如下： 比如适配需求是支持 QVGA、 HVGA、 VGA三种屏 幕分辨率的终端， SVC文件结构如下， 包含一个 track，该 track中包含三个 tier, Tierl对应的分辨率分为 QVGA、 Tier2对应的分辨率是 HVGA、 Tier3的分辨率是 VGA。 其中 Tier2的分辨率是联合解码 Tierl和 Tier2得到的视频的分辨率； Tier2 的分辨率是联合解码 Tierl、 Tier2、 Tier3得到的视频的分辨率， 则可按 Tier将 SVC文件分为一个基本文件和两个增强文件。
在确定了文件的分割方式后， 从完整的 SVC文件中抽取适配需求相应的基本 层和 /或增强层媒体数据形成多个文件， 其中一个称为基本文件， 其他的称为增 强文件。 基本文件包括基本层以及 0到多个增强层的媒体数据， 增强文件包括未 包含在基本文件中的 1到多个增强层的媒体数据。
将 SVC分割为多个文件后， 可给分割得到的文件分配 Fi leURI并记录文件的 解码依赖性信息。 所述解码依赖性信息例如可为：
( 1 ) 基本文件， 不依赖于其它文件， 独立解码；
(2 ) 增强文件 1， 依赖于基本文件才能解码；
(3 ) 增强文件 2， 依赖于基本文件和增强文件 1才能解码。
其中， 所谓的依赖是指， 需要将文件和被依赖的文件联合在一起才能解码 该文件。
在本发明实施例中， 抽取适配需求相应的媒体数据形成多个文件有多种实 现方式， 现举例说明如下： (一） 方法 1
根据适配需求从完整的 SVC文件中抽取相应的媒体数据形成一个基本文件 和至少一个增强文件， 其中增强文件只包括未包含在基本文件内的 1到多个增强 层的媒体数据； 基本文件除包括基本层以及 0到多个增强层的媒体数据外， 还包 括元数据。 该元数据描述了对完整的 SVC文件分割后得到的多个文件包含的所有 媒体数据的物理结构和时间结构， 其中用于描述媒体数据时间结构的元数据中 包括媒体数据的解码时间。
本发明实施例中， 完整的 SVC文件采用的文件格式基于 SVC文件格式， SVC文 件格式基于 ISO ( International Standards Organization, 国际标准组织） 文 件格式定义。 现举例说明方法 1的具体实现。
图 7描述的是一个完整的 SVC文件， 图中 " ftyp " 、 "mvhd " 、 " trak "表 示文件类型包 ( fi le type box) 、 "mvhd "表示影片头包 (movie header box) 、 "Trak "表示轨道包 （track box) ， 均用于存储元数据， 其中 "ftyp"用于存 储文件使用的协议版本等； "mvhd "用于存储影片的全局性描述信息， 如影片 的制作时间、 修改时间、 时长等信息； " trak " 中的元数据用于存储单个轨道， 包括轨道中媒体数据的物理结构和时间结构的描述。
如图 7所示， 该完整的 SVC文件包括多个视频轨道和至少一个其他轨道。 其 他轨道可以是音频轨道、 字幕轨道等； 多个视频轨道包括一个基本轨道和至少 一个增强轨道。 本例中， 有多个适配需求， 基本轨道及每个增强轨道分别包含 与某一适配需求对应的视频媒体数据。 从完整的 SVC文件中分别抽取各增强轨道 中的视频媒体数据存储形成各增强文件。 从完整的 SVC文件中抽取基本轨道的视 频媒体数据、 其他轨道的音频或字幕等媒体数据、 元数据存储形成基本文件。 基本文件采用的文件格式仍然基于 ISO文件格式。 增强文件采用文件格式不做绝 对化定义。 本发明的具体应用中， 开发者可以自己定义增强文件的格式， 如将 抽取出的媒体数据按二进制顺序存储 dat文件。
基本文件中的元数据用于描述对完整的 SVC文件分割后得到的多个文件包 含的所有媒体数据的物理结构和时间结构。 由于分割后， 媒体数据的物理存储 位置发生了变化， 如， 分割之前媒体数据存储在完整的 SVC文件中特定物理存储 位置上， 分割之后该媒体数据存储在基本文件或增强文件中特定物理存储位置 上。 需要对基本文件中的描述媒体数据的物理结构的元数据进行修改， 使之指 向新的物理存储位置。 描述媒体数据的物理结构的元数据包括， 包含媒体数据 的文件的 Fi leURI和媒体数据在该文件中的存储位置。 因此， 分割后， 需要为分 割得到的基本文件和增强文件分别分配 Fi leURI , 并修改基本文件中描述媒体数 据物理结构的元数据， 将 Fi leURI修改为分割后包含该媒体数据的基本文件或增 强文件的 Fi leURI , 将存储位置修改在分割后包含该媒体数据的基本文件或增强 文件中的存储位置。 使之指向新的物理存储位置。 例如， 对于增强文件中某一 媒体数据， 分割之前元数据都存放在 SVC文件中， 其中， 描述该媒体数据的物理 存储位置的元数据指向的是完整的 SVC文件中的物理存储位置， 分割之后元数据 都包含在基本文件中， 且要对描述该媒体数据的物理存储位置的元数据进行修 改， 使之指向增强文件中的物理存储位置。
(二） 方法 2
不同于方法 1将元数据集中存放在基本文件中， 该方法中元数据分散存放在 基本文件和各增强文件中， 即不管基本文件还是增强文件， 都包括元数据， 文 件中的元数据只用于描述本文件包含的媒体数据。 该元数据描述了本文件包含 的媒体数据的物理结构和时间结构， 其中用于描述媒体数据时间结构的元数据 中包括媒体数据的解码时间。
增强轨道中存储的媒体数据由指针和增强层媒体数据构成， 通过指针可引 用基本层和解码依赖性更低的增强层的媒体数据。 现有技术对指针的定义如下:
class al igned (8) Extractor () {
NALUnitHeader O；
unsigned int (8) track— ref— index ;
signed int (8) sample— off set；
unsigned int ( (lengthSizeMinusOne+1) *8) data off set；
unsigned int ( (lengthSizeMinusOne+l) *8)
data— length ; 通过指针中的 track— ref— index可在当前轨道的元数据中查找得到要引用 的基本层和解码依赖性更低的增强层媒体数据对应的轨道的标识。 根据轨道的 标识可找到这些轨道的元数据， 该元数据指向基本层和解码依赖性更低的增强 层媒体数据的物理存储位置。 从而可以引用基本层和解码依赖性更低的增强层 媒体数据。
由于现有技术中， 使用 trackID作为轨道的标识， 而 trackID只在一个展示 (presentation, 指文件元数据描述的视频轨道及其他轨道的组合） 中唯一标 识轨道， 因此现有技术只能实现引用同一个展示中的媒体数据。
而该方法 2中基本文件和增强文件是不同的展示， 因此需要对现有技术进行 扩展， 在增强文件的元数据中可用 Fi leURI和 trackID共同标识要引用的媒体数 据对应的 track, 从而实现引用另一个展示中的媒体数据。 现有 SVC文件格式中， 可以从 SVC文件的元数据中获取基本轨道中的媒体数据的解码时间和增强轨道 的媒体数据的解码时间， 根据解码时间同步基本轨道中的媒体数据和增强轨道 的媒体数据， 方法 2中类似地可以分别从增强文件、 基本文件的元数据中获取增 强文件、 基本文件的媒体数据的解码时间， 根据解码时间同步基本文件的媒体 数据和增强文件的媒体数据。
步骤 320， 进行文件传输。 如图 8所示， 该步骤细分为：
步骤 320-1， 将每一个分割后的文件用一个传输对象 （TO ) 承载， 产生 FDT 实例， 所述 FDT实例携带各文件的描述信息以及各文件的解码依赖性信息。
步骤 320-2， 传输所述 FDT实例和各传输对象。
本发明一实施例中， 对上述步骤 320-1有多种在 FDT实例中携带各文件的解 码依赖性信息的方法。 下面举例说明如下：
( 1 ) 第一种方法 扩展 FDT实例中对各文件的描述信息， 在文件的描述中增加该文件解码依赖 的一组（0到多个）文件的文件标识， 以指示该文件与其他文件的解码依赖关系。
另外， 作为本发明另一实施例， 可选的， FDT实例中还可增加解码依赖类型 标识， 用于指示解码依赖性的原因， 例如， 解码依赖类型标识的取值为 lay, 表 示解码依赖性是由分层编码造成的。 如果解码依赖性是其它原因造成的， 比如 密钥文件和媒体文件， 媒体文件依赖于密钥文件进行解码， 则可设置为其它取 值。
该 FDT实例相应的 XML定义可为：
<complexType name = "Fi leType " >
<sequence>
<element name= "DependencyOn type= " anyURI minOccurs=" 0，， maxOccurs= "unbounded" >
<element name=，， DependencyType JJ type=，， string" minOccurs=" 0，，
</complexType>
在 SVC文件被分成一个基本文件和一个增强文件时， 若基本文件的 Fi leURI 为 http : //www. example. com/SVCf i le/trackK 增强文件的 Fi leURI为 http : // www. example. com/SVCf i le/ tracks。 基本文件 http : //www. example. com/SVCfile /trackl不依赖于其他文件解码； 增强文件 http : //www. example. com/SVCfi le /^&。1^2依赖于基本文件^1 ：// ¾^. example. com/SVCf i le/trackl解码。此时， FDT实例中基本文件和增强文件的描述信息例如可为：
Content-Type=//video/3gpp-svc Content-Length=//7543//
Transfer-Length=//4294//
T0I="2"
FEC-0TI-Encoding-Symbol-Length=// 16//
FEC-OTI-Scheme-Specific-Info=//AAEBBA==//
Content-Location=http： //www. example. com/SVCf i le/ trackl/>
〃增强文件的描述信息
<Fi le
Content-Type= video/3gg-svc
Content-Length= 161934
Transfer-Length= 157821"
T0I='T
FEC-0TI-Encoding-Symbol-Length= 512
Content-Location=http： //www. example. com/SVCf i le/ track2>
<dependencyOn>http： //www. example. com/SVCf i le/ trackK/ dependencyOn)
〈/Fi le〉
其中， 基本文件不依赖于其他任何文件解码， 因此基本文件的描述信息中包 含 0个解码依赖文件的文件标识； 增强文件 http：〃 www. example. com/SVCf i le /track2依赖于基本文件 http : //丽. example. com/SVCf i le/trackl解码， 增强 文件的描述信息中包含 1个解码依赖文件的文件标识 http：〃 www. example, com /SVCfi le/trackl o ( 2 ) 第 2种方法
本方法中， 可将对完整的 SVC文件分割后得到的所有文件作为一个逻辑组 合， 即一个文件组。 在 FDT实例中增加文件组的描述， 通过文件组的描述说明文 件间的解码依赖关系。 文件组的描述包含： 组标识和多组描述信息。 每组描述 信息由某一文件的文件标识、 解码该文件要依赖的文件的文件标识组成， 用来 说明该文件和其他文件间的解码依赖关系。 可选的， 文件组描述信息中还可包 含组类型标识， 用于指示组中文件之间是否存在解码依赖关系， 例如， 组类型 标识取值为 DDP (decoding dependency) ， 表示组中文件间存在解码依赖关系。 另外， 作为本发明另一实施例， 可选的， FDT实例中还可增加解码依赖类型 标识， 用于指示文件间解码依赖关系的原因， 例如， 解码依赖类型标识的取值 为 lay, 表示解码依赖关系是由分层编码造成的。 如果解码依赖关系是其它原因 造成的， 比如密钥文件和媒体文件， 媒体文件依赖于密钥文件进行解码， 则可 设置为其它取值。
文件组描述的 XML定义可如下所示。
<complexType name = = "Fi leGroupType " >
<sequence>
<element name = "HowDependent，， type= "mbms： HowDependentType " maxOccurs= "unbounded"
</ sequence)
<attribute name= "GroupType " type= " string" use=，， optional " >
<attribute name= "Group ID" type= "mbms： groupIdType " use=，， required" </complexType>
<complexType name = = " HowDependent Type JJ >
<sequence>
<element name = "Dependency" type= " anyURI " >
<element name = "DependencyOn " type= " anyURI " maxOccurs= "unbounded
</ sequence)
<attribute name= "DependencyType " type= " string" use=，， optional " > </complexType>
一个具体的实施例如下所述： svc文件被分成一个基本文件和一个增强文 件， 基本文件的 Fi leURI为 http :〃胃. example. com/SVCfi le/trackl、 增强文 件的 Fi leURI为 http：〃 www. example. com/SVCf i le/track2。 两个文件组成 groupl。 此时， FDT实例中基本文件、 增强文件和文件组的描述例如可为：
〃基本文件的描述信息 <Fi le
Content-Type=//video/3gpp-svc//
Content-Length=//7543//
Transfer-Length=//4294//
T0I="2"
FEC-0TI-Encoding-Symbol-Length=// 16//
FEC-OTI- Scheme- Specific- Info="AAEBBA=="
Content-Location=http： //www. example. com/SVCf i le/ trackl groupID=，， 1，， />
〃增强文件的描述信息
<Fi le
Content-Type=//video/3gg-svc//
Content-Length=// 161934//
Transfer-Length=// 157821//
TOI ="3"
FEC-0TI-Encoding-Symbol-Length=//512//
Content-Location=http： //www. example. com/SVCf i le/ track2 groupID=，， 1，， />
〃文件组的描述信息
<Fi legroup
groupType=" DDP"
groupID=，， 1，，〉
<HowDependent
DependencyType=" lay JJ >
<Dependency>http： //www. example, com/ SVCf i le/ track2</Dependen <DependencyOn>http： //www. example. com/SVCf i le/ trackl
</DependencyOn>
</HowDependent>
</Fi legroup> 其中， 文件组的描述中包含一组描述信息， 表示增强文件 http : //www. example. eom/SVCfi le/t:rack2 依 赖 于 基 本 文 件 http：〃 www. example. com/SVCfi le/trackl解码。 本方法在具体实施时， 基本文 件的描述信息中可以不包含文件组标识。 这样， 当接收端用户设备接收的满足 某种适配需求的目标文件为基本文件时， 接收端用户设备就不需要先根据文件 组标识获取文件组的描述， 再在文件组的描述中查找目标文件对应的解码依赖 性信息了， 可以直接确定目标文件不存在解码依赖文件， 从而可以简化处理， 节省资源。
( 3 ) 第 3种方法
本方法中， 将对完整的 SVC文件分割后得到的所有文件作为一个逻辑组合， 即一个文件组。 所有文件的描述信息中都包含取值相同的组标识 （groupID) 字 段。 在文件的描述信息中增加该文件的解码依赖性大小标识， 用于指示文件的 解码依赖性大小。 默认情况下， 文件依赖于同一个文件组中解码依赖性更小的 文件进行解码。 例如， 对于如下的解码依赖性信息： 基本文件， 对应 QVGA格式 分辨率， 不依赖于其它文件， 独立解码； 增强文件 1， 对应 HVGA格式分辨率， 依 赖于基本文件才能解码； 增强文件 2， 对应 VGA格式分辨率， 依赖于基本文件和 增强文件 1才能解码。 所述基本文件的解码依赖性大小标识 （dependencylD) 取 值可为 0， 增强文件 1的解码依赖性大小标识取值可为 1， 增强文件 2的解码依赖 性大小标识取值可为 2。
相应的 XML定义可为：
<complexType name = "Fi leType " >
<sequence>
< any namespace=〃ftftothe:r〃 processContents=〃skip〃 minOccurs=〃0〃 maxOccurs= unbounded />
</ sequence) <attribute name= " dependencylD" type=，， integer"
use=，， required" >
</ complexType)
本发明实施例中， 通过根据适配需求分割 SVC文件为多个文件， 在需要满足 某种适配需求的数据时， 用户设备可仅接收该适配需求对应的分割后的文件及 其解码所依赖的文件， 而无需接收整个 SVC文件或文件组， 从而避免了用户设备 端缓存空间的浪费， 并减少了文件接收的时间， 节省了电力。
相应地， 本实施例还提供一种文件接收方法， 该方法可由作为接收端的终 端来完成， 如图 9所示， 该方法包括如下流程：
步骤 401 : 获取目标文件的文件标识 FileURI。
所述目标文件的文件标识 FileURI通常由上层应用设备传给接收端， 如用户 通过 ESG (Electronic Service Guide, 电子业务指南） 应用设备选择了一个目 标文件， 由 ESG应用设备将目标文件的 FileURI传给接收端。
步骤 402: 获取目标文件所在的文件传输会话的描述。
所述文件传输会话的描述包括： 源 IP地址， 传输会话标识 （Transport Session Identifier, TSI , 该 TSI和源 IP地址一起唯一标识一个 FLUTE会话） ， 目的 IP地址、 端口等。 通常从 SDP (Session Description Protocol , 会话描述 协议） 文件中可获取文件传输会话的描述。
终端首先获取 ESG, ESG中包含 SDP文件的获取地址， 或者直接内嵌了 SDP文 件。 终端选择了目标文件后， 可以获取并存储 SDP文件， 即在步骤 402前 SDP文件 已经预先存储在终端上了， 从而终端从 SDP文件中可获取文件传输会话的描述。
步骤 403: 加入文件传输会话。
根据步骤 402获取的文件传输会话的描述可加入文件传输会话， 属于现有技 术， 不再详述。
步骤 404: 获取 FDT实例。
由于默认 FDT实例的 T0I为 0， 即包头中 T0I=0的数据包用于承载 FDT实例。 因 此本步骤可包括：
步骤 404-1， 接收包头中 T0I=0的数据包， 并将这些数据包缓存在一起。 步骤 404-2， 判断是否接收到了足够的用于恢复完整的 FDT实例的数据包。 T0I=0的数据包的包头中还包括 FEC 0TI信息， 根据 FEC 0TI信息可以计算出 FDT实例被分成的源块的数量 Ν和每个源块中的编码符号的数量 η， 如果终端接收 到的源块的数 g =N且每个源块中的编码符号的数量 =η， 就认为接收到了足够恢 复 FDT实例的数据包。 如果接收到了足够恢复 FDT实例的数据包， 则转到步骤 404-3， 否则转到步骤 404-1。
步骤 404-3， 解析接收到的数据包， 恢复 FDT实例。
步骤 405: 接收目标文件及目标文件的解码依赖文件。 如图 10所示， 该步骤 具体包括：
步骤 405-1： 在 FDT实例中查找获得目标文件的描述信息。
步骤 405-2 : 判断目标文件是否依赖于其他文件进行解码。 根据在 FDT实例 中携带文件间解码依赖关系的方法不同， 判断目标文件是否依赖于其他文件解 码的方法也不同， 例如：
( 1 )如果采用步骤 320-2中第 1种方法携带文件间的解码依赖关系， 若目标 文件的描述信息中包含解码目标文件要依赖的文件的 FileURI , 则目标文件依赖 于其他文件进行解码。
(2 ) 如果采用步骤 320-2中第 2种方法携带文件间的解码依赖关系， 从 FDT 实例中查找获得文件组的描述， 若文件组的描述中包含解码目标文件要依赖的 一组文件的 FileURI , 则目标文件依赖于其他文件进行解码。
(3 )如果采用步骤 320-2中第 3种方法携带文件间的解码依赖关系， 若目标 文件的描述信息中的解码依赖性大小标识大于 0， 则目标文件依赖于其他文件进 行解码。
如果目标文件不依赖于其他文件进行解码， 则只需要接收目标文件， 该目 标文件为待接收的文件。 转到步骤 405-3。 步骤 405-3， 根据目标文件的描述信息接收目标文件， 对目标文件的接收可 同现有技术的接收步骤。 例如具体可包括；
( 1 ) 记录目标文件的 T0I , 目标文件的描述信息中包括目标文件的 T0I。
(2 ) 接收包头中的 T0I字段的取值与记录下来的 T0I相同的数据包， 并将 这些数据包缓存在一起。
(3 )判断是否接收到了足够的用于恢复目标文件的数据， 目标文件的描述 信息中包含 FEC 0TI信息， 根据 FEC 0TI信息可以计算出目标文件被分成的源块 的数量 Ν和每个源块中的编码符号的数量 η， 如果终端接收到的源块的数目 =N且 每个源块中的编码符号的数量 =η， 就认为接收到了足够恢复目标文件的数据包。 如果接收到了足够恢复目标文件的数据包，则转到步骤（4)，否则转到步骤（2 )。
(4) 解析接收到的数据包， 恢复目标文件。
如果目标文件依赖于其他文件进行解码， 则需要接收目标文件和目标文件 的解码依赖文件。 即目标文件和目标文件的解码依赖文件为待接收文件。 转到 步骤 405-4。
步骤 405-4: 确定解码目标文件要依赖的文件， 即确定目标文件的解码依赖 文件。 待接收文件为目标文件和目标文件的解码依赖文件， 记录待接收文件的 ΤΟΙ ο 根据在 FDT实例中携带文件间解码依赖关系的方法不同， 确定目标文件的 解码依赖文件的方法也不同。
如果采用步骤 320-2中第 1种方法和第 2种方法， 从目标文件或文件组的描述 中就能获得目标文件的解码依赖文件的 FileURI , 根据 Fi leURI在 FDT实例中查找 获得目标文件的解码依赖文件的描述信息， 从中获得目标文件的解码依赖文件 的 T0I。
如果采用步骤 320-2中第 3种方法， 需要扫描 FDT实例， 所有文件的描述信息 中包含相同 groupID但解码依赖性大小标识小于目标文件的解码依赖性标识的 文件即为目标文件的解码依赖文件。
步骤 405-5:接收和缓存用于承载待接收文件的数据包，即接收包头中的 T0I 字段的取值与记录下来的 TOI相同的数据包。 待接收文件至少有两个， 将这些数 据包按 T0I分组缓存， 即将其中 T0I相同的数据包缓存在一起。
步骤 405-6: 对于每个待接收文件， 根据文件的描述信息中的 FEC 0TI信息 判断是否接收到了足够恢复该文件的数据包； 如果否， 转到步骤 405-5; 如果是， 转到步骤 405-7。
步骤 405-7: 解析接收到的数据包， 恢复文件。
步骤 405-8: 判断是否接收到所有待接收文件； 如果是， 流程结束； 如果否， 转到步骤 405-5。
文件接收完毕后， 接收端将文件传给上层应用设备， 比如播放器， 由应用 设备完成文件的解码和展示。
本发明实施例中， 终端接收的是目标文件及目标文件的解码依赖文件， 而 不是完整的 SVC文件， 避免了对用户终端缓存的浪费， 并减少了电力消耗。 实施例 3
本实施例另提供一种 SVC文件的传输方法， 本实施例与实施例 2的不同之处 在于本实施例通过一个独立的文件而不是在 FDT实例来携带文件间的解码依赖 关系， 从而可以进一步提高方案的灵活性。 将该文件称为解码依赖关系声明文 件， 文件的格式可以是 XML、 SVG等等。
本实施例中， 解码依赖关系声明文件的传输方式可以有多种， 例如：
( 1 )通过文件传输表实例传输各文件的描述信息及解码依赖关系声明文件 的地址。
例如， 将解码依赖关系声明文件与分割得到的文件放在同一个 FLUTE会话中 传输。 在 FDT实例中分割得到的文件的描述信息中增加依赖性描述 (DependencyDescription) 元素， 取值为该解码依赖关系声明文件的 FileURI。
这样， 接收端接收目标文件时， 会首先根据目标文件的描述信息中的 DependencyDescription元素， 获得解码依赖关系声明文件的 FileURI， 然后从 FDT实例中获得解码依赖关系声明文件的描述信息， 根据解码依赖关系声明文件 的描述信息从 FLUTE会话中接收解码依赖关系声明文件， 根据解码依赖关系声明 文件确定目标文件依赖哪些文件进行解码， 接收目标文件和目标文件的解码依 赖文件。
( 2 )通过电子业务指南的内容分片或接入分片传输解码依赖关系声明文件 的地址。
例如， 在 ESG的 content (内容） 分片或者 Access (接入） 分片中增加 DependencyDescription元素， 取值为该解码依赖关系声明文件的 Fi leURI。
接收端接收目标文件时， 会同样根据 ESG中用于描述目标文件的 content分 片或者 Access分片中的 DependencyDescription元素， 获得解码依赖关系声明文 件的 Fi leURI , 然后从 FDT实例中获得解码依赖关系声明文件的描述信息， 根据 描述从 FLUTE会话中接收解码依赖关系声明文件， 解析解码依赖关系声明文件， 确定目标文件依赖哪些文件进行解码， 接收目标文件和目标文件的解码依赖文 件。
作为本发明实施例 1的另一替代方案， 还可以在 ESG中而不是在 FDT实例中携 带文件间的解码依赖关系。 例如， 可以在 ESG中用于描述目标文件的 content分 片或者 Access分片中增加解码该目标文件要依赖的一组文件的文件标识。 从而 还可以从 ESG的 content分片或者 Access分片获取目标文件解码依赖性关系， 进 而确定目标文件的解码依赖文件。 实施例 4
本实施例另提供一种 SVC文件的传输方法， 本实施例与前面实施例的不同之 处在于本实施例通过 T0I来携带文件间的解码依赖关系。
现有技术中通过 T0I标识一个传输对象， 一个传输对象用于承载一个文件， 本实施例中将 T0I分割为两部分。 第一部分仍然用于标识传输对象， 第二部分由 文件组标识和解码依赖性大小标识组成， 用于描述各文件之间的解码依赖关系。 可以在 FDT实例中设置 FileGroupIDLength、 D印 endencylDLength分别说明 文件组标识、 解码依赖性大小标识的长度。 一个具体的实施例如下：
基本文件， 对应 QVGA格式分辨率， 不依赖于其它文件， 独立解码； 增强文 件 1， 对应 HVGA格式分辨率， 依赖于基本文件才能解码； 增强文件 2， 对应 VGA格 式分辨率， 依赖于基本文件和增强文件 1才能解码。
基本文件、 增强文件 1、 增强文件 2组成一个文件组， 文件组的标识为 1。 基本文件的解码依赖性大小标识为 0， 增强文件 1的解码依赖性大小标识为 1， 增强文件 2的解码依赖性大小标识为 2。
在 FDT实例中设置 Fi leGroupIDLength为 12， 即用 12bi t表示文件组标识； D印 endencylDLength为 4， 即用 4bit表示解码依赖性大小标识。 则基本文件、 增 强文件 1、增强文件 2的 T0I的 16进制表示分别为： 00010010、 00020011、 00030012。 其中前 4位数用于标识传输对象， 分别为 1、 2、 3； 中间三位数代表文件组标识， 均为 1 ; 最后一位数代表解码依赖性大小标识， 分别为 0、 1、 2。 实施例 5
本实施例提供一种 SVC文件的传输装置， 如图 11所示， 该装置包括： 分割单元 510， 用于将所述可伸缩视频编码 SVC文件分割为一个基本文件和 至少一个增强文件； 其中， 所述基本文件至少包括基本层媒体数据， 所述增强 文件包括部分或全部增强层媒体数据。 在本发明一具体实施例中， 所述分割单 元可根据适配需求将所述可伸缩视频编码 SVC文件分割为一个基本文件和至少 一个增强文件。
传输单元 520， 用于将分割得到的每一个文件各自通过不同的传输对象进行 传输， 并传输所述一个基本文件和至少一个增强文件的描述信息及各文件的解 码依赖性信息， 以使得终端根据所接收到的解码依赖性信息确定要接收的一个 或多个文件以及根据所述一个或多个文件的描述信息接收所述一个或多个文 件。 作为本发明另一实施例， 所述传输单元 520还用于通过文件传输表 FDT实例 传输所述一个基本文件和至少一个增强文件的描述信息及各文件的解码依赖性 信息。
作为本发明另一实施例， 所述传输单元 520还通过文件传输表实例传输所述 一个基本文件和至少一个增强文件的描述信息， 通过传输对象标识的设定位传 输各文件的解码依赖性信息。
作为本发明另一实施例， 如图 12所示， 所述传输单元 520包括：
第一传输单元 521， 用于通过解码依赖关系声明文件传输各文件的解码依赖 性信息；
第二传输单元 522， 用于通过文件传输表实例传输各文件的描述信息及所述 解码依赖关系声明文件的地址。
作为本发明另一实施例， 如图 13所示， 所述传输单元 520还包括：
第三传输单元 523， 用于通过文件传输表实例传输各文件的描述信息； 第四传输单元 524， 用于通过电子业务指南传输解码依赖关系声明文件的地 址。 本发明另一实施例中， 所述第四传输单元 524通过电子业务指南的内容分片 或接入分片传输解码依赖关系声明文件的地址。
第五传输单元 525， 用于通过所述解码依赖关系声明文件传输各文件的解码 依赖性信息。
作为本发明另一实施例， 如图 14所示， 所述传输单元 520包括：
第三传输单元， 用于通过文件传输表实例传输各文件的描述信息； 第六传输单元， 通过电子业务指南传输各文件的解码依赖文件的文件标识。 本发明另一实施例中， 所述第六传输单元通过电子业务指南的内容分片或接入 分片传输各文件的解码依赖文件的文件标识。
相应地， 本发明实施例还提供一种文件接收装置 600， 如图 15所示， 包括： 获取单元 610， 用于获取目标文件的解码依赖性信息， 所述目标文件为基本 文件或增强文件， 所述基本文件至少包括基本层媒体数据， 所述增强文件包括 部分或全部增强层媒体数据；
确定单元 620， 用于根据所述解码依赖性信息确定待接收的文件， 所述待接 收的文件为一个基本文件， 或一个基本文件以及至少一个增强文件；
第一接收单元 630， 用于接收所述待接收的文件的描述信息；
第二接收单元 640， 用于根据所述待接收的文件的描述信息接收所述待接收 的文件。
作为本发明另一实施例， 所述确定单元 620在根据所述解码依赖性信息确定 所述目标文件存在解码依赖文件时， 确定所述目标文件和解码依赖文件为待接 收的文件， 在根据所述解码依赖性信息确定所述目标文件不存在解码依赖文件 时， 确定所述目标文件为待接收的文件。
作为本发明另一实施例， 所述文件接收装置 600还包括：
第三接收单元 650， 用于接收解码依赖关系声明文件地址信息；
所述获取单元 610还用于根据所述解码依赖关系声明文件地址信息接收所 述解码依赖关系声明文件， 获取所述目标文件的解码依赖性信息。
本发明实施例中， 终端接收的是对完整的 SVC文件分割后得到的多个文件 (一个基本文件和至少一个增强文件） 中的一个或多个文件， 避免了对用户终 端缓存的浪费， 并减少了接收时间， 节省了电力消耗。 本发明实施例还提供一 种视频编码文件， 该视频编码文件为将可伸缩视频编码 SVC文件分割为一个基本 文件和至少一个增强文件后的基本文件或增强文件； 其中， 所述基本文件至少 包括基本层媒体数据， 所述增强文件包括部分或全部增强层媒体数据， 所述增 强文件至少依赖于所述基本文件进行解码。
在本发明一具体应用中， 所述基本文件还包括元数据， 所述元数据中包括 对基本文件和增强文件各自媒体数据的描述。
在本发明另一具体应用中， 所述基本文件还包括元数据， 该元数据中包括 对基本文件对应的媒体数据的描述； 所述增强文件还包括元数据， 该元数据中 包括对增强文件对应的媒体数据的描述。 所述增强文件中还包括指向所依赖的 文件的指针。
接收端用户设备可以通过仅接收上述视频编码文件中尽量少的文件来解码 得到需要的视频， 避免了对用户终端缓存的浪费， 并减少了接收时间， 节省了 电力消耗。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程， 是可以通过计算机程序来指令相关的硬件来完成， 所述的程序可存储于一计算 机可读取存储介质中， 该程序在执行时， 可包括如上述各方法的实施例的流程。 其中， 所述的存储介质可为磁碟、 光盘、 只读存储记忆体 （Read-Only Memory, ROM) 或随机存储记忆体 （Random Access Memory, RAM) 等。
以上所述的具体实施例， 对本发明的目的、 技术方案和有益效果进行了进 一步详细说明， 所应理解的是， 以上所述仅为本发明的具体实施例而已， 并不 用于限定本发明的保护范围， 凡在本发明的精神和原则之内， 所做的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权 利 要 求 书
1、 一种可伸缩视频编码文件的传输方法， 其特征在于， 包括：
将所述可伸缩视频编码 SVC文件分割为一个基本文件和至少一个增强文件； 其中， 所述基本文件至少包括基本层媒体数据， 所述增强文件包括部分或全部 增强层媒体数据；
将分割得到的每一个文件各自通过不同的传输对象进行传输；
传输所述一个基本文件和至少一个增强文件的描述信息及各文件的解码依 赖性信息， 以使得终端根据所接收到的解码依赖性信息确定要接收的一个或多 个文件以及根据所述一个或多个文件的描述信息接收所述一个或多个文件。
2、 根据权利要求 1所述的方法， 其特征在于：
所述基本文件还包括元数据， 该元数据中包括对基本文件对应的媒体数据 的描述；
所述增强文件还包括元数据， 该元数据中包括对增强文件对应的媒体数据 的描述， 或对增强文件对应的媒体数据的描述以及指向所依赖的文件的指针。
3、 根据权利要求 1所述的方法， 其特征在于， 所述各文件的解码依赖性信 息包括：
各文件标识及所述各文件的解码依赖文件的文件标识； 或者
各文件的文件标识、 所述各文件的解码依赖文件的文件标识以及各文件所 属的同一个文件组的标识； 或者
各文件的文件标识、 所述各文件的解码依赖文件的文件标识、 各文件所属 的同一个文件组的标识和文件组类型标识， 该文件组类型标识用于指示该文件 组内的文件之间是否存在解码依赖关系。
4、 根据权利要求 3所述的方法， 其特征在于， 所述各文件的解码依赖性信 息还包括： 解码依赖类型标识， 该解码依赖类型标识用于指示产生解码依赖性 的原因。
5、 根据权利要求 1所述的方法， 其特征在于， 所述各文件的解码依赖性信 息包括： 各文件所属的同一个文件组的标识及各文件的解码依赖性大小标识。
6、 根据权利要求 1〜5中任意一项所述的方法， 其特征在于， 传输各文件的 解码依赖性信息包括：
通过文件传输表 FDT实例传输各文件的解码依赖性信息； 或者
通过传输对象标识的设定位传输各文件的解码依赖性信息； 或者
通过文件传输表实例传输解码依赖关系声明文件的地址， 并通过所述解码 依赖关系声明文件传输各文件的解码依赖性信息。
7、 根据权利要求 1所述的方法， 其特征在于， 传输各文件的解码依赖性信 息包括：
通过电子业务指南传输解码依赖关系声明文件的地址， 并通过所述解码依 赖关系声明文件传输各文件的解码依赖性信息； 或者
通过电子业务指南传输各文件解码要依赖的文件标识。
8、 一种文件接收方法， 其特征在于， 包括：
获取目标文件的解码依赖性信息， 所述目标文件为基本文件或增强文件， 所述基本文件至少包括基本层媒体数据， 所述增强文件包括部分或全部增强层 媒体数据；
根据所述解码依赖性信息确定待接收的文件， 所述待接收的文件为一个基 本文件， 或一个基本文件以及至少一个增强文件；
接收所述待接收的文件的描述信息；
根据所述待接收的文件的描述信息接收所述待接收的文件。
9、 根据权利要求 8所述的方法， 其特征在于， 所述根据所述解码依赖性信 息确定要接收的一个或多个文件包括：
如果根据所述解码依赖性信息确定所述目标文件存在解码依赖文件， 确定 所述目标文件和解码依赖文件为待接收的文件；
如果根据所述解码依赖性信息确定所述目标文件不存在解码依赖文件， 确 定所述目标文件为待接收的文件。
10、 根据权利要求 8所述的方法， 其特征在于： 获取目标文件的解码依赖性 信息具体为：
通过文件传输表或电子业务指南获取所述解码依赖性信息。
11、 根据权利要求 8所述的方法， 其特征在于， 还包括： 接收解码依赖关系 声明文件地址信息；
所述获取目标文件的解码依赖性信息包括： 根据所述解码依赖关系声明文 件地址信息接收所述解码依赖关系声明文件， 获取所述目标文件的解码依赖性 信息。
12、 根据权利要求 11所述的方法， 其特征在于：
所述解码依赖关系声明文件地址设置于文件传输表或电子业务指南中。
13、 一种可伸缩视频编码文件的传输装置， 其特征在于， 包括：
分割单元， 用于将所述可伸缩视频编码 SVC文件分割为一个基本文件和至少 一个增强文件； 其中， 所述基本文件至少包括基本层媒体数据， 所述增强文件 包括部分或全部增强层媒体数据；
传输单元， 用于将分割得到的每一个文件各自通过不同的传输对象进行传 输， 并传输所述一个基本文件和至少一个增强文件的描述信息及各文件的解码 依赖性信息， 以使得终端根据所接收到的解码依赖性信息确定要接收的一个或 多个文件以及根据所述一个或多个文件的描述信息接收所述一个或多个文件。
14、 根据权利要求 13所述的装置， 其特征在于：
所述传输单元还用于通过文件传输表 FDT实例传输所述一个基本文件和至 少一个增强文件的描述信息及各文件的解码依赖性信息； 或者所述传输单元还 用于通过文件传输表实例传输所述一个基本文件和至少一个增强文件的描述信 息， 通过传输对象标识的设定位传输各文件的解码依赖性信息。
15、 根据权利要求 13所述的装置， 其特征在于， 所述传输单元包括： 第一传输单元， 用于通过解码依赖关系声明文件传输各文件的解码依赖性 信息；
第二传输单元， 用于通过文件传输表实例传输各文件的描述信息及所述解 码依赖关系声明文件的地址。
16、 根据权利要求 13所述的装置， 其特征在于， 所述传输单元包括： 第三传输单元， 用于通过文件传输表实例传输各文件的描述信息； 第四传输单元， 用于通过电子业务指南传输解码依赖关系声明文件的地址; 第五传输单元， 用于通过所述解码依赖关系声明文件传输各文件的解码依 赖性信息。
17、 根据权利要求 13所述的装置， 其特征在于， 所述传输单元包括： 第三传输单元， 用于通过文件传输表实例传输各文件的描述信息； 第六传输单元， 通过电子业务指南传输各文件要依赖的文件标识。
18、 一种文件接收装置， 其特征在于， 包括：
获取单元， 用于获取目标文件的解码依赖性信息， 所述目标文件为基本文 件或增强文件， 所述基本文件至少包括基本层媒体数据， 所述增强文件包括部 分或全部增强层媒体数据；
确定单元， 用于根据所述解码依赖性信息确定待接收的文件， 所述待接收 的文件为一个基本文件， 或一个基本文件以及至少一个增强文件；
第一接收单元， 用于接收所述待接收的文件的描述信息；
第二接收单元， 用于根据所述待接收的文件的描述信息接收所述待接收的 文件。
19、 根据权利要求 18所述的文件接收装置， 其特征在于：
所述确定单元在根据所述解码依赖关系确定所述目标文件存在解码依赖文 件时， 确定所述目标文件和解码依赖文件为待接收的文件， 在根据所述解码依 赖关系确定所述目标文件不存在解码依赖文件时， 确定所述目标文件为待接收 的文件。
20、 根据权利要求 18所述的文件接收装置， 其特征在于， 还包括：
PCT/CN2009/072650 2009-07-06 2009-07-06 一种可伸缩视频编码文件的传输方法、接收方法及装置 WO2011003231A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP09846982.8A EP2453652B1 (en) 2009-07-06 2009-07-06 Transmission method, receiving method and device for scalable video coding files
CN2009801487267A CN102165776B (zh) 2009-07-06 2009-07-06 一种可伸缩视频编码文件的传输方法、接收方法及装置
PCT/CN2009/072650 WO2011003231A1 (zh) 2009-07-06 2009-07-06 一种可伸缩视频编码文件的传输方法、接收方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2009/072650 WO2011003231A1 (zh) 2009-07-06 2009-07-06 一种可伸缩视频编码文件的传输方法、接收方法及装置

Publications (1)

Publication Number Publication Date
WO2011003231A1 true WO2011003231A1 (zh) 2011-01-13

Family

ID=43428730

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/072650 WO2011003231A1 (zh) 2009-07-06 2009-07-06 一种可伸缩视频编码文件的传输方法、接收方法及装置

Country Status (3)

Country Link
EP (1) EP2453652B1 (zh)
CN (1) CN102165776B (zh)
WO (1) WO2011003231A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140113995A (ko) * 2012-01-27 2014-09-25 인텔 코포레이션 향상된 멀티캐스트 콘텐츠 전달을 위한 기술
CN112565815A (zh) * 2020-10-16 2021-03-26 腾讯科技（深圳）有限公司 文件封装方法、文件传输方法、文件解码方法及相关设备

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108429917B (zh) 2012-09-29 2022-04-29 华为技术有限公司 视频编码及解码方法、装置及系统
GB2538998A (en) * 2015-06-03 2016-12-07 Nokia Technologies Oy A method, an apparatus, a computer program for video coding
GB2538997A (en) 2015-06-03 2016-12-07 Nokia Technologies Oy A method, an apparatus, a computer program for video coding
CN107094141B (zh) * 2017-04-28 2020-06-02 山东交通学院 一种p2p流媒体系统中的svc视频文件分片及调度方法
EP3876383A1 (en) 2020-03-02 2021-09-08 Nokia Technologies Oy Data communications

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007080223A1 (en) * 2006-01-10 2007-07-19 Nokia Corporation Buffering of decoded reference pictures
CN101120593A (zh) * 2005-04-13 2008-02-06 诺基亚公司 可扩展性信息的编码、存储和信号发送
CN101189881A (zh) * 2005-04-13 2008-05-28 诺基亚公司 可分级视频编码中的帧号编码
CN101356822A (zh) * 2006-01-10 2009-01-28 汤姆逊许可公司 用于构造可伸缩视频的参考图像列表的方法和设备
CN101390399A (zh) * 2006-01-11 2009-03-18 诺基亚公司 可伸缩视频编码中的图片的后向兼容聚合

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7756206B2 (en) * 2005-04-13 2010-07-13 Nokia Corporation FGS identification in scalable video coding
US7725593B2 (en) * 2005-07-15 2010-05-25 Sony Corporation Scalable video coding (SVC) file format
CN101998123B (zh) * 2005-10-11 2015-03-18 诺基亚公司 用于有效的可伸缩流适配的系统和方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101120593A (zh) * 2005-04-13 2008-02-06 诺基亚公司 可扩展性信息的编码、存储和信号发送
CN101189881A (zh) * 2005-04-13 2008-05-28 诺基亚公司 可分级视频编码中的帧号编码
WO2007080223A1 (en) * 2006-01-10 2007-07-19 Nokia Corporation Buffering of decoded reference pictures
CN101356822A (zh) * 2006-01-10 2009-01-28 汤姆逊许可公司 用于构造可伸缩视频的参考图像列表的方法和设备
CN101390399A (zh) * 2006-01-11 2009-03-18 诺基亚公司 可伸缩视频编码中的图片的后向兼容聚合

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140113995A (ko) * 2012-01-27 2014-09-25 인텔 코포레이션 향상된 멀티캐스트 콘텐츠 전달을 위한 기술
CN104081798A (zh) * 2012-01-27 2014-10-01 英特尔公司 用于改善多播内容递送的技术
EP2807838A4 (en) * 2012-01-27 2015-07-22 Intel Corp TECHNIQUES FOR IMPROVED DIFFUSION OF MULTIDESTINATION CONTENT
KR101636842B1 (ko) 2012-01-27 2016-07-06 인텔 코포레이션 향상된 멀티캐스트 콘텐츠 전달을 위한 기술
US9565672B2 (en) 2012-01-27 2017-02-07 Intel Corporation Techniques for improved multicast content delivery
CN104081798B (zh) * 2012-01-27 2018-02-06 英特尔公司 用于改善多播内容递送的方法和设备
AU2017210634B2 (en) * 2012-01-27 2019-04-04 Apple Inc. Techniques for improved multicast content delivery
CN112565815A (zh) * 2020-10-16 2021-03-26 腾讯科技（深圳）有限公司 文件封装方法、文件传输方法、文件解码方法及相关设备
CN112565815B (zh) * 2020-10-16 2022-05-24 腾讯科技（深圳）有限公司 文件封装方法、文件传输方法、文件解码方法及相关设备

Also Published As

Publication number Publication date
EP2453652A4 (en) 2012-06-06
EP2453652B1 (en) 2019-09-04
EP2453652A1 (en) 2012-05-16
CN102165776B (zh) 2012-11-21
CN102165776A (zh) 2011-08-24

Similar Documents

Publication Publication Date Title
JP6441521B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
US20210176506A1 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
TWI714602B (zh) 超級本文傳輸協定(http)上動態自適應串流(dash)客戶經驗品質度量之中間軟體傳遞
RU2622621C2 (ru) Система и способ для потоковой передачи воспроизводимого контента
US7917644B2 (en) Extensions to rich media container format for use by mobile broadcast/multicast streaming servers
US8768984B2 (en) Media container file management
JP6258856B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
WO2016138844A1 (zh) 音视频文件直播方法和系统、服务器
EP3441932A1 (en) Apparatus and method for providing streaming contents
US9521469B2 (en) Carriage of quality information of content in media formats
US20120246335A1 (en) Method, terminal, and server for implementing fast playout
KR102303582B1 (ko) 웹 콘텐츠에 대한 파일 트랙들을 사용하여 미디어 데이터를 프로세싱
WO2008061416A1 (fr) Procédé et système permettant d&#39;accepter des données media de divers formats de codage
CN107634930B (zh) 一种媒体数据的获取方法和装置
CN103210642B (zh) 在http流送期间发生表达切换时传送用于自然再现的可缩放http流的方法
WO2011003231A1 (zh) 一种可伸缩视频编码文件的传输方法、接收方法及装置
US10560866B2 (en) Method of handling packet losses in transmissions based on DASH standard and FLUTE protocol
CN103843301A (zh) 经译码多媒体数据的网络串流期间的表示之间的切换
CN112771877A (zh) 用于流式传输媒体数据的服务描述
JP2017528022A (ja) ネットワークを介して交換されたファイルのためのエラー処理
EP3741132A1 (en) Processing dynamic web content of an iso bmff web resource track
US11184665B2 (en) Initialization set for network streaming of media data
EP3982642A1 (en) Video transcoding method and apparatus
Zhang et al. A MMT-based content classification scheme for VoD service
EP4068781A1 (en) File format with identified media data box mapping with track fragment box

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980148726.7

Country of ref document: CN

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

Ref document number: 09846982

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009846982

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE