WO2010095823A2 - 부호화/복호화 방법 및 장치 - Google Patents

부호화/복호화 방법 및 장치 Download PDF

Info

Publication number
WO2010095823A2
WO2010095823A2 PCT/KR2010/000605 KR2010000605W WO2010095823A2 WO 2010095823 A2 WO2010095823 A2 WO 2010095823A2 KR 2010000605 W KR2010000605 W KR 2010000605W WO 2010095823 A2 WO2010095823 A2 WO 2010095823A2
Authority
WO
WIPO (PCT)
Prior art keywords
decoder
toolbox
decoding
encoded data
list
Prior art date
Application number
PCT/KR2010/000605
Other languages
English (en)
French (fr)
Other versions
WO2010095823A3 (ko
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 US13/202,552 priority Critical patent/US9031136B2/en
Publication of WO2010095823A2 publication Critical patent/WO2010095823A2/ko
Publication of WO2010095823A3 publication Critical patent/WO2010095823A3/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8193—Monomedia components thereof involving executable data, e.g. software dedicated tools, e.g. video decoder software or IPMP tool
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]

Definitions

  • the present invention relates to encoding / decoding, and more particularly, to an apparatus and method for encoding / decoding video data through a combination of functional units performing unit decoding.
  • a video is converted into a bitstream form by an encoder.
  • the bitstream is stored according to an encoding type satisfying the constraint of the encoder.
  • MPEG requires syntax (hereinafter referred to as 'syntax') and semantics (hereinafter referred to as 'semantics') as constraints of the bitstream.
  • syntax indicates the structure, format, and length of the data, and in what order the data is represented. That is, syntax is to fit a grammar for encoding / decoding, and defines the order of each element included in the bitstream, the length of each element, and the data format.
  • Semantics means what each bit of data means. That is, semantics indicates what the meaning of each element in the bitstream is.
  • bitstreams may be generated according to encoding conditions of an encoder or an applied standard (or codec).
  • each standard eg MPEG-1, MPEG-2, MPEG-4, MPEG-4 AVC, etc.
  • MPEG-4 AVC MPEG-4 AVC, etc.
  • bitstreams encoded according to each standard or encoding condition may have different formats (ie, syntax and semantics), and a decoder corresponding to an encoder should be used to decode the bitstream.
  • the conventional bitstream decoder has a limitation of satisfying the constraints of the encoder, and this limitation causes a difficulty in implementing an integrated decoder corresponding to a plurality of standards.
  • the present invention is to solve the above-described problem, and is encoded in various formats (syntax, semantics) according to each standard (for example, MPEG-1, MPEG-2, MPEG-4, MPEG-4 AVC, etc.) It is an object of the present invention to provide a bitstream decoding method and apparatus capable of decoding a bitstream in the same information recognition scheme.
  • An object of the present invention is to provide an encoding / decoding method and apparatus capable of efficiently classifying, identifying, and using functional units for decoding.
  • An object of the present invention is to provide an encoding / decoding method and apparatus that can store and easily identify and use functional units for decoding according to types.
  • an extended bitstream including a decoder description or a decoder description can be generated to decode a bitstream encoded in various formats (syntax, semantics) according to each standard in the same information recognition method. It is an object of the present invention to provide a bitstream encoding method and apparatus for independently generating a decoder description.
  • the present invention provides a bitstream decoding in which a bitstream compressed by various encoding methods is parsed by the same information analysis method, and each functional unit (FU) for organic decoding is organically controlled using the parsed data. To provide a method and apparatus.
  • the present invention can propose scheduling management of each codec and organic processing structures (eg, parallel combining structure, serial merging structure, independent processing structure, individual processing structure, etc.) by using the decoder description. To provide a bitstream decoding method and apparatus.
  • codec and organic processing structures eg, parallel combining structure, serial merging structure, independent processing structure, individual processing structure, etc.
  • the present invention provides a method and apparatus for encoding / decoding a bitstream to which a syntax analysis method for decoding various types of bitstreams can be commonly applied.
  • the present invention provides a bitstream encoding / decoding method and apparatus for applying a new set of instructions for parsing various types of bitstreams using a common syntax analysis method.
  • the present invention provides a method and apparatus for decoding a bitstream in which a decoder can easily decode a bitstream even when a syntax element is changed, added, or deleted.
  • An object of the present invention is to provide a method and apparatus for decoding a bitstream which enables element information of the parsed syntax (ie, the result of syntax parsing) to be used by components used for bitstream decoding.
  • the present invention is to provide a method and apparatus for decoding a bitstream which makes it possible to use element information of an already parsed syntax for interpretation of subsequent bitstream syntax elements.
  • the present invention divides functions included in various decoding processes proposed by various standards (codecs) into functional units (FUs), and provides a bitstream decoding method and apparatus provided in a tool box. will be.
  • the present invention is to provide a method and apparatus for decoding a bitstream selectively using only the functional units required by a toolbox to decode a bitstream encoded in various forms.
  • the present invention is to provide a method and apparatus for decoding a bitstream that is easy to change, add, or delete a functional part stored in a toolbox.
  • An object of the present invention is to provide an encoding and decoding system that can be used for decoding and encoding by using customized FUs.
  • the present invention provides a coding and decoding system capable of providing a functional unit to a decoding system in a coding system.
  • An object of the present invention is to provide an encoding and decoding system capable of requesting and receiving a function unit necessary for decoding data received in a decoding system in a two-way communication environment.
  • an encoding / decoding apparatus and method that can be used universally in various encoding formats.
  • the encoding unit for encoding the data to generate encoded data (encoded data);
  • a decoder description generation unit for generating a decoder description describing function units (FUs) constituting a decoder for decoding the encoded data and a connection relation thereof;
  • a FU list generator for generating and outputting FU lists for function units (FUs) constituting a decoder for decoding the encoded data;
  • a packetizer that receives the encoded data, receives a decoder description, an FU list, and a function unit (FU) corresponding to the encoded data, and packetizes the output.
  • the packetizing unit assigns and packetizes a unique packet ID to each of the encoded data, the decoder description, the FU list, and the functional units, thereby encoding the encoded data packet, the decoder description packet, the FU list packet, and the functional unit. It may be characterized by generating a packet.
  • the encoding apparatus may further include a bitstream generator configured to generate a bitstream integrating the encoded data packet, the decoder description packet, the FU list packet, and the function packet.
  • the FU list packet may include FU identification information of corresponding FUs and packet ID information of corresponding FU packets.
  • the FU identification information may include a tool box number (TBN) field indicating a toolbox to which the corresponding function unit belongs and a FU number field indicating unique identification information of the corresponding function unit.
  • TBN tool box number
  • a tool box for storing a plurality of (Function Unit, FU);
  • a packet processor for dividing the received bitstream by packet type and outputting encoded data, a decoder description, an FU list, and an FU;
  • the FU list is input, the FU identification information of the FU list is extracted and compared with the FUs of the FUs stored in the toolbox to determine whether there is a new FU in the FU list.
  • a function unit comparator configured to receive an input from the toolbox and transmit the same to the toolbox so that the toolbox 2250 stores the new FU;
  • a decoder forming unit for interpreting the decoder description to load and combine the FUs needed to decode the encoded data from the toolbox into the following decoding solution to form a decoder;
  • a decoding solution that receives the encoded data and decodes the data through the combined decoder.
  • the toolbox may include a plurality of toolboxes that store the functional units by types, and the plurality of toolboxes may be divided into toolbox identification information.
  • the FU list may include a tool box number (TBN) field indicating a tool box to which the corresponding function part belongs and a FU number field indicating unique identification information of the corresponding function part.
  • TBN tool box number
  • the toolbox comprises: an MPEG video toolbox storing functional parts related to MPEG video decoding; An MPEG audio toolbox that stores functional parts related to MPEG audio decoding; An MPEG graphics toolbox for storing functional parts related to MPEG graphic decoding; It may include any one or more of a custom toolbox for storing the user-defined functional units.
  • An encoding apparatus includes a tool box for storing a plurality of functional units; An encoder which encodes the data and generates encoded data; A decoder description generation unit for generating a decoder description describing function units (FUs) constituting a decoder for decoding the encoded data and a connection relation thereof; A FU list generator for generating and outputting FU lists for function units (FUs) constituting a decoder for decoding the encoded data; A packetizer configured to receive the encoded data, packetize and output a decoder description and an FU list corresponding to the received encoded data, and receive and packetize the functional units (FUs); And an FU request signal processor for outputting the FU corresponding to the FU request signal received from the outside from the toolbox and inputting the FU request signal to the packetizer.
  • a decoder description generation unit for generating a decoder description describing function units (FUs) constituting a decoder for decoding the encoded data and a connection relation thereof
  • the encoding apparatus may further include a transport bitstream generator configured to generate a transport bitstream using one or more of the encoded data, the decoder description, and the packets of the FU list.
  • a transport bitstream generator configured to generate a transport bitstream using one or more of the encoded data, the decoder description, and the packets of the FU list.
  • the encoding apparatus may further include a FU transmission data generation unit for converting and generating the FU packet packetized by the packetization unit into FU transmission data which is data for transmission.
  • a tool box for storing a plurality of (Function Unit, FU); Communication unit for transmitting and receiving data with an external encoding device; A packet processing unit for separating the data received by the communication unit for each packet type and outputting encoded data, a decoder description, an FU list, and an FU; The FU list is compared with the FUs stored in the toolbox to determine whether a new FU is included in the FU list, and when a new FU is included, a FU request signal for requesting a new FU to the external encoding device is generated.
  • a FU list processing and function request unit A decoder forming unit for interpreting the decoder description to load and combine the FUs needed to decode the encoded data from the toolbox into the following decoding solution to form a recombinant decoder; And a decoding solution for receiving the encoded data and decoding the same through the recombination decoder.
  • the packet processing unit may receive a transport bitstream and extract encoded data, a decoder description, and an FU list from the transport bitstream.
  • the packet processing unit may receive FU transmission data, extract FU from the FU transmission data, and store the data in a toolbox.
  • An encoding method includes the steps of: (a) encoding encoded data to generate encoded data; (b) generating a decoder description describing a function unit (FU) constituting a decoder for decoding the encoded data and a connection relation thereof; (c) generating an FU list for Function Units (FUs) constituting a decoder for decoding the encoded data; And (d) packetizing the encoded data and decoder descriptions, FU lists, and functional units (FUs) corresponding to the encoded data.
  • a unique packet ID is assigned to each of the encoded data, the decoder description, the FU list, and the functional units (FU), and packetized, thereby encoding the encoded data packet, the decoder description packet, the FU list packet, and the like. It may be characterized by generating a functional packet.
  • the encoding method may further include a bitstream generation step of generating a bitstream integrating the encoded data packet, the decoder description packet, the FU list packet, and the function packet.
  • a decoding method includes: separating an input bitstream by packet type, and separately extracting encoded data, a decoder description, an FU list, and an FU; Extracting FU identification information of the FU list and comparing the FUs of FUs stored in the toolbox to determine whether there is a new FU in the FU list; As a result of the determination, if there is a new FU, transmitting the corresponding FU to the toolbox so that the toolbox stores the new FU; Interpreting the decoder description to load and combine the FUs needed to decode the encoded data from the toolbox to form a recombinant decoder; And decoding the encoded data through the recombination decoder.
  • An encoding method comprises the steps of: encoding encoded data to generate encoded data; Generating a decoder description describing function units (FUs) constituting a decoder for decoding the encoded data and a connection relation thereof; Generating a FU list for a function unit (FU) constituting a decoder for decoding the encoded data; A packetizer configured to packetize the encoded data and the decoder description and the FU list corresponding to the encoded data, and packetize the input functional units (FUs); And an FU request signal processor for outputting an FU corresponding to the FU request signal received from the outside from the toolbox and inputting the signal to the packetizer.
  • FUs function unit
  • the encoding method may further include generating a transport bitstream using any one or more of the packetized encoded data, decoder description, and FU lists.
  • the encoding method may further include converting and generating the packetized FU into FU transmission data which is data for transmission.
  • a decoding method comprises the steps of: receiving a transport bitstream from an external encoding device; Separating the transport bitstream by packet type and extracting encoded data, a decoder description, and an FU list; Comparing the FU list with FUs stored in the toolbox to determine whether a new FU is included in the FU list; Generating a FU request signal for requesting a new FU to the external encoding device when the new FU is included as a result of the determination; Receiving FU transmission data from an external encoding device; Extracting the FU from the FU transmission data and storing the FU in a toolbox; Interpreting the decoder description to load and combine the FUs needed to decode the encoded data to form a recombinant decoder; And decoding the encoded data through the recombination decoder.
  • a program of instructions that can be executed in a decoding apparatus is tangibly implemented, and a recording medium on which a program that can be read by the decoding apparatus is recorded is provided.
  • a program of instructions that can be executed in an encoding apparatus is tangibly embodied, and a recording medium on which a program that can be read by the encoding apparatus is recorded is provided.
  • the integrated codec apparatus and method according to the present invention are encoded in various formats (syntax, semantics) according to each standard (for example, MPEG-1, MPEG-2, MPEG-4, MPEG-4 AVC, etc.).
  • the decoded bitstream can be decoded with the same information recognition scheme.
  • the present invention has the effect of recombining the decoder by efficiently identifying, identifying and using functional units for decoding.
  • the present invention has an effect that can be stored and easily identified and used to separate the functional units for decoding in a plurality of tool boxes according to the type.
  • the present invention is an effect capable of generating an extended bitstream with a decoder description (decoder description) to decode the bitstream encoded in various formats (syntax, semantics) according to each standard in the same information recognition method There is also.
  • the present invention proposes scheduling management of each codec and an organic processing structure (eg, a parallel combining structure, a serial merging structure, an independent processing structure, an individual processing structure, etc.) of each codec using a decoder description. There is also an effect that can be done.
  • an organic processing structure eg, a parallel combining structure, a serial merging structure, an independent processing structure, an individual processing structure, etc.
  • the present invention has the effect that it is possible to design and build a variety of systems only by the decoder description described.
  • the present invention parses a bitstream compressed by various encoding schemes by the same information analysis method, and can organically control functional units (FU) for decoding using the parsed data. There is also an effect.
  • the present invention has an effect that can be commonly applied to the syntax analysis method for decoding various types of bitstream.
  • the present invention has the effect of applying a new set of instructions for parsing various types of bitstreams with a common syntax analysis method.
  • the present invention also has the effect that the decoder can easily decode the bitstream even when the syntax element is changed or added.
  • the present invention has an effect that allows the components used for bitstream decoding to share the element information (the result of parsing the syntax) of the parsed syntax.
  • the present invention also has the effect that the element information of the parsed syntax can be used for the interpretation of subsequent bitstream syntax elements.
  • the present invention also has an effect that can be used when integrating a moving picture or still picture codec that processes block units other than MPEG-1, MPEG-2, MPEG-4, and MPEG-4 AVC.
  • the present invention has an effect that can be stored in a toolbox by dividing the functions constituting various decoding methods proposed by various standards (codecs) into functional units (FU).
  • the present invention has the effect that it is possible to selectively decode only the functional units necessary in the toolbox to decode the bitstream encoded in various forms.
  • the present invention has an effect that it is easy to change, add, or delete a function unit stored in a toolbox.
  • the present invention has an effect that can be used for decoding and encoding by using user defined functional units (Customized FU).
  • 1 is a diagram schematically showing a configuration of a general decoder.
  • FIG. 2 is a diagram schematically illustrating a configuration of a general encoder.
  • FIG. 3 is a block diagram of an embodiment of an encoder according to the present invention.
  • FIG. 4 is a block diagram of an embodiment of a decoder in accordance with the present invention.
  • FIG. 5 is a diagram illustrating in detail a bitstream processing in a decoder according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating a decoder description input process according to another embodiment of the present invention.
  • FIG. 7 is a block diagram of another embodiment of a decoder according to the present invention.
  • FIG. 8 is a block diagram of another embodiment of the decoder of FIG. 4;
  • FIG. 9 illustrates a configuration of a BSDL parser according to another embodiment of the present invention.
  • FIG. 10 is a block diagram of another embodiment of a decoder according to the present invention.
  • FIG. 11 is a block diagram of an embodiment of a decoder of FIG. 10; FIG.
  • FIG. 12 illustrates the structure of an FU networking table in accordance with an embodiment of the present invention.
  • FIG. 13 is a view showing the structure of a VNT table according to an embodiment of the present invention.
  • FIG. 14 is a view showing the structure of the FUIT table according to an embodiment of the present invention.
  • 15 is a view showing the structure of a PT table according to an embodiment of the present invention.
  • 16 is a diagram showing the structure of an NCT table according to an embodiment of the present invention.
  • 17 is a diagram showing the structure of an ET table according to an embodiment of the present invention.
  • 18 is an exemplary diagram showing a mutual conversion relationship between CDDL / BSDL using a bitstream syntax list.
  • 19 is an exemplary view showing a detailed configuration of a toolbox according to an embodiment of the present invention.
  • FIG. 20 is an exemplary diagram showing functional unit identification information (FUID) according to an embodiment of the present invention.
  • 21 is a conceptual diagram for explaining the functional unit classification / identification mechanism according to the present invention.
  • 23 is an exemplary diagram showing a packet configuration of a bitstream transmitted according to another embodiment of the present invention.
  • 24 is an exemplary diagram conceptually illustrating a process of transmitting and receiving data in a broadcast environment according to another embodiment of the present invention.
  • 25 is a block diagram of a decoding apparatus according to another embodiment of the present invention.
  • FIG. 26 is an exemplary diagram conceptually illustrating a process of transmitting and receiving FU and encoded data in a bidirectional communication environment according to another embodiment of the present invention.
  • FIG. 26 is an exemplary diagram conceptually illustrating a process of transmitting and receiving FU and encoded data in a bidirectional communication environment according to another embodiment of the present invention.
  • FIG. 27 is a diagram illustrating an embodiment of the encoding system of FIG. 26.
  • FIG. 27 is a diagram illustrating an embodiment of the encoding system of FIG. 26.
  • FIG. 28 is a block diagram of an embodiment of a decoding system of FIG.
  • first and second may be used to describe various components, but the components are not limited by the terms. The terms are used only for the purpose of distinguishing one component from another.
  • first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.
  • the term “and / or” includes any combination of a plurality of related items or any item of a plurality of related items.
  • FIG. 1 is a diagram schematically showing a configuration of a general decoder
  • FIG. 2 is a diagram schematically showing a configuration of a general encoder.
  • the MPEG-4 decoder 100 generally includes a variable length decoding unit 110, an inverse scan unit 115, and an inverse DC / AC prediction unit. / AC Prediction (120), Inverse Quantization (125), Inverse Discrete Cosine Transform (Inverse Discrete Cosine Transformation, 130), and Video Restoration (VOP Reconstruction, 135). It is apparent that the configuration of the decoder 100 may be different according to the applied standard, and some components may be replaced with other components.
  • variable length decoding unit 110 quantizes the Huffman table using a pre-stored Huffman Table.
  • the inverse scan unit 115 performs the inverse scan to generate data in the same order as the moving image 140. That is, the inverse scan unit 115 outputs a value in reverse of the order of scanning in various ways during encoding.
  • a scan direction may be defined according to a distribution of frequency band values. In general, a zig-zag scan method is used, but the scan method may vary according to codecs.
  • Syntax parsing may be performed integrally in the variable length decoding unit 110 or may be performed in any component that processes the bitstream 105 prior to the variable length decoding unit 110. In this case, since syntax parsing is the same as that of the standard applied to the encoder and the decoding period, the syntax parsing is performed only by a predetermined standard corresponding to the standard.
  • the inverse DC / AC predictor 120 determines the direction of the reference block for prediction by using the magnitude of the DCT coefficient in the frequency band.
  • the inverse quantizer 125 inverse quantizes the inversely scanned data. That is, the DC and AC coefficients are reduced by using a quantization parameter (QP) specified during encoding.
  • QP quantization parameter
  • the inverse DCT unit 130 performs an Inverse Discrete Cosine Transform to obtain an actual video pixel value to generate a VOP (Video Object Plane).
  • VOP Video Object Plane
  • the video reconstruction unit 135 reconstructs and outputs a video signal by using the VOP generated by the inverse DCT unit 130.
  • the MPEG-4 encoder 200 generally includes a DCT unit 210, a quantizer 215, a DC / AC predictor 220, a scan unit 230, and a variable length encoder ( 235).
  • Each component included in the encoder 200 performs the inverse function of each component of the corresponding decoder 100, which is obvious to those skilled in the art.
  • the encoder 200 performs encoding by converting a video signal (ie, a digital image pixel value) into a frequency value through a discrete cosine transform, quantization, and the like, and then encoding the information.
  • Variable length encoding that differentiates the bit length according to the frequency is performed and output in the compressed bitstream state.
  • FIG. 3 is a block diagram of an encoder according to an embodiment of the present invention.
  • the encoder according to the present invention further includes an extended bitstream generation and output unit 2410 as compared to the conventional encoder 200 described with reference to FIG. 2.
  • the extended bitstream generation and output unit 2410 may control information (eg, a list of functional units required for decoding the encoded data and a connection relation in the process of generating the conventional bitstream 316 generated by the process up to the front end).
  • the decoder description is generated using input data, syntax information, syntax connection information, etc. of the corresponding functional units.
  • the extended bitstream 305 is generated using the generated decoder description 313 and the conventional bitstream 316 and transmitted to the decoder 300.
  • the functional unit is a configuration for performing unit decoding. That is, the functional units may be organically coupled to each other to form a decoder.
  • each of the components constituting the decoding apparatus of FIG. 1 may be one functional unit.
  • the encoder may include a toolbox (not shown) for storing functional units constituting a decoder capable of decoding the encoded data.
  • variable length encoder 235 herein refers to an arbitrary component (for example, an encoder) that performs encoding in order to generate the conventional bitstream 316 in the encoder. In addition, this does not limit the scope of the present invention.
  • FIG. 3 is a diagram illustrating a case in which an extended bitstream generated by using decoder description information and a conventional bitstream is provided to a decoder.
  • the decoder description may be delivered to the decoder 300 in the form of separate data or bitstream.
  • an encoded decoder description generation and output unit (not shown) is positioned at the rear of the variable length encoding unit 235 to provide the decoder 300 with the encoded decoder description generated independently of the conventional encoding unit. It can be obvious.
  • the decoder description includes functional unit identification information (FUID) of the corresponding functional units.
  • the functional unit identification information (FUID) includes a tool box number (TBN) field indicating a tool box to which a corresponding function part belongs in the tool box unit, and a FU number field indicating unique identification information of the corresponding function part.
  • FIG. 4 is a block diagram of an embodiment of a decoder according to the present invention
  • FIG. 5 is a diagram illustrating an embodiment of a bitstream processing process in the decoder of FIG. 4.
  • the decoder description and the image bitstream illustrated in FIG. 4 may be, for example, information generated and provided by an encoder.
  • the decoder 300 includes a decoder 305 and a separator 310.
  • the decoder 305 includes a BSDL parser 320, a decoder forming unit 330, a toolbox 335, and a decoding solution 340.
  • the BSDL parser 320 interprets syntax information of an image bitstream input from the outside using a BSDL schema input from the separator 310.
  • the video bitstream input to the BSDL parser 320 is data encoded by an arbitrary coding scheme (eg, MPEG-4, AVS, etc.). It will be readily understood by those skilled in the art that the BSDL parser 320 may interpret the BSDL Schema on its own or may be configured by an external algorithm through this specification.
  • the BSDL parser 320 includes a BSDL parser, which is an internal processor that reads the BSDL schema described in XML grammar and redefines the structure of the BSDL parser 320.
  • the rules to redefine using the BSDL schema can vary depending on the method applied by the producer. Therefore, the basic purpose is as follows. First, it is to be able to recognize the information about the length and meaning of the bitstream recorded on the BSDL schema. Second, to read the repetition structure and conditional execution structure defined in the BSDL schema, and to implement the programmatic routine that actually operates by the same repetition or conditional statement. Accordingly, the BSDL parser 320 before being redefined may be defined as a state in which only functions for achieving the above object are implemented. It is a process of redefining the process.
  • the BSDL parser 320 is implemented as a program capable of constructing a flexible data flow under the control of the BSDL interpreter.
  • the BSDL parser 320 is implemented using a programming language such as CAL (Caltrop Actor Language), C, C ++, and Java. Can be.
  • BSDL internal processing unit 2525 and BSDL parser 320 may be implemented without limitation according to the design criteria of the decoder designer.
  • existing BSDL management programs such as BSDL reference software may be applied.
  • BSDL reference software is official software designed for smooth operation of BSDL standardized by MPEG standardization organization. It is obvious that BSDL parser 320 receiving BSDL schema can be more easily implemented using such software resources. .
  • the basic structure of BSDL parser 320 may be designed by various methods chosen by the decoder designer. That is, the decoder designer may autonomously select the application and design of a detailed algorithm to perform the designated function of the BSDL parser 320.
  • the BSDL parser 320 may be redefined by the result of reading the BSDL schema, and the redefined result should be able to collaborate with (eg, communicate with) other components of the decoder 305.
  • the BSDL schema input by the BSDL parser 320 describes the details of the syntax information included in the bitstream. For example, the length of the syntax information, the meaning of the syntax information, the condition of the occurrence of the syntax information, and the repetition are described. The number of occurrences may be included.
  • the length of information means a bit length occupied by specific information on a bitstream, and the meaning of syntax information indicates what information the information has. For example, if a functional unit is requesting information A, it may be necessary to distinguish which information A.
  • an appearance condition may be necessary to avoid reading motion vector information when processing an intra frame, and the number of recurrences may be repeated if the macroblock has six blocks of the same structure. Can be used.
  • the BSDL interpretation processor delivers the decoded result information regarding the details to the BSDL parser 320 so that the BSDL parser 320 reads the information included in the bitstream in the order specified in the BSDL schema. To help them.
  • the BSDL parser 320 converts the contents of the input bitstream into meaningful data by referring to the result information provided from the BSDL interpretation processing unit and provides the same to the decoder forming unit 330 and / or the decoding solution 340.
  • the meaningful data provided by the BSDL parser 320 to the decoder forming unit and / or the decoding solution 340 include, for example, encoded image data of a predetermined macroblock size, AC for intra coded macroblocks.
  • a prediction flag (ACpred_flag), MCBPC (MB type & coded block pattern for chrominance), CBPY (coded block pattern for luminance), and the like may be included.
  • the data providing process may be performed regardless of whether the decoder forming unit 330 or the decoding solution 340 is driven.
  • This embodiment is intended to allow the decoder (decoder) to decode the bitstream using the decoder description, but to implement the decoder description using a BSDL language scheme and an XML-based format interoperable therewith.
  • the decoder description may have an XML format such as BSDL, CALML, BSDL schema may be used in the syntax parsing process, and CALML may be used for connection control between functional units. I can understand.
  • the BSDL language is described in the form of an XML document or XML schema that contains information about the structure and organization of the bitstream.
  • the language is designed so that each can represent one or more video bitstream structures.
  • the decoder can obtain high compatibility with other technologies even if the decoder applies the bitstream technology method that has been verified and used in the conventional MPEG standard. Since the language format and grammar related to BSDL are described in MPEG-B Part 5, the detailed description thereof will be omitted.
  • An example configuration of BSDL schema and connection control information using BSDL and XML is as follows.
  • the configuration format of the BSDL schema and connection control information is not limited thereto.
  • the decoder forming unit 330 may include a portion (eg, a predetermined macroblock) of connection control information received from the separation unit 310 and / or bitstream data received from the BSDL parser 320.
  • a portion eg, a predetermined macroblock
  • ACpred_flag AC prediction flag
  • MBBPC MB type & coded block pattern for chrominance
  • CBPY coded block pattern for luminance
  • the decoder forming unit 330 controls so that some or all of the functional units included in the toolbox 335 are loaded and aligned in the decoding solution 340 using the connection control information.
  • the connection control information may be written in CALML (CAL Markup Language).
  • CALML is an XML format that can describe the decoder configuration of the CAL language (Caltrop Markup Language) method currently being discussed by the MPEG standardization organization.
  • the CAL language consists of a connection between Actor, which is a program object, and each Actor.
  • the structure of the CAL language is expressed in XML format. An example of this has already been presented as an example of representation of BSDL schema and connection control information.
  • the decoder forming unit 330 has a right to access the toolbox 335 composed of a set of various functional units, and sets input and output connections between the functional units provided in the toolbox 335 to decode the result.
  • Configure solution 340 the input / output connection structure and execution order between the functional units are set with reference to the connection control information.
  • some information for identifying the type of the input bitstream may be received from the BSDL parser 320 and may be referred to in the functional unit connection process.
  • the connection structure can be regarded as an independent decoder capable of interpreting and decoding all kinds of video bitstreams intended by the decoder description maker, provided that continuous data input from the outside is assumed. Can be.
  • the completed functional connection structure may be referred to as a decoding solution 340.
  • the toolbox 335 includes a plurality of functional units, each implemented to perform a predetermined process.
  • Each of the functional units may each be implemented in a combination of program codes.
  • Each functional unit included in the toolbox 335 may be subdivided into a plurality of detailed toolboxes divided into sets for each application to which they are applied. For example, it may be subdivided into a first toolbox including MPEG functional units, a second toolbox including functional units other than the MPEG functional units, and the like. Or the first toolbox, which is a set of MPEG-2 functional units, the second toolbox, which is a set of MPEG-4 functional units, and the third toolbox, which is a set of AVS functional units, which is a digital TV compression standard of China. .
  • the toolbox 335 itself may be implemented in plural to have an independent connection relationship with the decoder forming unit 330 and the decoding solution 340.
  • the above-described first toolbox, second toolbox, etc. may be implemented as a toolbox of an independent type.
  • the toolbox 335 is an area including functional units (FUs) implemented to perform respective functions (that is, a predetermined process), and the respective functional units are decoded by the connection control of the decoder forming unit 330.
  • the encoded image data included in the image bitstream 380 is output as decoded image data by loading the solution 340 to form a sequential connection operation relationship.
  • the toolbox 335 may include, for example, a de-blocking filter (DF) function, a VOP reconstructor (VR) function, a frame field reordering (FFR) function, an intra prediction and picture reconstruction (IPR) function, and an IT ( Functional units such as an Inverse Transform (IQ) function, an Inverse Quantization (IQ) function, an Inverse AC Prediction (IAP) function, an Inverse Scan (IS) function, and a DC Reconstruction (DCR) function may be included.
  • DF de-blocking filter
  • VR VOP reconstructor
  • FFR frame field reordering
  • IPR intra prediction and picture reconstruction
  • IT Functional units such as an Inverse Transform (IQ) function, an Inverse Quantization (IQ) function, an Inverse AC Prediction (IAP) function, an Inverse Scan (IS) function, and a DC Reconstruction (DCR) function may be included.
  • IT4x4 function unit, IQ4x4 function unit) and DCR4x4 function unit is characterized in that the block size to be processed is 4x4. This is because MPEG-4 AVC processes data with 4x4 block size, whereas MPEG-1 / 2/4 processes data with 8x8 block size during Transform, Quantization, and Prediction.
  • the tool box 335 may include all the functional units for performing data decoding regardless of the applicable standard, and may add necessary functions in the course of technology development, and may modify existing functions. It is obvious that it can be removed. For example, if an IS4x4 functional unit for processing data in a 4x4 block size is additionally required for the decoding process, the corresponding functional units may be added to the toolbox 335. In addition, a special prediction (SPR) function for performing intra prediction in MPEG-4 AVC may be further added.
  • SPR special prediction
  • Each functional unit provided in the toolbox 335 does not exist independently in each standard, and in the case of a functional unit capable of the same processing regardless of the standard, it is obvious that the functional unit may be integrated into one functional unit.
  • the function of each functional unit is obvious to those skilled in the art and will be described briefly.
  • the DF function is a de-blocking filter of MPEG-4 AVC
  • the VR function is a function that stores the reconstructed pixel values.
  • the FFR function is a function for interlaced mode
  • the IPR function is a function for storing the reconstructed pixel value after intra prediction of MPEG-4 AVC.
  • intra prediction of MPEG-4 AVC may be performed by the SPR function.
  • the IT function unit is a function unit that performs inverse transform of DC values and AC values
  • the IQ function unit is a function unit that inverse quantizes AC values.
  • the IAP function is a function for inverse AC prediction of AC values
  • the IS function is a function for inverse scan of AC values.
  • the DCR function is a function that performs inverse prediction and inverse quantization of DC values.
  • the decoding solution 340 is a result generated by the decoder forming unit 330 and receives bitstream data (or encoded video data having a predetermined macroblock size) separated by syntax information units from the BSDL parser 320. .
  • the input bitstream data may be input through a tangible or intangible data interface for inputting / outputting data.
  • the data interface can be a specific memory buffer for software, a virtual port defining the flow of data, or a parameter on a program.
  • the hardware may be a connection line on a circuit, and may be variously implemented.
  • Data can be input continuously through the interface and continuously (for example, parallel processing) without regard to the performance of a particular function.
  • the decoding solution 340 processes the input data and outputs the decoded image data. As shown in FIG. 5, data may be delivered to each functional unit starting from a data interface, and the functional unit may process the data and deliver the data to subsequent functional units. All of this data flow is processed by the decoder forming unit 330 as predefined.
  • the decoding solution 340 may include a storage unit for storing data (eg, information extracted by syntax parsing of the bitstream) provided from the BSDL parser 320 and processing result data of each functional unit.
  • data eg, information extracted by syntax parsing of the bitstream
  • Each functional unit loaded by the control of the decoder forming unit 330 may perform a designated process using one or more of data provided from the BSDL parser 320 and result data of a previously operated functional unit. In this case, the functional unit that will subsequently perform the process should recognize that the operation of the preceding functional unit is completed. To this end, the decoder forming unit 330 may continuously monitor whether the operation of each functional unit is completed and control whether to start the operation of a subsequent functional unit.
  • the storage unit may be provided in the decoder forming unit 330, and the decoder forming unit 330 is a function unit to perform a current process (eg, parsing syntax of a bitstream (eg, data received from the BSDL parser 320). Information extracted by the above), and the processing result data of each functional unit may be provided to the corresponding functional unit.
  • a current process eg, parsing syntax of a bitstream (eg, data received from the BSDL parser 320).
  • Information extracted by the above and the processing result data of each functional unit may be provided to the corresponding functional unit.
  • the BSDL parser 320 reads the BSDL schema to the point corresponding to the information A. It is recognized that 5 bits of MB type data exists, and 2 bits of CBPY data exist at a point corresponding to information B.
  • the BSDL parser 320 then reads the specified number of bits at each point using the recognized information and delivers the read information to the decoding solution 340 according to the assigned meaning.
  • the decoding solution 340 receives and processes data named MB Type and CBPY from the BSDL parser 320. As described above, the decoding solution 340 is loaded and implemented by the functional units by the connection control of the decoder forming unit 330.
  • the data interface present in the decoding solution 340 accepts data transmitted from the outside, refers to the connection relationship of the functional units previously configured by the connection control information, and transfers the data to the functional units requesting the corresponding data.
  • Each functional unit also performs a decoding process according to a predetermined connection relationship (ie, a connection relationship for data processing).
  • the connection relationship between all data flows and the functional units is based on the details previously configured by the decoder forming unit 330.
  • the output image frame is output to the outside by sequential processing of the respective functional units.
  • a storage unit may be provided in the decoder forming unit 330 or the decoding solution 340. This is because, in receiving data from the BSDL parser 320, the delivery process is seamless and the data provision can be performed in parallel with the decoding process. In addition, each functional unit may read and use necessary data from the storage unit.
  • the BSDL parser 320 may provide corresponding data to the decoder forming unit 330 for decoding processing of the encoded image data so that the decoder forming unit 330 may provide the decoding solution 340, or the BSDL parser ( 320 may provide the data directly to the decoding solution 340.
  • the separator 310 separates the input decoder description 2560 into respective information and inputs the same to the decoder 305.
  • the decoder description 2560 input to the separator 310 may include a BSDL schema 2565 for describing the structure of the bitstream and CALML data 2570 for describing the decoding process of the bitstream.
  • the two types of data described above may be independently described by an XML grammar, and two types of data may be integrated and transmitted for efficient decoder operation.
  • FIG. 6 is a diagram illustrating a decoder description input process according to another embodiment of the present invention.
  • the decoder 300 may further include a description decoder 510.
  • the description decoder 510 may decode the input encoded decoder description 520, generate a decoder description 2560, and provide the decoder description 2560 to the separation unit 310.
  • the amount of data transmitted and received can be reduced.
  • FIG. 7 is a block diagram of another embodiment of a decoder according to the present invention.
  • the decoder description 2560 and the image bitstream are input to the decoder 305.
  • the decoder description 520 and the image bitstream 380 encoded with reference to FIG. 305) has been described.
  • FIG. 7 is a diagram illustrating a configuration of a decoding unit according to another embodiment of the present invention.
  • toolbox 335 may be implemented as one component of the decoder forming unit 330.
  • the decoder forming unit 330 may include not only a connection structure control function between the functional units but also a selection function of the functional units to be used, and the types of decoding solutions 340 that can be implemented through this may be various.
  • FIG. 9 is a diagram showing the configuration of a BSDL parser according to another embodiment of the present invention.
  • the BSDL parser 320 including the BSDL analysis processor has been described above with reference to FIG. 4.
  • the BSDL parser 320 may be predefined and provided from outside the decoder 300 before starting decoding of the bitstream. Therefore, the BSDL analysis processor described above may be omitted.
  • the BSDL parser maker 2610 may be configured by using an existing application program such as BSDL reference software.
  • the BSDL parser may be implemented as one functional unit included in the toolbox, or may be implemented to be included in advance as an independent component in the decoding solution. If the BSDL parser is provided in the toolbox, the decoder forming unit should load and control the BSDL parser to perform a process before the operation of the functional units operating for the bitstream decoding using the connection control information. Similarly, if the BSDL parser is previously included in the decoding solution, the decoder forming unit should control the BSDL parser to perform the process first before starting the process execution of each loaded functional unit.
  • the operation and function of the BSDL parser are the same as described above with reference to the related drawings, a detailed description thereof will be omitted.
  • the subject initially receiving the BSDL schema or / and bitstream may need to be changed to a decoder forming unit and / or a decoding solution.
  • connection control information is not described only with information about the connection relationship between the functional units for performing decoding by one standard, the processing process required for the corresponding functional unit, and the like. It is obvious that information may be described.
  • connection control information will be defined such that each frame having a different encoding method can be functionally combined and operated in accordance with each standard included in the toolbox 335. Do.
  • the description of the configuration that performs the same or extremely similar functions as the above-described embodiment will be omitted by the same description as the same reference numerals and reference numerals.
  • the toolbox 335, the decoder forming unit 330, and the decoding solution 330 illustrated in FIG. 11 are basically the same as the above-described configuration.
  • FIG. 10 is a block diagram of still another embodiment of a decoder according to the present invention
  • FIG. 11 is a diagram schematically showing an embodiment of a decoder of FIG. 10.
  • the decoder description input in the described embodiment is a table-based decoder description (hereinafter, referred to as a Compact Decoder Description Language (CDDL) -based decoder description), which is compressed in binary form and delivered to the decoder.
  • CDDL Compact Decoder Description Language
  • the decoder may reconfigure the decoder by combining necessary functional units according to the format of the input bitstream. Therefore, the decoder according to the present invention can decode the bitstream by forming a decoder corresponding to the input bitstream even if a bitstream encoded in any format is input.
  • a decoder according to the present invention will be described in detail with reference to the accompanying drawings.
  • the decoder description is provided with the bitstream to the decoder.
  • the decoder description may be provided to the decoder in the form of a bitstream 305 integrated with the bitstream, or may be provided to the decoder in the form of independent data.
  • the provision of the decoder description may be omitted.
  • the case will be described based on the case where the data is included in the bitstream and provided to the decoder.
  • the decoder includes a separator 310 and a decoder 320. At least one of the components of the illustrated decoder (eg, the separator 310, the decoder 320 itself, or one or more components included in the decoder 320, etc.) performs a function to be described below. It is apparent that the software program may be implemented as a software program (or a combination of program codes) implemented to.
  • the separator 310 separates the input bitstream into a compressed decoder description and encoded video data, and inputs them to the decoder 320.
  • the separation unit 310 may input the compressed decoder description 313 to the reconstruction unit 410, and the encoded video data 316 may be input to the decoding execution unit 450. As described above, when the compressed decoder description and the encoded video data are input as independent data, the separation unit 310 may be omitted. In addition, the encoded video data may be data in the same or similar format as the bitstream 105 of FIG. 1.
  • the decoder 320 decodes the encoded video data 316 using the compressed decoder description 313 input from the separator 310 and outputs the decoded image data 390.
  • the configuration of the decoder 320 will be described in detail with reference to FIG. 11.
  • the decoder 1320 includes a decompression unit 1410, a decoder description analyzer 1420, a toolbox 335, an ADM generator 1440, and a decoder execution unit 1450. do.
  • the decoding execution unit 1450 includes a decoder forming unit 330 and a decoding solution 330.
  • the decompressor 1410 decompresses the compressed decoder description 313 input from the separator 1310 according to a predetermined decompression method and outputs the decoded decoder description 313 to the decoder description analyzer 420. More specifically, the decoder description is compressed in a binary format according to a predetermined rule, and the decompression unit decodes the compressed decoder description in binary form to restore and output the corresponding CDDL-based decoder description.
  • the decoder description interpreter 1420 converts the restored CDDL-based decoder description into an XML-based decoder description described in XML format and outputs it to the ADM generator 1440.
  • the decoder description analyzer 420 may be omitted, and the restorer 410 may directly convert the input binary data into an XML-based decoder description and output the same.
  • the ADM generator 440 generates an abstract decoding model (ADM) including a plurality of functional unit information having one or more input / output ports and connection information between the ports.
  • ADM abstract decoding model
  • the ADM generator 440 generates an ADM capable of decoding the bitstream by combining the received functional units according to the context control information, the connection control information, and the parsing control information.
  • the decoding execution unit 450 may decode the input image using the corresponding functional units stored in the toolbox through the decoder forming unit 330 and the decoding solution 340 as described above. In addition, the decoding execution unit 450 may directly receive the XML-based decoder description and decode the input image.
  • DD CDDL based decoder description
  • CDDL-based Decoder Description is divided into a FU networking table group describing FU networking, which is a connection between FUs required to configure an ADM or / and decoding solution, and a syntax parsing table group for syntax parsing.
  • the FU networking table group includes a virtual network table (VNT), a functional unit table (FUIT), a network connection table (NCT), a parameter table (PT), and a representation. It includes a table (Expression Table, ET) and a type table (Type Table, TT).
  • the syntax parsing table group includes a control signal and context information table (CSCIT), a syntax element table (SET), a syntax rule table (SRT), and a default value table (DVT).
  • CSCIT control signal and context information table
  • SET syntax element table
  • SRT syntax rule table
  • DVD default value table
  • FIG. 12 is a diagram illustrating the structure of an FU networking table according to an embodiment of the present invention.
  • the FU networking table used in the CDDL-based decoder description (DD) is described in a binary representation bitstream according to the structure shown in FIG. 12.
  • Each table describes a Table Start Code and a unique Table Code for identifying the table.
  • the contents of the actual table are binarized to form a bitstream.
  • a table end code is added.
  • Table Start Code is a fixed value and consists of 24-bit binary number (111111111111111111110)
  • Table End Code is a fixed value and consists of 24-bit binary number (111111111111111111111111)
  • Table Code Is composed of 4-bit binary number as shown in Table 1 below to identify unique table number.
  • FIG. 13 is a diagram showing the structure of a VNT table according to an embodiment of the present invention.
  • the VNT table includes FUID, VN name, INPUT ports, OUTPUT Ports, and QID name fields.
  • a network which is a set of functional units, may have the same structure but different data used for input or output.
  • a basic template object using the inheritance concept is created and this template is used as a parent. Constructs a form that creates objects (children, inherited objects).
  • the VNT describes information corresponding to a basic template.
  • the FUID uses an index number indicating the number of items in the toolbox since the function FU may or may not be new in the toolbox.
  • the FUID flag is set to 1 if it exists in the toolbox and to 0 if it does not exist. If the FUID flag is set to 0, the FUID is skipped without being described.
  • VN name represents the name of the functional unit (FU).
  • the string length of the name is first described (8 bits), and then each alphabetic character is recorded one by one.
  • Each alphabetic letter may be represented by an ASCII code.
  • Version represents the version of the functional unit (FU).
  • the version flag is set to 1 if there is a version of the feature or 0 if it does not exist.
  • string length of the version is described first (8 bits), and then each alphabetic character is recorded one by one.
  • Each alphabetic letter may be represented by an ASCII code.
  • the QID name represents a character string used as an appropriate identifier of the functional unit FU. Since not all functional parts have a QID name, one bit specifies whether a QID name exists. If the flag is set to 0, the QID is skipped without being described. If the flag is set to 1, the length of the QID name is described as 8 bits. Then record the QID names one by one in English. Each alphabetic letter may be represented by an ASCII code.
  • the VNT table input into the binary bitstream having the above-described structure is converted into an XML-based decoder description by the reconstruction unit 1410 and / or the decoder description analyzer 1420 according to a predetermined rule. That is, a table abbreviation (English letter) representing a table is used, and the table contents begin with ' ⁇ ' and end with ' ⁇ '.
  • the fields in each table are separated by ',', one row begins with '(' and ends with ')', and if one field has multiple values, it begins with ' ⁇ ' and then with ' ⁇ '. And the representation of the character is written between the '"' marks.
  • the VNT table is expressed in the following text format.
  • VNT table for MPEG-4 SP that supports the XML format is as follows.
  • FIG. 14 is a diagram showing the structure of a FUIT table according to an embodiment of the present invention.
  • the FUIT table includes a VNT index, a Parent VNT index, Parameter indices, and a QID name field.
  • main information is stored to create objects used as a network actually needed based on the basic template, which is VNT information.
  • the network actually needed can be expressed as a sub-object (descendant, inherited object, instance) derived from the base template.
  • the VNT index is an index of the VNT table to indicate one functional unit.
  • the Parent VNT index represents a basic template that is required by a child instance. Index to refer to in the VNT table. If the flag is set to 0, the VNT index is skipped without being described.
  • the PT indices are index lists indicating several parameters of one functional unit. There may be no parameters or multiple parameters. The presence or absence of a parameter is indicated by a flag, and then a parameter table (PT) index containing parameter information is described next. Set to 1 if the description of all parameter information is complete, otherwise set to 0 if there is a parameter table index to record further. After that, the remaining parameter table index is recorded in the same manner.
  • PT parameter table
  • the QID name represents a string used as an appropriate identifier of the functional unit FU. Since not all functional parts have a QID name, one bit specifies whether a QID name exists. If the flag is set to 0, the QID is skipped without being described. If the flag is set to 1, the length of the QID name is described as 8 bits. Then record the QID names one by one in English. Each alphabetic letter may be represented by an ASCII code.
  • the FUIT table is expressed in the following text format.
  • VNT Index [Parent VNT Index], ⁇ PT Indexes ⁇ , [QID name]
  • 15 is a diagram showing the structure of a PT table according to an embodiment of the present invention.
  • the PT table includes a Parameter name, Parent VNT index, ET index, and TT index fields.
  • the parameter is not a syntax generated from the bitstream, but is used to generate data required when the functional unit is configured. Since parameters are not Syntax, they cannot be transmitted through the port that transmits data. Parameter can be transferred from the network, which is a set of functional units, to the lower network included in the network. Information about the parameter of one functional unit is described as PT index in FUIT. PT has creation information of each parameter.
  • each parameter has its name by default. Describes the length of the parameter name as 8 bits. Then write the parameter names alphabetically one by one. Each English letter can be represented by an ASCII code.
  • the parameter may be used in an upper Network functional unit that is a basic template or may be used in a lower functional unit object created through the basic template.
  • the flag is set to 1 and the index for referencing in the VNT table is described. Otherwise, when used in a sub-instance, the flag is set to 0 and the VNT table index is not described.
  • an expression representing the format of a parameter may be made.
  • the flag is set to 1 if there is an expression for the parameter and 0 if it does not exist. If the flag is set to 0, the ET index is skipped without being described. For expressions, refer to the index of the ET.
  • the TT index indicates the type of parameter (type of parameter). If a flag indicating whether a parameter type exists is set to 1, the TT index is described, otherwise the TT index is skipped without being described. For information about types, refer to the index of TT.
  • the PT table is expressed in the following text format.
  • An embodiment of the PT table for MPEG-4 SP that supports the XML format is as follows.
  • 16 is a diagram showing the structure of an NCT table according to an embodiment of the present invention.
  • the NCT table includes an Src FUIT index, a Dst FUIT index, an Src port name, a Dst port name, an Attribute name, an Attribute value, and an ET Index field.
  • NCT has information about Port, which is a path through which data can be transmitted between functional units.
  • the Input Ports and Output Ports responsible for each input and output can have unique names.
  • the Src FUIT index must indicate where the data comes from when it is transferred from one functional unit to another.
  • the functional unit at which data starts to be transmitted can be referenced as an index of the FUIT. If the beginning of the bitstream is not the functional unit itself, such as an input file file, it can be represented by a '-'. Therefore, the flag indicates whether or not the index refers to the FUIT and records the FUIT index. If the flag is set to 0, the FUIT index is skipped without being described.
  • the Dst FUIT index represents a functional unit to which data arrives and represents a FUIT index of the functional unit to which data arrives. If the beginning of the bitstream is not the functional unit itself, such as an output file, it can be represented by a '-'. Therefore, the flag indicates whether or not the index refers to the FUIT and records the FUIT index. If the flag is set to 0, the FUIT index is skipped without being described.
  • Src port name and Dst port name indicate the name of the port to which data is transmitted.
  • the output port of the functional unit becomes the start port of data transfer, and the input port of the other functional unit becomes the port to which data arrives.
  • the names of the output port and the input port to which data is sent may be the same. Therefore, the same flag indicating whether two transport port names are the same or not is described. If the same flag is set to 0, the Dst port name is not described.
  • the string length of the name is first described (8 bits), and then each alphabetic character is recorded one by one. Each alphabetic letter may be represented by an ASCII code.
  • Attribute name may be added to the connection attribute information in the connection relationship of the network. If the name of such attribute information exists, the flag is set to 1, and if not present, it is set to 0. If the flag is set to 0 the attribute name is passed without description.
  • the name of the connection attribute information is binarized and recorded in the bitstream, the string length of the name is first described (8 bits), and then each English letter is recorded one by one. Each alphabetic letter may be represented by an ASCII code.
  • the attribute value may be described when the name of the connection attribute information exists in the network connection relationship. If the flag is set to 0, no attribute value is passed. Therefore, the presence or absence of an attribute value is indicated by flag and the length of the string representing the value is described by 8 bits. After that, record one letter each. Each alphabetic letter may be represented by an ASCII code.
  • the ET index can be an additional expression of the network connection. At this time, the flag is set to 1 if there is additional expression and 0 if not. If the flag is set to 0, the ET index is skipped without being described. For expressions, refer to the index of the ET.
  • the NCT table is expressed in the following text format.
  • NCT table for MPEG-4 SP that supports the XML format is as follows.
  • 17 is a diagram illustrating the structure of an ET table according to an embodiment of the present invention.
  • the ET table includes Kind, Literal kind, Literal value, Variable name, Operator, Child ET index, and Args ET index fields.
  • the ET table is not information obtained from the bitstream, but a table referenced for the expression of syntax. It is written to represent some equation or information for presentation. This table shows the types and values of the representation techniques used in the representation and the names of the variables.
  • Kind means the kind represented by the expression. This field is described by three bits in the bitstream. There are five kinds of expressions as shown in the table below.
  • Literal kind indicates the kind that Literal can have only when the value of the previous Kind field is set to Literal. If the flag is set to 0, the Literal kind is skipped without being described.
  • Literal kind has the following kind of code.
  • Literal value indicates the value of Literal when the value of the previous Kind field is set to Literal. If the flag is set to 0, the Literal Value is skipped without being described. If the flag is set to 1, the length of the Literal Value is described as 8 bits. Then record the Literal Values one by one in English. Each alphabetic letter may be represented by an ASCII code.
  • Variable name represents the name of the variable when the value of the previous Kind field is set to Var. If the flag is set to 0, the variable name is passed without being described. When the flag is set to 1, the length of the variable name is described as 8 bits. Then record the variable names one by one in English. Each alphabetic letter may be represented by an ASCII code.
  • Operator represents an operator when an expression represents an operation. If the flag is set to 0, the operator is skipped without being described. When the flag is set to 1, the length of the operator is described as 8 bits. Then record Operators one by one in English. Each alphabetic letter may be represented by an ASCII code.
  • the Child ET index can describe a subexpression if the expression contains another expression. If the flag is set to 0, the ET index for the subexpression is skipped without being described. If the flag is set to 1, the ET index representing the subexpression is recorded as 8 bits.
  • Args ET index can represent the description of an argument as an ET index if the expression contains an argument. If the flag is set to 0, the ET index for representing the argument is skipped without being described. If the flag is set to 1, the ET index for representing the argument is recorded as 8 bits.
  • the ET table is expressed in the following XML text format.
  • An embodiment of the ET table for MPEG-4 SP that supports the XML format is as follows.
  • the Type Table (TT) includes a Type Name, Entry Name, Expr index, and Type index fields.
  • the CSCIT describes detailed information on element information (eg, CSCI), in which the parsing function has result information of a process using SET and SRT. That is, the CSCIT is processed from the conventional bitstream and stored in the CSCI storage, and has information about all meaningful data (ie element information) to be used by the decoding functions.
  • the CSCIT is a unique number of the corresponding element information, which is an index (C), a flag, an element name of the element information, and an attribute for specifying a data structural characteristic of the element information (for example, Storage space size of the element information, whether the corresponding element information is an array type, etc.), Global / Local indicating whether the corresponding element information is used only in the syntax parsing process or the overall decoding process.
  • CSCIT is a description manner such as a textual description or a binary description (in the form of a bit-converted binary code), but the minimum data required during the partial decoder description may be described in a similar script language.
  • the SET is a decoder description constructed by information on the syntaxes of the input conventional bitstream.
  • the SET includes an index, an element name, a parameter, and a process by SET-PROC information for each syntax.
  • the index is a delimiter (S) that distinguishes each syntax used in the SRT.
  • the element name is a name of a syntax and may be named according to the meaning or role of the syntax.
  • the parameter is provided as an argument value when the parsing process described in the SRT calls the SET's parsing algorithm, and this parameter value is a buffer for storing data derived from a fixed constant or bitstream, or data derived from the parsing process. It may be an identifier of a space (eg, CSCI memory).
  • the argument values passed through the parameters are distinguished through the index (P), and each argument value is element information (ie, CSCI information (C)), which can be used to store acquired data, and the corresponding element information is processed later. If necessary as data in the process, the corresponding element information may be read using the parameter index P again.
  • the parameter may indicate a constant value as well as CSCI information (C) as specified by the SRT.
  • the SET-process describes the process of receiving each bitstream syntax and what processing procedure to generate element information, which is output data.
  • the SET may be described in a description manner such as a textual description or a binary description (in the form of a bit-converted binary code), and the minimum data required in the partial decoder description may be described in a similar script language.
  • the SRT represents connection information between each syntax in the conventional bitstream. That is, the SRT has information instructing to call each syntax and move to the next syntax.
  • the parsing function reads the conventional bitstream using SRT or defines the order in which element information is stored and / or updated in the CSCI storage.
  • SRT includes index (R), parameter (P), and rule information.
  • the index R distinguishes each connection information rule. Since the index S of the syntax designates a syntax to be processed in a specific connection index, the parsing function (or functional units that perform syntax parsing) performs a process specified for the syntax using SET. Parameters are provided as argument values when the parsing process described in the SRT is hierarchically invoked by another SRT's parsing algorithm, which is calculated from a fixed constant or bitstream, or It may be an identifier of a buffer space (eg, CSCI memory) for storing derived data.
  • a buffer space eg, CSCI memory
  • the parameter values passed through the parameters are distinguished through the index (P), and each parameter value can be used to store the acquired data.Then, if the element information is needed as data in the process, the parameter index (P) is again used.
  • the corresponding element information may be read by using the corresponding element information.
  • the parameter may indicate a constant value as well as CSCI information (C) as specified by the SRT.
  • the rule information describes a process in which syntax parsing is handled. Control syntax such as branching and repetition may be used, and syntax parsing may be performed by calling another SRT or SET element in a lower layer.
  • the input data represents a list of element information to be used for determining a condition for connection control in the corresponding connection index.
  • the number of branches is the number of cases that can be linked to subsequent syntax, and represents the total number of branch paths that the connection index has.
  • Branch information is a condition determination algorithm for determining the number of branch information necessary for the number of branches (# 1, # 2, # 3, etc.), and which connection index to process next. The branch information can directly determine which contents are read in what order. If the number of branches is 1, no input data exists, and the process proceeds immediately to process the connection index specified in the branch information. However, if the number of branches is 2 or more, condition determination is performed (consisting of the next connection information R after the conditional statement) and proceeds to process the corresponding connection index.
  • the SRT be described in a description manner such as a textual description or a binary description (in the form of a bit-converted binary code), but the minimum data required in the partial decoder description may be described in a similar script language.
  • DVT is a decoder description in which Huffman table information used in each encoder / decoder is recorded.
  • Huffman table information used in each encoder / decoder is recorded.
  • a Huffman coding method is mainly used, and the information used in this case is a Huffman table.
  • Huffman table information to be used in the corresponding decoder must be provided for each decoding. Therefore, Huffman table information corresponding to each syntax is included in syntax parsing in the decoding description according to the present invention.
  • the transmission of the DVT may be omitted or only the codec number Codec # 1120 and the profile and level # 1130 may be included. There will be.
  • the DVT includes a name for each Huffman table, an actual value compressed and output by Huffman coding, and a code value used when the compressed actual value is stored in a conventional bitstream. For example, if the MCBPC value is compressed to obtain an actual value of 3, a code value is added to the conventional bitstream 316 by a Huffman table mapping operation (for example, the PROCESS portion of the SET). (code) 011 is recorded. As another example, the VLD [1] is recorded in the process portion of the index S77 of the above-described SET to call a function called VLD.
  • the function reads the conventional bitstream 316 for a predetermined length (fixed or variable length) by this function to obtain a code value, and then the corresponding actual value by Huffman table mapping. Can be obtained.
  • the Huffman table used at this time is [1], that is, the first table, CBPY.
  • DVT can be described in a description manner such as a textual description or a binary description (in the form of a bit-converted binary code), but the minimum data required in the decoder description may be described in a similar script language.
  • the DVT may be textual description as follows.
  • DVT ⁇ ((0,1), (1,001), (2,010), (3,011), (4,0001), (5,000001), (6,000010), (7,000011), (8,000000001) , (9, NULL)) ((0,0011), (1,00101), (2,00100), (3,1001), (4,00011), (5,0111), (6,000010), (7,1011), (8,00010), (9,000011), (10,0101), (11,1010), (12,0100), (13,1000), (14,0110), (15 , (11), (16,000000), (17,000001), (18, NULL)) ((0,011), (1,11), (2,10), (3,010), (4,001), (5, 0001), (6,00001), (7,000001), (8,0000001), (9,00000001), (10,000000001), (11,0000000001), (12,00000000001), (13, NULL) ) ((0,11), (1,10), (2,01), (3,001), (4,0001), (5,00001), (6,000001), (7,000000
  • the DVT may be binary described as follows.
  • the decoder basically processes the decoding process using XML-based, that is, BSDL-based decoder description, while the CDDL-based decoder compressed in binary form, as described above through the second embodiment. Even when a description is input, it can be processed by converting it to an XML-based (BSDL-based) decoder description.
  • DD based on BSDL has high readability, it is considered a suitable method for developers who want to try various implementations based on DD.
  • the XML-based BSDL format does not have its own compression function, it may be inefficient in terms of capacity in an environment requiring real-time transmission of DD. Therefore, by expressing BSDL using a CDDL format that expresses the same processing process with a smaller capacity as in the second embodiment of the present invention described above, it is possible to derive the compression effect required by the real-time environment.
  • bitstream syntax list can be used as an intermediate form. This list is provided in the same or similar form as that presented in the standard specification document.
  • the video bitstream is embedded according to the specification, it shows the details and the bit length of various syntax information. It is clear that all types of DD forms are written in compliance with the standards defined in the standard, so that it is easier to convert between different types of DD specifications by extracting information in the form of standard documents.
  • the following simple rules can be applied to the CDDL-based DD.
  • Lower SRT element call (Rn ();): Defined as a lower syntax element set call on the bitstream.
  • Branching and Looping Statements Keep the condition in the list.
  • A. READ command Determined as a syntax element with a fixed bit length. The length of the bit read is as defined in the element or in the higher SRT instruction that calls the element. If the Byte-align parameter is used, the syntax is regarded as start / end code.
  • VLD Human / Golomb
  • All CSCI elements are considered to be space for storing individual syntax information appearing on the bitstream.
  • CDDL syntax shown in Table 4 below may be converted into an XML syntax as follows.
  • each decoder description is not described only with information on connection relations of functional units for performing decoding by one standard, processing processes required for the corresponding functional unit, and the like. It is obvious that the information may be described.
  • the decoder description information included in the decoder description for decoding the encoded video data may be operated by combining the functional units according to each standard included in the tool box 510 for each frame having a different encoding method. It is obvious that it will be implemented.
  • 19 is an exemplary view showing a detailed configuration of a toolbox according to an embodiment of the present invention.
  • the toolbox according to the present invention may be configured as a set of a plurality of toolboxes separately separated to store / manage a plurality of functional units according to types.
  • the set of the plurality of tool boxes will be referred to as a tool box unit. That is, the functional units are divided and stored / managed into a plurality of toolboxes in the toolbox unit according to their types, and each toolbox is divided into toolbox numbers (TBNs) and identified and managed. That is, the toolbox number is a kind of toolbox identification information.
  • the toolbox unit includes an MPEG video toolbox for storing functional units related to MPEG video decoding; An MPEG audio toolbox that stores functional parts related to MPEG audio decoding; An MPEG graphics toolbox for storing functional parts related to MPEG graphic decoding; And a functional unit related to multimedia decryption, such as a system toolbox storing functional units related to system decryption, and further comprising a user-defined toolbox storing user-defined customized FUs.
  • a functional unit related to multimedia decryption such as a system toolbox storing functional units related to system decryption, and further comprising a user-defined toolbox storing user-defined customized FUs.
  • a functional unit related to multimedia decryption such as a system toolbox storing functional units related to system decryption, and further comprising a user-defined toolbox storing user-defined customized FUs.
  • a functional unit related to multimedia decryption such as a system toolbox storing functional units related to system decryption, and further
  • the toolbox number of the toolbox may be defined as shown in Table 5 below.
  • the toolbox unit and the toolbox may be logically divided into one storage means, or may be physically divided into a plurality of storage means.
  • FIG. 20 is an exemplary diagram illustrating functional unit identification information (FUID) according to an embodiment of the present invention.
  • the functional unit identification information (FUID) includes a tool box number (TBN) field indicating a toolbox to which the corresponding function unit belongs, and a FU number field indicating unique identification information of the corresponding function unit. It is configured by.
  • the toolbox number field may be implemented with 4 bits, and the FU number field may be implemented with 28 bits.
  • the FU number field By implementing the FU number field with 28 bits, 268,435,456 functions can be stored, identified and used in one toolbox.
  • the FUID may be included in the decoder description through a method such as applied to the FUID field in the VNT mentioned above.
  • 21 is a conceptual diagram illustrating a functional unit classification / identification mechanism according to the present invention.
  • the BSDL parser or decoder description analyzer of the decoder interprets the received decoder description to extract functional unit identification information (FUID) 1950, and the decoder forming unit of the functional unit identification information (FUID) 1950. Reading the TBN and FU numbers of the functions necessary to combine the decoders from them, and requesting the corresponding toolbox corresponding to the read TBN and FU numbers, the requested functions are loaded and connected to the decoding solution to form a recombinant decoder. To decode the input data.
  • the functional unit having the FU number 69 is requested and loaded.
  • the decoding apparatus requires a bitstream syntax parser for reading various types of bitstreams and an FU for decoding respective pieces of information in order to decode bitstreams based on various codecs.
  • the decoding apparatus can process the bitstream simply by sending additional information such as a decoder description. have.
  • additional information such as a decoder description. have.
  • a FU corresponding to a specific function used to encode a video in the encoding apparatus does not exist in the decoding apparatus, it is impossible to decode the corresponding bitstream. This problem can occur especially when using a customized codec that is not restricted by MPEG.
  • the present invention defines a mechanism by which the FU is delivered to the decoding apparatus.
  • the FU is delivered to the decoding apparatus.
  • another embodiment of transmitting an FU required for decoding data encoded by the encoding apparatus, receiving the same from the decoding apparatus, and processing the same will be described.
  • FIG. 22 is an encoding apparatus according to another embodiment of the present invention
  • FIG. 23 is an exemplary diagram showing a packet configuration of a bitstream transmitted according to another embodiment of the present invention.
  • the decoding apparatus includes an encoder 2110 which encodes video, audio, multimedia data, and the like to be encoded to generate encoded data.
  • a decoder description generation unit 2120 for generating a decoder description describing functional units (FUs) constituting a decoder for decoding the encoded data and a connection relation thereof, and receiving the decoder description to receive the encoded data.
  • FUs functional units
  • a FU list generator 2140 for generating and outputting a FU list which is information on functional units (FUs) necessary for decoding, a toolbox 2130 for storing the functional units (FU), and receiving the encoded data
  • a packetizer for receiving a decoder description, an FU list, and a function unit (FU) corresponding to the received encoded data and packetizing the packet is output.
  • an etizing unit 2150 a system bitstream generator 2160 for integrating and generating packets output from the packetizer into a system bitstream, and a transmitter (not shown) for transmitting the system bitstream. .
  • the encoder 2110 may be a non-standard encoder newly defined by a user as well as a conventional standard encoder such as a luxury unit described with reference to FIG. 2.
  • Decoder description generation unit 2120 is a functional unit identification information (FUID) list and the connection relationship between the functional units, input data of the functional units, syntax information, syntax connection to the functional units necessary to configure a decoder capable of decoding the encoded data Information and the like, and the functional unit identification information (FUID) includes a tool box number (TBN) field indicating a tool box to which the corresponding function unit belongs in the toolbox unit and a FU number field indicating unique identification information of the corresponding function unit. It is configured by.
  • TBN tool box number
  • the toolbox 2130 is composed of a toolbox unit which is a set of a plurality of separate toolboxes for storing / managing a plurality of functional units according to their types. Are stored and managed in a plurality of toolboxes, each toolbox (Toolbox) is divided into a tool box number (TBN), identified and managed.
  • TBN tool box number
  • the toolbox number is a kind of toolbox identification information.
  • the packetizer 2150 receives the encoded data, decoder descriptions and FUs corresponding thereto, and packetizes the packet by giving a separate packet ID (PID) to each.
  • PID packet ID
  • a packet generated by the packetizer 2150 includes an encoded data packet 3200, a decoder description packet 3300, an FU list packet 3400, and a function packet 3510, 3520, 3530,... It includes.
  • the packetizer 2150 packetizes the input encoded data into a predetermined packet ID (PID 010) into an encoded packet 3200, and assigns the input decoder description to a predetermined packet ID (PID 020). Packetize into decoder description packet 3300.
  • the FU may be implemented by a program syntax.
  • the FU is separated from the FU list header and transmitted as separate data in consideration of the data capacity of the FU.
  • each packet is assigned to the FUs 3510, 3520, and 3530 corresponding to the encoded data, respectively, and packetized, and the FU list information is separately packetized.
  • 100 is assigned to packetize the FU list packet 3400.
  • the FU list packet includes packet ID and functional unit identification information (FUID) of the packets of the FUs constituting the decoder capable of decoding the encoded data.
  • the system bitstream generator 2160 receives the packets generated by the packetizer and generates the system bitstream 3600 into a system bitstream 3600 which is a bitstream for transmission.
  • the bitstream of this embodiment which further includes FU information (FU list packet and FU packet), is referred to as a system bitstream 3600 to distinguish it from the above-described extension bitstream.
  • Packet ID Packet ID
  • Selective access to different types of packets existing in a broadcast bitstream based on PID is a widely used method for discriminating a plurality of channels and distinguishing each voice stream in multi-voice broadcasting.
  • the receiving side can easily derive a list of FUs not owned by comparing the FU currently equipped in its decoder with the transmitted FU list. have.
  • 24 is an exemplary diagram conceptually illustrating a process of transmitting and receiving data in a broadcast environment according to another embodiment of the present invention.
  • the transmitting apparatus 2100 including the encoding apparatus according to another embodiment of the present invention Encoded data, decoder description, functional unit (FU), and other auxiliary data encoding video, audio, and multimedia data using a receiving device 2200 including a decoding device according to another embodiment of the present invention. Is transmitted in the broadcast bitstream.
  • the FU may be periodically transmitted as part of the broadcast bitstream.
  • the reason why the FU is periodically transmitted is because it is unclear at which point in the video bitstream the broadcast receiver will connect to the broadcast service at any time. .
  • 25 is a block diagram of a decoding apparatus according to another embodiment of the present invention.
  • a decoding apparatus may include a packet decomposing unit 2210, a decoder forming unit 2220, a decoding solution 2230, and a functional unit comparing unit 2240. And toolbox 2250.
  • the packet processor 2210 receives the received bitstream and divides the received bitstream into packet types, and outputs coded data, a decoder description, an FU list, and an FU.
  • the functional unit comparator 2240 receives the FU list from the packet processor 2210, extracts the FU identification information of the FU list, compares the FU identification information of the FUs stored in the toolbox 2250, and receives a new FU. Judge. As a result of the determination, when a new FU is received, the corresponding FU is received from the packet processor 2210 and transmitted to the toolbox so that the toolbox 2250 stores the new FU. Meanwhile, the functional unit comparator 2240 may minimize the additional processing time by ignoring the FUs already stored in the toolbox without additional processing.
  • the decoder forming unit 2220 receives and interprets the decoder description, and loads and combines the FUs necessary to decode the encoded data from the toolbox 2250 to the decoding solution 2230 to form a recombinant decoder.
  • the decoding solution 2230 receives the encoded data, decodes the encoded data through the recombination decoder, and outputs the decoded data.
  • the above-described decoding apparatus may be a software system driven through a program memory in an environment such as a PC, or may be a hardware or firmware system based on a fixed chipset as in the case of STB / PVR / DVD-P.
  • the system under the environment may have a toolbox 2250 of an adaptive tool library structure for reading additionally transmitted FUs from the outside and storing them temporarily or at all times. That is, the toolbox 2250 may be an extra hard disk / memory space for storing and managing an external FU in a software environment, and may be implemented by a variable memory device such as a separate storage medium, a removable ROM, or a RAM in a hardware environment. Can be.
  • the encoding side may receive an FU required to decode the received data, and the encoding side may use a non-standard FU and a user-defined FU separately defined by a user, and provide the decoding side to the decoding side.
  • FIG. 26 is an exemplary diagram conceptually illustrating a process of transmitting and receiving FU and encoded data in a bidirectional communication environment according to another embodiment of the present invention.
  • an encoding system transmits a transport bitstream (S4310).
  • the transport bitstream includes encoded data obtained by encoding video, audio or multimedia data, and a decoder description and an FU list of the encoded data.
  • the decoding system 4200 receives the transport bitstream, separately extracts the encoded data, the decoder description, and the FU list from the received transport bitstream, and compares the FU list with the FUs stored in the toolbox ( S4320), it is determined whether there is a new FU (S4330).
  • the decoder is combined using the received decoder description and the FUs stored in the toolbox, and the received encoded data is decoded (S4360).
  • the FU request signal for requesting the transmission of the new FU to the encoding system is transmitted (S4340).
  • the encoding system receiving the FU request signal transmits FU transmission data including the requested FUs in response to the received FU request signal (S4350), and the decoding system receives the FU transmission data and receives the requested FU.
  • the decoder is combined using the received decoder description and the FUs stored in the toolbox, and the received encoded data is decoded (S4360).
  • This embodiment is applicable to an environment capable of transmitting / receiving such as IPTV.
  • the receiver can request delivery of a specific FU to the sender based on the FU list received.
  • FIG. 27 is a diagram illustrating an embodiment of the encoding system of FIG. 26.
  • the encoding system includes an encoder 2110, a decoder description generator 2120, a toolbox 2130, an FU list generator 2140, a packetizer 2150, and a transport bitstream generator. 4160, the FU transmission data generator 4170, the communication unit 4180, and the FU request signal processor 4190 may be configured.
  • the packetizer 2150 is configured to packetize and output the input data by giving a unique packet ID, and its basic function is the same as that of the packetizer 2150 described above with reference to FIG. However, the specific function according to the present embodiment will be described.
  • the packetizer 2150 may generate unique packet IDs from the encoded data received from the encoder 2110, the decoder description received from the decoder description generator 2120, and the FU list received from the FU list generator 2140. And packetize and output the packet to the transmission bitstream generator 4160.
  • the packetizer 2150 packetizes the functional unit FU received from the toolbox and outputs the packetized function unit FU to the FU transmission data generator 4170.
  • the packetizer 2150 assigns a packet ID to each of the FUs included in the FU list in the process of generating the FU list packet and includes the assigned packet ID information in the FU list packet by matching the FU identification information.
  • a packet ID assigned in the process of generating a FU list packet is assigned to the FU received from the toolbox.
  • the transport bitstream generator 4160 generates and outputs a transport bitstream by integrating the packets received from the packetizer 4150_ (ie, the transport bitstream generator 4160) from the packetizer 2150.
  • the encoded data packet, the decoder description packet, and the FU list packet are input and integrated to generate and output a transport bitstream (4160.)
  • the transport bitstream may be encoded data packet, decoder description packet, and FU list packet as necessary. Combinations of any one or more of the above.
  • the FU transmission data generator 4170 converts, generates, and outputs a functional unit FU received from the packetizer into FU transmission data, which is a format for transmitting through a wired or wireless communication network.
  • the communication unit 4180 is a configuration for transmitting and receiving data with an external communication network. Specifically, the communication unit 4180 receives and transmits the transmission bitstream or FU transmission data, and outputs the received FU request signal to the FU request signal processing unit 4190. do.
  • the FU request signal processor 4190 interprets the input FU request signal so that the FU requested in the FU request signal is output from the toolbox 2130_ to the packetizer 2150.
  • FIG. 28 is a diagram illustrating an embodiment of the decoding system of FIG. 26.
  • the decoding system includes a communication unit 4260, a packet processing unit 2210, an FU list processing unit 4270, a function unit requesting unit 4280, a decoder forming unit 2220, a decoding solution 2230, and the like. It may be configured to include a toolbox 2250.
  • the communication unit 4260 is a configuration for transmitting and receiving data with an external communication network. Specifically, the communication unit 4260 receives and outputs a transmission bitstream or FU transmission data through a communication network, and transmits an FU request signal to a corresponding encoding system.
  • the packet processor 2210 separates and outputs the received data for each packet type, and its basic function is the same as that of the packet processor 2210 described with reference to FIG. 25. However, the specific function according to the present embodiment will be described.
  • the packet processor 2210 separates and outputs the input transport bitstream into a decoder description, coded data, and an FU list using a packet ID. At this time, the decoder description is input to the decoder forming unit 2220, the encoded data is input to the decoding solution 2230, and the FU list is input to the FU lease processing unit 4270.
  • the packet processor 2210 separates the FUs from the FU transmission data and outputs the FUs to the toolbox 2250. At this time, the output FU is input to the toolbox 2250 and stored.
  • the FU list processor 4270 determines whether the new FU is included in the FU list by comparing the FUs stored in the toolbox 2250 using the functional unit identification information included in the input FU list.
  • the FU list processing unit 4270 outputs the functional unit identification information of the new FU to the functional unit requesting unit when the new FU is included as a result of the determination. Allow solution 2230 to begin the decoding process.
  • the functional unit request unit 4280 generates an FU request signal using the input functional unit identification information, outputs the FU request signal to the communication unit 4260, and transmits the generated FU request signal to the corresponding encoding system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Library & Information Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

부호화/복호화 방법 및 장치가 개시된다. 부호화 장치는, 데이터를 부호화하여 부호화된 데이터(encoded data)를 생성하는 부호화부; 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 및 그 연결 관계를 기술하는 디코더 디스크립션을 생성하는 디코더 디스크립션 생성부; 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 대한 FU 리스트를 생성하여 출력하는 FU 리스트 생성부; 및 상기 부호화된 데이터를 입력 받고, 상기 입력받은 부호화된 데이터에 상응하는 디코더 디스크립션, FU 리스트 및 기능부(FU)들을 입력 받아 패킷화하여 출력하는 패킷화부를 포함한다.

Description

부호화/복호화 방법 및 장치
본 발명은 부호화/복호화에 관한 것으로서, 특히 단위 복호화를 수행하는 기능부들(Funtional Units)의 조합을 통해 동영상 데이터 등을 부호화/복호화하는 장치 및 방법에 관한 것이다.
일반적으로 동영상은 부호화기(encoder, 인코더)에 의해 비트스트림(Bit-stream) 형태로 변환된다. 이때, 비트스트림은 부호화기의 제약 조건을 만족하는 부호화 유형에 따라 저장된다.
MPEG은 비트스트림의 제약 조건으로서 구문(syntax, 이하 'syntax'라 칭함) 및 의미(semantics, 이하 'semantics'라 칭함)를 요구한다.
syntax는 데이터의 구조나 형식 및 길이를 나타내며, 데이터가 어떤 순서로 표현되는지를 나타낸다. 즉, syntax는 부호화(encoding)/복호화(decoding) 작업을 위한 문법을 맞추기 위한 것으로, 비트스트림에 포함된 각 요소들(elements)의 순서와 각 요소의 길이, 데이터 형식 등을 정의한다.
Semantics는 데이터를 구성하는 각 비트가 의미하는 뜻을 나타낸다. 즉, semantics는 비트스트림 내의 각 요소들의 의미가 무엇인지를 나타낸다.
따라서, 부호화기의 부호화 조건 또는 적용된 표준(또는 코덱)에 따라 다양한 형태의 비트스트림이 생성될 수 있다. 일반적으로 각 표준(예를 들어 MPEG-1, MPEG-2, MPEG-4, MPEG-4 AVC 등)은 각각 상이한 비트스트림 syntax를 가진다.
따라서, 각 표준이나 부호화 조건에 따라 부호화된 비트스트림은 각각 다른 형식(즉, syntax 및 semantics)을 가진다고 할 수 있으며, 해당 비트스트림의 복호화를 위해서는 부호화기에 대응되는 복호화기가 사용되어야 한다.
상술한 바와 같이, 종래의 비트스트림 복호화기는 부호화기의 제약 조건을 만족하여야 하는 제한이 있었으며, 이러한 제한은 복수의 표준에 대응되는 통합 복호화기를 구현하기 어려운 원인이 된다.
따라서 본 발명은 상술한 문제점을 해결하기 위한 것으로, 각 표준(예를 들어, MPEG-1, MPEG-2, MPEG-4, MPEG-4 AVC 등)에 따른 다양한 형식(syntax, semantics)으로 부호화된 비트스트림을 동일한 정보 인식 방식으로 복호화(decoding)할 수 있는 비트스트림 디코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 복호화를 위한 기능부들을 효율적으로 구분하고 식별하여 이용할 수 있는 부호화/복호화 방법 및 장치를 제공하기 위한 것이다.
본 발명은 복호화를 위한 기능부들을 유형에 따라 구분하여 저장하고 용이하게 식별하여 이용할 수 있는 부호화/복호화 방법 및 장치를 제공하기 위한 것이다.
본 발명은 각 표준에 따른 다양한 형식(syntax, semantics)으로 부호화된 비트스트림을 동일한 정보 인식 방식으로 복호화(decoding)할 수 있도록 디코더 디스크립션(Decoder Description)을 부가한 확장 비트스트림을 생성하거나 비트스트림과 디코더 디스크립션을 독립적으로 생성하는 비트스트림 인코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 다양한 부호화 방식으로 압축된 비트스트림이 동일한 정보 분석 방법에 의해 파싱(parsing)되고, 파싱된 데이터를 이용하여 복호화를 위한 각 기능부(FU, Functional Unit)들이 유기적으로 제어되는 비트스트림 디코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 디코더 디스크립션을 이용하여 각 코덱의 스케쥴링(scheduling) 관리와 각 기능부들의 유기적 처리 구조(예를 들어, 병렬 결합 구조, 직렬 병합 구조, 독립 처리 구조, 개별적 처리 구조 등)를 제시할 수 있는 비트스트림 디코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 다양한 형태의 비트스트림을 복호하기 위한 syntax 해석 방법을 공통적으로 적용할 수 있는 비트스트림 부호화/복호화 방법 및 장치를 제공하기 위한 것이다.
본 발명은 다양한 형태의 비트스트림을 공통된 Syntax 해석 방법으로 파싱할 수 있도록 하기 위한 새로운 명령어들의 집합을 적용할 수 있는 비트스트림 부호화/복호화 방법 및 장치를 제공하기 위한 것이다.
본 발명은 syntax 엘리먼트의 변경이나 추가, 삭제 시에도 복호화기가 용이하게 비트스트림을 복호화할 수 있는 비트스트림 디코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 해석된 syntax의 엘리먼트 정보(element information, 즉 syntax 파싱에 의한 결과물)를 비트스트림 복호화를 위해 이용되는 구성 요소들이 이용할 수 있도록 하는 비트스트림 디코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 이미 해석된 syntax의 엘리먼트 정보를 후속하는 비트스트림 syntax 엘리먼트의 해석을 위해 이용할 수 있도록 하는 비트스트림 디코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 여러 표준(코덱)에서 제안하는 다양한 디코딩 과정에 포함된 기능들을 각기 기능부(FU, Functional Unit)대로 분할하여 툴박스(Tool-Box)에 구비하는 비트스트림 디코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 다양한 형태로 부호화된 비트스트림을 복호하기 위해 툴박스에서 필요한 기능부들만을 선별적으로 이용하는 비트스트림 디코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 툴박스에 저장된 기능부의 변경이나 추가, 삭제가 용이한 비트스트림 디코딩 방법 및 장치를 제공하기 위한 것이다.
본 발명은 사용자가 별도로 정의한 사용자 정의 기능부(Customized FU)들을 이용하여 복호화 및 부호화에 이용할 수 있는 부호화 및 복호화 시스템을 제공하기 위한 것이다.
본 발명은 방송 환경에 있어서, 부호화 시스템에서 기능부를 복호화 시스템에 제공할 수 있는 부호화 및 복호화 시스템을 제공하기 위한 것이다.
본 발명은 양 방향 통신 환경에 있어서, 복호화 시스템에서 수신된 데이터를 복호하는데 필요한 기능부를 부호화 시스템으로 요청하고 제공 받을 수 있는 부호화 및 복호화 시스템을 제공하기 위한 것이다.
상술한 목적을 달성하기 위하여 본 발명의 일 측면에 따르면, 다양한 부호화 형식에 범용적으로 이용될 수 있는 부호화/복호화 장치 및 방법이 제공된다.
본 발명의 바람직한 일실시예에 따른 부호화 장치는, 데이터를 부호화하여 부호화된 데이터(encoded data)를 생성하는 부호화부; 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 및 그 연결 관계를 기술하는 디코더 디스크립션을 생성하는 디코더 디스크립션 생성부; 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 대한 FU 리스트를 생성하여 출력하는 FU 리스트 생성부; 및 상기 부호화된 데이터를 입력 받고, 상기 입력받은 부호화된 데이터에 상응하는 디코더 디스크립션, FU 리스트 및 기능부(FU)들을 입력 받아 패킷화하여 출력하는 패킷화부를 포함할 수 있다.
상기 패킷화부는, 상기 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 기능부(FU)들 각각에 고유의 패킷 아이디를 부여하고 패킷화하여, 부호화된 데이터 패킷, 디코더 디스크립션 패킷, FU 리스트 패킷 및 기능부 패킷을 생성하는 것을 특징으로 할 수 있다.
상기 부호화 장치는, 상기 부호화된 데이터 패킷, 디코더 디스크립션 패킷, FU 리스트 패킷 및 기능부 패킷을 통합한 비트스트림을 생성하는 비트스트림 생성부를 더 포함할 수 있다.
상기 FU 리스트 패킷은 해당 FU들의 FU 식별 정보 및 해당 FU 패킷들의 패킷 아이디 정보를 포함할 수 있다.
상기 FU 식별 정보는, 해당 기능부가 속하는 툴박스를 나타내는 툴박스 넘버(TBN) 필드 및 해당 기능부의 고유 식별 정보를 나타내는 FU 넘버(FU Number) 필드를 포함할 수 있다.
본 발명의 바람직한 일실시에에 따른 복호화 장치는, 복수의 기능부(Function Unit, FU)들을 저장하는 툴박스; 입력받은 비트스트림을 패킷 유형별로 분리하여, 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 FU를 출력하는 패킷 처리부; 상기 FU 리스트를 입력받고, FU 리스트의 FU 식별정보를 추출하여 상기 툴박스에 저장된 FU들의 FU와 비교하여 FU 리스트에 신규 FU가 있는지 여부를 판단하고, 신규 FU가 있는 경우에는 해당 FU를 상기 패킷 처리부로부터 입력받아 툴박스에 전달하여 툴박스(2250)가 신규 FU를 저장하도록 하는 기능부 비교부; 상기 디코더 디스크립션을 해석하여, 상기 부호화된 데이터를 복호하는데 필요한 FU들을 상기 툴박스로부터 하기 디코딩 솔루션으로 로딩하고 조합하여 디코더를 형성하도록 하는 디코더 형성부; 및 상기 부호화된 데이터를 입력받아 상기 조합된 디코더를 통해 복호화하는 디코딩 솔루션를 포함하는 것을 특징으로 할 수 있다.
상기 툴박스는, 상기 기능부들을 유형별로 구분하여 저장한 복수의 툴박스로 구성되며, 상기 복수의 툴박스는 툴박스 식별 정보로 구분되는 것을 특징으로 할 수 있다.
상기 FU 리스트는 해당 기능부가 속하는 툴박스를 나타내는 툴박스 넘버(TBN) 필드 및 해당 기능부의 고유 식별 정보를 나타내는 FU 넘버(FU Number) 필드를 포함할 수 있다.
상기 툴박스는, MPEG 비디오 복호화와 관련된 기능부들을 저장하는 MPEG 비디오 툴박스; MPEG 오디오 복호화와 관련된 기능부들을 저장하는 MPEG 오디오 툴박스; MPEG 그래픽 복호화와 관련된 기능부들을 저장하는 MPEG 그래픽스 툴박스; 사용자 정의 기능부들을 저장하는 사용자 정의 툴박스 중 어느 하나 이상을 포함할 수 있다.
본 발명의 바람직한 일실시예에 따른 부호화 장치는 복수의 기능부들을 저장하는 툴박스; 데이터를 부호화하여 부호화된 데이터(encoded data)를 생성하는 부호화부; 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 및 그 연결 관계를 기술하는 디코더 디스크립션을 생성하는 디코더 디스크립션 생성부; 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 대한 FU 리스트를 생성하여 출력하는 FU 리스트 생성부; 상기 부호화된 데이터를 입력 받고, 상기 입력받은 부호화된 데이터에 상응하는 디코더 디스크립션 및 FU 리스트를 패킷화하여 출력하고, 상기 기능부(FU)들을 입력받아 패킷화하여 출력하는 패킷화부; 및 외부로부터 수신된 FU 요청 신호에 상응하는 FU를 상기 툴박스로부터 출력하여 상기 패킷화부로 입력하도록 하는 FU 요청 신호 처리부를 포함할 수 있다.
상기 부호화 장치는, 상기 부호화된 데이터, 디코더 디스크립션 및 FU 리스트의 패킷들 중 어느 하나 이상을 이용하여 전송 비트스트림을 생성하는 전송 비트스트림 생성부를 더 포함할 수 있다.
상기 부호화 장치는, 상기 패킷화부에서 패킷화된 FU 패킷을 전송용 데이터인 FU 전송 데이터로 변환 생성하는 FU 전송 데이터 생성부를 더 포함할 수 있다.
본 발명의 바람직한 일실시예에 따른 복호화 장치는, 복수의 기능부(Function Unit, FU)들을 저장하는 툴박스; 외부의 부호화 장치와 데이터를 송수신하는 통신부; 상기 통신부에서 수신한 데이터를 패킷 유형별로 분리하여, 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 FU를 출력하는 패킷 처리부; 상기 FU 리스트를 상기 툴박스에 저장된 FU 들과 비교하여 신규 FU가 상기 FU 리스트에 포함되어 있는지 여부를 판단하고, 신규 FU가 포함된 경우 신규 FU를 상기 외부의 부호화 장치로 요청하는 FU 요청 신호를 생성하는 FU 리스트 처리 및 기능부 요청부; 상기 디코더 디스크립션을 해석하여, 상기 부호화된 데이터를 복호하는데 필요한 FU들을 상기 툴박스로부터 하기 디코딩 솔루션으로 로딩하고 조합하여 재조합 디코더를 형성하도록 하는 디코더 형성부; 및 상기 부호화된 데이터를 입력받아 상기 재조합 디코더를 통해 복호화하는 디코딩 솔루션을 포함할 수 있다.
상기 패킷 처리부는, 전송 비트스트림을 입력 받고, 상기 전송 비트스트림으로부터 부호화된 데이터, 디코더 디스크립션 및 FU 리스트을 추출하는 것을 특징으로 할 수 있다.
상기 패킷 처리부는, FU 전송 데이터를 입력받고, 상기 FU 전송 데이터로부터 FU를 추출하여 툴박스에 저장하도록 하는 것을 특징으로 할 수 있다.
본 발명의 바람직한 일실시예에 따른 부호화 방법은, (a) 데이터를 부호화하여 부호화된 데이터(encoded data)를 생성하는 단계; (b) 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 및 그 연결 관계를 기술하는 디코더 디스크립션을 생성하는 단계; (c) 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 대한 FU 리스트를 생성하는 단계; 및 (d) 상기 부호화된 데이터 및 상기 부호화된 데이터에 상응하는 디코더 디스크립션, FU 리스트 및 기능부(FU)들을 패킷화하는 단계를 포함할 수 있다.
상기 (d) 단계는, 상기 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 기능부(FU)들 각각에 고유의 패킷 아이디를 부여하고 패킷화하여, 부호화된 데이터 패킷, 디코더 디스크립션 패킷, FU 리스트 패킷 및 기능부 패킷을 생성하는 것을 특징으로 할 수 있다.
상기 부호화 방법은, 상기 부호화된 데이터 패킷, 디코더 디스크립션 패킷, FU 리스트 패킷 및 기능부 패킷을 통합한 비트스트림을 생성하는 비트스트림 생성 단계를 더 포함할 수 있다.
본 발명의 바람직한 일실시예에 따른 복호화 방법은, 입력받은 비트스트림을 패킷 유형별로 분리하여, 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 FU를 분리 추출하는 단계; 상기 FU 리스트의 FU 식별정보를 추출하여 상기 툴박스에 저장된 FU들의 FU와 비교하여 FU 리스트에 신규 FU가 있는지 여부를 판단하는 단계; 상기 판단 결과, 신규 FU가 있는 경우, 해당 FU를 툴박스에 전달하여 툴박스가 신규 FU를 저장하도록 하는 단계; 상기 디코더 디스크립션을 해석하여, 상기 부호화된 데이터를 복호하는데 필요한 FU들을 상기 툴박스로부터 로딩하고 조합하여 재조합 디코더를 형성하는 단계; 및 상기 부호화된 데이터를 상기 재조합 디코더를 통해 복호화하는 단계를 포함할 수 있다.
본 발명의 바람직한 일실시예에 따른 부호화 방법은, 데이터를 부호화하여 부호화된 데이터(encoded data)를 생성하는 단계; 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 및 그 연결 관계를 기술하는 디코더 디스크립션을 생성하는 단계; 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 대한 FU 리스트를 생성하는 단계; 상기 부호화된 데이터 및 상기 부호화된 데이터에 상응하는 디코더 디스크립션 및 FU 리스트를 패킷화하고, 입력되는 기능부(FU)들을 패킷화하는 패킷화부; 및 외부로부터 수신된 FU 요청 신호에 상응하는 FU를 툴박스로부터 출력하여 상기 패킷화부로 입력하도록 하는 FU 요청 신호 처리부를 포함할 수 있다.
상기 부호화 방법은, 상기 패킷화된 부호화된 데이터, 디코더 디스크립션 및 FU 리스트들 중 어느 하나 이상을 이용하여 전송 비트스트림을 생성하는 단계를 더 포함할 수 있다.
상기 부호화 방법은, 상기 패킷화된 FU를 전송용 데이터인 FU 전송 데이터로 변환 생성하는 단계를 더 포함할 수 있다.
본 발명의 바람직한 일실시예에 따른 복호화 방법은, 외부의 부호화 장치로부터 전송 비트스트림을 수신하는 단계; 상기 전송 비트스트림을 패킷 유형별로 분리하여, 부호화된 데이터, 디코더 디스크립션 및 FU 리스트를 추출하는 단계; 상기 FU 리스트를 상기 툴박스에 저장된 FU 들과 비교하여 신규 FU가 상기 FU 리스트에 포함되어 있는지 여부를 판단하는 단계; 상기 판단 결과, 신규 FU가 포함된 경우, 신규 FU를 상기 외부의 부호화 장치로 요청하는 FU 요청 신호를 생성하여 송신하는 단계; 외부의 부호화 장치로부터 FU 전송 데이터를 수신하는 단계; 상기 FU 전송 데이터로부터 FU를 추출하여 툴박스에 저장하는 단계; 상기 디코더 디스크립션을 해석하여, 상기 부호화된 데이터를 복호하는데 필요한 FU들을 로딩하고 조합하여 재조합 디코더를 형성하는 단계; 및 상기 부호화된 데이터를 상기 재조합 디코더를 통해 복호화하는 단계를 포함할 수 있다.
상기 복호화 방법을 수행하기 위해 복호화 장치에서 실행될 수 있는 명령어들의 프로그램이 유형적으로 구현되어 있으며, 상기 복호화 장치에 의해 판독될 수 있는 프로그램이 기록된 기록 매체가 제공된다.
상기 부호화 방법을 수행하기 위해 부호화 장치에서 실행될 수 있는 명령어들의 프로그램이 유형적으로 구현되어 있으며, 상기 부호화 장치에 의해 판독될 수 있는 프로그램이 기록된 기록 매체가 제공된다.
상술한 바와 같이 본 발명에 따른 통합 코덱 장치 및 방법은 각 표준(예를 들어, MPEG-1, MPEG-2, MPEG-4, MPEG-4 AVC 등)에 따른 다양한 형식(syntax, semantics)으로 부호화된 비트스트림을 동일한 정보 인식 방식으로 복호화(decoding)할 수 있는 효과가 있다.
또한, 본 발명은 복호화를 위한 기능부들을 효율적으로 구분하고 식별하여 이용함으로써 복호화기를 재조합할 수 있는 효과가 있다.
또한, 본 발명은 복호화를 위한 기능부들을 유형에 따라 다수의 툴박스에 구분하여 저장하고 용이하게 식별하여 이용할 수 있는 효과가 있다.
또한, 본 발명은 각 표준에 따른 다양한 형식(syntax, semantics)으로 부호화된 비트스트림을 동일한 정보 인식 방식으로 복호화(decoding)하도록 디코더 디스크립션(decoder description)을 부가한 확장 비트스트림을 생성할 수 있는 효과도 있다.
또한, 본 발명은 디코더 디스크립션을 이용하여 각 코덱의 스케쥴링(scheduling) 관리와 각 기능부들의 유기적 처리 구조(예를 들어, 병렬 결합 구조, 직렬 병합 구조, 독립 처리 구조, 개별적 처리 구조 등)를 제시할 수 있는 효과도 있다.
또한, 본 발명은 기술된 디코더 디스크립션만으로 다양한 시스템 설계 및 구축이 가능한 효과도 있다.
또한, 본 발명은 다양한 부호화 방식으로 압축된 비트스트림을 동일한 정보 분석 방법에 의해 파싱(parsing)하고, 파싱된 데이터를 이용하여 복호화를 위한 각 기능부(FU, Functional Unit)들을 유기적으로 제어할 수 있는 효과도 있다.
또한, 본 발명은 다양한 형태의 비트스트림을 복호하기 위한 syntax 해석 방법을 공통적으로 적용할 수 있는 효과도 있다.
또한, 본 발명은 다양한 형태의 비트스트림을 공통된 Syntax 해석 방법으로 파싱할 수 있도록 하기 위한 새로운 명령어들의 집합을 적용할 수 있는 효과도 있다.
또한, 본 발명은 syntax 엘리먼트의 변경이나 추가시에도 복호화기가 용이하게 비트스트림을 복호화할 수 있는 효과도 있다.
또한, 본 발명은 해석된 syntax의 엘리먼트 정보(element information, 즉 syntax 파싱에 의한 결과물)를 비트스트림 복호화를 위해 이용되는 구성 요소들이 공유할 수 있도록 하는 효과도 있다.
또한, 본 발명은 해석된 syntax의 엘리먼트 정보를 후속하는 비트스트림 syntax 엘리먼트의 해석을 위해 이용할 수 있도록 하는 효과도 있다.
또한, 본 발명은 MPEG-1, MPEG-2, MPEG-4, MPEG-4 AVC 외의 블록 단위의 처리를 하는 동영상, 정지영상 코덱의 통합시에 사용할 수 있는 효과도 있다.
또한, 본 발명은 여러 표준(코덱)에서 제안하는 다양한 디코딩 방법을 구성하는 기능들을 각기 기능부(FU, Functional Unit)대로 분할하여 툴박스에 저장할 수 있는 효과도 있다.
또한, 본 발명은 다양한 형태로 부호화 된 비트스트림을 복호하기 위해 툴박스에서 필요한 기능부들만을 선별하여 디코딩할 수 있는 효과도 있다.
또한, 본 발명은 툴박스에 저장된 기능부의 변경이나 추가, 삭제가 용이한 효과도 있다.
본 발명은 사용자가 별도로 정의한 사용자 정의 기능부(Customized FU)들을 이용하여 복호화 및 부호화에 이용할 수 있는 효과가 있다.
도 1은 일반적인 복호화기의 구성을 개략적으로 나타낸 도면.
도 2는 일반적인 부호화기의 구성을 개략적으로 나타낸 도면.
도 3는 본 발명에 따른 부호화기의 일실시예 블록 구성도.
도 4는 본 발명에 따른 복호화기의 일실시예 블록 구성도.
도 5는 본 발명의 일 실시예에 따른 복호화부에서 비트스트림 처리 과정을 구체적으로 나타낸 도면.
도 6은 본 발명의 다른 실시예에 따른 디코더 디스크립션 입력 과정을 나타낸 도면.
도 7은 본 발명에 따른 복호화기의 다른 실시예 블록 구성도.
도 8은 도 4의 복호화부의 다른 실시예 블록 구성도.
도 9은 본 발명의 다른 실시예에 따른 BSDL 파서의 구성을 나타낸 도면.
도 10은 본 발명에 따른 복호화기의 또 다른 실시예 블록 구성도,
도 11은 도 10의 복호화부의 일실시예 블록 구성도.
도 12는 본 발명의 일실시예에 따른 FU 네트워킹 테이블의 구조를 나타낸 도면.
도 13는 본 발명의 일실시예에 따른 VNT 테이블의 구조를 나타낸 도면.
도 14는 본 발명의 일실시예에 따른 FUIT 테이블의 구조를 나타낸 도면.
도 15는 본 발명의 일실시예에 따른 PT 테이블의 구조를 나타낸 도면.
도 16은 본 발명의 일실시예에 따른 NCT 테이블의 구조를 나타낸 도면.
도 17은 본 발명의 일실시예에 따른 ET 테이블의 구조를 나타낸 도면.
도 18은 비트스트림 구문 목록을 활용한 CDDL/BSDL 간 상호 변환 관계를 나타내는 예시도.
도 19는 본 발명의 일실시예에 따른 툴박스의 상세 구성을 나타내는 예시도.
도 20은 본 발명의 일실시예에 따른 기능부 식별 정보(FUID)를 나타내는 예시도.
도 21은 본 발명에 따른 기능부 구분/식별 메커니즘을 설명하기 위한 개념도.
도 22는 본 발명의 또 다른 실시예에 따른 부호화 장치.
도 23은 본 발명의 또 다른 실시예에 따라 송신되는 비트스트림의 패킷 구성을 나타내는 예시도.
도 24는 본 발명의 또 다른 실시예에 따라 방송 환경에서 데이터가 송수신되는 과정을 개념적으로 나타내는 예시도.
도 25는 본 발명의 또 다른 실시예에 따른 복호화 장치의 구성도.
도 26은 본 발명의 또 다른 실시예에 따라 양방향 통신 환경에서 FU 및 부호화된 데이터가 송수신되는 과정을 개념적으로 나타내는 예시도.
도 27은 도 26의 부호화 시스템의 일실시예 구성도.
도 28은 도 26의 복호화 시스템의 일실시예 구성도.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. "및/또는" 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이하, 첨부한 도면들을 참조하여 본 발명에 따른 통합 코덱 방법 및 장치의 바람직한 실시예를 상세히 설명하기로 하며, 첨부 도면을 참조하여 설명함에 있어 도면 부호에 상관없이 동일하거나 대응하는 구성 요소에 대한 중복되는 설명은 생략할 수 있다.
도 1은 일반적인 복호화기의 구성을 개략적으로 나타낸 도면이고, 도 2는 일반적인 부호화기의 구성을 개략적으로 나타낸 도면이다.
도 1에 도시된 바와 같이, 일반적으로 MPEG-4 복호화기(100)는 가변장 디코딩부(Variable Length Decoding, 110), 역 스캔부(Inverse Scan, 115), 역 DC/AC 예측부(Inverse DC/AC Prediction, 120), 역 양자화부(Inverse Quantization, 125), 역 DCT부(Inverse Discrete Cosine Transform, 역 이산 여현 변환부, 130), 동영상 복원부(VOP Reconstruction, 135)를 포함한다. 복호화기(100)의 구성은 적용되는 표준에 따라 상이할 수 있음은 자명하며, 또한 일부 구성요소는 타 구성요소로 대체될 수도 있을 것이다.
전달된 비트스트림(105)이 syntax 파싱(parsing)되어 헤더 정보 및 인코딩된 비디오 데이터(encoded video data)가 추출되면, 가변장 디코딩부(110)는 미리 저장된 허프만 테이블(Huffman Table)을 이용하여 양자화된 DCT 계수를 만들고, 역 스캔부(115)는 역 스캔을 수행하여 동영상(140)과 동일한 순서의 데이터를 생성한다. 즉, 역 스캔부(115)는 인코딩시 여러 가지 방법으로 스캔된 순서의 역으로, 값을 출력한다. 인코딩 시 양자화(Quantization)를 수행한 후, 주파수 대역 값의 분포에 따라 스캔 방향이 정의될 수 있다. 일반적으로는 지그-재그(zig-zag) 스캔 방식이 사용되나, 스캔 방식은 코덱별로 다양할 수 있다.
Syntax 파싱은 가변장 디코딩부(110)에서 통합적으로 수행되거나, 가변장 디코딩부(110)에 선행하여 비트스트림(105)을 처리하는 임의의 구성 요소에서 수행될 수 있다. 이 경우, Syntax 파싱은 부호화기와 복호화기간에 적용되는 표준이 동일하므로 해당 표준에 상응하도록 미리 지정된 기준에 의해서만 처리된다.
역 DC/AC 예측부(120)는 주파수 대역에서 DCT 계수의 크기를 이용하여 예측을 위한 참조 블록의 방향성을 결정한다.
역 양자화부(125)는 역 스캔된 데이터를 역 양자화한다. 즉, 인코딩시 지정된 양자화값(QP, Quantization Parameter)을 이용하여 DC와 AC 계수를 환원한다.
역 DCT부(130)는 역 이산 여현 변환(Inverse Discrete Cosine Transform)을 수행함으로써 실제의 동영상 픽셀 값을 구하여 VOP(Video Object Plane)를 생성한다.
동영상 복원부(135)는 역 DCT부(130)에 의해 생성된 VOP를 이용하여 동영상 신호를 복원하여 출력한다.
도 2에 도시된 바와 같이, 일반적으로 MPEG-4 부호화기(200)는 DCT부(210), 양자화부(215), DC/AC 예측부(220), 스캔부(230), 가변장 인코딩부(235)를 포함한다.
부호화기(200)에 포함된 각 구성요소는 각각 대응되는 복호화기(100)의 구성 요소의 역 기능을 수행하며, 이는 당업자에게 자명하다. 간단히 설명하면, 부호화기(200)는 동영상 신호(즉, 디지털 영상 픽셀 값)를 이산 여현 변환(Discrete Cosine Transform), 양자화(Quantization) 등을 통해 주파수 값으로 변환하여 부호화를 수행한 후, 이를 정보의 빈도 수에 따라 비트 길이를 차별화하는 가변장 인코딩을 수행하여 압축된 비트스트림 상태로 출력한다.
도 3은 본 발명의 일 실시예에 따른 부호화기의 블록 구성도이다.
본 발명에 따른 부호화기는 앞서 도 2를 참조하여 설명한 종래의 부호화기(200)에 비해 확장 비트스트림 생성 및 출력부(2410)를 더 포함한다. 확장 비트스트림 생성 및 출력부(2410)는 전단까지의 처리에 의해 생성된 종래 비트스트림(316) 생성 과정에서의 제어 정보(예를 들어, 부호화된 데이터를 복호하는데 필요한 기능부들의 목록 및 연결 관계, 해당 기능부들의 입력 데이터, 신택스 정보, 신택스 연결 정보 등)를 이용하여 디코더 디스크립션을 생성한다. 또한, 생성된 디코더 디스크립션(313) 및 종래 비트스트림(316)를 이용하여 확장 비트스트림(305)을 생성하여 복호화기(300)로 전송한다. 여기서, 기능부란 단위 복호화를 수행하는 구성이다. 즉, 기능부들이 서로 유기적으로 결합됨으로써 디코더를 형성할 수 있다. 예를 들어, 도 1의 복호화 장치를 구성하는 각 구성들 각각이 하나의 기능부가 될 수 있다.
부호화기는 상기 부호화된 데이터를 복호할 수 있는 디코더를 구성하는 기능부들을 저장하는 툴박스(미도시)를 구비할 수 있다.
또한, 본 명세서에서 가변장 인코딩부(235)는 부호화기 내에서 종래 비트스트림(316)을 생성하기 위하여 최종적으로 부호화를 수행하는 임의의 구성 요소(예를 들어, 부호화부)를 지칭한 것일 뿐 이에 제한되는 것은 아니며, 또한 이로 인해 본 발명의 권리범위가 제한되지는 않는다.
도 3은 디코더 디스크립션 정보 및 종래 비트스트림을 이용하여 생성한 확장 비트스트림이 복호화기로 제공되는 경우를 가정한 도면이다.
하지만, 디코더 디스크립션은 별도의 데이터 또는 비트스트림 등의 형태로 복호화기(300)로 전달될 수도 있다. 이 경우는 가변장 인코딩부(235) 후단에 인코딩된 디코더 디스크립션 생성 및 출력부(도시되지 않음)가 위치하여, 종래의 인코딩부와 독립적으로 생성한 인코딩된 디코더 디스크립션을 복호화기(300)로 제공할 수도 있음은 자명하다.
한편, 상기 디코더 디스크립션은 해당 기능부들의 기능부 식별 정보(FUID)를 포함한다. 상기 기능부 식별 정보(FUID)는 툴박스 유닛 내에서 해당 기능부가 속하는 툴박스를 나타내는 툴박스 넘버(TBN) 필드 및 해당 기능부의 고유 식별 정보를 나타내는 FU 넘버(FU Number) 필드를 포함하여 구성된다.
상기 기능부 식별 정보 및 툴박스 유닛에 대하여는 관련 도면(도 19 내지 도 21) 및 관련 표(표 5)를 참조하여 후술하기로 한다.
<XML 기반 디코더 디스크립션>
도 4는 본 발명에 따른 복호화기의 일실시예 블록 구성도이고, 도 5는 도4의 복호화부에서 비트스트림 처리 과정의 일실시예를 구체적으로 나타낸 도면이다.
도 4에 예시된 디코더 디스크립션 및 영상 비트스트림은 예를 들어 부호화기에 의해 생성되어 제공되는 정보일 수 있다.
도 4을 참조하면, 복호화기(300)는 복호화부(305) 및 분리부(310)을 포함한다. 복호화부(305)는 BSDL 파서(320), 디코더 형성부(330), 툴박스(335) 및 디코딩 솔루션(340)을 포함한다.
BSDL 파서(320)는 분리부(310)로부터 입력된 BSDL 스키마(schema)를 이용하여 외부로부터 입력된 영상 비트스트림의 구문정보를 해석한다. BSDL 파서(320)로 입력되는 영상 비트스트림은 임의의 부호화 방식(예를 들어, MPEG-4, AVS 등)에 의해 부호화된 데이터이다. 본 명세서를 통해 BSDL 파서(320)가 자체적으로 BSDL Schema를 해석할 수 있거나, 또는 외부 알고리즘에 의해 구성될 수 있음을 당업자는 쉽게 이해할 수 있을 것이다.
BSDL 파서(320)는 XML 문법으로 기술된 BSDL 스키마를 읽어들여 BSDL 파서(320)의 구조를 재정의하기 위한 내부 처리부인 BSDL 해석 처리부를 포함한다.
BSDL 스키마를 이용해 재정의하는 규칙은 제작자가 적용하는 방법에 따라 다양할 수 있으므로, 그 기본적인 목적만을 제시하면 다음과 같다. 첫째, BSDL 스키마 상에 기록되어 있는 비트스트림의 길이 및 의미에 대한 정보를 인식할 수 있도록 하기 위한 것이다. 둘째, BSDL 스키마 상에 정의된 반복 구조 및 조건적 실행 구조를 읽어 들여 같은 반복 또는 조건문에 의해 실제 동작하는 프로그램적인 루틴을 구현하기 위한 것이다. 따라서, 재정의되기 이전의 BSDL 파서(320)는 위와 같은 목적을 달성하기 위한 기능들만이 구현된 상태라고 정의할 수도 있을 것이며, 상술한 파싱 기능을 활용해 실제로 구동하는 BSDL 파서(320)를 구현하는 과정을 재정의 하는 과정이라 할 수 있다.
BSDL 파서(320)는 BSDL 해석 처리부의 제어에 의해 유동적인 데이터 흐름을 구성할 수 있는 프로그램으로 구현되며, 예를 들어, CAL(Caltrop Actor Language), C, C++, Java 등 프로그램 언어를 이용하여 구현될 수 있다.
BSDL 내부 처리부(2525) 및 BSDL 파서(320)는 디코더 설계자의 설계 기준에 따라 제한없이 구현될 수 있다. 물론, BSDL 레퍼런스 소프트웨어와 같이 기존에 제시되어 있는 BSDL 운용 프로그램을 응용할 수도 있을 것이다. BSDL 레퍼런스 소프트웨어는 MPEG 표준화 단체에 의해 표준화된 BSDL의 원활한 운용을 위하여 제작된 공식 소프트웨어로서, BSDL 스키마를 입력받는 BSDL 파서(320) 역시 이러한 소프트웨어 자원을 이용하여 보다 용이하게 구현될 수 있음은 자명하다.
본 명세서에서 언급되는 바와 같이, BSDL 파서(320)의 기본적인 구조는 디코더 설계자가 선택한 다양한 방법에 의해 설계될 수 있다. 즉, 디코더 설계자는 BSDL 파서(320)의 지정된 기능을 수행하도록 하기 위한 상세한 알고리즘의 적용 및 설계를 자율적으로 선택할 수 있다. 다만, BSDL 파서(320)는 BSDL 스키마를 읽어들인 결과에 의해 재정의될 수 있으며, 재정의된 결과물이 복호화부(305)의 다른 구성 요소들과 협업(예를 들어, 통신 등)될 수 있어야 한다.
BSDL 파서(320)가 입력받는 BSDL 스키마에는 비트스트림에 포함된 구문 정보들에 대한 상세한 내역이 기술되며, 이 내역에는 예를 들어 구문 정보의 길이, 구문 정보의 의미, 구문 정보의 출현 조건 및 반복 출현 횟수 등이 포함될 수 있다. 여기서, 정보의 길이는 비트스트림 상에서 특정 정보가 차지하는 비트 길이를 의미하며, 구문 정보의 의미는 해당 정보가 어떤 의미를 가지는 정보인지를 나타낸다. 예를 들어, 임의의 기능부에서 A라는 정보를 요청하고 있을 경우 어느 것이 정보 A인지를 구별하는 데 필요할 수 있기 때문이다. 또한, 출현 조건이나 반복 출현 횟수의 경우, 하나의 BSDL 스키마를 이용해 동일한 규격의 동영상 비트스트림을 처리할 경우에도 비트스트림의 속성에 따라 일부 구문 정보의 출현 여부나 반복 횟수 등이 달라질 수 있으므로 이러한 경우를 정의하기 위해 BSDL 스키마에 첨부될 수 있는 정보이다. 예를 들어, 출현 조건은 인트라 프레임을 처리할 때는 모션 벡터 정보를 읽어들이지 않도록 하는 데에 필요할 수 있고, 반복 출현 횟수는 해당 매크로블록이 동일한 구조의 블록을 6개 지닌다고 할 경우 해당 블록을 반복시키는 데 사용될 수 있다.
도 5에 예시된 바와 같이, BSDL 해석 처리부는 상세한 내역에 관하여 해독한 결과 정보를 BSDL 파서(320)에 전달하여 BSDL 파서(320)가 BSDL 스키마에 지정된 순서에 따라 비트스트림에 포함된 정보를 읽어들이도록 지원한다.
BSDL 파서(320)는 BSDL 해석 처리부로부터 제공된 결과 정보를 참조하여 입력된 비트스트림의 내용을 의미 있는 데이터로 바꾸어 디코더 형성부(330) 및/또는 디코딩 솔루션(340)에 제공한다. 또한, BSDL 파서(320)가 디코더 형성부 또는/및 디코딩 솔루션(340)으로 제공하는 의미있는 데이터들로는 예를 들어, 미리 지정된 매크로블록 사이즈의 인코딩된 영상 데이터, 인트라 코딩된 매크로블록들에 대한 AC 예측 플래그(ACpred_flag), MCBPC(MB type & coded block pattern for chrominance), CBPY (coded block pattern for luminance) 등이 포함될 수 있다. 이러한 데이터 제공 과정은 디코더 형성부(330)나 디코딩 솔루션(340)의 구동 여부와 무관하게 진행될 수도 있다.
본 실시예는 디코더(복호화기)가 디코더 디스크립션을 이용하여 비트스트림을 디코딩하되, 디코더 디스크립션이 BSDL 언어 체계 및 이와 연동 가능한 XML 기반 서식을 사용하는 구조로 구현되도록 하기 위한 것이다. 본 실시예를 통해 디코더 디스크립션이 BSDL, CALML 등의 XML 서식을 가질 수 있고, BSDL 스키마는 Syntax Parsing 과정에, CALML은 기능부간의 연결 제어를 위해 사용되도록 그 역할이 구분될 수 있음을 당업자는 쉽게 이해할 수 있을 것이다.
BSDL 언어는 비트스트림의 구조와 구성 방식에 대한 정보를 포함한 XML 문서 또는 XML 스키마 형태로 기술된다. 이 언어는 각각이 하나 이상의 영상 비트스트림 구조를 표현할 수 있도록 제작된다. BSDL 언어를 사용함으로서, 디코더는 종래의 MPEG 표준에서 검증되어 사용되고 있는 비트스트림 기술 방식을 그대로 적용할지라도, 타 기술들과 높은 호환성을 획득할 수 있게 된다. BSDL에 관련된 언어 서식 및 문법은 MPEG-B Part 5에 기술되어 있으므로 이에 대한 상세한 설명은 생략한다.
BSDL과 XML을 이용한 BSDL 스키마와 연결 제어 정보의 구성예를 나타내면 아래와 같다. 물론, BSDL 스키마와 연결 제어 정보의 구성 형식이 이에 제한되지 않음은 자명하다.
BSDL 스키마
<xsd:element name="VideoObject">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="VOStartCode"
type="m4v:StartCodeType"/>
<xsd:element name="VOL">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="header" type="VOLHeaderType"
bs2:ifNext="&volSC;" rvc:port="0"/>
<xsd:element name="VOP"
type="VideoObjectPlaneType"
maxOccurs="unbounded"
bs2:ifNext="&vopSC;" rvc:port="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
연결 제어 정보
<Network name="Decoder">
<Package>
<QID>
<ID id="MPEG4 Simple Profile" />
</QID>
</Package>
<Port kind="Input" name="BITSTREAM" />
<Port kind="Ouput" name="YUV" />
<Instance id="1">
<Class name="Parser">
<QID>
<ID id="c" />
</QID>
</Class>
<Note kind="label" name="Stream Parser" />
</Instance>
<Instance id="2">
<Class name="VS">
<QID>
<ID id="c" />
</QID>
<Note kind="label" name="Video Session" />
</Class>
</Instance>
<Connection src="" src-port="BITSTREAM" dst="1" dst-port="BITSTREAM" />
<Connection src="1" src-port="CSCI" dst="2" dst-port="CSCI" />
<Connection src="1" src-port="DATA" dst="2" dst-port="DATA" />
<Connection src="2" src-port="YUV" dst="" dst-port="YUV" />
</Network>
본 실시예에서는 디코더 디스크립션(2560), 인코딩된 비디오 데이터(2580) 등의 정보가 외부로부터 입력되는 경우를 가정하여 설명하나, 그 중 하나 이상의 정보가 복호화부(305)의 임의의 구성 요소 내에 이미 내장되어 구현될 수도 있음은 자명하다.
다시 도 4을 참조하면, 디코더 형성부(330)는 분리부(310)로부터 입력받은 연결 제어 정보 또는/및 BSDL 파서(320)로부터 입력받은 비트스트림 데이터의 일부(예를 들어, 미리 지정된 매크로블록 사이즈의 인코딩된 영상 데이터, 인트라 코딩된 매크로블록들에 대한 AC 예측 플래그(ACpred_flag), MCBPC(MB type & coded block pattern for chrominance), CBPY (coded block pattern for luminance) 등 중 하나 이상)을 이용하여 디코딩 솔루션(340)이 구현되도록 제어한다.
즉, 디코더 형성부(330)는 연결 제어 정보 등을 이용하여 툴박스(335)에 구비된 기능부들 중 일부 또는 전체가 유기적인 연결 관계로서 디코딩 솔루션(340) 내에 로드되어 정렬되도록 제어한다. 여기서, 연결 제어 정보는 CALML(CAL Markup Language)로 작성될 수 있다. CALML이란 MPEG 표준화 단체에서 현재 논의중인 CAL언어(Caltrop Markup Language) 방식의 디코더 구성을 기술할 수 있는 XML 포맷이다. CAL언어는 프로그램 객체인 Actor와 각 Actor간의 연결 관계로 구성되는데, 이러한 CAL언어의 구조를 XML 서식에 의해 표현한 것이다. 이에 대한 표현 예는 앞서 BSDL 스키마와 연결 제어 정보의 표현 예로서 이미 제시하였다.
구체적으로, 디코더 형성부(330)는 여러 기능부의 집합으로 구성된 툴박스(335)에 접근할 권한을 가지며, 툴박스(335)에 구비된 기능부들간에 입, 출력 연결을 설정하여 그 결과물에 해당하는 디코딩 솔루션(340)을 구성한다. 이 때 기능부들간 입/출력 연결 구조 및 실행 순서는 연결 제어 정보를 참고하여 설정된다. 또한, 입력된 비트스트림의 종류를 구별하기 위한 일부 정보를 BSDL 파서(320)로부터는 전달받아, 기능부 연결 과정에서 참조할 수 있다. 기능부들간의 연결 구조가 모두 확정되면, 그 연결 구조는 외부로부터의 지속적인 데이터 입력이 전제될 경우 해당 디코더 디스크립션 제작자가 의도한 모든 종류의 영상 비트스트림을 해석, 디코딩 할 수 있는 독립적인 디코더로 간주할 수 있다. 이 때 이 완결된 기능부 연결 구조를 디코딩 솔루션(340)이라 명명할 수 있다.
툴박스(335)는 미리 지정된 프로세스를 수행하도록 각각 구현된 복수의 기능부들을 포함한다. 각각의 기능부들은 각각 프로그램 코드들의 조합으로 구현될 수도 있다.
툴박스(335)에 포함되는 각 기능부들은 적용되는 용도별 집합으로 구분된 복수의 세부 툴박스로 세분화될 수도 있다. 예를 들어, MPEG용 기능부들이 포함되는 제1 툴박스, MPEG용 기능부들 이외의 기능부들이 포함되는 제2 툴박스 등으로 세분화될 수 있다. 또는 MPEG-2용 기능부들의 집합인 제1 툴박스, MPEG-4용 기능부들의 집합인 제2 툴박스, 중국의 디지털 TV 압축 표준인 AVS용 기능부들의 집합인 제3 툴박스 등으로 세분화될 수 있다.
물론, 툴박스(335) 자체가 복수로 구현되어 디코더 형성부(330) 및 디코딩 솔루션(340)과 독립된 연결 관계를 가질 수도 있다. 이 경우, 도시되지는 않았으나 상술한 제1 툴박스, 제2 툴박스 등이 독립된 형식의 툴박스로 구현될 수 있을 것이다.
다만, 이하에서는 설명의 편의를 위해 하나의 툴박스(335) 내에 복수의 세부 툴박스들이 포함되거나 모든 기능부들이 집합체 구성없이 산재되어 포함되는 경우를 중심으로 설명하기로 한다.
툴박스(335)는 각각의 기능(즉, 미리 설정된 프로세스)을 수행하도록 구현된 기능부(FU, Functional Unit)들이 포함되는 영역으로, 각 기능부들은 디코더 형성부(330)의 연결 제어에 의해 디코딩 솔루션(340)에 로드(load)되어 순차적인 연결 동작 관계를 형성함으로써 영상 비트스트림(380)에 포함된 인코딩된 영상 데이터를 디코딩된 영상 데이터로 출력한다.
툴박스(335) 내에는 예를 들어, DF(De-blocking Filter) 기능부, VR(VOP Reconstructor) 기능부, FFR(Frame Field Reordering) 기능부, IPR(Intra prediction and Picture Reconstruction) 기능부, IT(Inverse Transform) 기능부, IQ(Inverse Quantization) 기능부, IAP(Inverse AC Prediction) 기능부, IS(Inverse Scan) 기능부, DCR(DC Reconstruction) 기능부 등의 기능부가 포함될 수 있다.
IT4x4 기능부, IQ4x4 기능부) 및 DCR4x4 기능부는 처리하는 블록 사이즈가 4x4인 것을 특징으로 한다. 이는 MPEG-1/2/4의 경우에는 Transform, Quantization, Prediction 시에 8x8 블록 사이즈로 데이터를 처리함에 비해, MPEG-4 AVC는 4x4 블록 사이즈로 데이터를 처리하는 경우가 존재하기 때문이다.
툴박스(335)에는 데이터 디코딩 기능을 수행하기 위한 기능부라면 적용되는 표준에 관계없이 모두 포함될 수 있을 뿐 아니라 기술 발전과정에서 필요한 기능부는 추가될 수 있고, 기존 기능부의 수정도 가능하며, 불필요한 기능부는 제거될 수 있음은 자명하다. 예를 들어, 복호화 처리를 위해 4x4 블록 사이즈로 데이터를 처리하는 IS4x4 기능부 등이 추가로 필요한 경우 해당 기능부들이 툴박스(335)에 추가될 수 있다. 또한, MPEG-4 AVC에서 인트라 예측(Intra Prediction) 수행을 위한 SPR(Special Prediction) 기능부 등이 더 추가될 수도 있을 것이다.
툴박스(335) 내에 구비된 각 기능부는 각 표준에 독립적으로 존재하지 않고, 표준에 관계없이 동일한 처리가 가능한 기능부의 경우에는 하나의 기능부로 통합되어 구비될 수도 있음은 자명하다. 각 기능부의 기능은 당업자에게 자명한 사항이므로 간략히 설명하기로 한다.
DF 기능부는 MPEG-4 AVC의 디-블록킹 필터(de-blocking filter)이고, VR 기능부는 복원된 픽셀값을 저장하는 기능부이다.
FFR 기능부는 interlaced 모드를 위한 기능부이고, IPR 기능부는 MPEG-4 AVC의 인트라 예측(Intra prediction)을 한 후 복원된 픽셀값을 저장하는 기능부이다. 상술한 바와 같이, MPEG-4 AVC의 인트라 예측은 SPR 기능부에 의해 수행될 수 있을 것이다.
IT 기능부는 DC값 및 AC값들의 역 변환(inverse transform)을 수행하는 기능부이고, IQ 기능부는 AC 값들을 역 양자화(inverse quantization)하는 기능부이다.
IAP 기능부는 AC값들을 역 예측(inverse AC prediction)하는 기능부이고, IS 기능부는 AC값들을 역 스캔(inverse scan)하는 기능부이다. DCR 기능부는 DC값들의 역 예측 및 역 양자화를 수행하는 기능부이다.
디코딩 솔루션(340)은 디코더 형성부(330)에 의해 생성된 결과물로, BSDL 파서(320)에서 구문 정보 단위로 분리된 비트스트림 데이터(또는 미리 지정된 매크로블록 크기의 인코딩된 비디오 데이터)를 입력 받는다.
도 5에 예시된 바와 같이, 입력된 비트스트림 데이터는 데이터를 입/출력하기 위한 유, 무형의 데이터 인터페이스를 통해 입력될 수 있다. 데이터 인터페이스는 소프트웨어의 경우 특정 메모리 버퍼이거나, 자료의 흐름을 정의하는 가상 포트(Port)이거나, 프로그램 상의 파라미터일 수 있고. 하드웨어의 경우에는 회로 상의 연결선일 수 있으며, 이외에도 다양하게 구현될 수 있다.
데이터의 입력은 해당 인터페이스를 통해 지속적으로, 그리고 특정 기능부의 프로세스 수행과 무관하게 지속적으로 입력(예를 들어, 병렬 처리가 가능하도록 입력)될 수 있다. 디코딩 솔루션(340)은 입력되는 데이터를 처리하여 디코딩된 영상 데이터로 출력한다. 도 5에 도시된 바와 같이, 데이터는 데이터 인터페이스로부터 시작해 각 기능부로 전달될 수 있으며, 기능부는 해당 데이터를 가공하여 후속하는 기능부로 전달할 수 있다. 이러한 데이터의 흐름은 모두 디코더 형성부(330)에 의해 사전 정의된 바에 의하여 처리된다.
디코딩 솔루션(340)내에는 BSDL 파서(320)로부터 제공받은 데이터(예를 들어, 비트스트림의 syntax 파싱에 의해 추출된 정보 등), 각 기능부의 처리 결과 데이터를 저장하기 위한 저장부가 포함될 수 있다. 디코더 형성부(330)의 제어에 의해 로드된 각 기능부는 BSDL 파서(320)로부터 제공된 데이터 및 선행하여 동작된 기능부의 결과 데이터 중 하나 이상을 이용하여 지정된 프로세스를 수행할 수 있다. 이 경우, 후속하여 프로세스를 수행할 기능부는 선행하는 기능부의 동작이 완료되었음을 인식하여야 한다. 이를 위해, 디코더 형성부(330)는 각 기능부의 동작 완료 여부를 지속적으로 모니터링하여 후속하는 기능부의 동작 개시 여부를 제어할 수 있다. 또한, 저장부 내에 각 기능부별로 독립된 영역이 구비되도록 하고, 선행하는 기능부의 처리 결과 데이터를 디코더 형성부(330)의 제어에 의해 후속하는 기능부를 위한 저장 영역에 저장되도록 하면, 후속하는 기능부는 자신의 저장 영역에 프로세스 수행을 위해 필요한 데이터가 저장되는 즉시 프로세스를 수행할 수도 있을 것이다. 이외에도, 기능부간의 처리 개시 시점을 제어하기 위한 다양한 방법이 추가적으로 고려될 수 있음은 자명하다.
물론, 해당 저장부는 디코더 형성부(330) 내에 구비될 수도 있으며, 디코더 형성부(330)는 현재 프로세스를 수행할 기능부로 BSDL 파서(320)로부터 제공받은 데이터(예를 들어, 비트스트림의 syntax 파싱에 의해 추출된 정보 등), 각 기능부의 처리 결과 데이터를 해당 기능부로 제공할 수도 있다.
이하, 도 5를 참조하여 복호화부(305)의 동작 과정을 간략히 설명하면 다음과 같다.
외부로부터 입력 영상 비트스트림과 BSDL 스키마가 입력되면(비트스트림의 임의 지점에 정보 A 와 정보 B가 존재하는 것으로 가정함), BSDL 파서(320)은 BSDL 스키마를 읽어 들여 정보 A에 해당하는 지점에 5bit의 MB type 데이터가 존재하고, 정보 B에 해당하는 지점에는 2bit의 CBPY 데이터가 존재함을 인식한다.
이어서, BSDL 파서(320)는 파서는 인식한 정보를 이용해 각 지점에서 지정된 수 만큼의 비트를 읽어 들이고, 읽어들인 정보를 부여된 의미에 따라 디코딩 솔루션(340)에 전달한다.
디코딩 솔루션(340)은 BSDL 파서(320)로부터 MB Type과 CBPY로 명명된 데이터를 제공받아 처리하게 된다. 디코딩 솔루션(340)은 디코더 형성부(330)의 연결 제어에 의해 각 기능부들이 로딩되어 구현됨은 앞서 설명한 바와 같다.
디코딩 솔루션(340)에 존재하는 데이터 인터페이스는 외부로부터 전달된 데이터를 받아들여, 연결 제어 정보에 의해 사전에 구성된 기능부들의 연결 관계를 참조하여, 해당 데이터를 요구하는 기능부들에 전달한다.
각 기능부는 역시 미리 지정된 연결 관계(즉, 데이터 처리를 위한 연결 관계)에 따라 디코딩 과정을 수행한다. 모든 데이터 흐름과 기능부 간의 연결 관계는 디코더 형성부(330)가 사전에 구성한 내역에 의한다. 각 기능부들의 순차적 처리에 의해 출력 영상 프레임이 외부로 출력된다.
상술한 바와 같이, 디코더 형성부(330) 또는/및 디코딩 솔루션(340) 내에는 저장부가 구비될 수 있다. BSDL 파서(320)로부터 데이터를 제공받음에 있어, 그 전달 과정에 끊김이 없고 또한 디코딩 과정과는 병렬적으로 데이터 제공이 수행될 수 있기 때문이다. 또한, 각 기능부는 필요한 데이터를 저장부로부터 독출하여 사용할 수도 있을 것이다.
또한, BSDL 파서(320)는 인코딩된 영상 데이터의 디코딩 처리를 위해 상응하는 데이터를 디코더 형성부(330)로 제공하여 디코더 형성부(330)가 디코딩 솔루션(340)으로 제공하도록 하거나, BSDL 파서(320)가 직접 해당 데이터를 디코딩 솔루션(340)으로 제공할 수도 있을 것이다.
다시 도 4을 참조하면, 분리부(310)는 입력된 디코더 디스크립션(2560)을 각각의 정보로 분리하여 복호화부(305)로 입력한다. 분리부(310)에 입력된 디코더 디스크립션(2560)은 비트스트림의 구조를 기술하기 위한 BSDL 스키마(2565)와 비트스트림의 디코딩 과정을 기술하기 위한 CALML 데이터(2570)를 포함할 수 있다. 상술한 두 가지 종류의 데이터는 각각 독립적으로 XML 문법에 의해 기술될 수도 있으며, 효율적인 디코더의 운용을 위하여 두 종류의 데이터가 통합되어 전송될 수 있다.
도 6는 본 발명의 다른 실시예에 따른 디코더 디스크립션 입력 과정을 나타낸 도면이다.
도 6에 예시된 바와 같이, 복호화기(300)는 디스크립션 디코더(510)를 더 포함할 수 있다. 디스크립션 디코더(510)는 입력된 인코딩된 디코더 디스크립션(520)을 디코딩 처리하여 디코더 디스크립션(2560)을 생성하여 분리부(310)로 제공할 수 있다.
디코더 디스크립션(2560)을 인코딩하여 송수신함으로써 송수신되는 데이터량을 절감할 수 있는 효과가 있다.
도 7은 본 발명에 따른 복호화기의 다른 실시예 블록 구성도이다.
앞서 도 4을 참조하여 디코더 디스크립션(2560)과 영상 비트스트림이 복호화부(305)로 입력되는 경우와, 도 6를 참조하여 인코딩된 디코더 디스크립션(520)과 영상 비트스트림(380)이 복호화부(305)로 입력되는 경우를 설명하였다.
그러나, 도 7에 예시된 바와 같이, 디코더 디스크립션(2560)의 구성 정보들이 원시적으로 분리되어 복호화부(305)로 입력될 수도 있음은 자명하다. 이 경우, 앞서 설명한 분리부(310), 디코더 디스크립션(2560) 등이 생략될 수 있음은 자명하다. 도 8은 본 발명의 다른 실시예에 따른 복호화부의 구성을 나타낸 도면이다.
앞서 도 4 내지 도 7을 참조하여 툴박스(335) 및 디코더 형성부(330)가 분리되어 구현된 복호화부(305)에 대하여 설명하였다.
그러나 도 8 에 예시된 바와 같이, 툴박스(335)가 디코더 형성부(330)의 일 구성 요소로 포함되어 구현될 수도 있음은 자명하다.
이 경우, 디코더 형성부(330)는 기능부간의 연결 구조 제어 기능 뿐 아니라 사용될 기능부의 선별 기능까지도 포함할 수 있으며, 이를 통해 구현 가능한 디코딩 솔루션(340)의 유형도 다양해질 수 있을 것이다.
도 9는 본 발명의 또 다른 실시예에 따른 BSDL 파서의 구성을 나타낸 도면이다.
앞서 도 4을 참조하여, BSDL 해석 처리부를 포함하는 BSDL 파서(320)에 대하여 설명하였다.
그러나, 본 발명에 따른 BSDL 파서(320)는 비트스트림의 디코딩을 개시하기 이전에 복호화기(300) 외부로부터 사전 정의되어 제공될 수도 있다. 따라서, 앞서 설명한 BSDL 해석 처리부가 생략될 수 있다. 이때, BSDL 파서 제작기(2610)는 BSDL 레퍼런스 소프트웨어와 같은 기존의 응용 프로그램을 활용하여 구성될 수 있을 것이다.
이제까지, BSDL 파서가 독립된 구성 요소로서 지정된 동작을 처리하는 경우를 중심으로 설명하였다. 다만, BSDL 파서는 툴박스 내에 포함되는 하나의 기능부로서 구현되거나, 디코딩 솔루션 내에 독립된 구성 요소로서 미리 포함되도록 구현될 수도 있을 것이다. 만일, BSDL 파서가 툴박스 내에 구비되는 경우 디코더 형성부는 연결 제어 정보를 이용하여 BSDL 파서가 비트스트림 디코딩을 위해 동작하는 기능부들의 동작 이전에 프로세스를 수행하도록 로드 및 제어하여야 할 것이다. 마찬가지로, BSDL 파서가 디코딩 솔루션 내에 미리 포함되는 경우, 디코더 형성부는 로드한 각 기능부들의 프로세스 수행 개시 이전에 BSDL 파서가 먼저 프로세스 수행하도록 제어하여야 할 것이다. 각각의 경우에도 BSDL 파서의 동작 및 기능은 앞서 관련 도면을 참조하여 설명한 바와 동일하므로 상세한 설명은 생략하기로 한다. 다만, BSDL 스키마 또는/및 비트스트림을 초기에 입력받는 주체가 디코더 형성부 또는/및 디코딩 솔루션으로 변경될 필요가 있을 수 있다.
이제까지 본 발명에 따른 복호화 장치 및 비트스트림 복호화를 위한 구문 해석 방법을 설명함에 있어 MPEG-4 AVC를 기준으로 설명하였으나, MPEG-1, MPEG-2, MPEG-4, AVS 및 이외의 동영상 부호화/복호화 표준에 아무런 제한없이 동일하게 적용할 수 있음은 당연하다.
또한, 연결 제어 정보에 포함되는 정보 역시 하나의 표준에 의한 디코딩 수행을 위한 기능부들의 연결 관계, 해당 기능부에 요구되는 처리 프로세스 등에 관한 정보만으로 기술되지 않고, 복수의 표준에 의한 디코딩 수행을 위한 정보로 기술될 수도 있음은 자명하다.
예를 들어, 영상 비트스트림의 초기 복수의 프레임은 MPEG-2로 인코딩되고, 후속하는 복수의 프레임은 MPEG-4로 인코딩되며, 나머지 프레임은 MPEG-1으로 인코딩되었다고 가정하자. 이 경우, 인코딩된 영상 데이터의 디코딩을 위해 연결 제어 정보는 인코딩 방법을 달리하는 각 프레임들이 툴박스(335)에 포함된 각 표준에 따른 기능부들이 유기적으로 결합되어 동작될 수 있도록 정의될 것임은 자명하다.
이하, 관련 도면을 참조하여, 본 발명에 따른 복호화기의 또 다른 실시예를 설명하기로 한다. 다만, 또 다른 실시예를 설명함에 있어, 전술한 실시예와 동일하거나 극히 유사한 기능을 수행하는 구성에 대한 설명은 그 명칭 및 도면 참조 부호를 동일하게 표시하는 것으로서 중복된 설명을 생략하기로 한다. 예를 들어, 도 11에 도시된 툴박스(335), 디코더 형성부(330) 및 디코딩 솔루션(330)은 기본적으로 전술한 구성과 동일하다.
<CDDL 기반 디코더 디스크립션>
도 10은 본 발명에 따른 복호화기의 또 다른 실시예 블록 구성도이고, 도 11은 도 10의 복호화부의 일실시예 구성을 개략적으로 나타낸 도면이다.
이하, 설명되는 실시예에서 입력되는 디코더 디스크립션은 테이블 기반 디코더 디스크립션(이하, CDDL(Compact Decoder Description Language) 기반 디코더 디스크립션)으로서, 바이너리 형태로 압축되어 복호기로 전달된다.
복호화기는 입력되는 비트스트림의 형식에 따라 필요한 기능부들을 조합하여 디코더를 재구성할 수 있다. 이로 인해, 본 발명에 따른 복호화기는 어떠한 형식으로 인코딩된 비트스트림이 입력되더라도 입력된 비트스트림에 상응하는 디코더를 형성하여 당해 비트스트림을 복호할 수 있다. 이하, 관련 도면을 참조하여 본 발명에 따른 복호화기에 대해 보다 상세히 설명하기로 한다.
전술한 바와 같이, 복호화기로 디코더 디스크립션이 비트스트림과 함께 제공된다. 디코더 디스크립션은 비트스트림과 통합적으로 구현된 비트스트림(305)의 형태로 복호화기에 제공되거나, 독립된 데이터 형태로 복호화기에 제공될 수 있다. 물론, 복호화기의 특정 저장부에 디코더 디스크립션에 상응하는 정보가 미리 저장된 경우라면, 디코더 디스크립션의 제공은 생략될 수도 있다. 다만, 이하에서는 해당 데이터가 비트스트림 내에 포함되어 복호화기로 제공되는 경우를 중심으로 설명하기로 한다.
본 발명의 다른 실시예에 따른 복호화기는 분리부(310) 및 복호화부(320)를 포함한다. 도시된 복호화기의 구성 요소(예를 들어, 분리부(310), 복호화부(320) 자체 또는 복호화부(320)에 포함된 하나 이상의 구성 요소 등) 중 하나 이상은 하기에서 설명될 기능을 수행하도록 구현된 소프트웨어 프로그램(또는 프로그램 코드들의 조합)으로 구현될 수도 있음은 자명하다.
분리부(310)는 입력된 비트스트림(Bitstream)을 압축된 디코더 디스크립션(Compressed Decoder Description)과 인코딩된 비디오 데이터로 분리하여 복호화부(320)로 각각 입력한다.
분리부(310)는 압축된 디코더 디스크립션(313)를 복원부(410)로 입력하고, 인코딩된 비디오 데이터(316)는 복호 실행부(450)로 입력할 수 있다. 상술한 바와 같이, 압축된 디코더 디스크립션과 인코딩된 비디오 데이터가 각각 독립된 데이터로 입력되는 경우 분리부(310)는 생략될 수 있다. 또한, 인코딩된 비디오 데이터는 앞서 도 1의 비트스트림(105)과 동일 또는 유사한 형식의 데이터일 수 있다.
복호화부(320)는 분리부(310)로부터 입력된 압축된 디코더 디스크립션(313)를 이용하여 인코딩된 비디오 데이터(316)을 복호화하여 디코딩된 영상 데이터(390)를 출력한다. 이하에서 도 11를 참조하여, 복호화부(320)를 구성에 대해 상세히 설명하도록 한다.
도 11을 참조하면, 복호화부(1320)는 복원부(Decompression Unit)(1410), 디코더 디스크립션 해석부(1420), 툴박스(335), ADM 생성부(1440), 복호 실행부(1450)을 포함한다. 복호 실행부(1450)는 디코더 형성부(330) 및 디코딩 솔루션(330)을 포함한다.
복원부(1410)는 분리부(1310)로부터 입력된 압축된 디코더 디스크립션(313)를 소정의 복원 방식에 따라 복원(decompression)하여 디코더 디스크립션 해석부(420)로 출력한다. 더욱 구체적으로는, 디코더 디스크립션은 소정의 규칙에 따라 바이너리 형식으로 압축되어 있으며, 복원부는 바이너리 형태의 압축된 디코더 디스크립션을 디코딩하여 상응하는 CDDL 기반 디코더 디스크립션을 복원하여 출력한다.
디코더 디스크립션 해석부(1420)는 복원된 CDDL 기반 디코더 디스크립션 을 XML 형식으로 기술된 XML 기반 디코더 디스크립션으로 변환하여 ADM 생성부(1440)로 출력한다. 물론, 디코더 디스크립션 해석부(420)을 생략하고 복원부(410)가 입력된 바이너리 데이터를 직접 XML 기반 디코더 디스크립션으로 변환하여 출력할 수도 있음은 자명하다.
ADM 생성부(440)는 하나 이상의 입출력 포트를 갖는 다수의 기능부 정보 및 상기 포트들 간의 연결 정보를 포함하는 추상적 복호화 모델(Abtstact Decoding Model, ADM)을 생성한다.
ADM 생성부(440)는 전송받은 기능부를 문맥 제어 정보, 연결 제어 정보, 파싱 제어 정보에 따라 조합하여 비트스트림을 복호화 할 수 있는 ADM을 생성한다.
복호 실행부(450)는 상기 ADM을 이용하여 전술한 바와 같이 디코더형성부(330) 및 디코딩 솔루션(340)을 통해 툴박스에 저장된 해당 기능부들을 이용하여 입력 영상을 디코딩 할 수 있다. 또한, 복호 실행부(450)는 상기 XML 기반 디코더 디스크립션을 직접 입력받아 입력 영상을 디코딩할 수도 있음은 물론이다.
이하, 본 발명의 일실시예에 따른 CDDL 기반 DD(Decoder Description)를 설명하기로 한다.
CDDL 기반 DD(Decoder Description)은 ADM 또는/및 디코딩 솔루션을 구성하는데 필요한 FU 들의 연결 관계인 FU 네트워킹을 기술하는 FU 네트워킹 테이블 그룹 및 신택스 파싱을 위한 신택스 파싱 테이블 그룹으로 구분된다.
FU 네트워킹 테이블 그룹은 가상 네트워크 테이블(Virtual Network Table, VNT), 기능부 인스턴스 테이블(Functional Unit Instance Table, FUIT), 네트워크 연결 테이블(Network Connection Table, NCT), 파라미터 테이블(Parameter Table, PT), 표현 테이블(Expression Table, ET) 및 유형 테이블(Type Table, TT)을 포함한다.
신택스 파싱 테이블 그룹은 CSCIT(Control Signal and Context Information Table), SET(Syntax Element Table), SRT(Syntax Rule Table) 및 DVT(Default Value Table)를 포함한다.
이하, 관련 도면을 참조하여 FU 네트워킹 테이블들에 대하여 먼저 설명한 후, 신택스 파싱 테이블들을 설명한다.
도 12는 본 발명의 일실시예에 따른 FU 네트워킹 테이블의 구조를 나타낸 도면이다.
CDDL 기반 DD(Decoder Description)에서 사용하는 FU 네트워킹 테이블 은 도 12에 도시된 바와 같은 구조에 따라 이진 표현 비트스트림으로 기술된다.
각 테이블은 테이블 시작 코드(Table Start Code)와 테이블 식별을 위한 고유한 테이블 번호(Table Code)가 기술된다. 그리고 실질적인 테이블의 내용이 이진화(Binary)되어 비트스트림을 구성한다. 하나의 테이블 내용이 완전하게, 즉, 하나의 테이블 내용 전체가 비트스트림에 기록되면 테이블 마침 코드(Table End Code)가 추가된다.
테이블 시작 코드(Table Start Code)는 고정된 값이며 24비트의 2진수(111111111111111111111110)로 이루어져 있고, Table End Code는 고정된 값이며 24비트의 2진수(111111111111111111111111)로 이루어져 있고, 테이블 코드(Table Code)는 고유한 테이블 번호를 식별하기 위하여 아래의 표 1과 같이 4비트의 2진수로 이루어져 있다.
표 1
Table Code
VNT 0100
NCT 0101
PT 0110
FUIT 0111
TT 1000
ET 1001
reserved 1010 ~ 1111
도 13는 본 발명의 일실시예에 따른 VNT 테이블의 구조를 나타낸 도면이다.
도 13에 도시된 바와 같이, VNT 테이블은 FUID, VN 명칭(VN name), 입력포트(INPUT ports), 출력 포트(OUTPUT Ports) 및 QID 명칭(QID name) 필드를 포함한다.
기능부의 집합인 Network는 구조가 동일하면서 입력이나 출력으로 쓰이는 데이터가 동일하지 않은 경우가 존재할 수 있다. 이렇게 구조가 동일하지만 입/출력이 동일하지 않은 여러 개의 Network(개체들)을 효율적으로 구현하기 위하여 상속 개념을 이용한 기본 템플릿(Template) 객체를 생성하여 두고 이 템플릿(Template)을 모체로 하여 필요한 하위 객체(자손, 상속된 객체)를 만들어내는 형태를 구성한다. VNT는 기본 템플릿(Template)에 해당하는 정보를 기술한다.
FUID는 기능부(FU)가 이미 도구 박스(toolbox)에 존재할 수도 있고 존재하지 않는 새로운 것 일수도 있기 때문에, 기능부가 도구 박스에서 몇 번째 항목인지를 나타내는 인덱스 번호를 사용한다. 도구 박스에 존재할 경우에는 FUID flag 가 1로 세팅되고 존재하지 않는 경우에는 0으로 세팅된다. FUID flag가 0으로 세팅되는 경우 FUID가 기술되지 않고 넘어간다.
VN name은 기능부(FU)의 이름을 나타낸다. 2진화되어 비트스트림에 기록될 때에는 이름의 문자열 길이를 먼저 기술하고(8비트), 그 이후에 각 영문자를 하나씩 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
Version은 기능부(FU)의 버전을 나타낸다. 기능부의 버전이 존재하는 경우에는 version flag가 1 로 세팅되고 존재하지 않는 경우에는 0으로 세팅된다. 2진화되어 비트스트림에 기록될 때에는 버전의 문자열 길이를 먼저 기술하고(8비트), 그 이후에 각 영문자를 하나씩 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
입력 포트는 여러 개일 수가 있다. 하나의 입력 포트 이름을 2진화시켜 기록하기 전에 입력 포트 이름의 길이를 8비트로 표시하고, 그 이후에 입력 포트의 영문자를 하나씩 기록한다. 입력 포트의 타입이 존재할 수도 있고 존재하지 않을 수도 있기 때문에, 입력 포트에 대한 type flag가 존재 유무를 나타낸다. type flag가 1으로 세팅되는 경우 Type 테이블 인덱스가 8비트로 기술되고, 그렇지 않으면 Type 테이블 인덱스가 기술되지 않고 넘어간다. 여러 개의 입력 포트가 존재하는 경우, 하나의 입력 포트에 대한 기술이 끝나면, 전체 입력 포트의 기록이 완료되었는지 안되었는지를 플래그(INPUT ports flag)로 나타낸다. 만약 모든 입력 포트의 기술이 끝났으면 1로 세팅하고, 그렇지 않고 더 기록할 입력 포트가 존재한다면 0으로 세팅한다. 이후에 동일한 방식으로 남아있는 입력 포트를 기록한다.
출력 포트 또한 여러 개일 수 있으며, 2진 표현으로 비트스트림에 기록하는 형태는 입력 포트와 동일하다.
QID 명칭(QID name)은 기능부(FU)의 적절한 식별자로서 사용되는 문자열을 나타낸다. 모든 기능부가 QID 이름을 가지고 있지는 않기 때문에 QID 이름이 존재하는지 여부를 1비트로 기술한다. flag가 0으로 세팅되는 경우 QID가 기술되지 않고 넘어간다. flag가 1로 세팅되는 경우 QID 이름의 길이를 8비트로 기술한다. 그리고 나서 QID 이름을 하나씩 영문자로 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
전술한 바와 같은 구조의 바이너리 비트스트림으로 입력된 VNT 테이블은 복원부(1410) 및/또는 디코더 디스크립션 해석부(1420)에서 소정의 규칙에 따라 XML 기반 디코더 디스크립션으로 변환된다. 즉, 테이블을 나타내는 테이블 약자(영문자)가 이용되고, 테이블 내용은 '{' 로 시작되며 '}' 로 끝이 난다. 각 테이블의 필드는 ',' 로 구분되며, 하나의 행은 '(' 로 시작되며 ')' 로 끝이 나고, 하나의 필드가 여러 개의 값을 가지는 경우 '{' 로 시작되며 '}' 로 끝이 나며, 문자의 표현은 '"' 마크 사이에 기술된다.
VNT 테이블은 다음과 같은 텍스트형식으로 표현된다.
{
([FU_ID,] (VN Name), (Version),{INPUT PORTS}, {OUTPUT PORTS}, [QID name]),
…
}
XML 형식을 지원하는 MPEG-4 SP에 대한 VNT 테이블의 실시예는 다음과 같다.
VNT
{
//0
(-, "decoder", -, "mpeg", -, {"video_Y", -, "video_U", -, "video_V", -}, "mpeg4"),
(1, "parser", -, "BITS", -, {"BTYPE_Y", -, "BTYPE_U", -, "BTYPE_V", -, "MV_Y", -, "MV_U", -, "MV_V", -, "B_Y", -, "B_U", -, "B_V", -},-),
(-, "intra_FUs_16x16_Y", -, {"BTYPE", -, "QFS", -}, "f", -, "mpeg4"),
(-, "intra_FUs_8x8_C", -, {"BTYPE", -, "QFS", -}, "f", -, "mpeg4"),
(-, "motion_Y", -, {"MV", -, "BTYPE", -, "TEX", -}, "VID", -, "mpeg4"),
//5
(-, "motion_U", -, {"MV", -, "BTYPE", -, "TEX", -}, "VID", -, "mpeg4"),
(-, "motion_V", -, {"MV", -, "BTYPE", -, "TEX", -}, "VID", -, "mpeg4"),
(-, "byte2bit", -, "in8", -, "BITS", -, -),
(2, "Address16x16', -, {"MV", -, "BTYPE", -}, {"WA", -, "RA", -, "halfpel", -}, -),
(3, "Framebuf", -, {"RA", -, "WA", -, "WD", -}, "RD", -, -),
//10
(4, "Interpolate", -, {"RD", -, "halfpel", -}, "MOT", -, -),
(5, "Add", -, {"MOT", -, "TEX", -, "BTYPE", -}, "VID", -, -),
(6, "Address8x8", -, {"MV", -, "BTYPE", -}, {"WA", -, "RA", -, "halfpel", -}, -),
(7, "DCSplit", -, "IN", -, {"DC", -, "AC", -}, -),
(-, "DCR_16x16_L", -, {"BTYPE", -, "QFS_DC", -}, {"QF_DC", -, "PTR", -, "AC_PRED_DIR", -, "SIGNED", -, "QUANT", -}, "cal"),
//15
(8, "InverseScan", -, {"QFS_AC", -, "AC_PRED_DIR ", -}, "PQF_AC", -, -),
(9, "IAP_16x16", -, {"PQF_AC", -, "PTR", -, "AC_PRED_DIR", -}, "QF_AC", -, -),
(10, "Dequant", -, {"AC", -, "DC", -, "QP", -}, "OUT", -, -),
(11, "idct2d", -, {"\in\", -, "signed", -}, "out", -, -),
(-, "DCR_8x8_C", -, {"BTYPE", -, "QFS_DC", -}, {"QF_DC", -, "PTR", -, "AC_PRED_DIR", -, "SIGNED", -, "QUANT", -}, "cal"),
//20
(12, "IAP_8x8", -, {"PQF_AC", -, "PTR", -, "AC_PRED_DIR", -}, "QF_AC", -, -),
(13, "DCR_addressing_8x8", -, "BTYPE", -, {"A", -, "B", -, "C", -}, -),
(14, "DCR_invpred_8x8_C", -, {"BTYPE", -, "A", -, "B", -, "C", -, "QFS_DC", -}, {"QF_DC", -, "PTR", -, "AC_PRED_DIR", -, "SIGNED", -, "QUANT", -}, -),
(15, "DCR_addressing_16x16", -, "BTYPE", -, {"A", -, "B", -, "C", -}, -),
(16, "DCR_invpred_16x16_L", -, {"BTYPE", -, "A", -, "B", -, "C", -, "QFS_DC", -}, {"QF_DC", -, "PTR", -, "AC_PRED_DIR", -, "SIGNED", -, "QUANT", -}, -)
}
도 14는 본 발명의 일실시예에 따른 FUIT 테이블의 구조를 나타낸 도면이다.
도 14에 도시된 바와 같이, FUIT 테이블은 VNT index, Parent VNT index, Parameter indices 및 QID name 필드를 포함한다. FUIT에서는 VNT 정보인 기본 템플릿(Template)에 기반하여 실제 필요로 하는 Network로 사용되는 객체들을 생성하기 위한 주요 정보가 저장된다. 실제 필요로 하는 Network는 기본 템플릿(Template) 에서 파생된 하위 객체(자손, 상속된 객체, Instance)로 표현할 수 있다.
VNT index는 하나의 기능부를 나타내기 위한 VNT 테이블의 인덱스이다.
Parent VNT index는 하위 객체(Instance)가 필요로 하는 기본 템플릿을 나타낸다. VNT 테이블에서 참조하기 위한 인덱스이다. flag가 0으로 세팅되는 경우 VNT index 가 기술되지 않고 넘어간다.
PT indices는 하나의 기능부가 가지는 여러개의 파라미터를 나타내는 인덱스 리스트로서, 기능부가 가지는 파라미터는 없을 수도 있고, 여러 개 일 수도 있다. 파라미터의 존재 여부를 flag 로 나타내고, 파라미터 정보가 담긴 파라미터 테이블(PT) 인덱스를 이어서 기술한다. 만약 모든 파라미터 정보의 기술이 끝났으면 1로 세팅하고, 그렇지 않고 더 기록할 파라미터 테이블 인덱스가 존재한다면 0으로 세팅한다. 이후에 동일한 방식으로 남아있는 파라미터 테이블 인덱스를 기록한다.
QID name은 기능부(FU)의 적절한 식별자로서 사용되는 문자열을 나타낸다. 모든 기능부가 QID 이름을 가지고 있지는 않기 때문에 QID 이름이 존재하는지 여부를 1비트로 기술한다. flag가 0으로 세팅되는 경우 QID가 기술되지 않고 넘어간다. flag가 1로 세팅되는 경우 QID 이름의 길이를 8비트로 기술한다. 그리고 나서 QID 이름을 하나씩 영문자로 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
FUIT 테이블은 다음과 같은 텍스트형식으로 표현된다.
{
(VNT Index, [Parent VNT Index], {PT Indexes}, [QID name] ),
…
}
XML 형식을 지원하는 MPEG-4 SP에 대한 FUIT 테이블의 실시예는 다음과 같다.
FUIT
{
(1, 0, {21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37}, "mpeg4"),
(2, 0, {21, 24, 25, 23, 26, 27, 28, 29, 33, 34, 39}, "mpeg4"),
(3, 0, {21, 24, 25, 23, 26, 27, 28, 29, 33, 34, 39}, "mpeg4"),
(3, 0, {21, 24, 25, 23, 26, 27, 28, 29, 33, 34, 39}, "mpeg4"),
(4, 0, {38, 21, 40, 37, 49, 41, 7, 25, 26, 27, 29, 30, 35}, "mpeg4"),
...
...
(24, 14, {52, 21, 24, 25, 23, 26, 27, 28, 29, 33, 34, 39}, "cal")
}
도 15는 본 발명의 일실시예에 따른 PT 테이블의 구조를 나타낸 도면이다.
도 15에 도시된 바와 같이, PT 테이블은 Parameter name, Parent VNT index, ET index 및 TT index 필드를 포함한다.
Parameter는 Bitstream으로부터 생성되는 Syntax는 아니지만 기능부가 구성될 때 필요한 데이터를 생성하기 위해 사용된다. Parameter 는 Syntax가 아니기 때문에 데이터를 전송하는 Port를 통해 전달될 수 없다. 기능부의 집합인 Network 에서 그 Network에 포함되어 있는 하위 Network로 Parameter를 전달할 수 있다. 하나의 기능부가 가지는 Parameter에 대한 정보는 FUIT에 PT 인덱스로 기술된다. PT에서는 각 Parameter의 생성 정보를 가진다.
Parameter name에 있어서, 각 파라미터는 기본적으로 그 이름을 가진다. 파라미터 이름의 길이를 8비트로 기술한다. 그리고 나서 파라미터 이름을 하나씩 영문자로 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다
Parent VNT index에 있어서, 파라미터는 기본 템플릿이 되는 상위의 Network 기능 유닛에서 사용될 수 있고, 기본 템플릿을 통해 생성된 하위 기능 유닛 객체(Instance)에서 사용될 수도 있다. 상위의 Network 에서 사용되는 파라미터일 경우에는 flag가 1으로 세팅되며 VNT 테이블에서 참조하기 위한 인덱스가 기술된다. 그렇지 않고 하위 객체(Instance)에서 사용되는 경우에는 flag가 0으로 세팅되고 VNT 테이블 인덱스가 기술되지 않는다.
ET index에 있어서 파라미터의 형식을 나타내는 표현이 이루어질 수 있다. 이때 파라미터에 대한 표현이 존재하는 경우 flag 가 1로 세팅되고 존재하지 않는 경우에는 0으로 세팅된다. flag가 0으로 세팅되는 경우 ET 인덱스가 기술되지 않고 넘어간다. 표현에 대한 내용은 ET의 인덱스를 참조하게 된다.
TT index는 파라미터의 타입(파라미터의 종류)을 나타낸다. 파라미터의 타입이 존재하는지를 나타내는 flag가 1로 세팅되면 TT 인덱스가 기술되고, 그렇지 않으면 TT 인덱스가 기술되지 않고 넘어간다. 타입에 대한 내용은 TT의 인덱스를 참조하게 된다.
PT 테이블은 다음과 같은 텍스트형식으로 표현된다.
{
(Parameter Name, [VNT Index], [Expr Index], [Type Index]),
…
}
XML 형식을 지원하는 MPEG-4 SP에 대한 PT 테이블의 실시예는 다음과 같다.
PT
{
//0
("MAXW_IN_MB", 0, 0, -),
("MAXH_IN_MB", 0, 1, -),
("ADDR_SZ", 0, 2, -),
("PIX_SZ", 0, 3, -),
("MV_SZ", 0, 3, -),
//5
("SAMPLE_COUNT_SZ", 0, 4, -),
("SAMPLE_SZ", 0, 5, -),
("MB_COORD_SZ", 0, 4, -),
("BTYPE_SZ", 0, 0, -),
("NEWVOP", 0, 6, -),
//10
("INTRA", 0, 7, -),
("INTER", 0, 8, -),
("QUANT_MASK", 0, 9, -),
("ROUND_TYPE", 0, 10, -),
("FCODE_MASK", 0, 11, -),
//15
("FCODE_SHIFT", 0, 12, -),
("ACPRED", 0, 13, -),
("ACCODED", 0, 14, -),
("FOURMV", 0, 15, -),
("MOTION", 0, 4, -),
//20
("QUANT_SZ", 0, 12, -),
("MAXW_IN_MB", -, 16, -),
("SAMPLE_COUNT_SZ", -, 17, -),
("SAMPLE_SZ", -, 18, -),
("MB_COORD_SZ", -, 19, -),
//25
("BTYPE_SZ", -, 20, -),
("NEWVOP", -, 21, -),
("INTRA", -, 22, -),
("INTER", -, 23, -),
("QUANT_MASK", -, 24, -),
//30
("ROUND_TYPE", -, 25, -),
("FCODE_MASK", -, 26, -),
("FCODE_SHIFT", -, 27, -),
("ACPRED", -, 28, -),
("ACCODED", -, 29, -),
//35
("MOTION", -, 30, -),
("FOURMV", -, 31, -),
("MV_SZ", -, 32, -),
("SEARCHWIN_IN_MB", -, 33, -),
("QUANT_SZ", -, 34, -),
//40
("MAXH_IN_MB", -, 35, -),
("PIX_SZ", -, 36, -),
("BUF_SZ", 4, 37, -),
("FLAG_SZ", 4, 15, -),
("BUF_SZ", 5, 37, -),
//45
("FLAG_SZ", 5, 15, -),
("BUF_SZ", 6, 37, -),
("FLAG_SZ", 6, 15, -),
("FLAG_SZ", -, 38, -),
("ADDR_SZ", -, 39, -),
//50
("BUF_SZ", -, 40, -),
("SEARCHWIN_IN_MB", -, 41, -),
("DCVAL", -, 7, -)
}
도 16은 본 발명의 일실시예에 따른 NCT 테이블의 구조를 나타낸 도면이다.
도 16에 도시된 바와 같이, NCT 테이블은 Src FUIT index, Dst FUIT index, Src port name, Dst port name, Attribute name, Attribute value 및 ET Index 필드를 포함한다.
NCT에는 각각의 기능 유닛들 간에 데이터를 전송할 수 있는 통로인 Port에 관한 정보를 가지고 있다. 각각의 입력과 출력을 담당하는 Input Port와 Output Port들은 고유한 이름을 가질 수 있다.
Src FUIT index는 데이터가 하나의 기능 유닛에서 다른 하나로 전송될 때 그 데이터가 어디에서 오는지를 나타내야 한다. 데이터가 전송되기 시작하는 기능 유닛을 FUIT의 인덱스로 참조할 수 있다. 만약 비트스트림의 시작이 입력 파일 파일과 같이 기능 유닛 자체가 아니라면 '-'로 표현될 수 있다. 따라서 FUIT를 참조하는 인덱스인지 아닌지를 flag로 나타내고 FUIT 인덱스를 기록한다. flag가 0으로 세팅되는 경우 FUIT 인덱스가 기술되지 않고 넘어간다.
Dst FUIT index는 데이터가 도달하는 기능 유닛을 나타내며, 데이터가 도달하는 기능 유닛의 FUIT 인덱스를 나타낸다. 만약 비트스트림의 시작이 출력 파일과 같이 기능 유닛 자체가 아니라면 '-'로 표현될 수 있다. 따라서 FUIT를 참조하는 인덱스인지 아닌지를 flag로 나타내고 FUIT 인덱스를 기록한다. flag가 0으로 세팅되는 경우 FUIT 인덱스가 기술되지 않고 넘어간다.
Src port name and Dst port name는 데이터가 전송되는 Port의 이름을 나타낸다. 기능 유닛의 출력 포트가 데이터의 전송 시작 포트가 되며, 다른 기능 유닛의 입력 포트가 데이터가 도달하는 포트가 된다. 데이터가 전송되는 출력 포트와 입력 포트의 이름이 동일할 수도 있다. 따라서 두개의 전송 포트 이름이 동일한지 동일하지 않은지를 나타내는 same flag가 기술된다. same flag가 0으로 세팅되는 경우 Dst port 이름이 기술되지 않는다. 2진화되어 비트스트림에 기록될 때에는 이름의 문자열 길이를 먼저 기술하고(8비트), 그 이후에 각 영문자를 하나씩 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
Attribute name는 네트워크의 연결관계에 있어서 연결 속성 정보가 추가될 수 있다. 그러한 속성 정보의 이름이 존재할 경우에는 flag 가 1로 세팅되고 존재하지 않는 경우에는 0으로 세팅된다. flag가 0으로 세팅되는 경우 속성 이름이 기술되지 않고 넘어간다. 연결 속성 정보의 이름이 2진화되어 비트스트림에 기록될 때에는 이름의 문자열 길이를 먼저 기술하고(8비트), 그 이후에 각 영문자를 하나씩 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
Attribute value는 네트워크의 연결관계에서 연결 속성 정보의 이름이 존재하는 경우 그 값이 기술되는 경우가 있다. flag가 0으로 세팅되는 경우 속성 값이 기술되지 않고 넘어간다. 따라서 속성 값의 존재 여부를 flag 로 나타내고, 값을 나타내는 문자열 길이를 8비트로 기술한다. 그 이후에 각 영문자를 하나씩 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
ET index는 네트워크의 연결관계의 추가적인 표현이 이루어질 수 있다. 이때 추가적인 표현이 존재하는 경우 flag 가 1로 세팅되고 존재하지 않는 경우에는 0으로 세팅된다. flag가 0으로 세팅되는 경우 ET 인덱스가 기술되지 않고 넘어간다. 표현에 대한 내용은 ET의 인덱스를 참조하게 된다.
NCT 테이블은 다음과 같은 텍스트형식으로 표현된다.
{
([Src FUIT Index], [Dst FUIT Index], Src Port, Dst Port, [Attribute Name], [Attribute Value], [Expr Index]),
…
}
XML 형식을 지원하는 MPEG-4 SP에 대한 NCT 테이블의 실시예는 다음과 같다.
NCT
{
//FUIT 0-7
(-, 7, "mpeg", "in8", -, -, -),
(7, 0, "out", "BITS", -, -, -),
(0, 1, "BTYPE_Y", "BTYPE", -, -, -),
(0, 1, "B_Y", "QFS", -, -, -),
(0, 2, "BTYPE_U", "BTYPE", -, -, -),
(0, 2, "B_U", "QFS", -, -, -),
(0, 3, "BTYPE_V", "BTYPE", -, -, -),
(0, 3, "B_V", "QFS", -, -, -),
(1, 4, "f", "TEX", -, -, -),
(2, 5, "f", "TEX", -, -, -),
(3, 6, "f", "TEX", -, -, -),
(0, 4, "MV_Y", "MV", -, -, -),
(0, 4, "BTYPE_Y", "BTYPE", -, -, -),
(0, 5, "MV_U", "MV", -, -, -),
(0, 5, "BTYPE_U", "BTYPE", -, -, -),
(0, 6, "MV_V", "MV", -, -, -),
(0, 6, "BTYPE_V", "BTYPE", -, -, -),
(4, -, "VID", "video_Y", -, -, -),
(5, -, "VID", "video_U", -, -, -),
(6, -, "VID", "video_V", -, -, -),
//FUIT 8 9 10 11
(-, 8, "MV", "MV", -, -, -),
(-, 8, "BTYPE", "BTYPE", -, -, -),
(-, 11, "TEX", "TEX", -, -, -),
(-, 11, "BTYPE", "BTYPE", -, -, -),
(8, 9, "WA", "WA", -, -, -),
(8, 9, "RA", "RA", -, -, -),
(8, 10, "halfpel", "halfpel", -, -, -),
(9, 10, "RD", "RD", -, -, -),
(10, 11, "MOT", "MOT", -, -, -),
(11, 9, "VID", "WD", -, -, -),
(11, -, "VID", "VID", -, -, -),
//FUIT 12 13 14 15
(-, 12, "MV", "MV", -, -, -),
(-, 12, "BTYPE", "BTYPE", -, -, -),
(-, 15, "TEX", "TEX", -, -, -),
(-, 15, "BTYPE", "BTYPE", -, -, -),
(12, 13, "WA", "WA", -, -, -),
(12, 13, "RA", "RA", -, -, -),
(12, 14, "halfpel", "halfpel", -, -, -),
(13, 14, "RD", "RD", -, -, -),
(14, 15, "MOT", "MOT", -, -, -),
(15, 13, "VID", "WD", -, -, -),
(15, -, "VID", "VID", -, -, -),
//FUIT 16 17 18 19
(-, 16, "MV", "MV", -, -, -),
(-, 16, "BTYPE", "BTYPE", -, -, -),
(-, 19, "TEX", "TEX", -, -, -),
(-, 19, "BTYPE", "BTYPE", -, -, -),
(16, 17, "WA", "WA", -, -, -),
(16, 17, "RA", "RA", -, -, -),
(16, 18, "halfpel", "halfpel", -, -, -),
(17, 18, "RD", "RD", -, -, -),
(18, 19, "MOT", "MOT", -, -, -),
(19, 17, "VID", "WD", -, -, -),
(19, -, "VID", "VID", -, -, -),
//FUIT 20 21 22 23 24 25
(-, 20, "QFS", "IN", -, -, -),
(20, 21, "DC", "QFS_DC", -, -, -),
(20, 22, "AC", "QFS_AC", -, -, -),
(-, 21, "BTYPE", "BTYPE", -, -, -),
(21, 22, "AC_PRED_DIR", "AC_PRED_DIR", -, -, -),
(22, 23, "PQF_AC", "PQF_AC", -, -, -),
(23, 24, "QF_AC", "QF_AC", -, -, -),
(24, 25, "OUT", "IN", -, -, -),
(21, 23, "PTR", "PTR", -, -, -),
(21, 23, "AC_PRED_DIR", "AC_PRED_DIR", -, -, -),
(21, 24, "QUANT", "QP", -, -, -),
(21, 24, "QF_DC", "DC", -, -, -),
(21, 25, "signed", "signed", -, -, -),
(25, -, "out", "f", -, -, -),
//FUIT 26 27 28 29 30 31
(-, 26, "QFS", "IN", -, -, -),
(26, 27, "DC", "QFS_DC", -, -, -),
(26, 28, "AC", "QFS_AC", -, -, -),
(-, 27, "BTYPE", "BTYPE", -, -, -),
(27, 28, "AC_PRED_DIR", "AC_PRED_DIR", -, -, -),
(28, 29, "PQF_AC", "PQF_AC", -, -, -),
(29, 30, "QF_AC", "QF_AC", -, -, -),
(30, 31, "OUT", "IN", -, -, -),
(27, 29, "PTR", "PTR", -, -, -),
(27, 29, "AC_PRED_DIR", "AC_PRED_DIR", -, -, -),
(27, 30, "QUANT", "QP", -, -, -),
(27, 30, "QF_DC", "DC", -, -, -),
(27, 31, "signed", "signed", -, -, -),
(31, -, "out", "f", -, -, -),
//FUIT 32 33
(-, 32, "BTYPE", "BTYPE", -, -, -),
(-, 33, "QFS_DC", "QFS_DC", -, -, -),
(-, 33, "BTYPE", "BTYPE", -, -, -),
(32, 33, "A", "A", -, -, -),
(32, 33, "B", "B", -, -, -),
(32, 33, "C", "C", -, -, -),
(33, -, "PTR", "PTR", -, -, -),
(33, -, "AC_PRED_DIR", "AC_PRED_DIR", -, -, -),
(33, -, "SIGNED", "SIGNED", -, -, -),
(33, -, "QF_DC", "QF_DC", -, -, -),
(33, -, "QUANT", "QUANT", -, -, -),
//FUIT 34 35
(-, 34, "BTYPE", "BTYPE", -, -, -),
(-, 35, "QFS_DC", "QFS_DC", -, -, -),
(-, 35, "BTYPE", "BTYPE", -, -, -),
(34, 35, "A", "A", -, -, -),
(34, 35, "B", "B", -, -, -),
(34, 35, "C", "C", -, -, -),
(35, -, "PTR", "PTR", -, -, -),
(35, -, "AC_PRED_DIR", "AC_PRED_DIR", -, -, -),
(35, -, "SIGNED", "SIGNED", -, -, -),
(35, -, "QF_DC", "QF_DC", -, -, -),
(35, -, "QUANT", "QUANT", -, -, -)
}
도 17은 본 발명의 일실시예에 따른 ET 테이블의 구조를 나타낸 도면이다.
도 17에 도시된 바와 같이, ET 테이블은 Kind, Literal kind, Literal value, Variable name, Operator, Child ET index, Args ET index 필드를 포함한다.
ET 테이블은 Bitstream으로부터 얻어내는 정보가 아니며 구문(Syntax)의 표현을 위하여 참조되는 테이블이다. 표현을 위한 어떤 수식이나 정보를 나타내기 위하여 기술된다. 이 테이블은 표현에 사용되는 표현 기법의 종류와 값, 변수의 이름 등을 나타낸다.
Kind는 표현식이 나타내는 종류를 의미한다. 이 필드는 비트스트림에 3비트로 기술된다. 표현식은 아래의 표와 같은 5가지 종류가 존재한다.
표 2
Kind Code
Literal 000
Var 001
Application 010
UnaryOp 011
BinOpSeq 100
Reserved 101 ~ 111
Literal kind는 이전 Kind 필드의 값이 Literal 로 지정되었을 때에만 Literal 이 가질 수 있는 종류을 나타낸다. flag가 0으로 세팅되는 경우 Literal kind 가 기술되지 않고 넘어간다. Literal kind는 아래의 표 3과 같은 종류의 코드를 갖는다.
표 3
Literal kind Code
Boolean 000
Integer 001
Real 010
String 011
Character 100
Reserved 101 ~ 111
Literal value는 이전 Kind 필드의 값이 Literal 로 지정되었을 때 Literal 이 가지는 값을 나타낸다. flag가 0으로 세팅되는 경우 Literal Value 가 기술되지 않고 넘어간다. flag가 1로 세팅되는 경우 Literal Value 의 길이를 8비트로 기술한다. 그리고 나서 Literal Value 를 하나씩 영문자로 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
Variable name은 이전 Kind 필드의 값이 Var 로 지정되었을 때 Variable 의 이름을 나타낸다. flag가 0으로 세팅되는 경우 Variable name 이 기술되지 않고 넘어간다. flag가 1로 세팅되는 경우 Variable name 의 길이를 8비트로 기술한다. 그리고 나서 Variable name 을 하나씩 영문자로 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
Operator는 표현식이 연산을 나타내는 경우 연산자를 나타낸다. flag가 0으로 세팅되는 경우 Operator 가 기술되지 않고 넘어간다. flag가 1로 세팅되는 경우 Operator 의 길이를 8비트로 기술한다. 그리고 나서 Operator 를 하나씩 영문자로 기록한다. 각 영문자는 아스키 코드(Ascii code)로 표현될 수 있다.
Child ET index는 표현식이 다른 표현식을 포함하게 되는 경우 하위 표현식에 대한 기술을 할 수 있다. flag가 0으로 세팅되는 경우 하위 표현식에 대한 ET 인덱스가 가 기술되지 않고 넘어간다. flag가 1로 세팅되는 경우 하위 표현식을 나타내는 ET 인덱스를 8비트로 기록한다.
Args ET index는 표현식이 인자를 포함하는 경우 인자에 대한 기술을 ET 인덱스로 나타낼 수 있다. flag가 0으로 세팅되는 경우 인자를 표현하기 위한 ET 인덱스가 기술되지 않고 넘어간다. flag가 1로 세팅되는 경우 인자를 표현하기 위한 ET 인덱스를 8비트로 기록한다.
ET 테이블은 다음과 같은 XML 텍스트형식으로 표현된다.
{
(Kind, [Literal-Kind], [value], [name], [Op], [Child-Expr(ET No.)] [Args-Expr(ET No.)]),
…
}
XML 형식을 지원하는 MPEG-4 SP에 대한 ET 테이블의 실시예는 다음과 같다.
ET
{
//0
("Literal", "Integer", "12", -, -, -, -),
("Literal", "Integer", "10", -, -, -, -),
("Literal", "Integer", "20", -, -, -, -),
("Literal", "Integer", "9", -, -, -, -),
("Literal", "Integer", "8", -, -, -, -),
//5
("Literal", "Integer", "13", -, -, -, -),
("Literal", "Integer", "2048", -, -, -, -),
("Literal", "Integer", "1024", -, -, -, -),
("Literal", "Integer", "512", -, -, -, -),
("Literal", "Integer", "31", -, -, -, -),
//10
("Literal", "Integer", "32", -, -, -, -),
("Literal", "Integer", "448", -, -, -, -),
("Literal", "Integer", "6", -, -, -, -),
("Literal", "Integer", "1", -, -, -, -),
("Literal", "Integer", "2", -, -, -, -),
//15
("Literal", "Integer", "4", -, -, -, -),
("Var", -, -, "MAXW_IN_MB", -, -, -),
("Var", -, -, "SAMPLE_COUNT_SZ", -, -, -),
("Var", -, -, "SAMPLE_SZ", -, -, -),
("Var", -, -, "MB_COORD_SZ", -, -, -),
//20
("Var", -, -, "BTYPE_SZ", -, -, -),
("Var", -, -, "NEWVOP", -, -, -),
("Var", -, -, "INTRA", -, -, -),
("Var", -, -, "INTER", -, -, -),
("Var", -, -, "QUANT_MASK", -, -, -),
//25
("Var", -, -, "ROUND_TYPE", -, -, -),
("Var", -, -, "FCODE_MASK", -, -, -),
("Var", -, -, "FCODE_SHIFT", -, -, -),
("Var", -, -, "ACPRED", -, -, -),
("Var", -, -, "ACCODED", -, -, -),
//30
("Var", -, -, "MOTION", -, -, -),
("Var", -, -, "FOURMV", -, -, -),
("Var", -, -, "MV_SZ", -, -, -),
("Literal", "Integer", "3", -, -, -, -),
("Var", -, -, "QUANT_SZ", -, -, -),
//35
("Var", -, -, "MAXH_IN_MB", -, -, -),
("Var", -, -, "PIX_SZ", -, -, -),
("Literal", "Integer", "...", -, -, -, -),
("Var", -, -, "FLAG_SZ", -, -, -),
("Var", -, -, "ADDR_SZ", -, -, -),
//40
("Var", -, -, "BUF_SZ", -, -, -),
("Var", -, -, "SEARCHWIN_IN_MB", -, -, -)
}
유형 테이블(Type Table, TT)은 Type Name, Entry Name, Expr index 및 Type index 필드를 포함한다.
이하, 신택스 파싱 테이블들에 대하여 설명한다.
CSCIT는 파싱 기능부가 SET 및 SRT를 이용한 프로세스의 결과 정보인 엘리먼트 정보(예를 들어, CSCI)에 대한 상세 정보가 기술된 것이다. 즉, CSCIT는 종래 비트스트림으로부터 처리되어 CSCI 저장부에 저장되고, 디코딩 기능부들에 의해 이용될 모든 의미있는 자료(즉, 엘리먼트 정보)들에 대한 정보를 가진다. CSCIT는 해당 엘리먼트 정보의 고유 번호로서 구분자인 인덱스(C), 플래그(flag), 해당 엘리먼트 정보의 이름(Element Name), 해당 엘리먼트 정보의 자료 구조적인 특성을 지정하기 위한 속성(예를 들어, 해당 엘리먼트 정보의 저장 공간 크기, 해당 엘리먼트 정보가 배열형(Array)인지 여부 등), 해당 엘리먼트 정보가 신택스 파싱 과정에서만 이용되는지 또는 전체적인 디코딩 과정에서 이용되는지를 나타내는 Global/Local 등을 포함한다. CSCIT는 textual description이나 binary description(비트 변환된 바이너리 코드 형태) 등의 기술 방식으로 기술될 수 있을 뿐 아니라, 상기 부분 디코더 디스크립션 중 필요한 최소한의 데이터가 유사 스크립트 언어로 기술될 수도 있다.
SET는 입력된 종래 비트스트림의 신택스(syntax)들에 대한 정보에 의해 구성된 디코더 디스크립션이다. SET는 각 신택스에 대한 인덱스(index), 엘리먼트 명칭(Element Name), 파라메터(Paramter) 및 SET-프로세스(process by SET-PROC) 정보를 포함한다. 여기서 인덱스는 SRT에서 사용되는 각 신택스를 구분하는 구분자(S)이다. 엘리먼트 명칭은 신택스의 이름으로, 신택스의 의미나 역할에 따라 명명될 수 있다. 파라메터는 SRT에 기술된 파싱 과정이 SET의 파싱 알고리즘을 호출할 때 인자 값으로 제공되며, 이 인자 값은 고정된 상수나 비트스트림으로부터 계산된 값, 또는 파싱 과정에서 도출된 자료를 저장하기 위한 버퍼 공간(예를 들어, CSCI 메모리)의 식별자일 수 있다. 파라메터를 통해 전달된 인자 값은 인덱스(P)를 통해 구분되며, 각 인자 값은 엘리먼트 정보(즉, CSCI 정보(C))로서, 획득한 데이터를 저장할 때 사용될 수 있으며, 추후 해당 엘리먼트 정보가 처리 과정에서 데이터로서 필요한 경우 다시 파라메터 인덱스(P)를 이용하여 해당 엘리먼트 정보가 리드(read)될 수 있다. 또한, 파라메터는 SRT에서 지정한 바에 따라 CSCI 정보(C) 뿐 아니라 상수 값을 나타낼 수도 있다. SET-프로세스는 각 비트스트림 신택스를 입력 받아 어떤 가공 절차를 거쳐 출력 데이터인 엘리먼트 정보를 생성할 것인지의 과정을 기술한다.
SET는 textual description이나 binary description(비트 변환된 바이너리 코드 형태) 등의 기술 방식으로 기술될 수 있을 뿐 아니라, 상기 부분 디코더 디스크립션 중 필요한 최소한의 데이터가 유사 스크립트 언어로 기술될 수도 있다.
다음으로, SRT는 종래 비트스트림 내의 각 신택스간의 연결 정보를 나타낸 것이다. 즉, SRT는 각 신택스를 호출하고 다음 신택스로 이동하도록 지시하는 정보를 가진다. 파싱 기능부는 SRT를 이용하여 종래 비트스트림을 읽어 들이거나 엘리먼트 정보가 CSCI 저장부에 저장 및/또는 갱신되는 순서를 규정한다.
SRT는 인덱스(R), 파라메터(P), 규칙 정보를 포함한다.
인덱스(R)은 각 연결 정보(Rule)를 구분하도록 한다. 신택스의 인덱스(S)는 특정 연결 인덱스에서 처리할 신택스를 지정하므로, 파싱 기능부(또는 syntax 파싱을 수행하는 기능부들)는 SET를 이용하여 해당 신택스에 대해 지정된 프로세스를 수행한다. 파라메터는 SRT에 기술된 파싱 과정이 계층적으로 하위 단계에 또 다른 SRT의 파싱 알고리즘을 호출할 때 인자 값으로 제공되며, 이 인자 값은 고정된 상수나 비트스트림으로부터 계산된 값, 또는 파싱 과정에서 도출된 자료를 저장하기 위한 버퍼 공간(예를 들어, CSCI 메모리)의 식별자일 수 있다. 파라메터를 통해 전달된 인자 값은 인덱스(P)를 통해 구분되며, 각 인자 값은 획득한 데이터를 저장할 때 사용될 수 있으며, 추후 해당 엘리먼트 정보가 처리 과정에서 데이터로서 필요한 경우 다시 파라메터 인덱스(P)를 이용하여 해당 엘리먼트 정보를 리드(read)될 수 있다. 또한 파라메터는 SRT에서 지정한 바에 따라 CSCI 정보(C) 뿐 아니라 상수 값을 나타낼 수도 있다. 규칙 정보는 신택스 파싱이 처리되는 과정을 기술한 것으로, 분기와 반복 등 제어 구문을 사용할 수 있으며 하위 계층에 또다른 SRT나 SET의 엘리먼트를 호출하여 신택스 파싱을 처리할 수 있다.
입력 데이터는 해당 연결 인덱스에서의 연결 제어를 위한 조건 판단에 사용될 엘리먼트 정보의 목록을 나타낸다.
분기의 수는 후속하는 신택스에 연결되어질 수 있는 경우의 수로서, 해당 연결 인덱스에서 가지는 분기 경로의 총 수를 나타낸다. 분기 정보는 분기의 수 만큼 필요한 분기 정보가 존재(#1, #2, #3… 등)하며, 다음에 어떤 연결 인덱스를 처리할 것인지를 결정하도록 하는 조건 판단 알고리즘이다. 분기 정보에 의해 어떤 순서에 따라 어떤 내용을 읽어 들일지가 직접적으로 판단될 수 있다. 분기의 수가 1인 경우에는 입력 데이터가 존재하지 않으며, 분기 정보에 지정된 연결 인덱스를 처리하기 위해 즉시 진행한다. 그러나, 분기의 수가 2 이상인 경우에는 조건 판단이 수행(조건문 이후에는 다음 번 연결 정보(R)로 구성됨)되고 상응하는 연결 인덱스를 처리하기 위해 진행한다.
파싱 기능부는 해당 연결 인덱스에서 정의한 신택스를 처리하여 CSCI 저장부를 갱신한 후, 갱신된 CSCI 저장부(532)의 엘리먼트 정보를 참조하여 읽어들인 후 분기 조건 판단에 활용한다. 이는 예를 들어, 인덱스 R0의 분기 정보의 분기 조건인 'C0==1'에서의 C0는 신택스 S0를 처리한 후의 엘리먼트 정보 C0이다.
SRT는 textual description이나 binary description(비트 변환된 바이너리 코드 형태) 등의 기술 방식으로 기술될 수 있을 뿐 아니라, 상기 부분 디코더 디스크립션 중 필요한 최소한의 데이터가 유사 스크립트 언어로 기술될 수도 있다.
마지막으로, DVT는 각 부호화기/복호화기에서 사용하는 허프만 테이블(Huffman table) 정보가 기록된 디코더 디스크립션이다. MPEG-1/2/4/AVC에서는 각 부호화 시 엔트로피 코딩(entropy coding)을 수행한다. 이 때 주로 허프만 코딩(Huffman coding) 방법이 이용되며, 이 경우 이용되는 정보가 허프만 테이블(Huffman table)이다. 통합 코덱을 구현하기 위해서는 각 복호 시 해당 복호화기에서 사용될 허프만 테이블(Huffman table) 정보가 제공되어야 한다. 따라서, 본 발명에 따른 디코딩 디스크립션 내에 신택스 파싱시 각 신택스(syntax)에 해당하는 허프만 테이블(Huffman table) 정보를 포함한다. 물론, 각 표준에 상응하는 허프만 테이블 정보가 이미 디스크립션 저장부에 기록되어 있는 경우 DVT의 전송은 생략되거나 코덱 번호(Codec #, 1120)와 프로파일 및 레벨 번호(Profile and level #, 1130)만이 포함될 수도 있을 것이다.
DVT는 각 허프만 테이블에 대한 이름(name), 허프만 코딩에 의해 압축되어 출력되는 실제 값(value) 및 압축된 실제 값이 종래 비트스트림에 저장될 때 사용되는 코드 값(code)을 포함한다. 예를 들어, MCBPC 값을 압축하여 3이란 실제 값(value)을 얻었다면, 허프만 테이블 매핑(Huffman table mapping) 작업(예를 들어, SET의 PROCESS 부분)에 의해 종래 비트스트림(316)에는 코드 값(code) 011이 기록된다. 다른 예로서, 앞서 예시한 SET의 인덱스 S77의 Process 부분에는 VLD[1]이라 기록되어 있어 VLD라는 함수를 호출하게 된다. 이 함수에 의해 미리 지정된 길이(고정길이 또는 가변 길이)만큼 종래 비트스트림(316)을 읽어 코드 값(code)값을 얻은 후 허프만 테이블 매핑(Huffman table mapping) 작업에 의해 상응하는 실제 값(value)을 얻을 수 있다. 이 때 사용되는 Huffman table은 [1], 즉 1번째 테이블인 CBPY이다.
DVT는 textual description이나 binary description(비트 변환된 바이너리 코드 형태) 등의 기술 방식으로 기술될 수 있을 뿐 아니라, 상기 디코더 디스크립션 중 필요한 최소한의 데이터가 유사 스크립트 언어로 기술될 수도 있다.
일 예로, DVT는 아래와 같이 textual description될 수 있다.
DVT{((0,1), (1,001), (2,010), (3,011), (4,0001), (5,000001), (6,000010), (7,000011), (8,000000001), (9,NULL)) ((0,0011), (1,00101), (2,00100), (3,1001), (4,00011),(5,0111), (6,000010), (7,1011), (8,00010), (9,000011), (10,0101), (11,1010), (12,0100), (13,1000), (14,0110), (15,11), (16,000000), (17,000001), (18,NULL)) ((0,011), (1,11), (2,10), (3,010), (4,001), (5,0001), (6,00001), (7,000001), (8,0000001), (9,00000001), (10,000000001), (11,0000000001), (12,00000000001), (13,NULL)) ((0,11), (1,10), (2,01), (3,001), (4,0001), (5,00001), (6,000001), (7,0000001), (8,00000001), (9,000000001), (10,0000000001), (11,00000000001), (12,000000000001), (13,NULL))...
다른 예로서, DVT는 아래와 같이 binary description될 수 있다.
0000001111111111111111111111111011111000011000110010001101000011011001000001001100000010011000001000110000011010010000000010000011111001000011001010010100101001000010010010010100011001000111001100000100010010110010100010001100000110010001010010010100010001000010010000010001100001011001100000000011000000100000111110001101100010110001010000110100001100100100000100101000010011000000100111000000101000000000010100100000000101010000000000101011000000000010000011111000101100010100001001000110010010000010010100001001100000010…
전술한 바와 같이, 본 발명에 따른 복호화기는 기본적으로 XML 기반, 즉 BSDL 기반 디코더 디스크립션을 이용하여 디코딩 프로세스가 처리되는 한편, 제2 실시예를 통하여 상술한 바와 같이, 바이너리 형태로 압축된 CDDL 기반 디코더 디스크립션을 입력받는 경우에도 이를 XML 기반(BSDL 기반) 디코더 디스크립션으로 변환하여 처리할 수 있다.
BSDL에 기반한 DD는 높은 가독성을 갖고 있기 때문에, DD를 기반으로 다양한 구현(Implementation)을 시도하고자 하는 개발자에게 적합한 방식으로 간주된다. 그러나 XML 기반인 BSDL 서식이 자체적으로 압축 기능을 갖고 있지 않기 때문에, DD의 실시간 전송이 필요한 환경에서는 용량 관계 상 비효율적일 수 있다. 따라서, 전술한 본 발명의 제2 실시예에서와 같이 보다 적은 용량으로 동일한 처리 과정을 표현하는 CDDL 서식을 이용해 BSDL을 표현함으로서, 실시간 환경이 필요로 하는 압축 효과를 이끌어 낼 수 있다.
CDDL과 BSDL 등 서로 다른 종류의 DD를 상호간의 방식으로 변환하기 위하여, 그 중간 형태 (Intermediate form) 로서 비트스트림 구문 목록을 활용할 수 있다. 이 목록은 표준 규격 문서에서 제시하는 것과 동일, 또는 유사한 형태로 제공되는 목록으로, 영상 비트스트림이 규격에 따라 내장하게 되면 다양한 구문 정보들의 내역과 비트 길이를 나타낸다. 모든 종류의 DD 서식은 표준에 정의된 규격에 준수하여 작성되었음이 자명하기 때문에, 표준 규격 문서의 형태로 정보를 추출해 냄으로서 서로 다른 종류의 DD 규격 간 변환을 보다 손쉽게 할 수 있다.
도 18은 비트스트림 구문 목록을 활용한 CDDL/BSDL 간 상호 변환 관계를 나타낸다.
CDDL로부터 구문 정보를 추출해 내기 위하여, 다음과 같은 간결한 규칙을 CDDL 기반 DD에 적용할 수 있다.
1. SRT의 구문 정보를 읽어들인다
A. 하위 SRT 요소 호출 (Rn();) : 비트스트림 상에서의 하위 구문 요소 집합 호출로 정의한다.
B. SET 요소 호출 (Sn();) : 각각의 개별 구문 요소로 판단한다.
C. 분기 및 반복문 : 그 조건을 그대로 목록 상에 보존한다.
2. SET 요소를 판독하여 비트스트림 관련 구문을 식별한다
A. READ 명령어: 고정된 비트 길이를 가진 구문 요소로 판단한다. 읽어들이는 비트의 길이는 해당 요소에 정의된 바, 또는 해당 요소를 호출하는 상위 SRT 명령어에서 정의한 바에 따른다. 만일 Byte-align 파라메터가 사용되었을 경우, 해당 구문을 start/end code로 간주한다.
B. SEEK 명령어: When be followed by IF condition in parent SRT element, it will be considered as nextbits() function.
C. 분기/반복문이 포함된 경우: 가변 길이를 가진 구문 요소로 판단한다.
D. VLD (Huffman/Golomb…) 명령어가 쓰인 경우 : 가변 길이를 가진 구문 요소로 판단한다.
E. 그 밖에 다수의 명령어가 결합된 경우: 가변 길이를 가진 구문 요소로 판단한다.
F. READ/SEEK/VLD 등 비트스트림을 읽는 명령어가 없는 경우: 해당 SET 요소는 비트스트림의 구성과 관계가 없는 것으로 간주되어, 처리 과정에서 무시된다.
3. 모든 CSCI 요소들은 비트스트림 상에서 출현하는 개별 구문 정보를 저장하기 위한 공간으로 간주한다.
상기 규칙을 적용하여 하기 표 4의CDDL 구문을 아래와 같이 XML 구문으로 변환할 수 있다.
표 4
Element name Mnemonic Bits
do {
CSCI_0 bslbf 32bit
CSCI_1 uimsbf 8bit
while (next_bits()==00 00 01 B2) {
R3();
}
R1();
} while (next_bits()==433) {
CSCI_2 bslbf 32bit
SET
{ ("READ P1 > P2;"),
("READ P1 B > P2;"),
("SEEK P1 > P2;"),
("SEEK P1 B > P2;")
}
SRT
{("
do {
S1(32, C0);
S0(8, C1);
S3(32,V0);
while(V0==434){
R3();
S3(32,V0);
}
R1();
S3(32,V0);
}while(V0!=433);
S1(32, C2);
")}
이제까지 본 발명에 따른 복호화 장치 및 비트스트림 복호화를 위한 구문 해석 방법을 설명함에 있어 MPEG-4를 중심으로 설명하였으나, MPEG-1, MPEG-2 및 이외의 동영상 부호화/복호화 표준에 아무런 제한없이 동일하게 적용할 수 있음은 당연하다.
또한, 각 디코더 디스크립션들에 포함되는 정보 역시 하나의 표준에 의한 디코딩 수행을 위한 기능부들의 연결 관계, 해당 기능부에 요구되는 처리 프로세스 등에 관한 정보만으로 기술되지 않고, 복수의 표준에 의한 디코딩 수행을 위한 정보로 기술될 수도 있음은 자명하다.
예를 들어, 확장 비트스트림에 포함된 인코딩된 비디오 데이터의 초기 복수의 프레임은 MPEG-2로 인코딩되고, 후속하는 복수의 프레임은 MPEG-4로 인코딩되며, 나머지 프레임은 MPEG-1으로 인코딩되었다고 가정하자. 이 경우, 인코딩된 비디오 데이터의 디코딩을 위해 디코더 디스크립션에 포함되는 디코더 디스크립션 정보들은 인코딩 방법을 달리하는 각 프레임들이 툴 박스(510)에 포함된 각 표준에 따른 기능부들이 유기적으로 결합되어 동작될 수 있도록 구현될 것임은 자명하다.
전술한 바와 같은 복호화 프로세서에서 해당 기능부들을 로드하고 재조합하여 디코더를 형성하기 위하여는 효율적이고 신속하게 기능부들을 구분하고 로드할 수 있는 메커니즘이 필요하다. 이하, 본 발명에 따른 기능부(FU)들의 구체적인 구분 식별 방법 및 툴박스의 상세 구성을 설명하기로 한다.
도 19는 본 발명의 일실시예에 따른 툴박스의 상세 구성을 나타내는 예시도이다.
도 19에 도시된 바와 같이, 본 발명에 따른 툴박스는 복수의 기능부들을 유형에 따라 저장/관리하기 위하여 별도로 구분된 복수의 툴박스의 집합으로 구성될 수 있다. 이하, 상기 복수의 툴박스의 집합을 툴박스 유닛이라 칭하기로 한다. 즉, 기능부들은 그 유형에 따라 툴박스 유닛 내에서 다수의 툴박스에 구분되어 저장/관리되며, 각각의 툴박스(Toolbox)는 툴박스 넘버(Tool Box Number, TBN)로 구분되고 식별되어 관리된다. 즉, 상기 툴박스 넘버는 일종의 툴박스 식별 정보이다.
즉, 본 발명에 따른 툴박스 유닛은 MPEG 비디오 복호화와 관련된 기능부들을 저장하는 MPEG 비디오 툴박스; MPEG 오디오 복호화와 관련된 기능부들을 저장하는 MPEG 오디오 툴박스; MPEG 그래픽 복호화와 관련된 기능부들을 저장하는 MPEG 그래픽스 툴박스; 및 시스템 복호화와 관련된 기능부들을 저장하는 시스템 툴박스(System toolbox)등 멀티미디어 복호화에 관련된 기능부로 구성될 수 있으며, 사용자가 별도로 정의한 사용자 정의 기능부(Customized FU)들을 저장하는 사용자 정의 툴박스를 더 포함할 수 있다. 본 실시예에서는 MPEG 표준화 형식에 따른 기능부들 및 그외 기타 사용자가 정의한 기능부들을 예시적으로 설명하고 있으나, 본 발명은 MPEG 부호화 포맷에 한정되는 것이 아니라 다양한 부호화 포맷에 자유롭게 적용될 수 있음은 당업자에게 자명하다 할 것이다.
상기 툴박스의 툴박스 넘버는 아래의 표 5와 같이 정의될 수 있다.
표 5
툴박스 넘버(Tool Box Number, TBN) 툴박스(Toolbox)
0 MPEG video toolbox
1 MPEG audio toolbox
2 MPEG graphics toolbox
3 System toolbox
4 Customized toolbox
5 Reserved
… …
n Reserved
상기 툴박스 유닛 및 툴박스들은 하나의 저장 수단 내에서 논리적으로 구분되어 구현될 수도 있고, 복수의 저장 수단으로 물리적으로 구분되어 구현될 수도 있다.
도 20은 본 발명의 일실시예에 따른 기능부 식별 정보(FUID)를 나타내는 예시도이다.
도 20에 도시된 바와 같이 본 발명에 따른 기능부 식별 정보(FUID)는 해당 기능부가 속하는 툴박스를 나타내는 툴박스 넘버(TBN) 필드 및 해당 기능부의 고유 식별 정보를 나타내는 FU 넘버(FU Number) 필드를 포함하여 구성된다.
상기 툴박스 넘버 필드는 4 비트로 구현되고, 상기 FU 넘버 필드는 28 비트로 구현될 수 있다. 28비트로 FU 넘버 필드를 구현함으로써, 268,435,456개의 기능부들을 하나의 툴박스에 저장하고 식별하여 이용할 수 있다.
상기 FUID는 위에서 언급하였던 VNT에서의 FUID 필드에 적용되는 등의 방법을 통해 디코더 디스크립션에 포함되어 표현될 수 있다. 또한, 동일한 의미의 정보를 담고 있는 XML 기반의 연결 제어 정보에서도, 디코더 구성에 사용되는 각 기능부를 지칭하는 데에 사용될 수 있음은 자명하다.
도 21은 본 발명에 따른 기능부 구분/식별 메커니즘을 설명하기 위한 개념도이다.
도 21을 참조하면, 복호화부의 BSDL 파서 또는 디코더 디스크립션 해석부는 수신된 디코더 디스크립션을 해석하여 기능부 식별 정보(FUID)(1950)을 추출하고, 디코더 형성부는 상기 기능부 식별 정보(FUID)(1950)로부터 디코더를 조합하는데 필요한 기능부들의 TBN 및 FU 넘버를 리딩하고, 리딩된 TBN 및 FU 넘버에 해당하는 기능부를 해당 툴박스로 요청하면, 요청된 기능부들은 디코딩 솔루션에 로딩되고 연결됨으로써 재조합 디코더를 형성하여 입력 데이터를 복호화한다.
예를 들어, 첫번째 FUID가 TBN이 0이고 FU 넘버가 69이므로, 툴박스 내의 MPEG 비디오 툴박스(MPEG video toolbox)(1910)에 저장된 기능부들 중에서 FU 넘버가 69인 기능부가 요청되어 로딩된다.
본 발명에 따른 복호화 장치는 다양한 코덱에 기반한 비트스트림을 복호하기 위하여 여러 종류의 비트스트림을 읽어 들이기 위한 비트스트림 신택스 파서와 각각의 정보들을 디코딩하기 위한 FU가 필요하다.
이 중 비트스트림의 처리 과정은 대부분의 종류의 비트스트림에 대해 구문 요소의 순서와 길이를 조정함으로써 비교적 일반화하여 처리하는 것이 가능하므로, 디코더 디스크립션과 같은 부가 정보를 보내는 것만으로 복호화 장치에서 처리할 수 있다. 하지만, 만일 부호화 장치에서 동영상을 인코딩 하는 데 사용한 특정 기능에 대응하는 FU가 복호화 장치에 존재하지 않을 경우, 해당 비트스트림을 디코딩하는 것은 불가능하다. 이러한 문제는 특히 MPEG에 제약받지 않는 사용자 정의 고덱(Customized Codec)을 사용할 경우에 발생할 수 있다.
이러한 문제를 해결하기 위하여 본 발명에서는 FU가 복호화 장치에 전달되는 메커니즘을 정의한다. 이하, 부호화 장치 측에서 부호화한 데이터를 복호하는데 필요한 FU를 송신하고, 이를 복호화 장치에서 수신하여 처리하는 또 다른 실시예들을 설명하기로 한다.
도 22는 본 발명의 또 다른 실시예에 따른 부호화 장치이고, 도 23은 본 발명의 또 다른 실시예에 따라 송신되는 비트스트림의 패킷 구성을 나타내는 예시도이다.
도 22에 도시된 바와 같이 본 발명의 또 다른 실시예에 따른 복호화 장치는 송신하고자 하는 비디오, 오디오 또는 멀리티미디어 데이터 등을 부호화하여 부호화된 데이터(encoded data)를 생성하는 부호화부(2110), 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(FU)들 및 그 연결 관계 등을 기술하는 디코더 디스크립션을 생성하는 디코더 디스크립션 생성부(2120), 상기 디코더 디스크립션을 입력받아 상기 부호화된 데이터를 복호하기 위해 필요한 기능부(FU)들에 대한 정보인 FU 리스트를 생성하여 출력하는 FU 리스트 생성부(2140), 상기 기능부(FU)들을 저장하는 툴박스(2130), 상기 부호화된 데이터를 입력 받고, 입력받은 부호화된 데이터에 상응하는 디코더 디스크립션, FU 리스트 및 기능부(FU)들을 입력 받아 패킷화하여 출력하는 패킷화부(packetizing unit)(2150), 상기 패킷화부로부터 출력된 패킷들을 시스템 비트스트림으로 통합하여 생성하는 시스템 비트스트림 생성부(2160) 및 시스템 비트스트림을 송신하는 송신부(미도시)를 포함하여 구성될 수 있다.
부호화부(2110)는 도 2를 참조하여 설명한 호화기 등과 같은 종래의 표준 부호화기는 물론 사용자가 새로이 정의하는 비표준 부호화기 등이 적용될 수 있다.
디코더 디스크립션 생성부(2120)는 부호화된 데이터를 복호할 수 있는 디코더를 구성하는데 필요한 기능부들에 기능부 식별 정보(FUID) 목록 및 기능부들의 연결 관계, 기능부들의 입력 데이터, 신택스 정보, 신택스 연결 정보 등을 기술하며, 상기 기능부 식별 정보(FUID)는 툴박스 유닛 내에서 해당 기능부가 속하는 툴박스를 나타내는 툴박스 넘버(TBN) 필드 및 해당 기능부의 고유 식별 정보를 나타내는 FU 넘버(FU Number) 필드를 포함하여 구성된다.
툴박스(2130)의 구체적인 구성은 도 19를 참조하여 전술한 바와 같다. 그 기술적 요지를 요약하면, 툴박스(2130)는 복수의 기능부들을 유형에 따라 저장/관리하기 위하여 별도로 구분된 복수의 툴박스의 집합인 툴박스 유닛으로 구성되며, 기능부들은 그 유형에 따라 툴박스 유닛 내에서 다수의 툴박스에 구분되어 저장/관리되며, 각각의 툴박스(Toolbox)는 툴박스 넘버(Tool Box Number, TBN)로 구분되고 식별되어 관리된다. 상기 툴박스 넘버는 일종의 툴박스 식별 정보이다.
패킷화부(2150)는 부호화된 데이터와 그에 상응하는 디코더 디스크립션 및 FU들을 입력받고, 각각에 별도의 패킷 ID(PID)를 부여하여 패킷화한다. 도 23을 참조하면, 패킷화부(2150)에서 생성하는 패킷은 부호화된 데이터 패킷(3200), 디코더 디스크립션 패킷(3300), FU 리스트 패킷(3400) 및 기능부 패킷(3510, 3520, 3530, …)을 포함한다.
패킷화부(2150)는 입력된 부호화된 데이터를 소정의 패킷 아이디(PID 010)를 부여하여 부호화된 패킷(3200)으로 패킷화하고, 입력된 디코더 디스크립션을 소정의 패킷 아이디(PID 020)를 부여하여 디코더 디스크립션 패킷(3300)으로 패킷화한다.
한편, FU는 프로그램 구문으로 구현될 수 있는데, 이 경우 FU의 데이터 용량을 고려하여 본 실시예에서는 이를 FU 리스트 헤더와 분리하여 별도의 데이터로 전송한다. 즉, 부호화된 데이터에 상응하는 FU들(3510, 3520, 3530)에 각각 별도의 패킷 ID(PID 101, PID 102, PID 103)를 부여하여 각각 패킷화하고, 상기 FU 리스트 정보를 별도의 패킷 ID(100)를 부여하여 FU 리스트 패킷(3400)으로 패킷화한다. 상기 FU 리스트 패킷에는 부호화된 데이터를 복호화할 수 있는 디코더를 구성하는 FU들의 패킷에 대한 패킷 아이디 및 기능부 식별 정보(FUID)를 포함한다.
시스템 비트스트림 생성부(2160) 는 패킷화부에서 생성된 패킷들을 입력받아 전송용 비트스트림인 시스템 비트스트림(3600)으로 통합 생성한다. 부호화된 데이터 및 디코더 디스크립션에 부가하여 FU 정보(FU 리스트 패킷 및 FU 패킷)가 더 포함된 본 실시예의 비트스트림을 전술한 확장 비트스트림과 구별하기 위해 시스템 비트스트림(3600)이라 칭한다.
전술한 바와 같이, 본 실시예에 따른 시스템 비트스트림(System Bitstream) 내의 데이터 패킷들은 Packet ID (PID) 라 불리는 식별정보를 이용하여 식별된다. PID에 기반하여 방송 비트스트림 내에 존재하는 서로 다른 종류의 패킷에 선별적으로 접근하는 것은 종래에 다수의 채널 간 구분, 다중음성 방송에서 각 음성 스트림의 구별 등에 널리 사용되는 방법이다.
이러한 방법을 응용하여, 전송되고 있는 FU 리스트와 FU 자체를 분리함으로서, 수신 측은 현재 자신의 디코더에 구비되어 있는 FU과 전송된 FU 목록을 대조함으로서 자신이 구비하지 않은 FU의 목록을 손쉽게 도출해낼 수 있다.
도 24는 본 발명의 또 다른 실시예에 따라 방송 환경에서 데이터가 송수신되는 과정을 개념적으로 나타내는 예시도이다.
도 24에 도시된 바와 같이, 본 발명의 또 다른 실시예에 따른 부호화 장치 및 복호화 장치가 방송 환경에 적용되는 경우, 본 발명의 또 다른 실시예에 따른 부호화 장치를 포함하는 송신 장치(2100)는 본 발명의 또 다른 실시예에 따른 복호화 장치를 포함하는 수신 장치(2200)로 비디오, 오디오 및 멀티 미디어 데이터를 부호화한 부호화된 데이터, 디코더 디스크립션, 기능부(FU) 및 기타 부가 데이터(auxiliary data)를 방송 비트스트림에 포함하여 송신한다.
일방향 전송인 방송 환경에서는 수신 장치에 복호화 과정에 필요한 FU가 존재하는지의 여부를 확신할 수 없으므로, 방송 비트스트림의 일부분으로서 FU를 주기적으로 전송할 수 있다. FU를 주기적으로 전송하는 이유는 방송 수신자가 임의의 시간에 방송 서비스에 연결할 것이므로, 수신자가 동영상 비트스트림의 어느 지점에 연결할지 불분명하기 때문이다. .
도 25는 본 발명의 또 다른 실시예에 따른 복호화 장치의 구성도이다.
도 25에 도시된 바와 같이, 본 발명의 또 다른 실시예에 따른 복호화 장치는 패킷 처리부(depacketizing unit)(2210), 디코더 형성부(2220), 디코딩 솔루션(2230), 기능부 비교부(2240) 및 툴박스(2250)를 포함한다.
패킷 처리부(2210)는 수신된 비트스트림을 입력받아 패킷 유형별로 분리하여, 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 FU를 출력한다.
기능부 비교부(2240)는 패킷 처리부(2210)로부터 FU 리스트를 입력받고, FU 리스트의 FU 식별정보를 추출하여 툴박스(2250)에 저장된 FU들의 FU 식별정보와 비교하여 신규한 FU가 수신되었는지 여부를 판단한다. 상기 판단 결과, 신규한 FU가 수신된 경우에는 해당 FU를 패킷 처리부(2210)로부터 입력받아 툴박스에 전달하여 툴박스(2250)가 신규 FU를 저장하도록 한다. 한편, 기능부 비교부(2240)는 툴박스에 이미 저장돼 있는 FU들은 별도의 처리 없이 무시함으로써 추가적인 처리 시간 소요를 최소화할 수 있다.
디코더 형성부(2220)는 디코더 디스크립션을 입력받아 해석하여, 상기 부호화된 데이터를 복호하는데 필요한 FU 들을 툴박스(2250)로부터 디코딩 솔루션(2230)으로 로딩하고 조합하여 재조합 디코더를 형성한다.
디코딩 솔루션(2230)은 부호화된 데이터를 입력받고, 상기 재조합 디코더를 통해 상기 부호화된 데이터를 복호화하여 출력한다.
전술한 복호화 장치는 PC 등의 환경에서 프로그램 메모리를 통해 구동되는 소프트웨어 방식일 수도 있고, STB/PVR/DVD-P등의 경우와 같이 고정된 칩셋에 기반한 하드웨어 또는 펌웨어 방식일 수도 있다. 어느 경우이든, 해당 환경하에서의 시스템은 외부로부터 추가로 전송된 FU를 읽어 들이고 이를 일시적 또는 항시적으로 저장해 두기 위한 적응적 툴 라이브러리 (Adaptive Tool Library) 구조의 툴박스(2250)를 가질 수 있다. 즉, 툴박스(2250)는 소프트웨어 환경에서는 외부 FU를 저장, 관리하기 위한 여분의 하드디스크/메모리 공간일 수 있고, 하드웨어 환경에서는 별도의 저장매체, Rewritable ROM, 또는 RAM등 가변 가능한 메모리 장치에 의해 구현할 수 있다.
본 실시예를 통해 부호화 측은 수신된 데이터를 복호하는데 필요한 FU를 수신할 수 있으며, 부호화 측은 비표준의 FU 및 사용자가 별도로 정의한 사용자 정의 FU를 이용하고 복호화 측에 제공할 수 있다.
이제까지 도 22내지 도 25를 참조하여 일방향 통신 구조인 방송 환경에서부호화된 데이터와 함께 FU가 제공되는 실시예를 설명하였다. 이하에서는 양방향 통신 환경에서 FU를 제공하는 본 발명의 또 다른 실시예에 따른 부호화 및 복호화 장치에 대하여 설명하기로 한다.
도 26은 본 발명의 또 다른 실시예에 따라 양방향 통신 환경에서 FU 및 부호화된 데이터가 송수신되는 과정을 개념적으로 나타내는 예시도이다.
도 26을 참조하면, 우선 본 발명의 또 다른 실시예에 따른 부호화 시스템이 전송 비트스트림을 전송한다(S4310). 상기 전송 비트스트림은 비디오, 오디오 또는 멀티미디어 데이터 등을 부호화한 부호화된 데이터와 상기 부호화된 데이터의 디코더 디스크립션 및 FU 리스트를 포함한다.
이어서, 복호화 시스템(4200)은 상기 전송 비트스트림을 수신하고, 수신된 전송 비트스트림에서 상기 부호화된 데이터, 디코더 디스크립션 및 FU 리스트를 분리 추출한 후, 상기 FU 리스트와 툴박스에 저장된 FU들과 비교하여(S4320), 신규 FU가 있는지 판단한다(S4330).
상기 판단 결과, 수신된 FU 리스트에 신규 FU가 없는 경우에는 수신된 디코더 디스크립션 및 툴박스에 저장된 FU들을 이용하여 디코더를 조합하고, 수신된 부호화된 데이터를 디코딩한다(S4360).
한편, 상기 판단 결과, 수신된 FU 리스트에 신규 FU가 있는 경우에는 부호화 시스템으로 신규 FU의 전송을 요청하는 FU 요청 신호를 송신한다(S4340).
이어서, 상기 FU 요청 신호를 수신한 부호화 시스템은 수신된 FU 요청 신호에 응답하여 요청된 FU 들을 포함하는 FU 전송 데이터를 송신하고(S4350), 복호화 시스템은 상기 FU 전송 데이터를 수신하고, 요청한 FU를 추출하여 툴박스에 저장한 후, 수신된 디코더 디스크립션 및 툴박스에 저장된 FU들을 이용하여 디코더를 조합하고, 수신된 부호화된 데이터를 디코딩한다(S4360).
본 실시예는 IPTV 등 송/수신이 가능한 환경에 적용 가능하다. 이러한 환경에서, 수신자는 자신이 전달받은 FU 리스트에 기반해 송신 측에 특정 FU의 전달을 요청할 수 있게 된다.
도 27은 도 26의 부호화 시스템의 일실시예 구성도이다.
도 27에 도시된 바와 같이, 부호화 시스템은, 부호화부(2110), 디코더 디스크립션 생성부(2120), 툴박스(2130), FU 리스트 생성부(2140), 패킷화부(2150), 전송 비트스트림 생성부(4160), FU 전송 데이터 생성부(4170), 통신부(4180) 및 FU 요청 신호 처리부(4190)을 포함하여 구성될 수 있다.
본 실시예의 상기 구성들 중에서 도 22를 참조하여 설명한 부호화 장치의 구성과 명칭 및 참조 부호가 동일한 것들은 그 기능 및 역할이 서로 동일한 구성이다. 따라서, 도 22와 동일한 구성에 대한 중복되는 설명은 생략하고 본 실시예의 특징적 구성의 기능 및 역할에 중점을 두고 상술하기로 한다.
패킷화부(2150)는 입력된 데이터를 고유의 패킷 아이디를 부여하여 패킷화하여 출력하는 구성으로서 그 기본적인 기능은 도 22를 참조하여 전술한 패킷화부(2150)와 동일하다. 다만, 본 실시예에 따른 구체적인 기능을 설명하면 다음과 같다. 패킷화부(2150)는 부호화부(2110)로부터 입력받은 부호화된 데이터, 디코더 디스크립션 생성부(2120)로부터 입력받은 디코더 디스크립션 및 FU 리스트 생성부(2140)으로부터 입력받은 FU 리스트를 각각 고유의 패킷 아이디를 부여하여 패킷화하고 전송 비트스트림 생성부(4160)로 출력한다. 또한, 패킷화부(2150)는 툴박스로부터 입력받은 기능부(FU)를 패킷화하여 FU 전송 데이터 생성부로 출력한다(4170). 이 때, 패킷화부(2150)는 FU 리스트 패킷을 생성하는 과정에서 FU 리스트에 포함된 FU 각각에 패킷 아이디를 부여하고 부여된 패킷 아이디 정보를 FU 리스트 패킷에 FU 식별정보와 매칭하여 포함시키며, FU 패킷을 생성하는 과정에서는 툴박스로부터 입력받은 FU에 대하여 FU 리스트 패킷을 생성하는 과정에서 부여된 패킷 아이디를 부여하여 패킷화한다.
전송 비트스트림 생성부(4160)은 패킷화부(4150_로부터 입력받은 패킷들을 통합하여 전송 비트스트림을 생성하여 출력한다(4160). 즉, 전송 비트스트림 생성부(4160)은 패킷화부(2150)로부터 부호화된 데이터 패킷, 디코더 디스크립션 패킷 및 FU 리스트 패킷을 입력받고 이들을 통합하여 전송 비트스트림을 생성하여 출력한다(4160). 상기 전송 비트스트림은 필요에 따라 부호화된 데이터 패킷, 디코더 디스크립션 패킷 및 FU 리스트 패킷 중 어느 하나 이상의 조합을 포함할 수 있다.
FU 전송 데이터 생성부(4170)는 패킷화부로부터 입력받은 기능부(FU)를 유무선 통신망을 통해 송신하기 위한 포맷인 FU 전송 데이터로 변환 생성하여 출력한다.
통신부는(4180)는 외부의 통신망과 데이터를 송수신하기 위한 구성으로서, 구체적으로는 상기 전송 비트스트림 또는 FU 전송 데이터를 입력받아 송신하고, 수신된 FU 요청 신호를 FU 요청 신호 처리부(4190)로 출력한다.
FU 요청 신호 처리부(4190)는 입력된 FU 요청 신호를 해석하여 FU 요청 신호에서 요청된 FU가 툴박스(2130_로부터 패킷화부(2150)로 출력되도록 한다.
도 28은 도 26의 복호화 시스템의 일실시예 구성도이다.
도 28에 도시된 바와 같이, 복호화 시스템은 통신부(4260), 패킷 처리부(2210), FU 리스트 처리부(4270), 기능부 요청부(4280), 디코더 형성부(2220), 디코딩 솔루션(2230) 및 툴박스(2250)를 포함하여 구성될 수 있다.
본 실시예의 상기 구성들 중에서 도 25를 참조하여 설명한 복호화 장치의 구성과 명칭 및 참조 부호가 동일한 것들은 그 기능 및 역할이 서로 동일한 구성이다. 따라서, 도 25와 동일한 구성에 대한 중복되는 설명은 생략하고 본 실시예의 특징적 구성의 기능 및 역할에 중점을 두고 상술하기로 한다.
통신부는(4260)는 외부의 통신망과 데이터를 송수신하기 위한 구성으로서, 구체적으로는 통신망을 통해 전송 비트스트림 또는 FU 전송 데이터를 수신하여 출력하고 FU 요청신호를 해당 부호화 시스템으로 송신한다.
패킷 처리부는(2210) 입력받은 데이터를 패킷 유형별로 분리하여 출력하는 구성으로서, 그 기본적인 기능은 도 25를 참조하여 전술한 패킷 처리부(2210)과 동일하다. 다만, 본 실시예에 따른 구체적인 기능을 설명하면 다음과 같다. 패킷 처리부(2210)는 입력된 전송 비트스트림을 패킷 아이디를 이용하여 디코더 디스크립션, 부호화된 데이터 및 FU 리스트로 분리 추출하여 출력한다. 이 때, 상기 디코더 디스크립션은 디코더 형성부(2220)로 입력되고, 부호화된 데이터는 디코딩 솔루션(2230)으로 입력되며 FU 리스트는 FU 리스 처리부(4270)으로 입력된다. 또한, 패킷 처리부(2210)는 FU 전송 데이터로부터 FU들을 각각 분리하여 툴박스(2250)로 출력한다. 이 때, 출력된 FU는 툴박스(2250)로 입력되어 저장된다.
FU 리스트 처리부(4270)는 입력된 FU 리스트에 포함된 기능부 식별정보를이용하여 툴박스(2250)에 저장된 FU 들과 비교하여 신규 FU가 FU 리스트에 포함되어 있는지 여부를 판단한다. FU 리스트 처리부(4270)는 상기 판단 결과, 신규 FU가 포함된 경우 신규 FU의 기능부 식별정보를 기능부 요청부로 출력하고, 상기 판단 결과, 신규 FU가 없는 경우에는 디코더 형성부(2220) 및 디코딩 솔루션(2230)이 디코딩 프로세스를 시작하도록 한다.
기능부 요청부(4280)는 입력된 기능부 식별정보를 이용하여 FU 요청 신호를 생성하여 통신부(4260)로 출력하여, 해당 부호화 시스템으로 송신하도록 한다.
상기에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술분야에서 통상의 지식을 가진 자라면 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.
영상 코덱에 이용될 수 있다.

Claims (15)

  1. 데이터를 부호화하여 부호화된 데이터(encoded data)를 생성하는 부호화부;
    상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 및 그 연결 관계를 기술하는 디코더 디스크립션을 생성하는 디코더 디스크립션 생성부;
    상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 대한 FU 리스트를 생성하여 출력하는 FU 리스트 생성부; 및
    상기 부호화된 데이터를 입력 받고, 상기 입력받은 부호화된 데이터에 상응하는 디코더 디스크립션, FU 리스트 및 기능부(FU)들을 입력 받아 패킷화하여 출력하는 패킷화부를 포함하는 부호화 장치.
  2. 제 1 항에 있어서,
    상기 패킷화부는,
    상기 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 기능부(FU)들 각각에 고유의 패킷 아이디를 부여하고 패킷화하여, 부호화된 데이터 패킷, 디코더 디스크립션 패킷, FU 리스트 패킷 및 기능부 패킷을 생성하는 것을 특징으로 하는 부호화 장치.
  3. 제 2 항에 있어서,
    상기 부호화된 데이터 패킷, 디코더 디스크립션 패킷, FU 리스트 패킷 및 기능부 패킷을 통합한 비트스트림을 생성하는 비트스트림 생성부를 더 포함하는 부호화 장치.
  4. 제 2 항에 있어서,
    상기 FU 리스트 패킷은 해당 FU들의 FU 식별 정보 및 해당 FU 패킷들의 패킷 아이디 정보를 포함하는 것을 특징으로 하는 부호화 장치.
  5. 복수의 기능부(Function Unit, FU)들을 저장하는 툴박스;
    입력받은 비트스트림을 패킷 유형별로 분리하여, 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 FU를 출력하는 패킷 처리부;
    상기 FU 리스트를 입력받고, FU 리스트의 FU 식별정보를 추출하여 상기 툴박스에 저장된 FU들의 FU와 비교하여 FU 리스트에 신규 FU가 있는지 여부를 판단하고, 신규 FU가 있는 경우에는 해당 FU를 상기 패킷 처리부로부터 입력받아 툴박스에 전달하여 툴박스(2250)가 신규 FU를 저장하도록 하는 기능부 비교부;
    상기 디코더 디스크립션을 해석하여, 상기 부호화된 데이터를 복호하는데 필요한 FU들을 상기 툴박스로부터 하기 디코딩 솔루션으로 로딩하고 조합하여 디코더를 형성하도록 하는 디코더 형성부; 및
    상기 부호화된 데이터를 입력받아 상기 조합된 디코더를 통해 복호화하는 디코딩 솔루션을 포함하는 복호화 장치.
  6. 제 5 항에 있어서,
    상기 툴박스는,
    MPEG 비디오 복호화와 관련된 기능부들을 저장하는 MPEG 비디오 툴박스;
    MPEG 오디오 복호화와 관련된 기능부들을 저장하는 MPEG 오디오 툴박스;
    MPEG 그래픽 복호화와 관련된 기능부들을 저장하는 MPEG 그래픽스 툴박스; 및
    사용자 정의 기능부들을 저장하는 사용자 정의 툴박스 중 어느 하나 이상을 포함하는 것을 특징으로 하는 복호화 장치.
  7. 복수의 기능부들을 저장하는 툴박스;
    데이터를 부호화하여 부호화된 데이터(encoded data)를 생성하는 부호화부;
    상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 및 그 연결 관계를 기술하는 디코더 디스크립션을 생성하는 디코더 디스크립션 생성부;
    상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 대한 FU 리스트를 생성하여 출력하는 FU 리스트 생성부;
    상기 부호화된 데이터를 입력 받고, 상기 입력받은 부호화된 데이터에 상응하는 디코더 디스크립션 및 FU 리스트를 패킷화하여 출력하고, 상기 기능부(FU)들을 입력받아 패킷화하여 출력하는 패킷화부; 및
    외부로부터 수신된 FU 요청 신호에 상응하는 FU를 상기 툴박스로부터 출력하여 상기 패킷화부로 입력하도록 하는 FU 요청 신호 처리부를 포함하는 부호화장치.
  8. 제 7 항에 있어서,
    상기 툴박스는,
    상기 기능부들을 유형별로 구분하여 저장한 복수의 툴박스로 구성되며,
    상기 복수의 툴박스는,
    MPEG 비디오 복호화와 관련된 기능부들을 저장하는 MPEG 비디오 툴박스;
    MPEG 오디오 복호화와 관련된 기능부들을 저장하는 MPEG 오디오 툴박스;
    MPEG 그래픽 복호화와 관련된 기능부들을 저장하는 MPEG 그래픽스 툴박스; 및
    사용자 정의 기능부들을 저장하는 사용자 정의 툴박스 중 어느 하나 이상을 포함하는 것을 특징으로 하는 부호화 장치.
  9. 복수의 기능부(Function Unit, FU)들을 저장하는 툴박스;
    외부의 부호화 장치와 데이터를 송수신하는 통신부;
    상기 통신부에서 수신한 데이터를 패킷 유형별로 분리하여, 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 FU를 출력하는 패킷 처리부;
    상기 FU 리스트를 상기 툴박스에 저장된 FU 들과 비교하여 신규 FU가 상기 FU 리스트에 포함되어 있는지 여부를 판단하고, 신규 FU가 포함된 경우 신규 FU를 상기 외부의 부호화 장치로 요청하는 FU 요청 신호를 생성하는 FU 리스트 처리 및 기능부 요청부;
    상기 디코더 디스크립션을 해석하여, 상기 부호화된 데이터를 복호하는데 필요한 FU들을 상기 툴박스로부터 하기 디코딩 솔루션으로 로딩하고 조합하여 재조합 디코더를 형성하도록 하는 디코더 형성부; 및
    상기 부호화된 데이터를 입력받아 상기 재조합 디코더를 통해 복호화하는 디코딩 솔루션을 포함하는 복호화 장치.
  10. 제 9 항에 있어서,
    상기 패킷 처리부는,
    전송 비트스트림을 입력 받고, 상기 전송 비트스트림으로부터 부호화된 데이터, 디코더 디스크립션 및 FU 리스트을 추출하는 것을 특징으로 하는 복호화 장치.
  11. 제 9 항에 있어서,
    상기 패킷 처리부는,
    FU 전송 데이터를 입력받고, 상기 FU 전송 데이터로부터 FU를 추출하여 툴박스에 저장하도록 하는 것을 특징으로 하는 복호화 장치.
  12. (a) 데이터를 부호화하여 부호화된 데이터(encoded data)를 생성하는 단계;
    (b) 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 및 그 연결 관계를 기술하는 디코더 디스크립션을 생성하는 단계;
    (c) 상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 대한 FU 리스트를 생성하는 단계; 및
    (d) 상기 부호화된 데이터 및 상기 부호화된 데이터에 상응하는 디코더 디스크립션, FU 리스트 및 기능부(FU)들을 패킷화하는 단계를 포함하는 부호화 방법.
  13. 입력받은 비트스트림을 패킷 유형별로 분리하여, 부호화된 데이터, 디코더 디스크립션, FU 리스트 및 FU를 분리 추출하는 단계;
    상기 FU 리스트의 FU 식별정보를 추출하여 상기 툴박스에 저장된 FU들의 FU와 비교하여 FU 리스트에 신규 FU가 있는지 여부를 판단하는 단계;
    상기 판단 결과, 신규 FU가 있는 경우, 해당 FU를 툴박스에 전달하여 툴박스가 신규 FU를 저장하도록 하는 단계;
    상기 디코더 디스크립션을 해석하여, 상기 부호화된 데이터를 복호하는데 필요한 FU들을 상기 툴박스로부터 로딩하고 조합하여 재조합 디코더를 형성하는 단계; 및
    상기 부호화된 데이터를 상기 재조합 디코더를 통해 복호화하는 단계를 포함하는 복호화 방법.
  14. 데이터를 부호화하여 부호화된 데이터(encoded data)를 생성하는 단계;
    상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 및 그 연결 관계를 기술하는 디코더 디스크립션을 생성하는 단계;
    상기 부호화된 데이터를 복호하기 위한 디코더를 구성하는 기능부(Function Unit, FU)들 대한 FU 리스트를 생성하는 단계;
    상기 부호화된 데이터 및 상기 부호화된 데이터에 상응하는 디코더 디스크립션 및 FU 리스트를 패킷화하고, 입력되는 기능부(FU)들을 패킷화하는 패킷화부; 및
    외부로부터 수신된 FU 요청 신호에 상응하는 FU를 툴박스로부터 출력하여 상기 패킷화부로 입력하도록 하는 FU 요청 신호 처리부를 포함하는 부호화 방법.
  15. 외부의 부호화 장치로부터 전송 비트스트림을 수신하는 단계;
    상기 전송 비트스트림을 패킷 유형별로 분리하여, 부호화된 데이터, 디코더 디스크립션 및 FU 리스트를 추출하는 단계;
    상기 FU 리스트를 상기 툴박스에 저장된 FU 들과 비교하여 신규 FU가 상기 FU 리스트에 포함되어 있는지 여부를 판단하는 단계;
    상기 판단 결과, 신규 FU가 포함된 경우, 신규 FU를 상기 외부의 부호화 장치로 요청하는 FU 요청 신호를 생성하여 송신하는 단계;
    외부의 부호화 장치로부터 FU 전송 데이터를 수신하는 단계;
    상기 FU 전송 데이터로부터 FU를 추출하여 툴박스에 저장하는 단계;
    상기 디코더 디스크립션을 해석하여, 상기 부호화된 데이터를 복호하는데 필요한 FU들을 로딩하고 조합하여 재조합 디코더를 형성하는 단계; 및
    상기 부호화된 데이터를 상기 재조합 디코더를 통해 복호화하는 단계를 포함하는 복호화 방법.
PCT/KR2010/000605 2009-02-19 2010-02-01 부호화/복호화 방법 및 장치 WO2010095823A2 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/202,552 US9031136B2 (en) 2009-02-19 2010-02-01 Device and method for encoding/decoding

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2009-0013814 2009-02-19
KR20090013814A KR20100094709A (ko) 2009-02-19 2009-02-19 부호화/복호화 방법 및 장치

Publications (2)

Publication Number Publication Date
WO2010095823A2 true WO2010095823A2 (ko) 2010-08-26
WO2010095823A3 WO2010095823A3 (ko) 2010-11-04

Family

ID=42634300

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2010/000605 WO2010095823A2 (ko) 2009-02-19 2010-02-01 부호화/복호화 방법 및 장치

Country Status (3)

Country Link
US (1) US9031136B2 (ko)
KR (1) KR20100094709A (ko)
WO (1) WO2010095823A2 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101372418B1 (ko) * 2007-10-19 2014-03-12 (주)휴맥스 비트스트림 디코딩 장치 및 방법
DE102009043286A1 (de) * 2009-09-29 2011-03-31 Abb Technology Ag Verfahren und Vorrichtung zur Überprüfung der Konfigurierung eines Computersystems
WO2019059107A1 (ja) * 2017-09-20 2019-03-28 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 符号化装置、復号装置、符号化方法及び復号方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100654601B1 (ko) * 2005-10-06 2006-12-08 주식회사 휴맥스 통합 코덱 장치 및 방법
KR100705971B1 (ko) * 2005-07-20 2007-04-12 주식회사 휴맥스 비트스트림 인코딩/디코딩 방법 및 장치
KR20070075197A (ko) * 2006-01-12 2007-07-18 주식회사 휴맥스 통합 코덱 장치 및 방법
KR100858244B1 (ko) * 2005-01-14 2008-09-12 주식회사 휴맥스 동영상 인코딩/디코딩 장치 및 방법
KR20090002508A (ko) * 2007-06-29 2009-01-09 주식회사 휴맥스 동영상 데이터의 인코딩/디코딩 방법 및 장치

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6570926B1 (en) * 1999-02-25 2003-05-27 Telcordia Technologies, Inc. Active techniques for video transmission and playback
US7254175B2 (en) * 1999-07-02 2007-08-07 Crystalmedia Technology, Inc. Frame-accurate seamless splicing of information streams
US7403564B2 (en) * 2001-11-21 2008-07-22 Vixs Systems, Inc. System and method for multiple channel video transcoding
KR100441604B1 (ko) * 2002-03-19 2004-07-23 삼성전자주식회사 멀티미디어 스트리밍 서비스를 위한 패킷 전송장치 및 그방법
AU2003283636A1 (en) * 2002-12-04 2004-06-23 Koninklijke Philips Electronics N.V. Method and apparatus for selecting particular decoder based on bitstream format detection
KR100604032B1 (ko) * 2003-01-08 2006-07-24 엘지전자 주식회사 복수 코덱을 지원하는 장치와 방법
WO2005071970A1 (en) * 2004-01-16 2005-08-04 General Instrument Corporation Method and apparatus for determining timing information from a bit stream
US7590059B2 (en) * 2004-05-21 2009-09-15 Broadcom Corp. Multistandard video decoder
US8149922B2 (en) 2004-10-22 2012-04-03 Humax Co., Ltd. Device and method for merging different video codec
US7872668B2 (en) * 2005-08-26 2011-01-18 Nvidia Corporation Video image processing with programmable scripting and remote diagnosis
US8879635B2 (en) * 2005-09-27 2014-11-04 Qualcomm Incorporated Methods and device for data alignment with time domain boundary
US9503777B2 (en) * 2007-06-05 2016-11-22 Broadcom Corporation Method and system for unified start code emulation prevention bits processing for AVS
US20090074376A1 (en) * 2007-09-17 2009-03-19 Himax Technologies Limited Apparatus and method for efficient av synchronization

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100858244B1 (ko) * 2005-01-14 2008-09-12 주식회사 휴맥스 동영상 인코딩/디코딩 장치 및 방법
KR100705971B1 (ko) * 2005-07-20 2007-04-12 주식회사 휴맥스 비트스트림 인코딩/디코딩 방법 및 장치
KR100654601B1 (ko) * 2005-10-06 2006-12-08 주식회사 휴맥스 통합 코덱 장치 및 방법
KR20070075197A (ko) * 2006-01-12 2007-07-18 주식회사 휴맥스 통합 코덱 장치 및 방법
KR20090002508A (ko) * 2007-06-29 2009-01-09 주식회사 휴맥스 동영상 데이터의 인코딩/디코딩 방법 및 장치

Also Published As

Publication number Publication date
US9031136B2 (en) 2015-05-12
WO2010095823A3 (ko) 2010-11-04
KR20100094709A (ko) 2010-08-27
US20110299603A1 (en) 2011-12-08

Similar Documents

Publication Publication Date Title
WO2014081226A1 (ko) 영상 디코딩 방법 및 이를 이용하는 장치
WO2014003515A1 (ko) 멀티미디어 시스템에서 적응적 미디어 구조 송신 방법 및 장치
WO2020222588A1 (ko) 적응적 모션 벡터 해상도를 이용한 비디오 신호 처리 방법 및 장치
WO2021210837A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2014104725A1 (ko) 영상의 부호화/복호화 방법 및 이를 이용하는 장치
WO2010021525A2 (en) A method for processing a web service in an nrt service and a broadcast receiver
WO2015126144A1 (ko) 파노라마 서비스를 위한 방송 신호 송수신 방법 및 장치
WO2016024794A1 (ko) 방송신호 전송방법, 방송신호 수신방법, 방송신호 전송장치, 방송신호 수신장치
WO2015080414A1 (ko) 트릭 플레이 서비스 제공을 위한 방송 신호 송수신 방법 및 장치
WO2014073927A1 (ko) 신호 송수신 장치 및 신호 송수신 방법
WO2009131342A2 (ko) 부호화/복호화 방법 및 장치
WO2016089095A1 (ko) 방송 신호 송신 방법, 방송 신호 송신 장치, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2016018066A1 (ko) 방송신호 전송방법, 방송신호 수신방법, 방송신호 전송장치, 방송신호 수신장치
WO2016171518A2 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2015199468A1 (ko) 방송 신호 송/수신 처리 방법 및 장치
WO2014107069A1 (ko) 영상 부호화/복호화 방법 및 장치
WO2016144031A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016064150A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2015152668A1 (ko) 방송신호 전송방법, 방송신호 수신방법, 방송신호 전송장치, 방송신호 수신장치
WO2016108606A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016108610A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2015056941A1 (ko) 다계층 기반의 영상 부호화/복호화 방법 및 장치
WO2015093811A1 (ko) 트릭 플레이 서비스 제공을 위한 신호 송수신 장치 및 신호 송수신 방법
WO2009125993A2 (ko) 적응적 복호화 장치 및 방법
WO2018062641A1 (ko) 관심 영역을 고려한 가상 현실 서비스 제공

Legal Events

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

Ref document number: 10743898

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13202552

Country of ref document: US

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 01-12-2011)

122 Ep: pct application non-entry in european phase

Ref document number: 10743898

Country of ref document: EP

Kind code of ref document: A2