WO2014057832A1 - 画像処理装置および方法 - Google Patents

画像処理装置および方法 Download PDF

Info

Publication number
WO2014057832A1
WO2014057832A1 PCT/JP2013/076486 JP2013076486W WO2014057832A1 WO 2014057832 A1 WO2014057832 A1 WO 2014057832A1 JP 2013076486 W JP2013076486 W JP 2013076486W WO 2014057832 A1 WO2014057832 A1 WO 2014057832A1
Authority
WO
WIPO (PCT)
Prior art keywords
unit
file
data
image
startcode
Prior art date
Application number
PCT/JP2013/076486
Other languages
English (en)
French (fr)
Inventor
鈴木　輝彦
平林　光浩
中野　雄彦
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to RU2015112109A priority Critical patent/RU2653308C2/ru
Priority to MX2016009728A priority patent/MX358606B/es
Priority to EP13845300.6A priority patent/EP2908523B1/en
Priority to MX2015004140A priority patent/MX340964B/es
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to BR112015007530A priority patent/BR112015007530A2/pt
Priority to JP2014540806A priority patent/JP6492661B2/ja
Priority to US14/432,786 priority patent/US10313694B2/en
Priority to CN201380051814.1A priority patent/CN104704823B/zh
Priority to KR1020157007429A priority patent/KR102134049B1/ko
Priority to CA2886943A priority patent/CA2886943C/en
Priority to EP19197683.6A priority patent/EP3618434B1/en
Priority to AU2013327962A priority patent/AU2013327962A1/en
Publication of WO2014057832A1 publication Critical patent/WO2014057832A1/ja
Priority to AU2017204793A priority patent/AU2017204793B2/en
Priority to AU2019219782A priority patent/AU2019219782B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H04N19/426—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements using memory downsizing methods
    • H04N19/427—Display on the fly, e.g. simultaneous writing to and reading from decoding memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • 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/85406—Content authoring involving a specific file format, e.g. MP4 format

Definitions

  • the present disclosure relates to an image processing apparatus and method, and in particular, an image processing apparatus and method capable of reducing a processing burden when generating a stream used for transmission or a stream used for storing in a file. About.
  • H. is one of the standard specifications for image coding.
  • two types of parameter sets are defined: a sequence parameter set (SPS) and a picture parameter set (PPS) for storing parameters used for image encoding and decoding. While the image data of each slice is classified into VCL (Video Coding Layer) NAL (Network Abstraction Layer) units, these parameter sets are classified into non-VCL NAL units.
  • VCL Video Coding Layer
  • NAL Network Abstraction Layer
  • H.M When an encoded stream encoded by the H.264 / AVC format is stored in a file including a header area and a data area, SPS and PPS are inserted into the header area, and image data is inserted into the data area.
  • APS is also a kind of parameter set. Therefore, according to the existing method, the APS is inserted into the header area of the file as well as the SPS and the PPS.
  • MP4 ISO / IEC 14496-14: 2003, hereinafter referred to as MP4
  • MPEG-4 Part 15 ISO / IEC 14496-15: 2004, AVC file
  • This disclosure has been made in view of such a situation, and reduces the processing burden when generating a stream for transmission or a stream for storage in a file.
  • An image processing apparatus includes a setting unit that sets startcode and filler data for a file including a bitstream obtained by encoding an image, and the startcode and filler data set in the setting unit. And a control unit that controls the setting unit so as to configure the file while maintaining the characteristics of parameters for managing the decoder buffer in the media data of the file.
  • the parameter for managing the decoder buffer is a parameter included in VUI (Video Usability Information), a parameter included in buffering period SEI (Supplemental Enhancement Information), or a parameter included in picture timing SEI.
  • the setting unit can set filler data as VCL data.
  • an image processing apparatus sets startcode and filler data for a file including a bitstream obtained by encoding an image, and sets the set startcode and filler data.
  • the setting of startcode and filler data is controlled so that the file is configured while retaining the characteristics of the parameters for managing the decoder buffer.
  • the image processing apparatus includes a bitstream obtained by encoding an image, and a startcode and a filler data hold a characteristic of a parameter for managing a decoder buffer in the media data of the file, and form a file
  • a reception unit that receives a file that is controlled and set, and reads the startcode and filler dat from the file received by the reception unit, and uses the parameter for managing the decoder buffer, and the bitstream And a decoding unit for decoding.
  • the parameter for managing the decoder buffer is a parameter included in VUI (Video Usability Information), a parameter included in buffering period SEI (Supplemental Enhancement Information), or a parameter included in picture timing SEI.
  • the filler data is set as VCL data.
  • an image processing apparatus includes a bitstream obtained by encoding an image, and startcode and filler data retain characteristics of parameters for managing a decoder buffer in media ⁇ ⁇ ⁇ ⁇ data of a file. Then, the file which is controlled and set to constitute the file is received, the startcode and the filler data are read from the received file, and the bit stream is decoded using the parameters for managing the decoder buffer. To do.
  • the image processing device is characterized in that the parameter of the parameter that manages the decoder buffer when startcode and filler data are deleted from the bitstream in the media data of the file including the bitstream in which the image is encoded And a generating unit that generates the file using the characteristics set by the setting unit.
  • the setting unit can set an identification parameter for identifying that the characteristic of the parameter that manages the decoder buffer has been changed.
  • the setting unit can set the identification parameter as an optional box in the sample entry of the file.
  • the image processing apparatus when startcode and filler data are deleted from the bitstream in the media data of the file including the bitstream obtained by encoding the image, the image processing apparatus sets the decoder buffer.
  • the characteristic of the parameter to be managed is set, and the file is generated using the set characteristic.
  • the characteristics of parameters for managing the decoder buffer are set when startcode and filler ⁇ data are deleted from media data of a file including a bitstream obtained by encoding an image.
  • an identification parameter for identifying that the characteristic of the parameter for managing the decoder buffer has been changed is set.
  • the decoder buffer is provided.
  • the characteristics of the parameter to be managed are set, the file generated using the set characteristic is received, the parameter for managing the decoder buffer is read from the received file, and the bit stream is read using the read parameter. Decrypt.
  • startcode and filler data are set for a file including a bitstream obtained by encoding an image. Then, the settings of startcode and filler ⁇ ⁇ data are controlled so that the set startcode and filler data hold the characteristics of the parameters for managing the decoder buffer in the media data of the file and configure the file.
  • the file includes a bitstream obtained by encoding an image, and the startcode and filler data form the file while maintaining the characteristics of parameters for managing the decoder buffer in the media data of the file.
  • a controlled and configured file is received.
  • the startcode and filler ⁇ ⁇ dat are read from the received file, and the bitstream is decoded using parameters for managing the decoder buffer.
  • the characteristics of the parameters for managing the decoder buffer are set. The Then, the file is generated using the set characteristics.
  • the above-described image processing apparatus may be an independent apparatus, or may be an internal block constituting one image encoding apparatus or image decoding apparatus.
  • an image can be encoded.
  • it is possible to reduce a processing burden when generating a stream used when transmitting a bit stream or a stream used when storing a bit stream.
  • an image can be decoded.
  • it is possible to reduce a processing burden when decoding a stream used for transmission or a stream used for storing in a file.
  • FIG. 22 is a diagram illustrating still another example of the MP4 video sample structure of FIG. 20. It is a figure which shows the example of a format of a sample auxiliary information function. It is a figure which shows the other example of a format of a sample auxiliary information function. It is a figure which compares the example of the MP4 video sample structure of this technique.
  • FIG. 24 is a diagram illustrating another example of the MP4 video sample structure of FIG. 23. It is a figure which shows the example of a byte stream format information box. It is a figure which shows the other example of a byte stream format information box. It is a figure explaining the data structure example of the byte stream format information stored in each sample entry. It is a figure which shows the example of the MP4 video sample structure in the case of the pattern 1. FIG. It is a figure which shows the example of the MP4 video sample structure in the case of the pattern 2. FIG. It is a figure which shows the example of the MP4 video sample structure in the case of the pattern 3. FIG. It is a figure explaining the other example of the data structure of the byte stream format information stored in each sample entry.
  • FIG. 1 is a block diagram illustrating a configuration example of a first embodiment of an encoding device as an image processing device to which the present technology is applied.
  • the encoding apparatus in FIG. 1 includes an encoder 1 and a file generation unit 2, encodes an image such as a captured image using the HEVC method, and generates a file that stores the encoded stream.
  • an image such as a captured image in units of frames is input as an input signal to the encoder 1 of the encoding device.
  • SPS Sequence Parameter Set
  • PPS Picture Parameter Set
  • VUI Video Usability Information
  • SEI Supplemental Enhancement Information
  • Encoder 1 encodes an input signal by the HEVC method using parameters included in SPS, PPS, VUI, and SEI. Then, the encoder 1 generates an encoded stream such as MPEG-2TransTS (Transport Stream) from the SPS, PPS, VUI, SEI and the resulting encoded data, and the generated encoded stream is converted into a file. It supplies to the production
  • the file generation unit 2 is a file (for example, MPEG-4 Part 14 (ISO / IEC 14496-14: 2003, hereinafter referred to as MP4)) that stores the encoded stream (encoded series of image data) from the encoder 1. ) Is generated. Details of the file generation unit 2 will be described later with reference to FIG.
  • FIG. 2 is a block diagram illustrating a configuration example of the encoder 1 of FIG.
  • Each unit of the encoder 1 encodes an image that is an input signal using parameters included in SPS, PPS, VUI, and SEI from the preceding stage (not shown) to generate an encoded stream.
  • a / D conversion unit 11 includes an A / D conversion unit 11, a screen rearrangement buffer 12, a calculation unit 13, an orthogonal transformation unit 14, a quantization unit 15, a lossless encoding unit 16, a storage buffer 17, an inverse quantization unit 18, An inverse orthogonal transform unit 19, an addition unit 20, a deblock filter 21, a frame memory 22, a switch 23, an intra prediction unit 24, a motion prediction / compensation unit 25, a predicted image selection unit 26, and a rate control unit 27 are configured. Is done.
  • an adaptive offset filter 41 and an adaptive loop filter 42 are provided between the deblock filter 21 and the frame memory 22.
  • the A / D conversion unit 11 of the encoder 1 performs A / D conversion on an image in frame units input as an input signal, and outputs and stores it in the screen rearrangement buffer 12.
  • the screen rearrangement buffer 12 rearranges the stored frame-by-frame images in the order for encoding in accordance with the GOP (Group of Picture) structure, the arithmetic unit 13, the intra prediction unit 24, and Output to the motion prediction / compensation unit 25.
  • GOP Group of Picture
  • the calculation unit 13 performs encoding by calculating the difference between the predicted image supplied from the predicted image selection unit 26 and the encoding target image output from the screen rearrangement buffer 12. Specifically, the calculation unit 13 performs encoding by subtracting the prediction image supplied from the prediction image selection unit 26 from the encoding target image output from the screen rearrangement buffer 12. The calculation unit 13 outputs the image obtained as a result to the orthogonal transform unit 14 as residual information. When the predicted image is not supplied from the predicted image selection unit 26, the calculation unit 13 outputs the image read from the screen rearrangement buffer 12 to the orthogonal transform unit 14 as residual information as it is.
  • the orthogonal transform unit 14 performs orthogonal transform on the residual information from the calculation unit 13 and supplies a coefficient obtained as a result of the orthogonal transform to the quantization unit 15.
  • the quantization unit 15 quantizes the coefficient supplied from the orthogonal transform unit 14.
  • the quantized coefficient is input to the lossless encoding unit 16.
  • the lossless encoding unit 16 acquires information indicating the optimal intra prediction mode (hereinafter referred to as intra prediction mode information) from the intra prediction unit 24.
  • information indicating the optimal inter prediction mode hereinafter referred to as inter prediction mode information
  • inter prediction mode information information indicating the optimal inter prediction mode
  • a motion vector information for specifying a reference image, and the like are acquired from the motion prediction / compensation unit 25.
  • the lossless encoding unit 16 acquires the storage flag, index or offset, and type information from the adaptive offset filter 41 as offset filter information, and acquires filter coefficients from the adaptive loop filter 42.
  • the lossless encoding unit 16 performs variable length encoding (for example, CAVLC (Context-Adaptive Variable Length Coding)), arithmetic encoding (for example, CABAC) on the quantized coefficients supplied from the quantization unit 15. (Context-Adaptive Binary Arithmetic Coding) etc.) is performed.
  • variable length encoding for example, CAVLC (Context-Adaptive Variable Length Coding)
  • CABAC arithmetic encoding
  • CABAC Context-Adaptive Binary Arithmetic Coding
  • the lossless encoding unit 16 uses the intra prediction mode information or the inter prediction mode information, the motion vector, the information specifying the reference image, the offset filter information, the filter coefficient, and the like as the encoding information related to the encoding. Turn into.
  • the lossless encoding unit 16 generates an encoded stream from the encoded information and coefficients that have been losslessly encoded, supplies the encoded stream to the accumulation buffer 17, and accumulates the encoded stream.
  • the losslessly encoded information may be the header information of the losslessly encoded coefficient.
  • the accumulation buffer 17 temporarily stores the encoded stream supplied from the lossless encoding unit 16. Further, the accumulation buffer 17 supplies the stored encoded stream to the file generation unit 2 in FIG.
  • the quantized coefficient output from the quantization unit 15 is also input to the inverse quantization unit 18, subjected to inverse quantization, and then supplied to the inverse orthogonal transform unit 19.
  • the inverse orthogonal transform unit 19 performs inverse orthogonal transform on the coefficients supplied from the inverse quantization unit 18 and supplies residual information obtained as a result to the addition unit 20.
  • the adding unit 20 adds the residual information as the decoding target image supplied from the inverse orthogonal transform unit 19 and the predicted image supplied from the predicted image selecting unit 26 to obtain a locally decoded image. .
  • the adding unit 20 sets the residual information supplied from the inverse orthogonal transform unit 19 as a locally decoded image.
  • the adder 20 supplies the locally decoded image to the deblocking filter 21 and also supplies it to the frame memory 22 for storage.
  • the deblocking filter 21 removes block distortion by filtering the locally decoded image supplied from the adding unit 20.
  • the deblocking filter 21 supplies an image obtained as a result to the adaptive offset filter 41.
  • the adaptive offset filter 41 performs an adaptive offset filter (SAO: Sample adaptive offset) process that mainly removes ringing on the image after the adaptive deblock filter process by the deblock filter 21.
  • SAO Sample adaptive offset
  • the adaptive offset filter 41 determines the type of adaptive offset filter processing for each LCU (Largest Coding Unit) which is the maximum coding unit, and obtains an offset used in the adaptive offset filter processing.
  • the adaptive offset filter 41 performs the determined type of adaptive offset filter processing on the image after the adaptive deblocking filter processing, using the obtained offset. Then, the adaptive offset filter 41 supplies the image after the adaptive offset filter processing to the adaptive loop filter 42.
  • the adaptive offset filter 41 has a buffer for storing the offset.
  • the adaptive offset filter 41 determines whether the offset used for the adaptive deblocking filter processing is already stored in the buffer for each LCU.
  • the adaptive offset filter 41 determines that the offset used for the adaptive deblocking filter processing is already stored in the buffer, the adaptive offset filter 41 stores a storage flag indicating whether the offset is stored in the buffer, and the offset is stored in the buffer. Is set to a value (1 in this case) indicating that the
  • the adaptive offset filter 41 stores, for each LCU, a storage flag that is set to 1, an index that indicates the storage position of the offset in the buffer, and type information that indicates the type of adaptive offset filter processing that has been performed. 16 is supplied.
  • the adaptive offset filter 41 stores the offset in order in the buffer. Further, the adaptive offset filter 41 sets the storage flag to a value (here, 0) indicating that the offset is not stored in the buffer. Then, the adaptive offset filter 41 supplies the storage flag, offset, and type information set to 0 to the lossless encoding unit 16 for each LCU.
  • the adaptive loop filter 42 performs an adaptive loop filter (ALF: Adaptive Loop Filter) process on the image after the adaptive offset filter process supplied from the adaptive offset filter 41, for example, for each LCU.
  • ALF Adaptive Loop Filter
  • the adaptive loop filter process for example, a process using a two-dimensional Wiener filter is used. Of course, filters other than the Wiener filter may be used.
  • the adaptive loop filter 42 is configured so that the residual of the original image that is the image output from the screen rearrangement buffer 12 and the image after the adaptive loop filter processing is minimized for each LCU. A filter coefficient used in the processing is calculated. Then, the adaptive loop filter 42 performs an adaptive loop filter process for each LCU using the calculated filter coefficient on the image after the adaptive offset filter process.
  • the adaptive loop filter 42 supplies the image after the adaptive loop filter processing to the frame memory 22.
  • the adaptive loop filter 42 supplies the filter coefficient to the lossless encoding unit 16.
  • the adaptive loop filter processing is performed for each LCU, but the processing unit of the adaptive loop filter processing is not limited to the LCU. However, the processing can be efficiently performed by combining the processing units of the adaptive offset filter 41 and the adaptive loop filter 42.
  • the image stored in the frame memory 22 is output as a reference image to the intra prediction unit 24 or the motion prediction / compensation unit 25 via the switch 23.
  • the intra prediction unit 24 uses the reference image that has not been filtered by the deblocking filter 21 that is read from the frame memory 22 via the switch 23, and is used for all intra prediction modes in units of tiles and slices. Perform prediction processing.
  • the intra prediction unit 24 calculates cost function values for all candidate intra prediction modes based on the image read from the screen rearrangement buffer 12 and the prediction image generated as a result of the intra prediction process. (Details will be described later). Then, the intra prediction unit 24 determines the intra prediction mode that minimizes the cost function value as the optimal intra prediction mode.
  • the intra prediction unit 24 supplies the predicted image generated in the optimal intra prediction mode and the corresponding cost function value to the predicted image selection unit 26.
  • the intra prediction unit 24 supplies the intra prediction mode information to the lossless encoding unit 16 when the prediction image selection unit 26 is notified of selection of a prediction image generated in the optimal intra prediction mode.
  • the cost function value is also called RD (Rate Distortion) cost. It is calculated based on a method of either High Complexity mode or Low Complexity mode as defined by JM (Joint Model) which is reference software in the H.264 / AVC format.
  • D is the difference (distortion) between the original image and the decoded image
  • R is the amount of generated code including up to the coefficient of orthogonal transform
  • ⁇ is the Lagrange multiplier given as a function of the quantization parameter QP.
  • D is the difference (distortion) between the original image and the decoded image
  • Header_Bit is the header bit for the prediction mode
  • QPtoQuant is a function given as a function of the quantization parameter QP.
  • the motion prediction / compensation unit 25 performs motion prediction / compensation processing for all candidate inter prediction modes in units of tiles and slices. Specifically, the motion prediction / compensation unit 25 is based on the image supplied from the screen rearrangement buffer 12 and the filtered reference image read from the frame memory 22 via the switch 23 in units of tiles and slices. , Detecting motion vectors of all candidate inter prediction modes. Then, the motion prediction / compensation unit 25 performs compensation processing on the reference image based on the motion vector in units of tiles and slices, and generates a predicted image.
  • the motion prediction / compensation unit 25 calculates a cost function value for all candidate inter prediction modes based on the image and the predicted image supplied from the screen rearrangement buffer 12, and calculates the cost function value.
  • the inter prediction mode that minimizes is determined as the optimal inter measurement mode.
  • the motion prediction / compensation unit 25 supplies the cost function value of the optimal inter prediction mode and the corresponding predicted image to the predicted image selection unit 26.
  • the motion prediction / compensation unit 25 specifies inter prediction mode information, a corresponding motion vector, and information for specifying a reference image. Are output to the lossless encoding unit 16.
  • the predicted image selection unit 26 Based on the cost function values supplied from the intra prediction unit 24 and the motion prediction / compensation unit 25, the predicted image selection unit 26 has a smaller corresponding cost function value of the optimal intra prediction mode and the optimal inter prediction mode. Are determined as the optimum prediction mode. Then, the predicted image selection unit 26 supplies the predicted image in the optimal prediction mode to the calculation unit 13 and the addition unit 20. Further, the predicted image selection unit 26 notifies the intra prediction unit 24 or the motion prediction / compensation unit 25 of selection of the predicted image in the optimal prediction mode.
  • the rate control unit 27 controls the quantization operation rate of the quantization unit 15 based on the encoded data stored in the storage buffer 17 so that overflow or underflow does not occur.
  • the start code and filler data are removed, and the decoder buffer is managed.
  • the parameter value to be changed may be different. Accordingly, for example, it is necessary to reset buffering period (SEI (Supplemental enhancement information), which leads to an increase in processing load when converting the bitstream.
  • SEI Supplemental enhancement information
  • the file generation unit 2 sets startcode and filler data for a file including a bitstream obtained by encoding an image when generating a stream used for transmission or a stream used for storing in a file.
  • the startcode and filler data are controlled so that the file is configured while retaining the characteristics of the parameters that manage the decoder buffer. .
  • the file generation unit 2 sets the characteristics of the parameters for managing the decoder buffer when startcode and filler ⁇ data are deleted in the media ⁇ data of the file including the bitstream obtained by encoding the image. Was used to generate files.
  • the parameter for managing the decoder buffer is an HRD parameter (Hypothetical Reference Decoder Parameter), that is, a parameter for managing the virtual reference decoder.
  • the parameters for managing the decoder buffer are parameters in the VUI, parameters in the buffering period SEI, or parameters in the picture timing SEI.
  • filler ⁇ data can be handled by doing the following. That is, in the AVC or HEVC system, the filler data is non-VCL as shown in the table of NAL unit type codes and NAL unit type classes. Specifically, when nal_unit_type is 31, Name of nal_unit_type is FD_NUT, Content of NAL unit and RBSP syntax structure is filler data, filler_data_rbsp (), NAL shortcut type class is non-VCL . By changing this non-VCL to VCL data, it is possible to include filler ⁇ data in the media data of the file, so that it is possible to suppress the removal of filler data during conversion to a transmission stream.
  • the file generation unit 2 sets startcode and filler data as follows.
  • HRD parameters are wrong When startcode, filler data, etc were removed from the elementary stream to store ISOMFF, HRD parameters, eg buffering period SEI, picture timing SEI, etc are not correct.However, decoder can not know if HRD parameters in the elementary stream is correct. There should be an id to indicate the HRD parameters in the elementary stream maybe wrong.
  • filler data is categorized as non-VCL.That mean the bit for filler data is counted as non-VCL (header information). As this video bitstream itself.In this case, filler data is not necessary to remove from the elementary stream and HRD parameters are not changed.
  • the table for HEVC is attached.
  • an identification parameter is set for identifying whether the characteristics of the parameter for managing the decoder buffer have been changed.
  • data is stored in an optional box of a file format is shown.
  • such id can be defined as an optional box in AVCSampleEntry as follows.
  • AVCSampleEntry extends VisualSampleEntry (type ') ⁇ // type is 'avc1' or 'avc3' AVCConfigurationBox config; MPEG4BitRateBox (); // Optional MPEG4ExtensionDescriptorsBox (); // Optional HRDConformanceBox (); // Optional ⁇ Add HRDConformanceBox into AVCSampleEntry and AVC2SVVSampleEntry in 5.4.2.1 Add HRDConformanceBox into AVCSVCSampleEntry, AVC2SVCSampleEntry and SVCSampleEntry in 6.5.3.1.
  • the identification parameter is set as follows, for example.
  • HRDConformanceFlag is the identifier if HRD characteristics was changed by removing startcode, filler data, etc from the elementary stream.
  • HRDConformanceFlag is equal to1
  • the HRD parameters eg buffering period SEI, picture timing SEI, was changed by removing startcode, filler data, etc from the elementary stream.
  • the file generation unit 2 in FIG. 1 that performs the above processing is configured as shown in FIG.
  • FIG. 3 is a block diagram illustrating a configuration example of a file generation unit that performs the above-described processing.
  • the file generation unit 2 is configured to include a control unit 31, a setting unit 32, and a file writing unit 33.
  • the control unit 31 controls the generation processing of the mdat data that is the VCL data portion of the file by the setting unit 32 according to whether or not the characteristics of the HRD parameter that is a parameter for managing the decoder buffer are retained. Also, the control unit 31 sets the characteristics of the HRD parameter or moov which is the management information part of the file depending on whether startcode and fillerfilldata are deleted in the mdat data set by the setting unit 32. Controls the setting of HRD identification parameters.
  • the setting unit 32 uses the encoded stream from the encoder 1 to generate mdat data of the file under the control of the control unit 31, and supplies the generated mdat data to the file writing unit 33.
  • startcode and filler data are deleted, but in the method of this technology, mdat data is generated with the startcode and filler data set in the encoded stream being set. .
  • the setting unit 32 resets the characteristics of the HRD parameters or sets the identification parameters of the HRD in the moov of the file under the control of the control unit 31. Then, the setting unit 32 generates a moov of the file and supplies the generated moov to the file writing unit 33.
  • the file writing unit 33 writes moov from the setting unit 32 to a file, and further writes mdat to the file.
  • the MP4 file written out by the file writing unit 33 is transmitted to a decoding device, which will be described later, and read and decoded by the decoding device.
  • step S1 the control unit 31 determines whether or not to retain the characteristics of the HRD parameter that is a parameter for managing the decoder buffer. If it is determined in step S1 that the characteristics of the HRD parameter are not retained, the process proceeds to step S2. In step S ⁇ b> 2, the setting unit 32 performs conventional mdat data generation processing under the control of the control unit 31. This process will be described later with reference to FIG.
  • step S2 startcode is detected, NAL data is acquired, and startcode is deleted. Then, depending on whether the acquired data is VCL data, filler data, or management information, Unit size is added and stored in the buffer, or discarded, and mdat data Is generated. The generated mdat data is supplied to the file writing unit 33, and the process proceeds to step S4.
  • step S1 determines whether the characteristics of the HRD parameter are retained. If it is determined in step S1 that the characteristics of the HRD parameter are retained, the process proceeds to step S3.
  • step S ⁇ b> 3 the setting unit 32 performs mdat data generation processing of the present technology under the control of the control unit 31. This process will be described later with reference to FIG.
  • step S3 By the process of step S3, startcode is detected, NAL data is acquired, the acquired data is set as VCL data, Unit Size is added, and accumulated in the buffer, thereby generating mdat data.
  • the generated mdat data is supplied to the file writing unit 33, and the process proceeds to step S4.
  • step S4 the control unit 31 determines whether or not startcode and filler data are deleted in the mdat data generated in step S2 or S3.
  • step S4 If it is determined in step S4 that startcode and filler data have been deleted, the process proceeds to step S5.
  • step S5 the setting unit 32 sets the characteristics of the HRD parameter. That is, since the characteristics of the HRD parameter are different, the characteristics of the HRD parameter are calculated again and set again. Then, the SEI and VUI of the mdat data are rewritten with the set HRD parameter.
  • step S4 If it is determined in step S4 that startcode and filler data are not deleted, step S5 is skipped, and the process proceeds to step S6.
  • step S6 the setting unit 32 generates a moov of the file using the data size information obtained in the process of step S2 or S3.
  • step S3 the management information etc. which were accumulate
  • the generated moov is supplied to the file writing unit 33.
  • step S7 the file writing unit 33 writes the moov generated in step S6 to a file.
  • step S8 the file writing unit 33 writes the mdat generated in step S2 or S3 to a file.
  • the MP4 file written out by the file writing unit 33 is transmitted to a decoding device to be described later, and read and decoded by the decoding device. At that time, the file is generated without changing the characteristics of the HRD parameter. In addition, since the HRD parameter is set again even if startcode and filler data are deleted, the decoding process can be performed accurately by referring to the HRD parameter.
  • step S11 the control unit 31 determines whether or not to retain the characteristics of the HRD parameter that is a parameter for managing the decoder buffer. If it is determined in step S11 that the characteristics of the HRD parameter are not retained, the process proceeds to step S12. In step S ⁇ b> 12, the setting unit 32 performs conventional mdat data generation processing under the control of the control unit 31. This process will be described later with reference to FIG.
  • step S12 startcode is detected, NAL data is acquired, and startcode is deleted. Then, depending on whether the acquired data is VCL data, filler data, or management information, Unit size is added and stored in the buffer, or discarded, and mdat data Is generated. The generated mdat data is supplied to the file writing unit 33, and the process proceeds to step S14.
  • step S11 determines whether the characteristics of the HRD parameter are to be retained. If it is determined in step S11 that the characteristics of the HRD parameter are to be retained, the process proceeds to step S13.
  • step S ⁇ b> 13 the setting unit 32 performs mdat data generation processing of the present technology under the control of the control unit 31. This process will be described later with reference to FIG.
  • step S13 startcode is detected, NAL data is acquired, the acquired data is set as VCL data, Unit Size is added, and accumulated in the buffer, thereby generating mdat data.
  • the generated mdat data is supplied to the file writing unit 33, and the process proceeds to step S14.
  • step S14 the control unit 31 determines whether or not startcode and filler data have been deleted from the mdat data generated in step S12 or S13.
  • step S14 If it is determined in step S14 that startcode and filler data are not deleted, the process proceeds to step S15.
  • step S15 the setting unit 32 sets the moov HRD identification parameter to 1, and the process proceeds to step S17. As a result, the decoding side can determine that the HRD parameter is correct.
  • step S14 If it is determined in step S14 that startcode and fillerdata have been deleted, the process proceeds to step S16.
  • step S16 the setting unit 32 sets the moov HRD identification parameter to 0, and the process proceeds to step S17. As a result, the decoding side can determine that the HRD parameter is incorrect (incorrect).
  • step S17 the setting unit 32 generates a moov of the file using the data size information obtained in the process of step S12 or S13.
  • step S13 the management information etc. which were accumulate
  • the generated moov is supplied to the file writing unit 33.
  • step S18 the file writing unit 33 writes the moov generated in step S17 to a file.
  • step S19 the file writing unit 33 writes the mdat generated in step S12 or S13 into a file.
  • the MP4 file written out by the file writing unit 33 is transmitted to a decoding device to be described later, and read and decoded by the decoding device. At that time, the file is generated without changing the characteristics of the HRD parameter. Further, since the identification parameter for identifying whether or not the HRD parameter is correct is set, it is possible to clearly determine whether or not decoding is performed with reference to the HRD parameter.
  • step S2 of FIG. 4 or step S12 of FIG. 5
  • step S2 of FIG. 4 or step S12 of FIG. 5
  • the setting unit 32 detects startcode from the encoded stream from the encoder 1 in step S21, and acquires NAL data from the startcode detected in step S21 to the next startcode in step S22.
  • the setting unit 32 deletes the startcode detected in step S21 in step S23.
  • step S24 it is determined whether the data acquired in step S22 is VCL data.
  • step S24 If it is determined in step S24 that the data acquired in step S22 is VCL data, the process proceeds to step S25.
  • step S25 the setting unit 32 adds the corresponding Unit size to the data acquired in step S22 to obtain an access unit.
  • step S26 the setting unit 32 accumulates the access unit to which Unit size is added in the built-in mdat buffer, and the process proceeds to step S30.
  • step S24 If it is determined in step S24 that the data acquired in step S22 is not VCL data, the process proceeds to step S27.
  • step S27 the setting unit 32 determines whether or not the data acquired in step S22 is filler ⁇ data.
  • step S27 If it is determined in step S27 that the data acquired in step S22 is filler data, the process proceeds to step S28.
  • step S28 the setting unit 32 discards filler data, and the process proceeds to step S30.
  • step S27 If it is determined in step S27 that the data acquired in step S22 is not fillerfilldata, the process proceeds to step S29.
  • the acquired data is management information such as SPS and PPS
  • step S29 the setting unit 32 accumulates the acquired data in the built-in moov buffer, and the process proceeds to step S30. .
  • step S30 the setting unit 32 detects startcode from the encoded stream from the encoder 1.
  • step S31 the setting unit 32 determines whether or not the current data is the last data of the file. If startcode is not detected in step S30, it is determined in step S31 that the data is the last data in the file, the mdat data generation process is terminated, and the process is step S2 in FIG. 4 (or step S12 in FIG. 5). Return to.
  • step S30 If startcode is detected in step S30, if it is determined in step S31 that the data is not the last data in the file, the process proceeds to step S22, and the subsequent processes are repeated.
  • the setting unit 32 detects startcode from the encoded stream from the encoder 1 in step S41, and acquires NAL data from the startcode detected in step S41 to the next startcode in step S42. In the example of FIG. 7, startcode is not deleted.
  • step S43 the setting unit 32 determines whether the data acquired in step S42 is fillerfilldata. If it is determined in step S43 that the data acquired in step S42 is filler data, the process proceeds to step S44. In step S44, the setting unit 32 sets filler data to VCL data.
  • step S44 is skipped, and the process proceeds to step S45.
  • step S45 the corresponding unit size is added to the data acquired in step S42 to obtain an access unit
  • step S46 the access unit to which unit size is added is stored in the built-in mdat buffer.
  • the acquired data is management information such as SPS or PPS, it is also stored in the built-in moov buffer.
  • step S6 of FIG. 4 or step S17 of FIG. Stored as SPS or PPS.
  • the acquired data is management information such as SPS or PPS
  • it may be stored only in the built-in moov buffer instead of being stored in the mdat buffer as in the past.
  • step S47 the setting unit 32 detects startcode from the encoded stream from the encoder 1.
  • step S48 the setting unit 32 determines whether or not the current data is the last data of the file. If startcode is not detected in step S47, it is determined in step S48 that the data is the last data in the file, the mdat data generation process is terminated, and the process proceeds to step S3 in FIG. 4 (step S13 in FIG. 5). Return.
  • step S47 If the startcode is detected in step S47, if it is determined in step S48 that it is not the last data of the file, the process proceeds to step S42, and the subsequent processes are repeated.
  • the settings of startcode and fillerfilldata are controlled so that the file is configured while retaining the characteristics of the parameters for managing the decoder buffer. That is, the startcode and fillerfilldata are not deleted, and the startcode and filler data are included to configure the file, so that the characteristics of the parameters for managing the decoder buffer can be maintained.
  • fillerfilldata is changed to VCL data
  • Filler data can be included in the media data of the file, and removal of fillerfilldata during conversion to a transmission stream can be suppressed.
  • an identification parameter that identifies that the characteristics of the parameter that manages the decoder buffer has been changed is set, and the set identification parameter is used, The file was generated. Thereby, decoding can be performed correctly.
  • FIG. 8 is a block diagram illustrating a configuration example of a first embodiment of a decoding device as an image processing device to which the present technology is applied, which decodes an encoded stream transmitted from the encoding device in FIG. 1.
  • the file reading unit 51 of the decoding device receives the MP4 file generated by the encoding device of FIG. 1 and, from the received file, the SPS, PPS, and SPS constituting the encoded stream encoded by the encoder 1 of FIG. Read VUI, SEI, encoded data, etc.
  • the file reading unit 51 supplies SPS, PPS, VUI, SEI, and encoded data to the decoder 52.
  • the file reading unit 51 includes a bit stream obtained by encoding an image, and the startcode and filler data hold the characteristics of the parameters for managing the decoder buffer in the media data of the file, and configure the file. Receives files that are controlled and configured. Alternatively, the file reading unit 51 sets the characteristics of parameters for managing the decoder buffer when startcode and fillerfilldata are deleted in media data of a file including a bitstream obtained by encoding an image. Receive a file that has been generated using. Then, the file reading unit 51 reads the received file, and causes the decoder 52 to decode the encoded data of the bit stream.
  • the decoder 52 is supplied from the file reading unit 51 with reference to SPS, PPS, VUI, SEI, etc. (particularly the characteristics of the HRD parameter) supplied from the file reading unit 51 under the control of the file reading unit 51. Decode the encoded data by the HEVC method. The decoder 52 supplies an image obtained as a result of decoding to the subsequent stage as an output signal.
  • FIG. 9 is a block diagram illustrating a configuration example of the file reading unit 51.
  • the file reading unit 51 is configured to include a file receiving unit 71, a parameter acquiring unit 72, a decoding control unit 73, and a data reading unit 74.
  • the file receiving unit 71 receives the MP4 file generated by the file generating unit 2 in FIG. 1 and supplies the received file to the parameter acquiring unit 72.
  • the parameter acquisition unit 72 acquires moov that is management information from the MP4 file, and supplies it to the data reading unit 74. Further, the parameter acquisition unit 72 causes the data reading unit 74 to read data from mdat based on the acquired moov.
  • the parameter acquisition unit 72 acquires an identification parameter for determining whether or not the characteristics of the HRD parameter are correct from the moov, and sends it to the decoding control unit 73. Supply its identification parameters.
  • the decoding control unit 73 determines whether to follow the HRD parameter according to the HRD identification parameter, and controls the decoder 52 to perform the decoding process.
  • the data reading unit 74 reads SPS, PPS, VUI, SEI, and the like from the moov or mdat of the file, and reads the encoded data from the mdat of the file under the control of the parameter acquisition unit 72. The data reading unit 74 then supplies the read SPS, PPS, VUI, SEI, encoded data, and the like to the decoder 52.
  • FIG. 10 is a block diagram illustrating a configuration example of the decoder 52 of FIG.
  • Each unit of the decoder 52 uses the parameters included in the SPS, PPS, VUI, and SEI from the file reading unit 51 to decode the encoded data to generate an image.
  • the 10 includes an accumulation buffer 101, a lossless decoding unit 102, an inverse quantization unit 103, an inverse orthogonal transform unit 104, an addition unit 105, a deblock filter 106, a screen rearrangement buffer 107, a D / A conversion unit 108, The frame memory 109, the switch 110, the intra prediction unit 111, the motion compensation unit 112, and the switch 113 are included.
  • an adaptive offset filter 141 and an adaptive loop filter 142 are provided between the deblock filter 106 and the screen rearrangement buffer 107 and the frame memory 109.
  • the accumulation buffer 101 of the decoder 52 receives and accumulates encoded data from the file reading unit 51 of FIG.
  • the accumulation buffer 101 supplies the accumulated encoded data to the lossless decoding unit 102.
  • the lossless decoding unit 102 obtains quantized coefficients and encoded information by performing lossless decoding such as variable length decoding and arithmetic decoding on the encoded data from the accumulation buffer 101.
  • the lossless decoding unit 102 supplies the quantized coefficient to the inverse quantization unit 103.
  • the lossless decoding unit 102 supplies intra prediction mode information or the like as encoded information to the intra prediction unit 111, and provides motion vectors, information for identifying reference images, inter prediction mode information, and the like to the motion compensation unit 112. Supply. Further, the lossless decoding unit 102 supplies intra prediction mode information or inter prediction mode information as encoded information to the switch 113.
  • the lossless decoding unit 102 supplies offset filter information as encoded information to the adaptive offset filter 141 and supplies filter coefficients to the adaptive loop filter 142.
  • the inverse quantization unit 103, the inverse orthogonal transform unit 104, the addition unit 105, the deblock filter 106, the frame memory 109, the switch 110, the intra prediction unit 111, and the motion compensation unit 112 are the same as the inverse quantization unit 18, FIG.
  • the same processing as that performed by the inverse orthogonal transform unit 19, the addition unit 20, the deblock filter 21, the frame memory 22, the switch 23, the intra prediction unit 24, and the motion prediction / compensation unit 25 is performed, whereby the image is decoded.
  • the inverse quantization unit 103 inversely quantizes the quantized coefficient from the lossless decoding unit 102 and supplies the resulting coefficient to the inverse orthogonal transform unit 104.
  • the inverse orthogonal transform unit 104 performs inverse orthogonal transform on the coefficient from the inverse quantization unit 103, and supplies residual information obtained as a result to the addition unit 105.
  • the addition unit 105 performs decoding by adding the residual information as the decoding target image supplied from the inverse orthogonal transform unit 104 and the prediction image supplied from the switch 113.
  • the adding unit 105 supplies the image obtained as a result of decoding to the deblocking filter 106 and also supplies it to the frame memory 109.
  • the addition unit 105 supplies the image, which is residual information supplied from the inverse orthogonal transform unit 104, to the deblocking filter 106 as an image obtained as a result of decoding. It is supplied to the frame memory 109 and accumulated.
  • the deblock filter 106 removes block distortion by filtering the image supplied from the addition unit 105.
  • the deblocking filter 106 supplies the resulting image to the adaptive offset filter 141.
  • the adaptive offset filter 141 has a buffer for sequentially storing offsets supplied from the lossless decoding unit 102. Further, the adaptive offset filter 141 performs adaptive offset filter processing on the image after the adaptive deblocking filter processing by the deblocking filter 106 based on the offset filter information supplied from the lossless decoding unit 102 for each LCU. .
  • the adaptive offset filter 141 uses the offset included in the offset filter information for the image after the deblocking filter processing in units of LCUs.
  • the type of adaptive offset filter processing indicated by the type information is performed.
  • the adaptive offset filter 141 is stored at the position indicated by the index included in the offset filter information with respect to the image after the deblocking filter processing in units of LCUs. Read the offset. Then, the adaptive offset filter 141 performs the type of adaptive offset filter processing indicated by the type information, using the read offset. The adaptive offset filter 141 supplies the image after the adaptive offset filter processing to the adaptive loop filter 142.
  • the adaptive loop filter 142 performs an adaptive loop filter process for each LCU on the image supplied from the adaptive offset filter 141 using the filter coefficient supplied from the lossless decoding unit 102.
  • the adaptive loop filter 142 supplies the image obtained as a result to the frame memory 109 and the screen rearrangement buffer 107.
  • the image stored in the frame memory 109 is read as a reference image via the switch 110 and supplied to the motion compensation unit 112 or the intra prediction unit 111.
  • the screen rearrangement buffer 107 stores the image supplied from the deblock filter 106 in units of frames.
  • the screen rearrangement buffer 107 rearranges the stored frame-by-frame images for encoding in the original display order and supplies them to the D / A conversion unit 108.
  • the D / A converter 108 D / A converts the frame unit image supplied from the screen rearrangement buffer 107 and outputs it as an output signal to a subsequent stage (not shown).
  • the intra prediction unit 111 uses the reference image not filtered by the deblocking filter 106 read out from the frame memory 109 via the switch 110 in units of tiles and slices, and is supplied from the lossless decoding unit 102. Intra prediction processing in the intra prediction mode indicated by the mode information is performed. The intra prediction unit 111 supplies the prediction image generated as a result to the switch 113.
  • the motion compensation unit 112 is filtered by the deblocking filter 106 from the frame memory 109 via the switch 110 based on the information for specifying the reference image supplied from the lossless decoding unit 102 in units of tiles and slices. Read the reference image.
  • the motion compensation unit 112 performs motion compensation processing in the optimal inter prediction mode indicated by the inter prediction mode information using the motion vector and the reference image.
  • the motion compensation unit 112 supplies the predicted image generated as a result to the switch 113.
  • the switch 113 supplies the prediction image supplied from the intra prediction unit 111 to the addition unit 105.
  • the switch 113 supplies the predicted image supplied from the motion compensation unit 112 to the adding unit 105.
  • This file decryption process is a process for the file generated by the file generation process of FIG. That is, the characteristics of the HRD parameter in this file are set again even if startcode and filler data are deleted.
  • step S71 the file receiving unit 71 receives the MP4 file and supplies the received file to the parameter acquiring unit 72.
  • step S72 the parameter acquisition unit 72 acquires moov as management information from the MP4 file and supplies the acquired moov to the data reading unit 74.
  • step S73 the data reading unit 74 acquires SPS and PPS from moov.
  • step S74 the parameter acquisition unit 72 acquires the unit size of mdat to be decoded based on the moov acquired in step S72.
  • step S75 the parameter acquisition unit 72 detects NAL based on the Unit size acquired in step S74.
  • startcode is also acquired and referenced according to the file structure described later with reference to FIGS. 17 and 18.
  • step S76 the data reading unit 74 reads data from the NAL detected in step S75 and supplies the data to the decoder 52.
  • the NAL is SPS or PPS
  • the moov SPS or PPS acquired in step S73 is a default value, and the NAL SPS or PPS is used.
  • step S77 the decoder 52 performs a decoding process. At that time, the decoder 52 performs a decoding process according to the HRD parameter.
  • the file is configured, so that the decoding process can be performed correctly.
  • the transmission rate of VBR or CBR is specified from the outside.
  • VBR the stream is output as it is from the data reading unit 74 to the decoder 52.
  • CBR in the data reading unit 74, Filler data or stuffing bit is added so as to be CBR, The HRD parameter is rewritten. At that time, since the HRD parameter of the MP4 file is normal, it can be rewritten normally on the decoding side.
  • This file decryption process is a process for the file generated by the file generation process of FIG. That is, an identification parameter for identifying whether the characteristics of the HRD parameter are correct or different is set in the moov of this file.
  • step S91 the file receiving unit 71 receives the MP4 file and supplies the received file to the parameter acquiring unit 72.
  • step S92 the parameter acquisition unit 72 acquires moov as management information from the MP4 file, and supplies the acquired moov to the data reading unit 74.
  • step S93 the data reading unit 74 acquires SPS and PPS from moov.
  • step S94 the parameter acquisition unit 72 acquires the HRD identification parameter from the moov acquired in step S92, and supplies the acquired HRD identification parameter to the decoding control unit 73.
  • step S95 the parameter acquisition unit 72 acquires the unit size of mdat to be decoded based on the moov acquired in step S92.
  • step S96 the parameter acquisition unit 72 detects NAL based on the Unit size acquired in step S95.
  • startcode is also acquired and referenced according to the file structure described later with reference to FIGS. 17 and 18.
  • step S97 the data reading unit 74 reads data from the NAL detected in step S96 and supplies the data to the decoder 52. If the NAL is SPS or PPS, the moov SPS or PPS acquired in step S93 is a default value, and the NAL SPS or PPS is used.
  • step S98 the decryption control unit 73 determines whether or not the HRD identification parameter from the parameter acquisition unit 72 is 1. If it is determined in step S98 that the HRD identification parameter is 1, the process proceeds to step S99.
  • step S99 the decoder 52 performs a decoding process according to the HRD parameter under the control of the decoding control unit 73.
  • step S98 determines whether the HRD identification parameter is not 1, the process proceeds to step S100.
  • step S100 the decoder 52 ignores the HRD parameter and performs the decoding process under the control of the decoding control unit 73.
  • the file is configured, so that the decoding process can be performed correctly.
  • FIG. 13 is a block diagram illustrating an example of the configuration of the image encoding device 201 according to an embodiment for generating the above-described MP4 file.
  • the image encoding device 201 includes an encoding unit 211, a VCL buffer 212, a non-VCL buffer 213, a file generation unit 214, and a control unit 215.
  • the encoding unit 211 in FIG. 13 corresponds to the encoder 1 in FIG.
  • the VCL buffer 212, the non-VCL buffer 213, the file generation unit 214, and the control unit 215 in FIG. 13 correspond to the file generation unit 2 in FIG.
  • the encoding unit 211 is an encoder that operates according to the HEVC method.
  • the encoding unit 211 sequentially acquires images to be encoded from a moving image source such as a camera or a television tuner connected to the image encoding device 201. Then, the encoding unit 211 encodes the acquired image using parameters included in the SPS, PPS, and APS, and generates a bit stream of image data. Also, the encoding unit 211 generates SPS and PPS as non-VCL NAL units. On the other hand, the encoding unit 211 generates a bit stream of filler data and image data as a VCL NAL unit.
  • the encoding unit 211 outputs the filler data and the bit stream of the image data to the file generation unit 214 via the VCL buffer 212. Also, the encoding unit 211 outputs the SPS and the PPS to the file generation unit 214 via the non-VCL buffer 213.
  • the VCL buffer 212 buffers the VCL NAL unit.
  • the non-VCL buffer 213 buffers non-VCL NAL units.
  • the file generation unit 214 generates a HEVC file 151 that stores a series of encoded image data. More specifically, the file generation unit 214 inserts the filler data and the bit stream of the image data into the data area (for example, the mdat box) of the HEVC file 151 in the decoding order as a VCL NAL unit.
  • the file generation unit 214 inserts SPS and PPS as non-VCL NAL units into the header area (for example, moov box) of the HEVC file 151.
  • the control unit 215 controls encoding processing executed in the image encoding device 201.
  • control unit 215 can control the generation of an encoded stream so as not to break the decoder buffer, using a virtual decoder model called HRD (Hypothetical Reference Decoder).
  • HRD Hypothetical Reference Decoder
  • two types of conformance points of type 1 and type 2 are defined as conformance points (standard conformance check points) to be satisfied by the encoded stream.
  • Type 1 conformance points apply to VCL NAL units and filter data NAL units, not to non-VCL NAL units.
  • Type 2 conformance points apply to VCL NAL units, filter data NAL units, and non-VCL NAL units.
  • fillerfilldata is defined as a VCL NAL unit rather than a non-VCL NAL unit. Therefore, the control unit 215 may control the generation of the encoded stream so that not only the bit stream of the image data but also the filler data satisfies the type 1 conformance point.
  • FIG. 14 is a block diagram illustrating an example of a configuration of an image decoding apparatus according to an embodiment for decoding an image from the MP4 file described above.
  • the image decoding apparatus 251 includes a VCL buffer 261, a non-VCL buffer 262, a parameter memory 263, a decoding unit 264, and a control unit 265.
  • VCL buffer 261, the non-VCL buffer 262, the parameter memory 263, and the control unit 265 in FIG. 14 correspond to the file reading unit 51 in FIG. Further, the decoding unit 264 in FIG. 14 corresponds to the decoder 52 in FIG.
  • the VCL buffer 261 buffers the bit stream of image data and filler data read from the data area (for example, mdat box) of the file.
  • the non-VCL buffer 262 buffers a parameter set read from a file header area (for example, a moov box).
  • the parameter memory 263 collectively stores the parameter set in the header area of the file acquired via the non-VCL buffer 262.
  • the decoding unit 264 is a decoder that operates according to the HEVC method.
  • the decoding unit 264 decodes an image from a bit stream that is sequentially acquired from the data area of the file via the VCL buffer 261.
  • the decoding unit 264 uses parameters in the SPS and PPS stored in the parameter memory 263 when decoding an image.
  • the control unit 265 controls the decoding process executed in the image decoding device 251.
  • FIG. 15 is a diagram illustrating an example of a conventional MP4 video sample structure. NAL units constituting a video sample are defined as shown in FIG.
  • an AVC stream composed of a plurality of NAL units is shown.
  • one picture is one access unit.
  • the types of NAL units that make up an access unit include units such as SPS, PPS, access unit delimiter (access unit delimiter), SEI, IDR picture, non IDR picture, end of sequence (end of ⁇ ⁇ ⁇ sequence), and filler data. .
  • one access unit is stored in one video sample. That is, each NAL unit constituting one access unit is added with Unit ⁇ ⁇ ⁇ size and stored in one video sample.
  • the NAL units constituting the access unit include SPS, PPS, and filler data NAL units, the SPS, PPS, and filler data NAL units are excluded from the video samples.
  • the first access unit from the left consists of NAL units of access unit delimiters, SPS, PPS, SEI, and IDR pictures.
  • NAL units of SPS and PPS are Are excluded.
  • the second access unit from the left consists of the access unit delimiter, SPS, SEI, nonIDR picture, and filler data NAL unit.
  • SPS and filler data NAL unit are excluded.
  • the third access unit from the left is composed of access unit delimiters, SPS, SEI, and non-IDR picture NAL units, but the SPS NAL unit is excluded when storing the access unit in the sample. .
  • FIG. 16 is a diagram illustrating a configuration example of one access unit of an AVC stream.
  • an identifier (startcode) is added in front of each NAL unit. Identifiers are also excluded.
  • the access unit is stored as it is in the MP4 sample.
  • Example of storing the access unit of this technology 17 and 18 are diagrams illustrating examples of the MP4 video sample structure of the present technology.
  • the unit size describing the size of the access unit is added to the head of the access unit, and the access unit is stored as it is in the MP4 sample. “As is” means that the startcode is still added, and if there is filler data, the filler data is not deleted. That is, “as is” means that startcode and fillerfilldata are still set.
  • Step S75 of FIG. 11 or Step S96 of FIG. 12 described above access units corresponding to Unit size are detected, and among them, NAL is detected based on startcode.
  • step S76 in FIG. 11 or step S97 in FIG. 12 NAL data up to the next startcode IV is acquired.
  • the structure is very simple.
  • the unit size describing the size of each NAL unit including startcode is added to the head of each NAL unit constituting the access unit, and the access unit is stored as it is in the MP4 sample. Yes.
  • startcode + NAL corresponding to Unit size is detected in step S75 in Fig. 11 or step S96 in Fig. 12 described above. Then, in step S76 of FIG. 11 or step S97 of FIG. 12, the start code is discarded and NAL data is acquired.
  • the implementation is similar to the conventional size + data structure, but the startcode needs to be interpreted from the obtained data structure.
  • the unit size describing the size of each NAL unit is added to the head of each NAL unit constituting the access unit, and the size of the startcode including 0 data, that is, NAL Offset sizes up to are added.
  • the NAL unit in which the unit size and the offset size are added to the MP4 sample is stored as it is.
  • step S76 of FIG. 11 or step S97 of FIG. 12 NAL data corresponding to the unit size is acquired.
  • C in FIG. 18 is an example in which the FixedStartCodeSizeFlag of the HRD Conformance Box shown in FIG. 19 described later is 0.
  • FixedStartCodeSizeFlag is 0, start code size is not fixed, so the size of startcode is stored in offset size field.
  • the unit size describing the size of each NAL unit is added to the head of each NAL unit constituting the access unit, and the NAL unit is stored as it is in the MP4 sample. Yes.
  • the size of each NAL unit, the size of startcode, and the unit size in which startcode is described are added to the head of each NAL unit constituting the access unit, and further includes 0 data.
  • the size of startcode that is, the offset size up to NAL is added.
  • the NAL unit in which the unit size and the offset size are added to the MP4 sample is stored as it is.
  • step S75 of FIG. 11 or step S96 of FIG. 12 described above the offset size + startcode + NAL for the unit size is detected, the offset size is acquired, and from the position where the offset is skipped, NAL is detected.
  • step S76 in FIG. 11 or step S97 in FIG. 12 NAL data corresponding to Unit size ⁇ (offset size + startcode) is acquired.
  • D of FIG. 18 is an example when FixedStartCodeSizeFlag of HRD Conformance Box is 0.
  • FixedStartCodeSizeFlag is 0, start code size is not fixed, so the size of startcode is stored in offset size field.
  • the structure is close to the conventional size + data structure, and the implementation is as before, but it is a parse structure that skips the offset size at the beginning of the obtained data structure. In this case, startcode needs to be interpreted.
  • FIG. 19 is a diagram illustrating an example of HRD Conformance Box extension. An example of HRD Conformance Box extension is also shown below.
  • AVCSampleEntry extends VisualSampleEntry ('type') ⁇ // type is 'avc3' or 'avc4', (and all hevc) AVCConfigurationBox config; MPEG4BitRateBox (); // Optional MPEG4ExtensionDescriptorsBox (); // Optional HRDConformanceBox (); // Optional ⁇ Add HRDConformanceBox into AVCSampleEntry and AVC2SVVSampleEntry in 5.4.2.1 Add HRDConformanceBox into AVCSVCSampleEntry, AVC2SVCSampleEntry and SVCSampleEntry in 6.5.3.1.
  • HRDConformanceBox into AVCMVCSampleEntry, AVC2MVCSampleEntry and MVCSampleEntry in section7.6.3.3. Add HRDConformanceBox into HEVC SampleEntry in section 8.4.1.1. Sample entry without HRDConformanceBox is used only for samples without start codes nor fillers. HRDConformanceBox can be defined as follows.
  • HRDConformanceFlag is equal to1, the HRD parameters, eg buffering period SEI, picture timing SEI, was changed by removing startcode, filler data, etc from the elementary stream
  • FixedStartCodeSizeFlag is the idetifier when startcode in each NAL is fixed size of 4 bytes.When FixedStartCodeSizeFlag is equal to 1, no offset field is for each NAL in sample data to indicate the size of Start Code.
  • Offset exampleMinusOne indicates the length in bytes of the StartcodeLength field in a video sample minus one.For example, a size of one byte is indicated with a value of 0.The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
  • HRDConformanceBox is useful to indicate the status of HRD conformance even in the other options.
  • FixedStartCodeSizeFlag which is a flag for identifying the presence / absence of startcode size information, is additionally defined in the HRD Conformance Box.
  • FIG. 20 is a diagram illustrating another example of the MP4 video sample structure according to the present technology.
  • the unit size is removed from the mdat, and the elementary stream including the startcode is stored (stored) without change.
  • offset_count is an integer that gives the number of entries in the following subtable.
  • offset_size is an integer that gives the byte size of the offset field in the following subtable.
  • offset is an integer that gives the offset of the start of a NAL unit into its containing sample.
  • a list of offsets may be included at the beginning of each sample as shown in the example of E ′ in FIG. Good.
  • MP4 video sample file shown in FIGS. 17 and 18 is generated by the file generation process shown in FIG. 4 or 5 by the file generation unit 2 having the configuration shown in FIG.
  • the MP4 video sample file shown in FIGS. 20 and 22 is also generated by the file generation process shown in FIG. 4 or 5 by the file generation unit 2 having the configuration shown in FIG.
  • the MP4 video sample file shown in FIGS. 17 and 18 is decoded by the above-described file decoding process shown in FIG. 11 or FIG.
  • the MP4 video sample files shown in FIGS. 20 and 22 are also decoded by the file reading unit 51 shown in FIG.
  • FIG. 23 is a diagram illustrating still another example of the MP4 video sample structure according to the present technology.
  • the unit size is removed from the mdat, and the elementary stream including the startcode is stored (stored) without change.
  • startcode start code
  • NAL unit NAL unit
  • a sample auxiliary information function defined in ISO / IEC 14496-12 is applied.
  • the sample auxiliary information function is referred to by 'saiz' which is a sample auxiliary information function size box (SampleAuxiliaryInformationSizesBox) to be used and 'saio' which is a sample auxiliary information function offset box.
  • FIG. 24 is a diagram illustrating an example of the format of the sample auxiliary information function. An example of the format of the sample auxiliary information function is also shown below.
  • NALUnitSizeMinusOne indicates the length in bytes of the NALUnit Size field minus one.For example, a size of one byte is indicated with a value of 0.The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
  • StartcodeSize indicates the length in bytes of the Startcode of subsample in a sample
  • NALUnitSize indicates the length in bytes of the Startcode of subsample in a sample
  • StartcodeSizeMinusOne indicates a value obtained by subtracting 1 from the byte length of the start code size field (StartcodeStartSize field). For example, when the byte length of the start code size field is 1 byte, the value of StartcodeSizeMinusOne is 0. The value of StartcodeSizeMinusOne is 0, 1, or 3 corresponding to the code length of 1 byte, 2 bytes, or 4 bytes.
  • NALUnitSizeMinusOne indicates a value obtained by subtracting 1 from the byte length of the NAL unit size field (NALUnit Size field). For example, when the byte length of the NAL unit size field is 1 byte, the value of NALUnitSizeMinusOne is 0. The value of NALUnitSizeMinusOne is 0, 1, or 3 corresponding to the code length of 1 byte, 2 bytes, or 4 bytes.
  • StartcodeSize indicates the byte length of the start code of the subsample in the sample.
  • NALUnitSize indicates the byte length of the NAL unit (NAL unit) of the subsample in the sample.
  • the format of the sample auxiliary information function may be as follows.
  • FIG. 25 is a diagram illustrating another example of the format of the sample auxiliary information function. In the following, another example of the format of the sample auxiliary information function is also shown.
  • Start value SizeMinusOne indicates the length in bytes of the Startcode Size field minus one.For example, a size of one byte is indicated with a value of 0.The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
  • NALUnitSizeMinusOne indicates the length in bytes of the NALUnit Size field minus one.For example, a size of one byte is indicated with a value of 0.The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
  • StartcodeSize indicates the length in bytes of the Startcode of subsample in a sample
  • NALUnitSize indicates the length in bytes of the Startcode of subsample in a sample
  • FixedStartCodeSizeFlag is flag information. This is flag information indicating whether or not the size of the start code (startcode) before each NAL unit (NAL unit) is 4 bytes. If the size of the start code (startcode) before each NAL unit (NAL unit) is 4 bytes, the value of FixedStartCodeSizeFlag is set to 1; otherwise, it is set to 0. In other words, when the value of FixedStartCodeSizeFlag is 1, it indicates that the size of the start code (startcode) before each NAL unit (NAL unit) is 4 bytes, and when the value of FixedStartCodeSizeFlag is 0, each NAL Indicates that the size of the start code (startcode) before the unit (NAL unit) is not 4 bytes.
  • MP4 video sample file in FIG. 23 is generated by the file generation process in FIG. 4 or 5 described above by the file generation unit 2 having the configuration in FIG. 3 described above.
  • MP4 video sample file shown in FIG. 23 is decoded by the file reading unit 51 shown in FIG.
  • sample Auxiliary Information with aux_info_type equal to 'nalz' and aux_info_type_parameter equal to 0.
  • sample Auxiliary Information is referenced by using a SampleAuxiliaryInformationSizesBox ('saiz') and a SampleAuxiliaryInformationOffsetsBox ('saio')
  • Start example Size anus of the length in bytes of the Startcode Size field minus one.
  • a size of one byte is indicated with a value of 0.
  • the value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
  • NALUnitSizeMinusOne indicates the length in bytes of the NALUnit Size field minus one.
  • a size of one byte is indicated with a value of 0.
  • the value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
  • StartcodeSize indicates the length in bytes of the Startcode of subsample in a sample
  • NALUnitSize indicates the length in bytes of the NAL unit of subsample in a sample
  • the storage example of the access unit B in FIG. 17 has an advantage of being close to the conventional (current) size + data structure.
  • the storage example of the access unit C in FIG. 18 or C ′ in FIG. 18 is close to the conventional (current) size + data structure, and has the advantage that the unit size semantics are not changed. Also, when the startcode size is fixed, there is an advantage that the data structure is the same as the conventional (current) file format design.
  • the example of storing the access unit D in FIG. 18 or D ′ in FIG. 18 has an advantage of being close to the conventional (current) size + data structure.
  • the store to the elementary stream is simple (that is, it is not necessary to remove the startcode, and it is not necessary to add the unit size or the startcode size. ).
  • C in FIG. 18 or C ′ in FIG. 18 is the best proposal.
  • E in FIG. 20 or E ′ in FIG. 22 is the best way to store an elementary stream without any changes.
  • FIG. 27 is a diagram showing another example of the MP4 video sample structure of FIG.
  • each start code (startcode) is included in the NAL unit (NAL unit), and the length of the NAL unit including the start code is stored in the ISO.
  • the sample auxiliary information function specified in / IEC 14496-12 is applied.
  • the sample auxiliary information function is referred to by 'saiz' which is a sample auxiliary information function size box (SampleAuxiliaryInformationSizesBox) to be used and 'saio' which is a sample auxiliary information function offset box.
  • the length of the start code is not stored as the sample auxiliary information function, but only the length of the NAL unit including the start code is stored. Therefore, the example of G in FIG. 27 is the same as the example of F in FIG. 23 except that the length of the start code is not stored.
  • the MP4 video sample file shown in FIG. 27 is generated by the file generation process shown in FIG. 4 or 5 by the file generation unit 2 having the configuration shown in FIG.
  • MP4 video sample file shown in FIG. 27 is decoded by the file reading unit 51 shown in FIG.
  • a byte stream format that is a stream including startcode stored in an MPEG2-PS file is defined.
  • a byte stream format information box for storing byte stream format information is defined so that it can be identified whether there is a byte stream in the sample.
  • Byte stream format information box is optionally defined for sample entries that can contain parameter sets. Sample entries that can contain parameter sets etc. can also be stored as byte streams. At this time, this box is stored in order to signal that it is a byte stream.
  • the Byte Stream Format Information Box may be stored in 'avc3', 'avc4', 'mvc3', 'mvc4' or 'hev1' Sample Entry (in Sample entry box of media track). This box SHALL be stored when sample data is structured by Byte Stream Format as defined in ISO / IEC 14496-10.
  • the Sub-Sample Information Box may be used to store one or more contiguous Byte stream NAL unit size a sub-sample is defined as one or more contiguous Byte stream NAL units as defined in ISO / IEC 14496-10.
  • the byte stream format information box is stored (stored) in the sample entry of 'avc3', 'avc4', 'mvc3', 'mvc4', or 'hevc1' in the sample entry box of the media track.
  • the sample entry of 'avc3', 'avc4', 'mvc3', 'mvc4', or 'hevc1' is a sample entry that can contain a parameter set or the like.
  • the subsample information box may be used to store a NAL unit size including one or more consecutive startcodes.
  • a subsample is defined as one or more consecutive byte stream NAL units as defined in ISO / IEC 14496-10.
  • box type is 'bsfi'
  • the included (Container) is a sample entry of 'avc3', 'avc4', 'mvc3', 'mvc4', or 'hevc1'.
  • Constant a sample entry of 'avc3', 'avc4', 'mvc3', 'mvc4', or 'hevc1'.
  • the byte stream format information box extends the 'bsfi' box in which the byte stream format information is described.
  • sample entries of new formats 'avc5', 'avc6', 'mvc5', 'mvc6', or 'hevc2' The sample entry can be expanded simply by inserting.
  • FIG. 29 is a diagram showing another example of the byte stream format information box.
  • the Byte Stream Format Information Box SHALL be stored in 'avc5', 'avc6', 'mvc5', 'mvc6' or 'hev2' Sample Entry (in Sample entry box of media track). This box SHALL be stored when sample data is structured by Byte Stream Format as defined in ISO / IEC 14496-10.
  • the Sub-Sample Information Box may be used to store one or more contiguous Byte stream NAL unit size a sub-sample is defined as one or more contiguous Byte stream NAL units as defined in ISO / IEC 14496-10.
  • 'avc3', 'avc4', 'mvc3', 'mvc4', or 'hevc1' is a type of codec that can contain a parameter set, but 'avc3', 'avc4', 'mvc3', In case of 'mvc4' or 'hevc1', startcode may or may not be entered.
  • the codec type including all startcodes is expanded to 'avc5', 'avc6', 'mvc5', 'mvc6' or 'hev2', etc.
  • this sample entry it is possible to identify whether or not there is a byte stream in the sample.
  • the sample entry is 'avc3', 'avc4', 'mvc3', 'mvc4', or 'hevc1'
  • the byte stream format information as follows, Whether or not there is a byte stream (that is, whether or not startcode is included) can be identified.
  • the byte stream format information is configured as follows to indicate the structure of the subsample byte stream be able to.
  • FIG. 30 is a diagram for explaining an example data structure of byte stream format information stored in each sample entry.
  • StartcodePresentFlag is a flag indicating the presence or absence of Startcode in the sample. If all subsamples in the sample include a 3-byte Startcode before the NAL unit, StartcodePresentFlag is 1.
  • ZeroBytePresentFlag is a flag indicating the presence or absence of 1-byte zero data before Startcode. When this Flag is 1, it indicates that Startcode is 4 bytes.
  • StartcodePresentFlag and ZeroBytePresentFlag
  • a 2-bit flag may be used to indicate whether the Startcode is 3 bytes or 4 bytes.
  • LeadingZeroBytePresentFlag is a flag indicating the presence or absence of 0 data in the sample.
  • LeadingZeroBytePresentFlag becomes 1 when a plurality of 1-byte 0x00 is included before 3 bytes or 4 bytes of at least one of the subsamples in the sample.
  • LeadingZeroBytePresentFlag is 0, it can be seen that the top of the subsample is a fixed-length start code.
  • TrailingZeroBytePresentFlag is a flag indicating the presence or absence of 0 data in the sample. TrailingZeroBytePresentFlag is 1 when a plurality of 1-byte 0x00 is included after the 3-byte NAL unit of at least one of the sub-samples in the sample.
  • FIG. 31 is a diagram illustrating an example of an MP4 video sample structure in the case of pattern 1 having 0x00 (0 data) before and after the NAL unit. That is, in the example of FIG. 31, an example of the MP4 video sample structure in the case where StartcodePresentFlag, ZeroBytePresentFlag, LeadingZeroBytePresentFlag, and TrailingZeroBytePresentFlag, which are the above-described byte stream format information flags, are all 1 is shown.
  • the sample is composed of 5 subsamples, and the size of the 5 subsamples is stored in the sample size box as the sample size.
  • the subsample is composed of leading 0 data (LeadingZeroBytes), Startcode (4 bytes), NAL unit, and trailing 0 data (TrailingZeroBytes).
  • the size from the leading 0 data to the trailing 0 data is sub
  • the sample size is stored in the subsample information box. That is, since the subsample information box has the size of the subsample, the subsample boundary can be known.
  • the sample auxiliary information function is referred to by 'saiz' which is a sample auxiliary information function size box (SampleAuxiliaryInformationSizesBox) to be used and 'saio' which is a sample auxiliary information function offset box.
  • this operation may be used in CBR (constant bit rate) for business use. Therefore, this pattern 1 is suitable, for example, when it is used for a stream in which all for business use is composed of intra pictures.
  • the separation between LeadingZeroBytes and TrailingZeroBytes may be set by operating the application, for example.
  • FIG. 32 is a diagram illustrating an example of the MP4 video sample structure in the case of the pattern 2 in which the subsample starts from Startcode and does not have 0x00 (0 data). That is, in the example of FIG. 32, an example of the MP4 video sample structure in the case where StartcodePresentFlag and ZeroBytePresentFlag are 1 and LeadingZeroBytePresentFlag and TrailingZeroBytePresentFlag is 0 is shown.
  • the subsample is composed of Startcode (4 bytes) and NAL unit, and the size from Startcode to NAL unit is stored in the subsample information box as the size of the subsample. That is, since the subsample information box has the size of the subsample, the subsample boundary can be known.
  • This pattern 2 is the simplest example.
  • FIG. 33 is a diagram illustrating an example of the MP4 video sample structure in the case of the pattern 3 in which the subsample starts from Startcode and NAL is followed by 0x00 (0 data). That is, in the example of FIG. 33, an example of an MP4 video sample structure in the case where StartcodePresentFlag, ZeroBytePresentFlag, and TrailingZeroBytePresentFlag is 1 and LeadingZeroBytePresentFlag is 0 is shown.
  • the sample is composed of five subsamples, and the size of the five subsamples is stored in the sample size box as the sample size.
  • the subsample consists of Startcode (4 bytes), NAL unit, and trailing 0 data (TrailingZeroBytes).
  • Startcode 4 bytes
  • NAL unit NAL unit
  • trailing 0 data TrailingZeroBytes
  • the size from Startcode to trailing 0 data is stored in the subsample information box as the subsample size. ing. That is, since the subsample information box has the size of the subsample, the subsample boundary can be known.
  • this pattern 3 has an advantage that it is easy to edit because, for example, in a stream editing machine composed of all intra pictures for business use, it can be seen that TrailingZero has a fixed length.
  • the 3 byte start code may be used in a video conference system.
  • the byte stream format information is boxed and the byte stream format information is defined.
  • the subsample is configured as any one of the patterns 1 to 3 described above with reference to FIGS. 31 to 33, it is possible to identify whether or not the sample is a byte stream.
  • the files of the MP4 video samples shown in FIGS. 31 to 33 are generated by the file generation process shown in FIG. 4 or 5 by the file generation unit 2 having the configuration shown in FIG.
  • each MP4 video sample file shown in FIG. 31 to FIG. 33 is decoded by the file reading unit 51 shown in FIG.
  • FIG. 34 is a diagram for explaining an example data structure of byte stream format information stored in each sample entry. That is, in the example of FIG. 34, another example of the data structure described above with reference to FIG. 30 is shown.
  • StartcodePresentFlag is a 2-bit flag indicating the structure of Startcode of all subsamples.
  • StartcodePresentFlag 00b indicates reserved.
  • StartcodePresentFlag 01b indicates that all subsamples in the sample include a 3-byte Startcode before the NAL unit.
  • StartcodePresentFlag 10b indicates that all subsamples in the sample include 3 bytes of Startcode and 1 byte of ZeroByte data (ie, 4 bytes) before the NAL unit.
  • StartcodePresentFlag 11b indicates that all sub-samples in the sample include 3 bytes of Startcode and 1 byte of ZeroByte data before the NAL unit. That is, in this case, since there is a possibility that 3 bytes and 4 bytes of Startcode are mixed, it cannot be guaranteed whether it is 01b or 10b.
  • This example is another example of the structure example described with reference to FIG. 30 and is an example in which the size of the Startcode is known.
  • a 2 bit flag indicates 3 bytes, 4 bytes, or a mixture thereof.
  • LeadingZeroBytePresentFlag indicates that among the subsamples in the sample, a plurality of 1 byte 0x00 may be included before 3 bytes or 4 bytes of Startcode of at least one subsample.
  • TrailingZeroBytePresentFlag indicates that a plurality of 1 byte 0x00 may be included after the NAL unit of at least one subsample among the subsamples in the sample.
  • FIG. 35 is a block diagram illustrating a configuration example of a file conversion apparatus as an image processing apparatus to which the present technology is applied.
  • the file conversion apparatus 300 in FIG. 35 converts, for example, MPEG-2 TS into an MP4 file.
  • the file conversion apparatus 300 is configured to include a video stream analysis unit 311 and the file generation unit 2 of FIG.
  • the video stream analysis unit 311 analyzes the format of the input video stream, and supplies the video stream to the file generation unit 2 when analyzing the MPEG-2 TS.
  • the file generation unit 2 performs processing to convert MPEG-2 TS to MP4 file. That is, the file generation unit 2 generates an MP4 file that stores MPEG-2 TS as in the example of FIG.
  • step S311 the video stream analysis unit 311 analyzes the format of the input video stream, and if the video stream analysis unit 311 analyzes that it is MPEG-2 TS, supplies the video stream to the file generation unit 2.
  • step S312 the file generation unit 2 generates an MP4 file storing MPEG-2 TS. Since this file generation process is the same as the file generation process described above with reference to FIG. 5, the description thereof will be omitted to avoid repetition.
  • the file conversion apparatus 300 can also be configured.
  • the encoding device and decoding device based on the HEVC method have been described, but the present technology can also be applied to an encoding device and decoding device based on the AVC method, as will be described below.
  • FIG. 37 is a block diagram illustrating another configuration example of the encoding device as the image processing device to which the present technology is applied.
  • FIG. 37 differs from the configuration of FIG. 1 in that an encoder 401 is provided instead of the encoder 1.
  • the configuration of the encoding device in FIG. 37 is common to the configuration in FIG. 1 in that the file generation unit 2 is provided.
  • an image such as a captured image in units of frames is input to the encoder 401 as an input signal. Further, SPS set in the preceding stage of the encoder 401 (not shown), VUI, SEI, and the like indicating the characteristics of the image corresponding to the encoded data for each sequence are also input.
  • Encoder 401 encodes an input signal by the AVC method using parameters included in SPS, PPS, VUI, and SEI. Then, the encoder 401 generates an encoded stream such as MPEG-2 TS from the SPS, PPS, VUI, SEI and the encoded data obtained as a result, and transmits the generated encoded stream to the file generation unit 2. Supply. Details of the encoder 401 will be described later with reference to FIG.
  • the file generation unit 2 generates a file that stores the encoded stream (encoded series of image data) from the encoder 401.
  • the encoding apparatus of FIG. 36 is different from the encoding apparatus of FIG. 1 only in that encoding processing by the AVC method is performed.
  • FIG. 38 is a block diagram illustrating a configuration example of the encoder 401 in FIG.
  • a / D conversion unit 11 includes an A / D conversion unit 11, a screen rearrangement buffer 12, a calculation unit 13, an orthogonal transformation unit 14, a quantization unit 15, a lossless encoding unit 16, a storage buffer 17, an inverse quantization unit 18, An inverse orthogonal transform unit 19, an addition unit 20, a deblock filter 21, a frame memory 22, a switch 23, an intra prediction unit 24, a motion prediction / compensation unit 25, a predicted image selection unit 26, and a rate control unit 27 are configured. Is done.
  • the configuration of the encoder 401 in FIG. 38 is only illustrated in that the adaptive offset filter 141 and the adaptive loop filter 142 are removed, and that the lossless encoding unit 16 performs encoding using the AVC method instead of the HEVC method. Different from the configuration of 2. Therefore, in the encoder 401, encoding processing is performed in units of blocks, not in units of CUs.
  • the object of the encoding process of the lossless encoding unit 16 is basically the same as that of the lossless encoding unit 16 of FIG. 2 except for the parameters of the adaptive offset filter and the adaptive loop filter. That is, the lossless encoding unit 16 acquires the intra prediction mode information from the intra prediction unit 24 as in the case of the lossless encoding unit 16 of FIG. Also, inter prediction mode information, motion vectors, information for specifying a reference image, and the like are acquired from the motion prediction / compensation unit 25.
  • the lossless encoding unit 16 performs variable length encoding (for example, CAVLC) and arithmetic encoding on the quantized coefficient supplied from the quantization unit 15.
  • Variable length encoding for example, CAVLC
  • CABAC for example, CABAC
  • the lossless encoding unit 16 similarly to the lossless encoding unit 16 of FIG. 2, intra prediction mode information, inter prediction mode information, motion vector, information specifying a reference image, offset filter information, and filter coefficients Etc. are losslessly encoded as encoding information relating to encoding.
  • the lossless encoding unit 16 supplies the encoding information and the coefficients that have been losslessly encoded to the accumulation buffer 17 as encoded data and accumulates them.
  • the losslessly encoded information may be the header information of the losslessly encoded coefficient.
  • the deblocking filter 21 removes block distortion by filtering the locally decoded image supplied from the adding unit 20.
  • the deblocking filter 21 supplies the image obtained as a result to the frame memory 22 and accumulates it.
  • the image stored in the frame memory 22 is output as a reference image to the intra prediction unit 24 or the motion prediction / compensation unit 25 via the switch 23.
  • the present technology can also be applied to such an AVC encoding device.
  • FIG. 39 is a block diagram illustrating another configuration example of a decoding device to which the present technology is applied, which reads and decodes a file generated by the encoding device of FIG.
  • FIG 39 differs from the configuration of FIG. 8 in that a decoder 451 is provided instead of the decoder 52.
  • the configuration of the decryption device 251 is common to the configuration of FIG. 8 in that the file reading unit 51 is provided.
  • the file reading unit 51 of the decoding device receives the MP4 file generated by the encoding device of FIG. 37, and from the received file, the SPS, PPS, and SPS that constitute the encoded stream encoded by the encoder 401 of FIG. Read VUI, SEI, encoded data, etc.
  • the file reading unit 51 supplies SPS, PPS, VUI, SEI, and encoded data to the decoder 451.
  • the decoder 451 Under the control of the file reading unit 51, the decoder 451 refers to SPS, PPS, VUI, SEI, etc. supplied from the file reading unit 51, and decodes the encoded data supplied from the file reading unit 51 by the AVC method. To do.
  • the decoder 451 supplies an image obtained as a result of decoding to the subsequent stage as an output signal.
  • the decoding device of FIG. 39 is different from the decoding device of FIG. 8 only in that the decoding process by the AVC method is performed.
  • FIG. 40 is a block diagram illustrating a configuration example of the decoding unit 261 in FIG.
  • the 40 includes a storage buffer 101, a lossless decoding unit 102, an inverse quantization unit 103, an inverse orthogonal transform unit 104, an addition unit 105, a deblock filter 106, a screen rearrangement buffer 107, a D / A conversion unit 108, The frame memory 109, the switch 110, the intra prediction unit 111, the motion compensation unit 112, and the switch 113 are included.
  • the configuration of the decoder 451 in FIG. 40 is the same as the configuration in FIG. 10 except that the adaptive offset filter 141 and the adaptive loop filter 142 are removed and that the lossless decoding unit 102 performs decoding by the AVC method instead of the HEVC method. Different. Therefore, in the decoding unit 261, the decoding process is performed in units of blocks, not in units of CUs.
  • the object of the decoding process of the lossless decoding unit 102 is basically the same as that of the lossless decoding unit 102 of FIG. 10 except for the parameters of the adaptive offset filter and the adaptive loop filter. That is, the lossless decoding unit 102 is quantized by performing lossless decoding such as variable-length decoding and arithmetic decoding on the encoded data from the storage buffer 101, similarly to the lossless decoding unit 102 of FIG. Coefficient and coding information are obtained. The lossless decoding unit 102 supplies the quantized coefficient to the inverse quantization unit 103.
  • the lossless decoding unit 102 supplies intra prediction mode information or the like as encoded information to the intra prediction unit 111 in the same manner as the lossless decoding unit 102 of FIG. 10, and information for specifying a motion vector and a reference image, Inter prediction mode information and the like are supplied to the motion compensation unit 112. Further, the lossless decoding unit 102 supplies intra prediction mode information or inter prediction mode information as encoded information to the switch 113.
  • the deblock filter 106 removes block distortion by filtering the image supplied from the addition unit 105.
  • the deblocking filter 106 supplies the resulting image to the frame memory 109 and the screen rearrangement buffer 107.
  • the present technology can also be applied to such an AVC decoding device.
  • the file format is not limited to the MP4 file format or the AVC file format. If the problems and effects of the present technology are the same, the present invention can be similarly applied to another file format, a stream used for transmission, and a stream used for storing in a file.
  • the present disclosure provides, for example, image information (bitstream) compressed by orthogonal transformation such as discrete cosine transformation and motion compensation, such as HEVC, satellite broadcasting, cable television, the Internet, or a mobile phone.
  • image information such as discrete cosine transformation and motion compensation
  • HEVC discrete cosine transformation and motion compensation
  • the present invention can be applied to an image encoding device and an image decoding device used when receiving via a network medium.
  • the present disclosure can be applied to an image encoding device and an image decoding device that are used when processing on a storage medium such as an optical disk, a magnetic disk, and a flash memory.
  • the series of processes described above can be executed by hardware or can be executed by software.
  • a program constituting the software is installed in the computer.
  • the computer includes, for example, a general-purpose personal computer capable of executing various functions by installing various programs by installing a computer incorporated in dedicated hardware.
  • FIG. 41 is a block diagram showing an example of a hardware configuration of a computer that executes the above-described series of processing by a program.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • an input / output interface 805 is connected to the bus 804.
  • An input unit 806, an output unit 807, a storage unit 808, a communication unit 809, and a drive 810 are connected to the input / output interface 805.
  • the input unit 806 includes a keyboard, a mouse, a microphone, and the like.
  • the output unit 807 includes a display, a speaker, and the like.
  • the storage unit 808 includes a hard disk, a nonvolatile memory, and the like.
  • the communication unit 809 includes a network interface or the like.
  • the drive 810 drives a removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 801 loads the program stored in the storage unit 808 to the RAM 803 via the input / output interface 805 and the bus 804 and executes the program, for example. Is performed.
  • the program executed by the computer 800 can be provided by being recorded in, for example, a removable medium 811 as a package medium or the like.
  • the program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • the program can be installed in the storage unit 808 via the input / output interface 805 by attaching the removable medium 811 to the drive 810.
  • the program can be received by the communication unit 809 via a wired or wireless transmission medium and installed in the storage unit 808.
  • the program can be installed in the ROM 802 or the storage unit 808 in advance.
  • the program executed by the computer may be a program that is processed in time series in the order described in this specification, or in parallel or at a necessary timing such as when a call is made. It may be a program for processing.
  • the step of describing the program recorded on the recording medium is not limited to the processing performed in chronological order according to the described order, but may be performed in parallel or It also includes processes that are executed individually.
  • system represents the entire apparatus composed of a plurality of devices (apparatuses).
  • the configuration described as one device (or processing unit) may be divided and configured as a plurality of devices (or processing units).
  • the configurations described above as a plurality of devices (or processing units) may be combined into a single device (or processing unit).
  • a configuration other than that described above may be added to the configuration of each device (or each processing unit).
  • a part of the configuration of a certain device (or processing unit) may be included in the configuration of another device (or other processing unit). . That is, the present technology is not limited to the above-described embodiment, and various modifications can be made without departing from the gist of the present technology.
  • the present technology can take a configuration of cloud computing in which one function is shared by a plurality of devices via a network and is jointly processed.
  • each step described in the above flowchart can be executed by being shared by a plurality of apparatuses in addition to being executed by one apparatus.
  • the plurality of processes included in the one step can be executed by being shared by a plurality of apparatuses in addition to being executed by one apparatus.
  • An image encoding device and an image decoding device include a transmitter or a receiver in optical broadcasting, satellite broadcasting, cable broadcasting such as cable TV, distribution on the Internet, and distribution to terminals by cellular communication, etc.
  • the present invention can be applied to various electronic devices such as a recording device that records an image on a medium such as a magnetic disk and a flash memory, or a playback device that reproduces an image from these storage media.
  • a recording device that records an image on a medium such as a magnetic disk and a flash memory
  • a playback device that reproduces an image from these storage media.
  • FIG. 42 illustrates an example of a schematic configuration of a television device to which the above-described embodiment is applied.
  • the television apparatus 900 includes an antenna 901, a tuner 902, a demultiplexer 903, a decoder 904, a video signal processing unit 905, a display unit 906, an audio signal processing unit 907, a speaker 908, an external interface 909, a control unit 910, a user interface 911, And a bus 912.
  • Tuner 902 extracts a signal of a desired channel from a broadcast signal received via antenna 901, and demodulates the extracted signal. Then, the tuner 902 outputs the encoded bit stream obtained by the demodulation to the demultiplexer 903. In other words, the tuner 902 serves as a transmission unit in the television apparatus 900 that receives an encoded stream in which an image is encoded.
  • the demultiplexer 903 separates the video stream and audio stream of the viewing target program from the encoded bit stream, and outputs each separated stream to the decoder 904. Further, the demultiplexer 903 extracts auxiliary data such as EPG (Electronic Program Guide) from the encoded bit stream, and supplies the extracted data to the control unit 910. Note that the demultiplexer 903 may perform descrambling when the encoded bit stream is scrambled.
  • EPG Electronic Program Guide
  • the decoder 904 decodes the video stream and audio stream input from the demultiplexer 903. Then, the decoder 904 outputs the video data generated by the decoding process to the video signal processing unit 905. In addition, the decoder 904 outputs audio data generated by the decoding process to the audio signal processing unit 907.
  • the video signal processing unit 905 reproduces the video data input from the decoder 904 and causes the display unit 906 to display the video.
  • the video signal processing unit 905 may cause the display unit 906 to display an application screen supplied via a network.
  • the video signal processing unit 905 may perform additional processing such as noise removal on the video data according to the setting.
  • the video signal processing unit 905 may generate a GUI (Graphical User Interface) image such as a menu, a button, or a cursor, and superimpose the generated image on the output image.
  • GUI Graphic User Interface
  • the display unit 906 is driven by a drive signal supplied from the video signal processing unit 905, and displays an image on a video screen of a display device (for example, a liquid crystal display, a plasma display, or an OELD (Organic ElectroLuminescence Display) (organic EL display)). Or an image is displayed.
  • a display device for example, a liquid crystal display, a plasma display, or an OELD (Organic ElectroLuminescence Display) (organic EL display)). Or an image is displayed.
  • the audio signal processing unit 907 performs reproduction processing such as D / A conversion and amplification on the audio data input from the decoder 904, and outputs audio from the speaker 908.
  • the audio signal processing unit 907 may perform additional processing such as noise removal on the audio data.
  • the external interface 909 is an interface for connecting the television apparatus 900 to an external device or a network.
  • a video stream or an audio stream received via the external interface 909 may be decoded by the decoder 904. That is, the external interface 909 also has a role as a transmission unit in the television apparatus 900 that receives an encoded stream in which an image is encoded.
  • the control unit 910 includes a processor such as a CPU and memories such as a RAM and a ROM.
  • the memory stores a program executed by the CPU, program data, EPG data, data acquired via a network, and the like.
  • the program stored in the memory is read and executed by the CPU when the television apparatus 900 is activated.
  • the CPU executes the program to control the operation of the television device 900 according to an operation signal input from the user interface 911, for example.
  • the user interface 911 is connected to the control unit 910.
  • the user interface 911 includes, for example, buttons and switches for the user to operate the television device 900, a remote control signal receiving unit, and the like.
  • the user interface 911 detects an operation by the user via these components, generates an operation signal, and outputs the generated operation signal to the control unit 910.
  • the bus 912 connects the tuner 902, the demultiplexer 903, the decoder 904, the video signal processing unit 905, the audio signal processing unit 907, the external interface 909, and the control unit 910 to each other.
  • the decoder 904 has the function of the image decoding apparatus according to the above-described embodiment (for example, the decoding apparatus including the file reading unit 51 and the decoder 52 in FIG. 8). Thereby, when decoding an image on the television device 900, it is possible to reduce a processing load when decoding a stream used for transmission or a stream used for storing in a file.
  • FIG. 43 shows an example of a schematic configuration of a mobile phone to which the above-described embodiment is applied.
  • a cellular phone 920 includes an antenna 921, a communication unit 922, an audio codec 923, a speaker 924, a microphone 925, a camera unit 926, an image processing unit 927, a demultiplexing unit 928, a recording / reproducing unit 929, a display unit 930, a control unit 931, an operation A portion 932 and a bus 933.
  • the antenna 921 is connected to the communication unit 922.
  • the speaker 924 and the microphone 925 are connected to the audio codec 923.
  • the operation unit 932 is connected to the control unit 931.
  • the bus 933 connects the communication unit 922, the audio codec 923, the camera unit 926, the image processing unit 927, the demultiplexing unit 928, the recording / reproducing unit 929, the display unit 930, and the control unit 931 to each other.
  • the mobile phone 920 has various operation modes including a voice call mode, a data communication mode, a shooting mode, and a videophone mode, and is used for sending and receiving voice signals, sending and receiving e-mail or image data, taking images, and recording data. Perform the action.
  • the analog voice signal generated by the microphone 925 is supplied to the voice codec 923.
  • the audio codec 923 converts an analog audio signal into audio data, A / D converts the compressed audio data, and compresses it. Then, the audio codec 923 outputs the compressed audio data to the communication unit 922.
  • the communication unit 922 encodes and modulates the audio data and generates a transmission signal. Then, the communication unit 922 transmits the generated transmission signal to a base station (not shown) via the antenna 921. In addition, the communication unit 922 amplifies a radio signal received via the antenna 921 and performs frequency conversion to acquire a received signal.
  • the communication unit 922 demodulates and decodes the received signal to generate audio data, and outputs the generated audio data to the audio codec 923.
  • the audio codec 923 decompresses the audio data and performs D / A conversion to generate an analog audio signal. Then, the audio codec 923 supplies the generated audio signal to the speaker 924 to output audio.
  • the control unit 931 generates character data constituting the e-mail in response to an operation by the user via the operation unit 932.
  • the control unit 931 causes the display unit 930 to display characters.
  • the control unit 931 generates e-mail data in response to a transmission instruction from the user via the operation unit 932, and outputs the generated e-mail data to the communication unit 922.
  • the communication unit 922 encodes and modulates email data and generates a transmission signal. Then, the communication unit 922 transmits the generated transmission signal to a base station (not shown) via the antenna 921.
  • the communication unit 922 amplifies a radio signal received via the antenna 921 and performs frequency conversion to acquire a received signal.
  • the communication unit 922 demodulates and decodes the received signal to restore the email data, and outputs the restored email data to the control unit 931.
  • the control unit 931 displays the content of the electronic mail on the display unit 930 and stores the electronic mail data in the storage medium of the recording / reproducing unit 929.
  • the recording / reproducing unit 929 has an arbitrary readable / writable storage medium.
  • the storage medium may be a built-in storage medium such as a RAM or a flash memory, or an externally mounted type such as a hard disk, magnetic disk, magneto-optical disk, optical disk, USB (Universal Serial Bus) memory, or memory card. It may be a storage medium.
  • the camera unit 926 images a subject to generate image data, and outputs the generated image data to the image processing unit 927.
  • the image processing unit 927 encodes the image data input from the camera unit 926 and stores the encoded stream in the storage medium of the storage / playback unit 929.
  • the demultiplexing unit 928 multiplexes the video stream encoded by the image processing unit 927 and the audio stream input from the audio codec 923, and the multiplexed stream is the communication unit 922. Output to.
  • the communication unit 922 encodes and modulates the stream and generates a transmission signal. Then, the communication unit 922 transmits the generated transmission signal to a base station (not shown) via the antenna 921.
  • the communication unit 922 amplifies a radio signal received via the antenna 921 and performs frequency conversion to acquire a received signal.
  • These transmission signal and reception signal may include an encoded bit stream.
  • the communication unit 922 demodulates and decodes the received signal to restore the stream, and outputs the restored stream to the demultiplexing unit 928.
  • the demultiplexing unit 928 separates the video stream and the audio stream from the input stream, and outputs the video stream to the image processing unit 927 and the audio stream to the audio codec 923.
  • the image processing unit 927 decodes the video stream and generates video data.
  • the video data is supplied to the display unit 930, and a series of images is displayed on the display unit 930.
  • the audio codec 923 decompresses the audio stream and performs D / A conversion to generate an analog audio signal. Then, the audio codec 923 supplies the generated audio signal to the speaker 924 to output audio.
  • the image processing unit 927 includes an image encoding device (for example, an encoding device including the encoder 1 and the file generation unit 2 in FIG. 1) and an image decoding device according to the above-described embodiment. (For example, a decoding device including the file reading unit 51 and the decoder 52 in FIG. 8). Accordingly, when encoding and decoding an image with the mobile phone 920, it is possible to reduce a processing load when decoding a stream used for transmission or a stream used for storing in a file.
  • FIG. 44 shows an example of a schematic configuration of a recording / reproducing apparatus to which the above-described embodiment is applied.
  • the recording / reproducing device 940 encodes audio data and video data of a received broadcast program and records the encoded data on a recording medium.
  • the recording / reproducing device 940 may encode audio data and video data acquired from another device and record them on a recording medium, for example.
  • the recording / reproducing device 940 reproduces data recorded on the recording medium on a monitor and a speaker, for example, in accordance with a user instruction. At this time, the recording / reproducing device 940 decodes the audio data and the video data.
  • the recording / reproducing apparatus 940 includes a tuner 941, an external interface 942, an encoder 943, an HDD (Hard Disk Drive) 944, a disk drive 945, a selector 946, a decoder 947, an OSD (On-Screen Display) 948, a control unit 949, and a user interface. 950.
  • Tuner 941 extracts a signal of a desired channel from a broadcast signal received via an antenna (not shown), and demodulates the extracted signal. Then, the tuner 941 outputs the encoded bit stream obtained by the demodulation to the selector 946. That is, the tuner 941 has a role as a transmission unit in the recording / reproducing apparatus 940.
  • the external interface 942 is an interface for connecting the recording / reproducing apparatus 940 to an external device or a network.
  • the external interface 942 may be, for example, an IEEE1394 interface, a network interface, a USB interface, or a flash memory interface.
  • video data and audio data received via the external interface 942 are input to the encoder 943. That is, the external interface 942 serves as a transmission unit in the recording / reproducing device 940.
  • the encoder 943 encodes video data and audio data when the video data and audio data input from the external interface 942 are not encoded. Then, the encoder 943 outputs the encoded bit stream to the selector 946.
  • the HDD 944 records an encoded bit stream in which content data such as video and audio is compressed, various programs, and other data on an internal hard disk. Further, the HDD 944 reads out these data from the hard disk when reproducing video and audio.
  • the disk drive 945 performs recording and reading of data to and from the mounted recording medium.
  • the recording medium mounted on the disk drive 945 is, for example, a DVD disk (DVD-Video, DVD-RAM, DVD-R, DVD-RW, DVD + R, DVD + RW, etc.) or a Blu-ray (registered trademark) disk. It may be.
  • the selector 946 selects an encoded bit stream input from the tuner 941 or the encoder 943 when recording video and audio, and outputs the selected encoded bit stream to the HDD 944 or the disk drive 945. In addition, the selector 946 outputs the encoded bit stream input from the HDD 944 or the disk drive 945 to the decoder 947 during video and audio reproduction.
  • the decoder 947 decodes the encoded bit stream and generates video data and audio data. Then, the decoder 947 outputs the generated video data to the OSD 948. The decoder 904 outputs the generated audio data to an external speaker.
  • OSD 948 reproduces the video data input from the decoder 947 and displays the video. Further, the OSD 948 may superimpose a GUI image such as a menu, a button, or a cursor on the video to be displayed.
  • the control unit 949 includes a processor such as a CPU and memories such as a RAM and a ROM.
  • the memory stores a program executed by the CPU, program data, and the like.
  • the program stored in the memory is read and executed by the CPU when the recording / reproducing apparatus 940 is activated, for example.
  • the CPU controls the operation of the recording / reproducing apparatus 940 in accordance with an operation signal input from the user interface 950, for example, by executing the program.
  • the user interface 950 is connected to the control unit 949.
  • the user interface 950 includes, for example, buttons and switches for the user to operate the recording / reproducing device 940, a remote control signal receiving unit, and the like.
  • the user interface 950 detects an operation by the user via these components, generates an operation signal, and outputs the generated operation signal to the control unit 949.
  • the encoder 943 has the function of the image encoding apparatus according to the above-described embodiment (for example, the encoding apparatus including the encoder 1 and the file generation unit 2 in FIG. 1).
  • the decoder 947 has a function of the image decoding apparatus according to the above-described embodiment (for example, a decoding apparatus including the file reading unit 51 and the decoder 52 in FIG. 8).
  • FIG. 45 illustrates an example of a schematic configuration of an imaging apparatus to which the above-described embodiment is applied.
  • the imaging device 960 images a subject to generate an image, encodes the image data, and records it on a recording medium.
  • the imaging device 960 includes an optical block 961, an imaging unit 962, a signal processing unit 963, an image processing unit 964, a display unit 965, an external interface 966, a memory 967, a media drive 968, an OSD 969, a control unit 970, a user interface 971, and a bus. 972.
  • the optical block 961 is connected to the imaging unit 962.
  • the imaging unit 962 is connected to the signal processing unit 963.
  • the display unit 965 is connected to the image processing unit 964.
  • the user interface 971 is connected to the control unit 970.
  • the bus 972 connects the image processing unit 964, the external interface 966, the memory 967, the media drive 968, the OSD 969, and the control unit 970 to each other.
  • the optical block 961 includes a focus lens and a diaphragm mechanism.
  • the optical block 961 forms an optical image of the subject on the imaging surface of the imaging unit 962.
  • the imaging unit 962 includes an image sensor such as a CCD (Charge-Coupled Device) or a CMOS (Complementary Metal-Oxide Semiconductor), and converts an optical image formed on the imaging surface into an image signal as an electrical signal by photoelectric conversion. Then, the imaging unit 962 outputs the image signal to the signal processing unit 963.
  • CCD Charge-Coupled Device
  • CMOS Complementary Metal-Oxide Semiconductor
  • the signal processing unit 963 performs various camera signal processing such as knee correction, gamma correction, and color correction on the image signal input from the imaging unit 962.
  • the signal processing unit 963 outputs the image data after the camera signal processing to the image processing unit 964.
  • the image processing unit 964 encodes the image data input from the signal processing unit 963 and generates encoded data. Then, the image processing unit 964 outputs the generated encoded data to the external interface 966 or the media drive 968. The image processing unit 964 also decodes encoded data input from the external interface 966 or the media drive 968 to generate image data. Then, the image processing unit 964 outputs the generated image data to the display unit 965. In addition, the image processing unit 964 may display the image by outputting the image data input from the signal processing unit 963 to the display unit 965. Further, the image processing unit 964 may superimpose display data acquired from the OSD 969 on an image output to the display unit 965.
  • the OSD 969 generates a GUI image such as a menu, a button, or a cursor, and outputs the generated image to the image processing unit 964.
  • the external interface 966 is configured as a USB input / output terminal, for example.
  • the external interface 966 connects the imaging device 960 and a printer, for example, when printing an image.
  • a drive is connected to the external interface 966 as necessary.
  • a removable medium such as a magnetic disk or an optical disk is attached to the drive, and a program read from the removable medium can be installed in the imaging device 960.
  • the external interface 966 may be configured as a network interface connected to a network such as a LAN or the Internet. That is, the external interface 966 has a role as a transmission unit in the imaging device 960.
  • the recording medium mounted on the media drive 968 may be any readable / writable removable medium such as a magnetic disk, a magneto-optical disk, an optical disk, or a semiconductor memory.
  • a recording medium may be fixedly mounted on the media drive 968, and a non-portable storage unit such as an internal hard disk drive or an SSD (Solid State Drive) may be configured.
  • the control unit 970 includes a processor such as a CPU and memories such as a RAM and a ROM.
  • the memory stores a program executed by the CPU, program data, and the like.
  • the program stored in the memory is read and executed by the CPU when the imaging device 960 is activated, for example.
  • the CPU controls the operation of the imaging device 960 according to an operation signal input from the user interface 971 by executing the program.
  • the user interface 971 is connected to the control unit 970.
  • the user interface 971 includes, for example, buttons and switches for the user to operate the imaging device 960.
  • the user interface 971 detects an operation by the user via these components, generates an operation signal, and outputs the generated operation signal to the control unit 970.
  • the image processing unit 964 includes an image encoding device (for example, an encoding device including the encoder 1 and the file generation unit 2 in FIG. 1) and an image decoding device according to the above-described embodiment. (For example, a decoding device including the file reading unit 51 and the decoder 52 in FIG. 8). Accordingly, when encoding and decoding an image in the imaging device 960, it is possible to reduce a processing load when decoding a stream used for transmission or a stream used for storing in a file.
  • FIG. 46 illustrates an example of a schematic configuration of a video set to which the present technology is applied.
  • the video set 1300 shown in FIG. 46 has such a multi-functional configuration, and a device having a function relating to image encoding and decoding (either or both of them) can be used for the function. It is a combination of devices having other related functions.
  • the video set 1300 includes a module group such as a video module 1311, an external memory 1312, a power management module 1313, and a front-end module 1314, and an associated module 1321, a camera 1322, a sensor 1323, and the like. And a device having a function.
  • a cocoon module is a component that has several functions that are related to each other and that have a coherent function.
  • the specific physical configuration is arbitrary. For example, a plurality of processors each having a function, electronic circuit elements such as resistors and capacitors, and other devices arranged on a wiring board or the like can be considered. . It is also possible to combine the module with another module, a processor, or the like to form a new module.
  • the video module 1311 is a combination of configurations having functions related to image processing, and includes an application processor, a video processor, a broadband modem 1333, and an RF module 1334.
  • the processor is a configuration in which a configuration having a predetermined function is integrated on a semiconductor chip by an SoC (System On Chip), and for example, there is also a system LSI (Large Scale Integration) or the like.
  • the configuration having the predetermined function may be a logic circuit (hardware configuration), a CPU, a ROM, a RAM, and the like, and a program (software configuration) executed using them. , Or a combination of both.
  • a processor has a logic circuit and a CPU, ROM, RAM, etc., a part of the function is realized by a logic circuit (hardware configuration), and other functions are executed by the CPU (software configuration) It may be realized by.
  • the application processor 1331 in FIG. 46 is a processor that executes an application related to image processing.
  • the application executed in the application processor 1331 not only performs arithmetic processing to realize a predetermined function, but also can control the internal and external configurations of the video module 1311 such as the video processor 1332 as necessary. .
  • the video processor 1332 is a processor having a function related to image encoding / decoding (one or both of them).
  • the broadband modem 1333 is a processor (or module) that performs processing related to wired or wireless (or both) broadband communication performed via a broadband line such as the Internet or a public telephone line network.
  • the broadband modem 1333 digitally modulates data to be transmitted (digital signal) to convert it into an analog signal, or demodulates the received analog signal to convert it into data (digital signal).
  • the broadband modem 1333 can digitally modulate and demodulate arbitrary information such as image data processed by the video processor 1332, a stream obtained by encoding the image data, an application program, setting data, and the like.
  • the RF module 1334 is a module that performs frequency conversion, modulation / demodulation, amplification, filter processing, and the like on an RF (Radio RF Frequency) signal transmitted and received via an antenna. For example, the RF module 1334 generates an RF signal by performing frequency conversion or the like on the baseband signal generated by the broadband modem 1333. Further, for example, the RF module 1334 generates a baseband signal by performing frequency conversion or the like on the RF signal received via the front end module 1314.
  • RF Radio RF Frequency
  • the application processor 1331 and the video processor 1332 may be integrated into a single processor.
  • the external memory 1312 is a module having a storage device that is provided outside the video module 1311 and is used by the video module 1311.
  • the storage device of the external memory 1312 may be realized by any physical configuration, but is generally used for storing a large amount of data such as image data in units of frames. For example, it is desirable to realize it with a relatively inexpensive and large-capacity semiconductor memory such as DRAM (Dynamic Random Access Memory).
  • the power management module 1313 manages and controls power supply to the video module 1311 (each component in the video module 1311).
  • the front end module 1314 is a module that provides the RF module 1334 with a front end function (a circuit on a transmitting / receiving end on the antenna side). As illustrated in FIG. 46, the front end module 1314 includes, for example, an antenna unit 1351, a filter 1352, and an amplification unit 1353.
  • Antenna unit 1351 has an antenna for transmitting and receiving a radio signal and its peripheral configuration.
  • the antenna unit 1351 transmits the signal supplied from the amplification unit 1353 as a radio signal, and supplies the received radio signal to the filter 1352 as an electric signal (RF signal).
  • the filter 1352 performs a filtering process on the RF signal received via the antenna unit 1351 and supplies the processed RF signal to the RF module 1334.
  • the amplifying unit 1353 amplifies the RF signal supplied from the RF module 1334 and supplies the amplified RF signal to the antenna unit 1351.
  • Connectivity 1321 is a module having a function related to connection with the outside.
  • the physical configuration of the connectivity 1321 is arbitrary.
  • the connectivity 1321 has a configuration having a communication function other than the communication standard supported by the broadband modem 1333, an external input / output terminal, and the like.
  • the communication 1321 is compliant with wireless communication standards such as Bluetooth (registered trademark), IEEE 802.11 (for example, Wi-Fi (Wireless Fidelity, registered trademark)), NFC (Near Field Communication), IrDA (InfraRed Data Association), etc. You may make it have a module which has a function, an antenna etc. which transmit / receive the signal based on the standard.
  • the connectivity 1321 has a module having a communication function compliant with a wired communication standard such as USB (Universal Serial Bus), HDMI (registered trademark) (High-Definition Multimedia Interface), or a terminal compliant with the standard. You may do it.
  • the connectivity 1321 may have other data (signal) transmission functions such as analog input / output terminals.
  • the connectivity 1321 may include a data (signal) transmission destination device.
  • the drive 1321 reads and writes data to and from a recording medium such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory (not only a removable medium drive, but also a hard disk, SSD (Solid State Drive) NAS (including Network Attached Storage) and the like.
  • the connectivity 1321 may include an image or audio output device (a monitor, a speaker, or the like).
  • the eyelid camera 1322 is a module having a function of capturing an image of a subject and obtaining image data of the subject.
  • Image data obtained by imaging by the camera 1322 is supplied to, for example, a video processor 1332 and encoded.
  • the sensor 1323 includes, for example, a voice sensor, an ultrasonic sensor, an optical sensor, an illuminance sensor, an infrared sensor, an image sensor, a rotation sensor, an angle sensor, an angular velocity sensor, a velocity sensor, an acceleration sensor, an inclination sensor, a magnetic identification sensor, an impact sensor, It is a module having an arbitrary sensor function such as a temperature sensor.
  • the data detected by the sensor 1323 is supplied to the application processor 1331 and used by an application or the like.
  • the configuration described above as a module may be realized as a processor, or conversely, the configuration described as a processor may be realized as a module.
  • the present technology can be applied to the video processor 1332 as described later. Therefore, the video set 1300 can be implemented as a set to which the present technology is applied.
  • FIG. 47 shows an example of a schematic configuration of a video processor 1332 (FIG. 46) to which the present technology is applied.
  • the video processor 1332 receives the video signal and the audio signal, encodes them in a predetermined method, decodes the encoded video data and audio data, A function of reproducing and outputting an audio signal.
  • the video processor 1332 includes a video input processing unit 1401, a first image scaling unit 1402, a second image scaling unit 1403, a video output processing unit 1404, a frame memory 1405, and a memory control unit 1406.
  • the video processor 1332 includes an encoding / decoding engine 1407, video ES (ElementaryElementStream) buffers 1408A and 1408B, and audio ES buffers 1409A and 1409B.
  • the video processor 1332 includes an audio encoder 1410, an audio decoder 1411, a multiplexing unit (MUX (Multiplexer)) 1412, a demultiplexing unit (DMUX (Demultiplexer)) 1413, and a stream buffer 1414.
  • MUX Multiplexing unit
  • DMUX demultiplexing unit
  • the video input processing unit 1401 acquires a video signal input from, for example, the connectivity 1321 (FIG. 46) and converts it into digital image data.
  • the first image enlargement / reduction unit 1402 performs format conversion, image enlargement / reduction processing, and the like on the image data.
  • the second image enlargement / reduction unit 1403 performs image enlargement / reduction processing on the image data in accordance with the format of the output destination via the video output processing unit 1404, or is the same as the first image enlargement / reduction unit 1402. Format conversion and image enlargement / reduction processing.
  • the video output processing unit 1404 performs format conversion, conversion to an analog signal, and the like on the image data and outputs the reproduced video signal to, for example, the connectivity 1321 (FIG. 46).
  • the frame memory 1405 is a memory for image data shared by the video input processing unit 1401, the first image scaling unit 1402, the second image scaling unit 1403, the video output processing unit 1404, and the encoding / decoding engine 1407. .
  • the frame memory 1405 is realized as a semiconductor memory such as a DRAM, for example.
  • the memory control unit 1406 receives the synchronization signal from the encoding / decoding engine 1407, and controls the writing / reading access to the frame memory 1405 according to the access schedule to the frame memory 1405 written in the access management table 1406A.
  • the access management table 1406A is updated by the memory control unit 1406 in accordance with processing executed by the encoding / decoding engine 1407, the first image enlargement / reduction unit 1402, the second image enlargement / reduction unit 1403, and the like.
  • the encoding / decoding engine 1407 performs encoding processing of image data and decoding processing of a video stream that is data obtained by encoding the image data. For example, the encoding / decoding engine 1407 encodes the image data read from the frame memory 1405 and sequentially writes the data as a video stream in the video ES buffer 1408A. Further, for example, the video stream is sequentially read from the video ES buffer 1408B, decoded, and sequentially written in the frame memory 1405 as image data.
  • the encoding / decoding engine 1407 uses the frame memory 1405 as a work area in the encoding and decoding. Also, the encoding / decoding engine 1407 outputs a synchronization signal to the memory control unit 1406, for example, at a timing at which processing for each macroblock is started.
  • the video ES buffer 1408A buffers the video stream generated by the encoding / decoding engine 1407 and supplies the buffered video stream to the multiplexing unit (MUX) 1412.
  • the video ES buffer 1408B buffers the video stream supplied from the demultiplexer (DMUX) 1413 and supplies the buffered video stream to the encoding / decoding engine 1407.
  • the audio ES buffer 1409A buffers the audio stream generated by the audio encoder 1410 and supplies the buffered audio stream to the multiplexing unit (MUX) 1412.
  • the audio ES buffer 1409B buffers the audio stream supplied from the demultiplexer (DMUX) 1413 and supplies the buffered audio stream to the audio decoder 1411.
  • the audio encoder 1410 converts, for example, an audio signal input from the connectivity 1321 (FIG. 46), for example, into a digital format, and encodes the audio signal using a predetermined method such as an MPEG audio method or an AC3 (Audio Code number 3) method.
  • the audio encoder 1410 sequentially writes an audio stream, which is data obtained by encoding an audio signal, in the audio ES buffer 1409A.
  • the audio decoder 1411 decodes the audio stream supplied from the audio ES buffer 1409B, performs conversion to an analog signal, for example, and supplies the reproduced audio signal to, for example, the connectivity 1321 (FIG. 46).
  • Multiplexer (MUX) 1412 multiplexes the video stream and the audio stream.
  • the multiplexing method (that is, the format of the bit stream generated by multiplexing) is arbitrary.
  • the multiplexing unit (MUX) 1412 can also add predetermined header information or the like to the bit stream. That is, the multiplexing unit (MUX) 1412 can convert the stream format by multiplexing. For example, the multiplexing unit (MUX) 1412 multiplexes the video stream and the audio stream to convert it into a transport stream that is a bit stream in a transfer format. Further, for example, the multiplexing unit (MUX) 1412 multiplexes the video stream and the audio stream, thereby converting the data into file format data (file data) for recording.
  • the demultiplexing unit (DMUX) 1413 demultiplexes the bit stream in which the video stream and the audio stream are multiplexed by a method corresponding to the multiplexing by the multiplexing unit (MUX) 1412. That is, the demultiplexer (DMUX) 1413 extracts the video stream and the audio stream from the bit stream read from the stream buffer 1414 (separates the video stream and the audio stream). That is, the demultiplexer (DMUX) 1413 can convert the stream format by demultiplexing (inverse conversion of the conversion by the multiplexer (MUX) 1412).
  • the demultiplexing unit (DMUX) 1413 obtains a transport stream supplied from, for example, the connectivity 1321 and the broadband modem 1333 (both in FIG. 46) via the stream buffer 1414 and demultiplexes the transport stream. Can be converted into a video stream and an audio stream. Further, for example, the demultiplexer (DMUX) 1413 obtains the file data read from various recording media by the connectivity 1321 (FIG. 46) via the stream buffer 1414 and demultiplexes it, for example. It can be converted into a video stream and an audio stream.
  • the stream buffer 1414 buffers the bit stream.
  • the stream buffer 1414 buffers the transport stream supplied from the multiplexing unit (MUX) 1412 and, for example, at the predetermined timing or based on a request from the outside, for example, the connectivity 1321 or the broadband modem 1333 (whichever Are also supplied to FIG.
  • MUX multiplexing unit
  • the stream buffer 1414 buffers the file data supplied from the multiplexing unit (MUX) 1412 and, for example, the connectivity 1321 (FIG. 46) or the like at a predetermined timing or based on an external request or the like. To be recorded on various recording media.
  • MUX multiplexing unit
  • the connectivity 1321 FIG. 46
  • the stream buffer 1414 buffers the transport stream acquired through, for example, the connectivity 1321 and the broadband modem 1333 (both in FIG. 46), and reverses the stream at a predetermined timing or based on a request from the outside.
  • the data is supplied to a multiplexing unit (DMUX) 1413.
  • DMUX multiplexing unit
  • the stream buffer 1414 buffers file data read from various recording media in the connectivity 1321 (FIG. 46), for example, and at a predetermined timing or based on an external request or the like, a demultiplexing unit (DMUX) 1413.
  • DMUX demultiplexing unit
  • a video signal input from the connectivity 1321 (FIG. 46) or the like to the video processor 1332 is converted into digital image data of a predetermined format such as 4: 2: 2Y / Cb / Cr format by the video input processing unit 1401.
  • the data is sequentially written in the frame memory 1405.
  • This digital image data is read by the first image enlargement / reduction unit 1402 or the second image enlargement / reduction unit 1403, and format conversion to a predetermined method such as 4: 2: 0Y / Cb / Cr method and enlargement / reduction processing are performed. Is written again in the frame memory 1405.
  • This image data is encoded by the encoding / decoding engine 1407 and written as a video stream in the video ES buffer 1408A.
  • an audio signal input to the video processor 1332 from the connectivity 1321 (FIG. 46) or the like is encoded by the audio encoder 1410 and written as an audio stream in the audio ES buffer 1409A.
  • the video stream of the video ES buffer 1408A and the audio stream of the audio ES buffer 1409A are read and multiplexed by the multiplexing unit (MUX) 1412 and converted into a transport stream or file data.
  • the transport stream generated by the multiplexing unit (MUX) 1412 is buffered in the stream buffer 1414 and then output to the external network via, for example, the connectivity 1321 and the broadband modem 1333 (both of which are shown in FIG. 46).
  • the file data generated by the multiplexing unit (MUX) 1412 is buffered in the stream buffer 1414, and then output to, for example, the connectivity 1321 (FIG. 46) and recorded on various recording media.
  • the transport stream input from the external network to the video processor 1332 via the connectivity 1321 or the broadband modem 1333 (both in FIG. 46) is buffered in the stream buffer 1414, and then demultiplexed (DMUX) 1413 is demultiplexed.
  • DMUX demultiplexed
  • file data read from various recording media in the connectivity 1321 (FIG. 46) and input to the video processor 1332 is buffered in the stream buffer 1414 and then demultiplexed by the demultiplexer (DMUX) 1413. It becomes. That is, the transport stream or file data input to the video processor 1332 is separated into a video stream and an audio stream by the demultiplexer (DMUX) 1413.
  • the audio stream is supplied to the audio decoder 1411 via the audio ES buffer 1409B and decoded to reproduce the audio signal.
  • the video stream is written to the video ES buffer 1408B, and then sequentially read and decoded by the encoding / decoding engine 1407, and written to the frame memory 1405.
  • the decoded image data is enlarged / reduced by the second image enlargement / reduction unit 1403 and written to the frame memory 1405.
  • the decoded image data is read out to the video output processing unit 1404, format-converted to a predetermined system such as 4: 2: 2Y / Cb / Cr system, and further converted into an analog signal to be converted into a video signal. Is played out.
  • the present technology when the present technology is applied to the video processor 1332 configured as described above, the present technology according to each embodiment described above may be applied to the encoding / decoding engine 1407. That is, for example, the encoding / decoding engine 1407 includes an encoding device (FIG. 1) including the encoder 1 and the file generation unit 2 according to the first embodiment, and a decoding device including the file reading unit 51 and the decoder 52 (FIG. 8). ) Function. In this way, the video processor 1332 can obtain the same effects as those described above with reference to FIGS.
  • the present technology (that is, the functions of the image encoding device and the image decoding device according to each embodiment described above) may be realized by hardware such as a logic circuit. It may be realized by software such as an embedded program, or may be realized by both of them.
  • FIG. 48 illustrates another example of a schematic configuration of the video processor 1332 (FIG. 46) to which the present technology is applied.
  • the video processor 1332 has a function of encoding / decoding video data by a predetermined method.
  • the video processor 1332 includes a control unit 1511, a display interface 1512, a display engine 1513, an image processing engine 1514, and an internal memory 1515.
  • the video processor 1332 includes a codec engine 1516, a memory interface 1517, a multiplexing / demultiplexing unit (MUX DMUX) 1518, a network interface 1519, and a video interface 1520.
  • MUX DMUX multiplexing / demultiplexing unit
  • the eyelid control unit 1511 controls the operation of each processing unit in the video processor 1332 such as the display interface 1512, the display engine 1513, the image processing engine 1514, and the codec engine 1516.
  • the control unit 1511 includes, for example, a main CPU 1531, a sub CPU 1532, and a system controller 1533.
  • the main CPU 1531 executes a program and the like for controlling the operation of each processing unit in the video processor 1332.
  • the main CPU 1531 generates a control signal according to the program and supplies it to each processing unit (that is, controls the operation of each processing unit).
  • the sub CPU 1532 plays an auxiliary role of the main CPU 1531.
  • the sub CPU 1532 executes a child process such as a program executed by the main CPU 1531, a subroutine, or the like.
  • the system controller 1533 controls operations of the main CPU 1531 and the sub CPU 1532 such as designating a program to be executed by the main CPU 1531 and the sub CPU 1532.
  • the display interface 1512 outputs image data to, for example, the connectivity 1321 (FIG. 46) or the like under the control of the control unit 1511.
  • the display interface 1512 converts the digital data image data into an analog signal, and outputs it to the monitor device of the connectivity 1321 (FIG. 46) or the like as a reproduced video signal or as the digital data image data.
  • the display engine 1513 Under the control of the control unit 1511, the display engine 1513 performs various conversion processes such as format conversion, size conversion, color gamut conversion, and the like so as to match the image data with hardware specifications such as a monitor device that displays the image. I do.
  • the eyelid image processing engine 1514 performs predetermined image processing such as filter processing for improving image quality on the image data under the control of the control unit 1511.
  • the internal memory 1515 is a memory provided inside the video processor 1332 that is shared by the display engine 1513, the image processing engine 1514, and the codec engine 1516.
  • the internal memory 1515 is used, for example, for data exchange performed between the display engine 1513, the image processing engine 1514, and the codec engine 1516.
  • the internal memory 1515 stores data supplied from the display engine 1513, the image processing engine 1514, or the codec engine 1516, and stores the data as needed (eg, upon request). This is supplied to the image processing engine 1514 or the codec engine 1516.
  • the internal memory 1515 may be realized by any storage device, but is generally used for storing a small amount of data such as image data or parameters in units of blocks. It is desirable to realize a semiconductor memory having a relatively small capacity but a high response speed (for example, as compared with the external memory 1312) such as “Static Random Access Memory”.
  • the codec engine 1516 performs processing related to encoding and decoding of image data.
  • the encoding / decoding scheme supported by the codec engine 1516 is arbitrary, and the number thereof may be one or plural.
  • the codec engine 1516 may be provided with codec functions of a plurality of encoding / decoding schemes, and may be configured to perform encoding of image data or decoding of encoded data using one selected from them.
  • the codec engine 1516 includes, for example, MPEG-2 video 1541, AVC / H.2641542, HEVC / H.2651543, HEVC / H.265 (Scalable) 1544, as function blocks for processing related to the codec.
  • HEVC / H.265 (Multi-view) 1545 and MPEG-DASH 1551 are included.
  • “MPEG-2” Video 1541 is a functional block that encodes and decodes image data in the MPEG-2 format.
  • AVC / H.2641542 is a functional block that encodes and decodes image data using the AVC method.
  • HEVC / H.2651543 is a functional block that encodes and decodes image data using the HEVC method.
  • HEVC / H.265 (Scalable) 1544 is a functional block that performs scalable encoding and scalable decoding of image data using the HEVC method.
  • HEVC / H.265 (Multi-view) 1545 is a functional block that multi-view encodes or multi-view decodes image data using the HEVC method.
  • MPEG-DASH 1551 is a functional block that transmits and receives image data in the MPEG-DASH (MPEG-Dynamic Adaptive Streaming over HTTP) method.
  • MPEG-DASH is a technology for streaming video using HTTP (HyperText Transfer Protocol), and selects and transmits appropriate data from multiple encoded data with different resolutions prepared in advance in segments. This is one of the features.
  • MPEG-DASH 1551 generates a stream compliant with the standard, controls transmission of the stream, and the like.
  • MPEG-2 Video 1541 to HEVC / H.265 (Multi-view) 1545 described above are used. Is used.
  • the memory interface 1517 is an interface for the external memory 1312. Data supplied from the image processing engine 1514 or the codec engine 1516 is supplied to the external memory 1312 via the memory interface 1517. The data read from the external memory 1312 is supplied to the video processor 1332 (the image processing engine 1514 or the codec engine 1516) via the memory interface 1517.
  • a multiplexing / demultiplexing unit (MUX DMUX) 1518 multiplexes and demultiplexes various data related to images such as a bit stream of encoded data, image data, and a video signal.
  • This multiplexing / demultiplexing method is arbitrary.
  • the multiplexing / demultiplexing unit (MUX DMUX) 1518 can not only combine a plurality of data into one but also add predetermined header information or the like to the data.
  • the multiplexing / demultiplexing unit (MUX DMUX) 1518 not only divides one data into a plurality of data but also adds predetermined header information or the like to each divided data. it can.
  • the multiplexing / demultiplexing unit (MUX DMUX) 1518 can convert the data format by multiplexing / demultiplexing.
  • the multiplexing / demultiplexing unit (MUX DMUX) 1518 multiplexes the bitstream, thereby transporting the transport stream, which is a bit stream in a transfer format, or data in a file format for recording (file data).
  • the transport stream which is a bit stream in a transfer format, or data in a file format for recording (file data).
  • file data file format for recording
  • the network interface 1519 is an interface for the broadband modem 1333, the connectivity 1321 (both are FIG. 46), etc., for example.
  • the video interface 1520 is an interface for, for example, the connectivity 1321 and the camera 1322 (both are FIG. 46).
  • the transport stream is transmitted to the multiplexing / demultiplexing unit (MUX) via the network interface 1519.
  • MUX multiplexing / demultiplexing unit
  • DMUX 1518 is demultiplexed and decoded by the codec engine 1516.
  • the image data obtained by decoding by the codec engine 1516 is subjected to predetermined image processing by the image processing engine 1514, subjected to predetermined conversion by the display engine 1513, and connected to, for example, the connectivity 1321 (see FIG. 46) etc., and the image is displayed on the monitor.
  • image data obtained by decoding by the codec engine 1516 is re-encoded by the codec engine 1516, multiplexed by a multiplexing / demultiplexing unit (MUX DMUX) 1518, converted into file data, and video
  • MUX DMUX multiplexing / demultiplexing unit
  • the data is output to, for example, the connectivity 1321 (FIG. 46) via the interface 1520 and recorded on various recording media.
  • encoded data file data obtained by encoding image data read from a recording medium (not shown) by the connectivity 1321 (FIG. 46) is multiplexed / demultiplexed via the video interface 1520. Is supplied to a unit (MUX DMUX) 1518, demultiplexed, and decoded by the codec engine 1516. Image data obtained by decoding by the codec engine 1516 is subjected to predetermined image processing by the image processing engine 1514, subjected to predetermined conversion by the display engine 1513, and, for example, connectivity 1321 (FIG. 46) via the display interface 1512. And the image is displayed on the monitor.
  • MUX DMUX unit
  • image data obtained by decoding by the codec engine 1516 is re-encoded by the codec engine 1516, multiplexed by the multiplexing / demultiplexing unit (MUX DMUX) 1518, and converted into a transport stream,
  • MUX DMUX multiplexing / demultiplexing unit
  • the connectivity 1321 and the broadband modem 1333 are supplied via the network interface 1519 and transmitted to another device (not shown).
  • image data and other data are exchanged between the processing units in the video processor 1332 using, for example, the internal memory 1515 and the external memory 1312.
  • the power management module 1313 controls power supply to the control unit 1511, for example.
  • the present technology when the present technology is applied to the video processor 1332 configured as described above, the present technology according to each of the above-described embodiments may be applied to the codec engine 1516. That is, for example, the codec engine 1516 uses the encoding device (FIG. 1) including the encoder 1 and the file generation unit 2 according to the first embodiment, and the decoding device (FIG. 8) including the file reading unit 51 and the decoder 52. What is necessary is just to have a functional block to implement
  • the present technology (that is, the functions of the image encoding device and the image decoding device according to each of the above-described embodiments) may be realized by hardware such as a logic circuit or an embedded program. It may be realized by software such as the above, or may be realized by both of them.
  • the configuration of the video processor 1332 is arbitrary and may be other than the two examples described above.
  • the video processor 1332 may be configured as one semiconductor chip, but may be configured as a plurality of semiconductor chips. For example, a three-dimensional stacked LSI in which a plurality of semiconductors are stacked may be used. Further, it may be realized by a plurality of LSIs.
  • Video set 1300 can be incorporated into various devices that process image data.
  • the video set 1300 can be incorporated into the television device 900 (FIG. 42), the mobile phone 920 (FIG. 43), the recording / reproducing device 940 (FIG. 44), the imaging device 960 (FIG. 45), or the like.
  • the apparatus can obtain the same effects as those described above with reference to FIGS.
  • each configuration of the video set 1300 described above can be implemented as a configuration to which the present technology is applied as long as it includes the video processor 1332.
  • the video processor 1332 can be implemented as a video processor to which the present technology is applied.
  • the processor or the video module 1311 indicated by the dotted line 1341 can be implemented as a processor or a module to which the present technology is applied.
  • the video module 1311, the external memory 1312, the power management module 1313, and the front end module 1314 can be combined and implemented as a video unit 1361 to which the present technology is applied. In any case, the same effects as those described above with reference to FIGS. 1 to 36 can be obtained.
  • any configuration including the video processor 1332 can be incorporated into various devices that process image data, as in the case of the video set 1300.
  • a video processor 1332 a processor indicated by a dotted line 1341, a video module 1311, or a video unit 1361, a television device 900 (FIG. 42), a mobile phone 920 (FIG. 43), a recording / playback device 940 (FIG. 44), The imaging device 960 (FIG. 45) can be incorporated.
  • the apparatus can obtain the same effects as those described above with reference to FIGS. 1 to 36, as in the case of the video set 1300. .
  • various information such as startcode and filler ⁇ data, parameters for managing decoder buffers, identification parameters, FixedStartCodeSizeFlag, etc. are multiplexed in the encoded stream and transmitted from the encoding side to the decoding side.
  • the method for transmitting such information is not limited to such an example.
  • these pieces of information may be transmitted or recorded as separate data associated with the encoded bitstream without being multiplexed into the encoded bitstream.
  • the term “associate” means that an image (which may be a part of an image such as a slice or a block) included in the bitstream and information corresponding to the image can be linked at the time of decoding. Means.
  • information may be transmitted on a transmission path different from that of the image (or bit stream).
  • Information may be recorded on a recording medium (or another recording area of the same recording medium) different from the image (or bit stream).
  • the information and the image (or bit stream) may be associated with each other in an arbitrary unit such as a plurality of frames, one frame, or a part of the frame.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Television Signal Processing For Recording (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

　本開示は、ストリームを生成する際の処理の負担を軽減することができるようにする画像処理装置および方法に関する。 ファイル生成部は、画像を符号化したビットストリームを含むファイルを対象として、startcodeとfiller dataとを設定し、設定されたstartcodeとfiller dataとを、ファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、startcodeとfiller dataとの設定を制御する。本開示は、例えば、画像処理装置に適用することができる。

Description

画像処理装置および方法
　本開示は、画像処理装置および方法に関し、特に、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを生成する際の処理の負担を軽減することができるようにした画像処理装置および方法に関する。
　画像符号化方式の標準仕様の１つであるＨ．２６４／ＡＶＣでは、画像の符号化及び復号のために用いられるパラメータを格納するためのシーケンスパラメータセット（ＳＰＳ）及びピクチャパラメータセット（ＰＰＳ）という２種類のパラメータセットが定義されている。各スライスの画像データがＶＣＬ（Video　Coding　Layer）　ＮＡＬ（Network　Abstraction　Layer）ユニットに分類される一方で、これらパラメータセットは非ＶＣＬ　ＮＡＬユニットに分類される。通常、Ｈ．２６４／ＡＶＣ方式で符号化された符号化ストリームがヘッダ領域及びデータ領域を含むファイルに格納される場合、ＳＰＳ及びＰＰＳはヘッダ領域に、画像データはデータ領域に挿入される。
　Ｈ．２６４／ＡＶＣに続く次世代の画像符号化方式であるＨＥＶＣ（High　Efficiency　Video　Coding）の標準化作業では、ＳＰＳ及びＰＰＳとは異なる新たなパラメータセットである適応パラメータセット（ＡＰＳ：Adaptation　Parameter　Set）を導入することが提案されている（下記非特許文献１、２参照）。
　ＡＰＳもまたパラメータセットの一種である。従って、既存の手法によれば、ＳＰＳ及びＰＰＳと同様、ＡＰＳもファイルのヘッダ領域に挿入されることになる。ヘッダ領域及びデータ領域を含むファイルフォーマットの一例として、ＭＰＥＧ－４　Ｐａｒｔ１４（ＩＳＯ／ＩＥＣ１４４９６－１４：２００３、以下、ＭＰ４という）フォーマット、ＭＰＥＧ－４　Ｐａｒｔ１５（ＩＳＯ／ＩＥＣ１４４９６－１５：２００４、ＡＶＣファイル）フォーマットが挙げられる。
Stephan　Wenger，　Jill　Boyce，　Yu-Wen　Huang，　Chia-Yang　Tsai，　Ping　Wu，　Ming　Li，　"Adaptation　Parameter　Set　(APS)"，　JCTVC-F747r3,　July　2011 Benjamin　Bross,　Woo-Jin　Han,　Jens-Rainer　Ohm,　Gary　J.　Sullivan,　Thomas　Wiegand,　"High　efficiency　video　coding　(HEVC)　text　specification　draft　6"，　JCTVC-H1003　ver20,　February　2012
　しかしながら、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを生成する場合に、startcodeとfiller dataなどのデータをストリームとして含むことが許容されないフォーマットがある。したがって、ストリームのデータを読み込む際に、処理負荷の要因になっている。
　本開示は、このような状況に鑑みてなされたものであり、伝送する際のストリーム又はファイルに格納する際のストリームを生成する際の処理の負担を軽減するものである。
　本開示の第１の側面の画像処理装置は、画像を符号化したビットストリームを含むファイルを対象として、startcodeとfiller dataとを設定する設定部と、前記設定部において設定されたstartcodeとfiller dataとを、ファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、前記設定部を制御する制御部とを備える。
　前記デコーダバッファを管理するパラメータは、VUI(Video Usability Information)に含まれるパラメータ、またはbuffering period SEI（Supplemental Enhancement Information）に含まれるパラメータ、または、picture timing SEIに含まれるパラメータである。
　前記設定部は、filler dataを、VCLデータとして設定することができる。
　本開示の第１の側面の画像処理方法は、画像処理装置が、画像を符号化したビットストリームを含むファイルを対象として、startcodeとfiller dataとを設定し、設定されたstartcodeとfiller dataとを、ファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、startcodeとfiller dataとの設定を制御する。
　本開示の第２の側面の画像処理装置は、画像を符号化したビットストリームを含み、startcodeとfiller dataとがファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように制御されて設定されているファイルを受け取る受け取り部と、前記受け取り部により受け取られたファイルから、前記startcodeとfiller datとを読み取り、前記デコーダバッファを管理するパラメータを用いて、前記ビットストリームを復号する復号部とを備える。
　前記デコーダバッファを管理するパラメータは、VUI(Video Usability Information)に含まれるパラメータ、または、buffering period SEI（Supplemental Enhancement Information）、に含まれるパラメータ、または、picture timing SEIに含まれるパラメータである。
　前記filler dataは、VCLデータとして設定されている。
　本開示の第２の側面の画像処理方法は、画像処理装置が、画像を符号化したビットストリームを含み、startcodeとfiller dataとがファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように制御されて設定されているファイルを受け取り、受け取られたファイルから、前記startcodeとfiller dataとを読み取り、前記デコーダバッファを管理するパラメータを用いて、前記ビットストリームを復号する。
　本開示の第３の側面の画像処理装置は、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性を設定する設定部と、前記設定部により設定された特性を用いて、前記ファイルを生成する生成部とを備える。
　前記設定部は、デコーダバッファを管理するパラメータの特性が変更されたことを識別する識別パラメータを設定することができる。
　前記設定部は、前記識別パラメータを、前記ファイルのサンプルエントリにおけるオプショナルボックスとして設定することができる。
　本開示の第３の側面の画像処理方法は、画像処理装置が、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性を設定し、設定された特性を用いて、前記ファイルを生成する。
　本開示の第４の側面の画像処理装置は、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性が設定され、設定された特性を用いて生成されているファイルを受け取る受け取り部と、前記受け取り部により受け取られたファイルから、前記デコーダバッファを管理するパラメータを読み取り、読み取ったパラメータを用いて前記ビットストリームを復号する復号部とを備える。
　前記ファイルには、デコーダバッファを管理するパラメータの特性が変更されたことを識別する識別パラメータが設定されている。
　本開示の第４の側面の画像処理方法は、画像処理装置が、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性が設定され、設定された特性を用いて生成されているファイルを受け取り、受け取られたファイルから、前記デコーダバッファを管理するパラメータを読み取り、読み取ったパラメータを用いて前記ビットストリームを復号する。
　本開示の第１の側面においては、画像を符号化したビットストリームを含むファイルを対象として、startcodeとfiller dataとが設定される。そして、設定されたstartcodeとfiller dataとが、ファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、startcodeとfiller dataとの設定が制御される。
　本開示の第２の側面においては、画像を符号化したビットストリームを含み、startcodeとfiller dataとがファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように制御されて設定されているファイルが受け取られる。そして、受け取られたファイルから、前記startcodeとfiller datとが読み取られ、前記デコーダバッファを管理するパラメータを用いて、前記ビットストリームが復号される。
　本開示の第３の側面においては、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性が設定される。そして、設定された特性を用いて、前記ファイルが生成される。
　本開示の第４の側面においては、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性が設定され、設定された特性を用いて生成されているファイルが受け取られる。そして、受け取られたファイルから、前記デコーダバッファを管理するパラメータが読み取られ、読み取ったパラメータを用いて前記ビットストリームが復号される。
　なお、上述の画像処理装置は、独立した装置であっても良いし、１つの画像符号化装置または画像復号装置を構成している内部ブロックであってもよい。
　本開示の第１および第３の側面によれば、画像を符号化することができる。特に、ビットストリームを伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを生成する際の処理の負担を軽減することができる。
　本開示の第２および第４の側面によれば、画像を復号することができる。特に、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを復号する際の処理の負担を軽減することができる。
本技術を適用した符号化装置の第１実施の形態の構成例を示すブロック図である。 エンコーダの構成例を示すブロック図である。 ファイル生成部の構成例を示すブロック図である。 ファイル生成処理を説明するフローチャートである。 ファイル生成処理の他の例を説明するフローチャートである。 従来のmdatデータの生成処理を説明するフローチャートである。 本技術のmdatデータの生成処理を説明するフローチャートである。 本技術を適用した復号装置の第１実施の形態の構成例を示すブロック図である。 ファイル読取部の構成例を示すブロック図である。 デコーダの構成例を示すブロック図である。 ファイル復号処理を説明するフローチャートである。 ファイル復号処理の他の例を説明するフローチャートである。 本技術を適用した符号化装置の第２実施の形態の構成例を示すブロック図である。 本技術を適用した復号装置の第２実施の形態の構成例を示すブロック図である。 従来のMP4ビデオサンプル構造の例を示す図である。 AVCストリームの１アクセスユニットの構成例を示す図である。 本技術のMP4ビデオサンプル構造の例を示す図である。 本技術のMP4ビデオサンプル構造の他の例を示す図である。 HRD Conformance Box拡張の例を示す図である。 本技術のMP4ビデオサンプル構造のさらに他の例を示す図である。 Sample tableに追加されるBOXの例を示す図である。 図２０のMP4ビデオサンプル構造の他の例を示す図である。 図２０のMP4ビデオサンプル構造のさらに他の例を示す図である。 サンプル補助情報機能のフォーマットの例を示す図である。 サンプル補助情報機能のフォーマットの他の例を示す図である。 本技術のMP4ビデオサンプル構造の例を比較する図である。 図２３のMP4ビデオサンプル構造の他の例を示す図である。 バイトストリームフォーマットインフォメーションボックスの例を示す図である。 バイトストリームフォーマットインフォメーションボックスの他の例を示す図である。 各サンプルエントリに格納されるバイトストリームフォーマットインフォメーションのデータ構造例を説明する図である。 パターン１の場合のMP4ビデオサンプル構造の例を示す図である。 パターン２の場合のMP4ビデオサンプル構造の例を示す図である。 パターン３の場合のMP4ビデオサンプル構造の例を示す図である。 各サンプルエントリに格納されるバイトストリームフォーマットインフォメーションのデータ構造の他の例を説明する図である。 本技術を適用したファイル変換装置の構成例を示す図である。 ファイル変換処理を説明するフローチャートである。 本技術を適用した符号化装置の第３実施の形態の構成例を示すブロック図である。 エンコーダの構成例を示すブロック図である。 本技術を適用した復号装置の第３実施の形態の構成例を示すブロック図である。 デコーダの構成例を示すブロック図である。 コンピュータの構成例を示すブロック図である。 テレビジョン装置の概略的な構成の一例を示すブロック図である。 携帯電話機の概略的な構成の一例を示すブロック図である。 記録再生装置の概略的な構成の一例を示すブロック図である。 撮像装置の概略的な構成の一例を示すブロック図である。 ビデオセットの概略的な構成の一例を示すブロック図である。 ビデオプロセッサの概略的な構成の一例を示すブロック図である。 ビデオプロセッサの概略的な構成の他の例を示すブロック図である。
　以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（HEVC方式の符号化装置、復号装置）
２．第２の実施の形態（画像符号化装置、画像復号装置）
３．第３の実施の形態（MP4ビデオサンプル構造）
４．第４の実施の形態（バイトストリームフォーマットインフォメーションボックス）
５．第５の実施の形態（ファイル変換装置）
６．第６の実施の形態（AVC方式の符号化装置、復号装置）
７．応用例
８．第７の実施の形態（セット・ユニット・モジュール・プロセッサ）
　＜１．第１の実施の形態＞
　［符号化装置の第１実施の形態の構成例］
　図１は、本技術を適用した画像処理装置としての、符号化装置の第１実施の形態の構成例を示すブロック図である。
　図１の符号化装置は、エンコーダ１およびファイル生成部２により構成され、撮影(Captured)画像等の画像をHEVC方式で符号化し、符号化されたストリームを格納するファイルを生成する。
　具体的には、符号化装置のエンコーダ１には、フレーム単位の撮影画像等の画像が入力信号として入力される。また、図示せぬエンコーダ１の前段で設定されたSPS（Sequence Parameter Set）、PPS（Picture Parameter Set）、符号化データに対応する画像の特性（ユーザビリティ）をシーケンスごとに示すVUI(Video Usability Information)、SEI（Supplemental Enhancement Information）なども入力される。
　エンコーダ１は、SPS、PPS、VUI、SEIに含まれるパラメータを用いて、入力信号をHEVC方式で符号化する。そして、エンコーダ１は、SPS、PPS、VUI、SEIと、その結果得られる符号化データとから、MPEG-2 TS(Transport Stream)などの符号化ストリームを生成し、生成した符号化ストリームを、ファイル生成部２に供給する。エンコーダ１の詳細は、図２を参照して後述される。
　ファイル生成部２は、エンコーダ１からの符号化ストリーム（符号化された一連の画像データ）を格納するファイル（例えば、ＭＰＥＧ－４　Ｐａｒｔ１４（ＩＳＯ／ＩＥＣ１４４９６－１４：２００３、以下、ＭＰ４という）のファイル）を生成する。ファイル生成部２の詳細は、図３を参照して後述される。
　［エンコーダの構成例］
　図２は、図１のエンコーダ１の構成例を示すブロック図である。エンコーダ１の各部は、図示せぬ前段からのSPS、PPS、VUI、SEIに含まれるパラメータを用いて、入力信号である画像を符号化し、符号化ストリームを生成する。
　図２のエンコーダ１は、A/D変換部１１、画面並べ替えバッファ１２、演算部１３、直交変換部１４、量子化部１５、可逆符号化部１６、蓄積バッファ１７、逆量子化部１８、逆直交変換部１９、加算部２０、デブロックフィルタ２１、フレームメモリ２２、スイッチ２３、イントラ予測部２４、動き予測・補償部２５、予測画像選択部２６、およびレート制御部２７を含むように構成される。
　さらに、デブロックフィルタ２１およびフレームメモリ２２の間には、適応オフセットフィルタ４１と適応ループフィルタ４２が備えられている。
　具体的には、エンコーダ１のA/D変換部１１は、入力信号として入力されたフレーム単位の画像をA/D変換し、画面並べ替えバッファ１２に出力して記憶させる。画面並べ替えバッファ１２は、記憶した表示の順番のフレーム単位の画像を、GOP（Group of Picture）構造に応じて、符号化のための順番に並べ替え、演算部１３、イントラ予測部２４、および動き予測・補償部２５に出力する。
　演算部１３は、予測画像選択部２６から供給される予測画像と、画面並べ替えバッファ１２から出力された符号化対象の画像の差分を演算することにより符号化を行う。具体的には、演算部１３は、画面並べ替えバッファ１２から出力された符号化対象の画像から、予測画像選択部２６から供給される予測画像を減算することにより符号化を行う。演算部１３は、その結果得られる画像を、残差情報として直交変換部１４に出力する。なお、予測画像選択部２６から予測画像が供給されない場合、演算部１３は、画面並べ替えバッファ１２から読み出された画像をそのまま残差情報として直交変換部１４に出力する。
　直交変換部１４は、演算部１３からの残差情報に対して直交変換を施し、直交変換の結果得られる係数を量子化部１５に供給する。
　量子化部１５は、直交変換部１４から供給される係数を量子化する。量子化された係数は、可逆符号化部１６に入力される。
　可逆符号化部１６は、最適イントラ予測モードを示す情報（以下、イントラ予測モード情報という）をイントラ予測部２４から取得する。また、最適インター予測モードを示す情報（以下、インター予測モード情報という）、動きベクトル、参照画像を特定するための情報などを動き予測・補償部２５から取得する。また、可逆符号化部１６は、適応オフセットフィルタ４１から格納フラグ、インデックスまたはオフセット、および種類情報をオフセットフィルタ情報として取得し、適応ループフィルタ４２からフィルタ係数を取得する。
　可逆符号化部１６は、量子化部１５から供給される量子化された係数に対して、可変長符号化（例えば、CAVLC（Context-Adaptive Variable Length Coding）など）、算術符号化（例えば、CABAC（Context-Adaptive Binary Arithmetic Coding）など）などの可逆符号化を行う。
　また、可逆符号化部１６は、イントラ予測モード情報、または、インター予測モード情報、動きベクトル、参照画像を特定する情報、オフセットフィルタ情報、およびフィルタ係数などを、符号化に関する符号化情報として可逆符号化する。可逆符号化部１６は、可逆符号化された符号化情報と係数とから、符号化ストリームを生成して蓄積バッファ１７に供給し、蓄積させる。なお、可逆符号化された符号化情報は、可逆符号化された係数のヘッダ情報とされてもよい。
　蓄積バッファ１７は、可逆符号化部１６から供給される符号化ストリームを、一時的に記憶する。また、蓄積バッファ１７は、記憶している符号化ストリームを、図１のファイル生成部２に供給する。
　また、量子化部１５より出力された、量子化された係数は、逆量子化部１８にも入力され、逆量子化された後、逆直交変換部１９に供給される。
　逆直交変換部１９は、逆量子化部１８から供給される係数に対して逆直交変換を施し、その結果得られる残差情報を加算部２０に供給する。
　加算部２０は、逆直交変換部１９から供給される復号対象の画像としての残差情報と、予測画像選択部２６から供給される予測画像を加算して、局部的に復号された画像を得る。なお、予測画像選択部２６から予測画像が供給されない場合、加算部２０は、逆直交変換部１９から供給される残差情報を局部的に復号された画像とする。加算部２０は、局部的に復号された画像をデブロックフィルタ２１に供給するとともに、フレームメモリ２２に供給して蓄積させる。
　デブロックフィルタ２１は、加算部２０から供給される局部的に復号された画像をフィルタリングすることにより、ブロック歪を除去する。デブロックフィルタ２１は、その結果得られる画像を適応オフセットフィルタ４１に供給する。
　適応オフセットフィルタ４１は、デブロックフィルタ２１による適応デブロックフィルタ処理後の画像に対して、主にリンギングを除去する適応オフセットフィルタ(SAO: Sample adaptive offset)処理を行う。
　より詳細には、適応オフセットフィルタ４１は、最大の符号化単位であるLCU（Largest Coding Unit）ごとに適応オフセットフィルタ処理の種類を決定し、その適応オフセットフィルタ処理で用いられるオフセットを求める。適応オフセットフィルタ４１は、求められたオフセットを用いて、適応デブロックフィルタ処理後の画像に対して、決定された種類の適応オフセットフィルタ処理を行う。そして、適応オフセットフィルタ４１は、適応オフセットフィルタ処理後の画像を適応ループフィルタ４２に供給する。
　また、適応オフセットフィルタ４１は、オフセットを格納するバッファを有している。適応オフセットフィルタ４１は、LCUごとに、適応デブロックフィルタ処理に用いられたオフセットが既にバッファに格納されているかどうかを判定する。
　適応オフセットフィルタ４１は、適応デブロックフィルタ処理に用いられたオフセットが既にバッファに格納されていると判定した場合、オフセットがバッファに格納されているかを示す格納フラグを、オフセットがバッファに格納されていることを示す値（ここでは１）に設定する。
　そして、適応オフセットフィルタ４１は、LCUごとに、１に設定された格納フラグ、バッファにおけるオフセットの格納位置を示すインデックス、および、行われた適応オフセットフィルタ処理の種類を示す種類情報を可逆符号化部１６に供給する。
　一方、適応オフセットフィルタ４１は、適応デブロックフィルタ処理に用いられたオフセットがまだバッファに格納されていない場合、そのオフセットを順にバッファに格納する。また、適応オフセットフィルタ４１は、格納フラグを、オフセットがバッファに格納されていないことを示す値（ここでは０）に設定する。そして、適応オフセットフィルタ４１は、LCUごとに、０に設定された格納フラグ、オフセット、および種類情報を可逆符号化部１６に供給する。
　適応ループフィルタ４２は、適応オフセットフィルタ４１から供給される適応オフセットフィルタ処理後の画像に対して、例えば、LCUごとに、適応ループフィルタ（ALF:Adaptive Loop Filter)処理を行う。適応ループフィルタ処理としては、例えば、２次元のウィナーフィルタ（Wiener Filter）による処理が用いられる。もちろん、ウィナーフィルタ以外のフィルタが用いられてもよい。
　具体的には、適応ループフィルタ４２は、LCUごとに、画面並べ替えバッファ１２から出力される画像である原画像と適応ループフィルタ処理後の画像の残差が最小となるように、適応ループフィルタ処理で用いられるフィルタ係数を算出する。そして、適応ループフィルタ４２は、適応オフセットフィルタ処理後の画像に対して、算出されたフィルタ係数を用いて、LCUごとに適応ループフィルタ処理を行う。
　適応ループフィルタ４２は、適応ループフィルタ処理後の画像をフレームメモリ２２に供給する。また、適応ループフィルタ４２は、フィルタ係数を可逆符号化部１６に供給する。
　なお、ここでは、適応ループフィルタ処理は、LCUごとに行われるものとするが、適応ループフィルタ処理の処理単位は、LCUに限定されない。但し、適応オフセットフィルタ４１と適応ループフィルタ４２の処理単位を合わせることにより、処理を効率的に行うことができる。
　フレームメモリ２２に蓄積された画像は、参照画像としてスイッチ２３を介してイントラ予測部２４または動き予測・補償部２５に出力される。
　イントラ予測部２４は、フレームメモリ２２からスイッチ２３を介して読み出されたデブロックフィルタ２１でフィルタリングされていない参照画像を用いて、タイルおよびスライス単位で、候補となる全てのイントラ予測モードのイントラ予測処理を行う。
　また、イントラ予測部２４は、画面並べ替えバッファ１２から読み出された画像と、イントラ予測処理の結果生成される予測画像とに基づいて、候補となる全てのイントラ予測モードに対してコスト関数値（詳細は後述する）を算出する。そして、イントラ予測部２４は、コスト関数値が最小となるイントラ予測モードを、最適イントラ予測モードに決定する。
　イントラ予測部２４は、最適イントラ予測モードで生成された予測画像、および、対応するコスト関数値を、予測画像選択部２６に供給する。イントラ予測部２４は、予測画像選択部２６から最適イントラ予測モードで生成された予測画像の選択が通知された場合、イントラ予測モード情報を可逆符号化部１６に供給する。
　なお、コスト関数値は、RD(Rate Distortion)コストともいい、例えば、H．264/AVC方式における参照ソフトウエアであるJM(Joint Model)で定められているような、High Complexity モードか、Low Complexity モードのいずれかの手法に基づいて算出される。
　具体的には、コスト関数値の算出手法としてHigh Complexity モードが採用される場合、候補となる全ての予測モードに対して、仮に可逆符号化までが行われ、次の式（１）で表わされるコスト関数値が各予測モードに対して算出される。
　Cost(Mode)=D＋λ・R　　　　　　　　　　　　　　　・・・（１）
　Dは、原画像と復号画像の差分（歪）、Rは、直交変換の係数まで含んだ発生符号量、λは、量子化パラメータQPの関数として与えられるラグランジュ乗数である。
　一方、コスト関数値の算出手法としてLow Complexity モードが採用される場合、候補となる全ての予測モードに対して、復号画像の生成、および、予測モードを示す情報などのヘッダビットの算出が行われ、次の式（２）で表わされるコスト関数値が各予測モードに対して算出される。
　Cost(Mode)=D＋QPtoQuant(QP)・Header_Bit　　　　　・・・（２）
　Dは、原画像と復号画像の差分（歪）、Header_Bitは、予測モードに対するヘッダビット、QPtoQuantは、量子化パラメータQPの関数として与えられる関数である。
　Low Complexity モードにおいては、全ての予測モードに対して、復号画像を生成するだけでよく、可逆符号化を行う必要がないため、演算量が少なくて済む。
　動き予測・補償部２５は、タイルおよびスライス単位で、候補となる全てのインター予測モードの動き予測・補償処理を行う。具体的には、動き予測・補償部２５は、タイルおよびスライス単位で、画面並べ替えバッファ１２から供給される画像と、フレームメモリ２２からスイッチ２３を介して読み出されるフィルタリングされた参照画像に基づいて、候補となる全てのインター予測モードの動きベクトルを検出する。そして、動き予測・補償部２５は、タイルおよびスライス単位で、その動きベクトルに基づいて参照画像に補償処理を施し、予測画像を生成する。
　このとき、動き予測・補償部２５は、画面並べ替えバッファ１２から供給される画像と予測画像とに基づいて、候補となる全てのインター予測モードに対してコスト関数値を算出し、コスト関数値が最小となるインター予測モードを最適インター測モードに決定する。そして、動き予測・補償部２５は、最適インター予測モードのコスト関数値と、対応する予測画像を予測画像選択部２６に供給する。また、動き予測・補償部２５は、予測画像選択部２６から最適インター予測モードで生成された予測画像の選択が通知された場合、インター予測モード情報、対応する動きベクトル、参照画像を特定する情報などを可逆符号化部１６に出力する。
　予測画像選択部２６は、イントラ予測部２４および動き予測・補償部２５から供給されるコスト関数値に基づいて、最適イントラ予測モードと最適インター予測モードのうちの、対応するコスト関数値が小さい方を、最適予測モードに決定する。そして、予測画像選択部２６は、最適予測モードの予測画像を、演算部１３および加算部２０に供給する。また、予測画像選択部２６は、最適予測モードの予測画像の選択をイントラ予測部２４または動き予測・補償部２５に通知する。
　レート制御部２７は、蓄積バッファ１７に蓄積された符号化データに基づいて、オーバーフローあるいはアンダーフローが発生しないように、量子化部１５の量子化動作のレートを制御する。
　［背景と問題点］
　ISO/IEC 14496-15において規定されているAVCファイルフォーマットでは、startcodeとfiller dataとを、ビットストリーム(Elementary Stream)に含めることが許容されていない。しかしながら、ISO base media file format及びMPEG-2 TS(Transport Stream)などのデータを扱う際の処理負荷を増大する要因となっている。
　また、ビットストリーム(Elementary Stream)からMPEG-2 TSを生成(変換)するためには、startcodeとfiller data（データサイズを調整するためのダミーデータ）とが除去されることにより、デコーダバッファを管理するパラメータの値が異なる場合がある。これにより、例えば、buffering period SEI(Supplemental enhancement information)を再設定する必要があり、ビットストリームを変換する際の処理負荷の増大につながる。
　［ファイル生成部の動作］
　そこで、ファイル生成部２は、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを生成する場合に、画像を符号化したビットストリームを含むファイルを対象として、startcodeとfiller dataとを設定し、設定されたstartcodeとfiller dataとを、ファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、startcodeとfiller dataとの設定を制御するようにした。
　また、ファイル生成部２は、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性を設定し、設定された特性を用いて、ファイルを生成するようにした。
　なお、デコーダバッファを管理するパラメータは、HRD parameter（Hypothetical Reference Decoder Parameter）、すなわち、仮想参照デコーダを管理するパラメータである。このデコーダバッファを管理するパラメータは、VUIにあるパラメータ、buffering period SEIにあるパラメータ、または、picture timing SEIにあるパラメータである。
　以上のようにすることで、伝送する際、または、ファイルへ格納する際のストリームを生成(変換)する場合に、startcodeとfiller dataとを再設定する必要がなくなり、処理の負担を軽減することができる。
　なお、filler dataについては、次のようにすることで、対応することも可能である。すなわち、AVCまたはHEVC方式において、NAL unit type codesと、NAL unit type classesのテーブルにあるように、filler dataは、non-VCLである。具体的には、nal_unit_type が３１で、Name of nal_unit_typeが、FD_NUTで、Content of NAL unit and RBSP syntax structureが、filler data、filler_data_rbsp()のとき、NAL nuit type classは、non-VCLとなっている。このnon-VCLを、VCLデータに変更することで、ファイルのmedia dataに、filler dataを含めることができるので、伝送用ストリームへの変換時にfiller dataが除去されることを抑制することができる。
　より具体的には、ファイル生成部２は、以下のように、startcodeとfiller dataとの設定を行う。
・Startcode and filler data
Therefore, this contribution proposes to allow to include startcode and filler data in the elementary streams for new brands ony.
In the original version of ISO/IEC 14496-15, SPS/PPS can't be included in the elementary stream. In ISO/IEC 14496-16 PDAM2, it is allowed to include SPS/PPS now. If it is allowed to include startcode and filler data in the elementary stream, then the burden for bitstream converter is significantly reduced. Rewriting of HRD parameters, e.g. buffering period SEI and picture timing SEI,  is not necessary in this case.
In order to ensure backward compatibility, this change should be applied to new brands. (new AVC brand and HEVC)
・Indication that HRD parameters are wrong
When startcode, filler data, etc were removed from the elementary stream to store ISOMFF, HRD parameters, e.g. buffering period SEI, picture timing SEI, etc are not correct. However, decoder can not know if HRD parameters in the elementary stream is correct. There should be an id to indicate the HRD parameters in the elementary stream maybe wrong.
・In HEVC or AVC change filler data as VCL data
Currently in HEVC and AVC, filler data is categorized as non-VCL. That mean the bit for filler data is counted as non-VCL (header information). However, if we specify filler data as VCL data, the bit for filler is counted as video bitstream itself. In this case, filler data is not necessary to remove from the elementary stream and HRD parameters are not changed. The table for HEVC is attached.
　更に、デコーダバッファを管理するパラメータが異なる(正しくない)場合、デコーダはデコーダバッファを管理するパラメータが同じ(正しい)ことを判別することができない。そこで、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性が変更されたかを識別する識別パラメータを設定する。一例として、ファイルフォーマットのオプショナルボックスで格納する場合を示す。

For example, in case of AVC, such id can be defined as an optional box in AVCSampleEntry as follows. (The same approach can be applied to other AVC sample entries and HEVCSampleEntry.)

AVCSampleEntry() extends VisualSampleEntry(type') {

//type is 'avc1' or 'avc3'
AVCConfigurationBox config;
MPEG4BitRateBox(); //Optional
MPEG4ExtensionDescriptorsBox(); //Optional
HRDConformanceBox(); //Optional
}

Add HRDConformanceBox into AVCSampleEntry and AVC2SVVSampleEntry in 5.4.2.1 
Add HRDConformanceBox into AVCSVCSampleEntry, AVC2SVCSampleEntry and  SVCSampleEntry in 6.5.3.1.
Add HRDConformanceBox into AVCMVCSampleEntry, AVC2MVCSampleEntry and MVCSampleEntry in section7.6.3.3.
Add  HRDConformanceBox into　HEVC SampleEntry in section 8.4.1.1.

HRDConformanceBox can be defined as follows.

class HRDConformanceBox extends Box('hrdc') {
HRDConformanceData() HRDConformance;
}

aligned(8) class HRDConformanceData {
unsigned int(7) reserved =0;
unsigned int(1) HRDConformanceFlag;
unsigned int (24) reserved;
Box[] any_box;//Optional
}
　識別パラメータは、例えば以下のように設定される。

HRDConformanceFlag is the identifier if HRD characteristics was changed by removing startcode, filler data, etc from the elementary stream. When HRDConformanceFlag is equal to1, the HRD parameters, e.g. buffering period SEI, picture timing SEI, was changed by removing startcode, filler data, etc from the elementary stream.
　以上の処理を行う図１のファイル生成部２は、次の図３に示すように構成される。
　［ファイル生成部の構成例］
　図３は、上述した処理を行うファイル生成部の構成例を示すブロック図である。
　図３の例において、ファイル生成部２は、制御部３１、設定部３２、およびファイル書き出し部３３を含むように構成されている。
　制御部３１は、デコーダバッファを管理するパラメータであるHRDパラメータの特性を保持するか否かに応じて、設定部３２によるファイルのVCLデータ部分であるmdatデータの生成処理を制御する。また、制御部３１は、設定部３２により設定されたmdatデータにおいて、startcodeとfiller dataが削除されているか否かに応じて、HRDパラメータの特性の設定、または、ファイルの管理情報部分であるmoovにおけるHRDの識別パラメータの設定を制御する。
　設定部３２は、エンコーダ１からの符号化ストリームを用いて、制御部３１による制御のもと、ファイルのmdatデータを生成し、生成したmdatデータをファイル書き出し部３３に供給する。なお、従来の手法においては、startcodeとfiller dataが削除されるが、本技術の手法においては、符号化ストリームにおいて設定されているstartcodeとfiller dataとが設定されたまま、mdatデータが生成される。
　また、設定部３２は、制御部３１による制御のもと、HRDパラメータの特性の再設定、またはファイルのmoovにおけるHRDの識別パラメータの設定を行う。そして、設定部３２は、ファイルのmoovを生成し、生成したmoovをファイル書き出し部３３に供給する。
　ファイル書き出し部３３は、設定部３２からのmoovをファイルに書き出し、さらに、mdatをファイルに書き出す。ファイル書き出し部３３により書き出されたＭＰ４のファイルは、後述する復号装置などに伝送され、復号装置において、読みとられ、復号される。
　［ファイル生成処理の例］
　次に、図４のフローチャートを参照して、ファイル生成部２のファイル生成処理を説明する。
　ステップＳ１において、制御部３１は、デコーダバッファを管理するパラメータであるHRDパラメータの特性を保持するか否かを判定する。ステップＳ１において、HRDパラメータの特性を保持しないと判定された場合、処理は、ステップＳ２に進む。ステップＳ２において、設定部３２は、制御部３１の制御のもと、従来のmdatデータの生成処理を行う。この処理は、図６を参照して後述される。
　ステップＳ２の処理により、startcodeが検出されて、NALデータが取得され、startcodeが削除される。そして、取得されたデータがVCLデータであるか、filler dataであるか、あるいは、管理情報であるかなどに応じて、Unit sizeの付加およびバッファへの蓄積、または破棄が行われて、mdatデータが生成される。生成されたmdatデータは、ファイル書き出し部３３に供給され、処理は、ステップＳ４に進む。
　一方、ステップＳ１において、HRDパラメータの特性を保持すると判定された場合、処理は、ステップＳ３に進む。ステップＳ３において、設定部３２は、制御部３１の制御のもと、本技術のmdatデータの生成処理を行う。この処理は、図７を参照して後述される。
　ステップＳ３の処理により、startcodeが検出されて、NALデータが取得され、取得されたデータがVCLデータに設定されて、Unit Sizeが付加されて、バッファに蓄積されることで、mdatデータが生成される。生成されたmdatデータは、ファイル書き出し部３３に供給され、処理は、ステップＳ４に進む。
　ステップＳ４において、制御部３１は、ステップＳ２またはＳ３で生成されたmdatデータにおいて、startcodeとfiller dataが削除されているか否かを判定する。
　ステップＳ４において、startcodeとfiller dataが削除されていると判定された場合、処理は、ステップＳ５に進む。ステップＳ５において、設定部３２は、HRDパラメータの特性を設定する。すなわち、HRDパラメータの特性が異なっているので、HRDパラメータの特性は、再度計算され、再度設定される。そして、設定されたHRDパラメータで、mdatデータのSEIおよびVUIが書き換えられる。
　ステップＳ４において、startcodeとfiller dataが削除されていないと判定された場合、ステップＳ５は、スキップされ、処理は、ステップＳ６に進む。
　ステップＳ６において、設定部３２は、ステップＳ２またはＳ３の処理で得られたデータのサイズ情報を用いて、ファイルのmoovを生成する。なお、ステップＳ３が行われた場合、moov用のバッファに蓄積された管理情報なども用いられる。生成されたmoovは、ファイル書き出し部３３に供給される。
　ステップＳ７において、ファイル書き出し部３３は、ステップＳ６により生成されたmoovをファイルに書き出す。
　ステップＳ８において、ファイル書き出し部３３は、ステップＳ２またはＳ３により生成されたmdatをファイルに書き出す。
　以上のようにして、ファイル書き出し部３３により書き出されたＭＰ４のファイルは、後述する復号装置などに送信され、復号装置において読みとられ、復号される。その際、HRDパラメータの特性を変えることなく、ファイルが生成される。また、HRDパラメータは、startcodeとfiller dataが削除されていたとしても再度設定されているので、HRDパラメータを参照することで、復号処理を正確に行うことができる。
　なお、図４の説明においては、startcodeとfillerdataが削除されている場合に、HRDパラメータの特性を再設定する例を説明したが、次に説明するように、HRDパラメータの特性が正しいか異なっているかを示す識別パラメータを設定するようにしてもよい。
　［ファイル生成処理の他の例］
　次に、図５のフローチャートを参照して、ファイル生成部２のファイル生成処理を説明する。
　ステップＳ１１において、制御部３１は、デコーダバッファを管理するパラメータであるHRDパラメータの特性を保持するか否かを判定する。ステップＳ１１において、HRDパラメータの特性を保持しないと判定された場合、処理は、ステップＳ１２に進む。ステップＳ１２において、設定部３２は、制御部３１の制御のもと、従来のmdatデータの生成処理を行う。この処理は、図５を参照して後述される。
　ステップＳ１２の処理により、startcodeが検出されて、NALデータが取得され、startcodeが削除される。そして、取得されたデータがVCLデータであるか、filler dataであるか、あるいは、管理情報であるかなどに応じて、Unit sizeの付加およびバッファへの蓄積、または破棄が行われて、mdatデータが生成される。生成されたmdatデータは、ファイル書き出し部３３に供給され、処理は、ステップＳ１４に進む。
　一方、ステップＳ１１において、HRDパラメータの特性を保持すると判定された場合、処理は、ステップＳ１３に進む。ステップＳ１３において、設定部３２は、制御部３１の制御のもと、本技術のmdatデータの生成処理を行う。この処理は、図６を参照して後述される。
　ステップＳ１３の処理により、startcodeが検出されて、NALデータが取得され、取得されたデータがVCLデータに設定されて、Unit Sizeが付加されて、バッファに蓄積されることで、mdatデータが生成される。生成されたmdatデータは、ファイル書き出し部３３に供給され、処理は、ステップＳ１４に進む。
　ステップＳ１４において、制御部３１は、ステップＳ１２またはＳ１３で生成されたmdatデータにおいて、startcodeとfiller dataが削除されているか否かを判定する。
　ステップＳ１４において、startcodeとfiller dataが削除されていないと判定された場合、処理は、ステップＳ１５に進む。ステップＳ１５において、設定部３２は、moovのHRDの識別パラメータを１に設定し、処理は、ステップＳ１７に進む。これにより、復号側で、HRDパラメータが正しいことを判別することができる。
　ステップＳ１４において、startcodeとfillerdataが削除されていると判定された場合、処理は、ステップＳ１６に進む。ステップＳ１６において、設定部３２は、moovのHRDの識別パラメータを０に設定し、処理は、ステップＳ１７に進む。これにより、復号側で、HRDパラメータが間違っている（正しくない）ことを判別することができる。
　ステップＳ１７において、設定部３２は、ステップＳ１２またはＳ１３の処理で得られたデータのサイズ情報を用いて、ファイルのmoovを生成する。なお、ステップＳ１３が行われた場合、moov用のバッファに蓄積された管理情報なども用いられる。生成されたmoovは、ファイル書き出し部３３に供給される。
　ステップＳ１８において、ファイル書き出し部３３は、ステップＳ１７により生成されたmoovをファイルに書き出す。
　ステップＳ１９において、ファイル書き出し部３３は、ステップＳ１２またはＳ１３により生成されたmdatをファイルに書き出す。
　以上のようにして、ファイル書き出し部３３により書き出されたＭＰ４のファイルは、後述する復号装置などに送信され、復号装置において読みとられ、復号される。その際、HRDパラメータの特性を変えることなく、ファイルが生成される。また、HRDパラメータが正しいか否かを識別するための識別パラメータを設定するようにしたので、HRDパラメータを参照して復号するのかしないのかを明確に判別することができる。
　［従来のmdatデータの生成処理例］
　次に、図６のフローチャートを参照して、図４のステップＳ２（または図５のステップＳ１２）における従来のmdatデータの生成処理について説明する。
　設定部３２は、ステップＳ２１において、エンコーダ１からの符号化ストリームからstartcodeを検出し、ステップＳ２２において、ステップＳ２１により検出されたstartcodeから、次のstartcode までのNALデータを取得する。
　設定部３２は、ステップＳ２３において、ステップＳ２１により検出されたstartcodeを削除する。ステップＳ２４において、ステップＳ２２により取得されたデータが、VCLデータであるか否かを判定する。
　ステップＳ２４において、ステップＳ２２により取得されたデータが、VCLデータであると判定された場合、処理は、ステップＳ２５に進む。ステップＳ２５において、設定部３２は、ステップＳ２２により取得されたデータに、対応するUnit sizeを付加して、アクセスユニットとする。そして、設定部３２は、ステップＳ２６において、Unit sizeが付加されたアクセスユニットを、内蔵するmdatバッファに蓄積し、処理は、ステップＳ３０に進む。
　ステップＳ２４において、ステップＳ２２により取得されたデータが、VCLデータではないと判定された場合、処理は、ステップＳ２７に進む。ステップＳ２７において、設定部３２は、ステップＳ２２により取得されたデータが、filler dataであるか否かを判定する。
　ステップＳ２７において、ステップＳ２２により取得されたデータが、filler dataであると判定された場合、処理は、ステップＳ２８に進む。ステップＳ２８において、設定部３２は、filler dataを破棄し、処理は、ステップＳ３０に進む。
　ステップＳ２７において、ステップＳ２２により取得されたデータが、filler dataではないと判定された場合、処理は、ステップＳ２９に進む。この場合、取得されたデータは、SPSやPPSなどの管理情報であるので、ステップＳ２９において、設定部３２は、取得されたデータを、内蔵するmoovバッファに蓄積し、処理は、ステップＳ３０に進む。
　ステップＳ３０において、設定部３２は、エンコーダ１からの符号化ストリームからstartcodeを検出する。
　ステップＳ３１において、設定部３２は、いまのデータがファイル最後のデータであるか否かを判定する。ステップＳ３０によりstartcodeが検出されなかった場合、ステップＳ３１において、ファイル最後のデータであると判定され、mdatデータの生成処理が終了され、処理は、図４のステップＳ２（または図５のステップＳ１２）に戻る。
　ステップＳ３０によりstartcodeが検出された場合、ステップＳ３１において、ファイル最後のデータではないと判定された場合、処理は、ステップＳ２２に進み、それ以降の処理が繰り返される。
　［本技術のmdatデータの生成処理例］
　これに対して、図７のフローチャートを参照して、図４のステップＳ３（図５のステップＳ１３）における本技術のmdatデータの生成処理について説明する。
　設定部３２は、ステップＳ４１において、エンコーダ１からの符号化ストリームからstartcodeを検出し、ステップＳ４２において、ステップＳ４１により検出されたstartcodeから、次のstartcode までのNALデータを取得する。なお、図７の例においては、startcodeは削除されない。
　設定部３２は、ステップＳ４３において、ステップＳ４２により取得されたデータが、filler dataであるか否かを判定する。ステップＳ４３において、ステップＳ４２により取得されたデータが、filler dataであると判定された場合、処理は、ステップＳ４４に進む。ステップＳ４４において、設定部３２は、filler dataを、VCLデータに設定する。
　ステップＳ４３において、ステップＳ４２により取得されたデータが、filler dataではないと判定された場合、ステップＳ４４はスキップされ、処理は、ステップＳ４５に進む。
　ステップＳ４５において、ステップＳ４２により取得されたデータに、対応するUnit sizeを付加して、アクセスユニットとし、ステップＳ４６において、Unit sizeが付加されたアクセスユニットを、内蔵するmdatバッファに蓄積する。ここで、取得されたデータがSPSやPPSなどの管理情報であった場合、内蔵するmoovバッファにも蓄積され、図４のステップＳ６または図５のステップＳ１７において、moovのSample Descriptionに、デフォルトのSPSやPPSとして格納される。
　なお、取得されたデータがSPSやPPSなどの管理情報であった場合、従来のように、mdatバッファに蓄積されず、内蔵するmoovバッファだけに蓄積されてもよい。
　ステップＳ４７において、設定部３２は、エンコーダ１からの符号化ストリームからstartcodeを検出する。
　ステップＳ４８において、設定部３２は、いまのデータがファイル最後のデータであるか否かを判定する。ステップＳ４７によりstartcodeが検出されなかった場合、ステップＳ４８において、ファイル最後のデータであると判定され、mdatデータの生成処理が終了され、処理は、図４のステップＳ３（図５のステップＳ１３）に戻る。
　ステップＳ４７によりstartcodeが検出された場合、ステップＳ４８において、ファイル最後のデータではないと判定された場合、処理は、ステップＳ４２に進み、それ以降の処理が繰り返される。
　以上のようにして、本技術においては、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、startcodeとfiller dataとの設定を制御するようにした。すなわち、startcodeとfiller data は削除されず、startcodeとfiller dataとを含んで、ファイルを構成するようにしたので、デコーダバッファを管理するパラメータの特性を保持することができる。
　また、filler dataを、VCLデータに変更するようにしたので、ファイルのmedia dataに、Filler dataを含めることができ、伝送用ストリームへの変換時にfiller dataが除去されることを抑制することができる。
　さらに、ファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性を設定し、設定されたパラメータを用いて、ファイルを生成するようにした。これにより、復号を正しく行うことができる。
　あるいは、ファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性が変更されたことを識別する識別パラメータを設定し、設定された識別パラメータを用いて、ファイルを生成するようにした。これにより、復号を正しく行うことができる。
　［復号装置の第１実施の形態の構成例］
　図８は、図１の符号化装置から伝送される符号化ストリームを復号する、本技術を適用した画像処理装置としての、復号装置の第１実施の形態の構成例を示すブロック図である。
　図８の復号装置は、ファイル読取部５１、およびデコーダ５２により構成される。
　復号装置のファイル読取部５１は、図１の符号化装置により生成されたＭＰ４のファイルを受け取り、受け取ったファイルから、図１のエンコーダ１により符号化された符号化ストリームを構成するSPS,PPS,VUI,SEI、符号化データ等を読み取る。ファイル読取部５１は、SPS,PPS,VUI,SEI、符号化データをデコーダ５２に供給する。
　より具体的には、ファイル読取部５１は、画像を符号化したビットストリームを含み、startcodeとfiller dataとがファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように制御されて設定されているファイルを受け取る。または、ファイル読取部５１は、画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性が設定され、設定された特性を用いて生成されているファイルを受け取る。そして、ファイル読取部５１は、受け取られたファイルを読み取り、デコーダ５２に、ビットストリームの符号化データを復号させる。
　デコーダ５２は、ファイル読取部５１の制御のもと、ファイル読取部５１から供給されるSPS,PPS,VUI,SEI等(特に、HRDパラメータの特性)を参照し、ファイル読取部５１から供給される符号化データをHEVC方式で復号する。デコーダ５２は、復号の結果得られる画像を、出力信号として後段に供給する。
　［ファイル読取部の構成例］
　図９は、ファイル読取部５１の構成例を示すブロック図である。
　図９の例において、ファイル読取部５１は、ファイル受け取り部７１、パラメータ取得部７２、復号制御部７３、およびデータ読み出し部７４を含むように構成されている。
　ファイル受け取り部７１は、図１のファイル生成部２により生成されたＭＰ４のファイルを受け取り、受け取ったファイルをパラメータ取得部７２に供給する。
　パラメータ取得部７２は、ＭＰ４のファイルから管理情報であるmoovを取得し、データ読み出し部７４に供給する。また、パラメータ取得部７２は、取得したmoovに基づいて、データ読み出し部７４に、mdatからデータを読み出させる。
　なお、図５のファイル生成処理により生成されたファイルの場合、パラメータ取得部７２は、moovから、HRDパラメータの特性が正しいか否かを判別するための識別パラメータを取得し、復号制御部７３にその識別パラメータを供給する。
　復号制御部７３は、パラメータ取得部７２からのHRDの識別パラメータがある場合、HRDの識別パラメータに応じて、HRDパラメータに従うか否かを決めて、デコーダ５２を制御し、復号処理を行わせる。
　一方、図４のファイル生成処理により生成されたファイルの場合、moovには、HRDの識別パラメータがないが、そのＭＰ４のファイルのstartcodeとfiller dataとが削除されていても、HRDパラメータの特性は、再度設定されているので、正しい。したがって、この場合、復号制御部７３は、特に動作を行わない。
　データ読み出し部７４は、パラメータ取得部７２の制御のもと、ファイルのmoovまたはmdatから、SPS、PPS、VUI、SEIなどを読み出して、また、ファイルのmdatから符号化データを読み出す。そして、データ読み出し部７４は、読み出したSPS、PPS、VUI、SEI、符号化データなどを、デコーダ５２に供給する。
　［復号部の構成例］
　図１０は、図８のデコーダ５２の構成例を示すブロック図である。デコーダ５２の各部は、ファイル読取部５１からのSPS、PPS、VUI、SEIに含まれるパラメータを用いて、符号化データを復号して、画像を生成する。
　図１０のデコーダ５２は、蓄積バッファ１０１、可逆復号部１０２、逆量子化部１０３、逆直交変換部１０４、加算部１０５、デブロックフィルタ１０６、画面並べ替えバッファ１０７、D/A変換部１０８、フレームメモリ１０９、スイッチ１１０、イントラ予測部１１１、動き補償部１１２、およびスイッチ１１３により構成される。
　また、デブロックフィルタ１０６と、画面並べ替えバッファ１０７およびフレームメモリ１０９との間には、適応オフセットフィルタ１４１と適応ループフィルタ１４２が備えられている。
　デコーダ５２の蓄積バッファ１０１は、図８のファイル読取部５１から符号化データを受け取り、蓄積する。蓄積バッファ１０１は、蓄積されている符号化データを可逆復号部１０２に供給する。
　可逆復号部１０２は、蓄積バッファ１０１からの符号化データに対して、可変長復号や、算術復号等の可逆復号を施すことで、量子化された係数と符号化情報を得る。可逆復号部１０２は、量子化された係数を逆量子化部１０３に供給する。また、可逆復号部１０２は、符号化情報としてのイントラ予測モード情報などをイントラ予測部１１１に供給し、動きベクトル、参照画像を特定するための情報、インター予測モード情報などを動き補償部１１２に供給する。さらに、可逆復号部１０２は、符号化情報としてのイントラ予測モード情報またはインター予測モード情報をスイッチ１１３に供給する。
　可逆復号部１０２は、符号化情報としてのオフセットフィルタ情報を適応オフセットフィルタ１４１に供給し、フィルタ係数を適応ループフィルタ１４２に供給する。
　逆量子化部１０３、逆直交変換部１０４、加算部１０５、デブロックフィルタ１０６、フレームメモリ１０９、スイッチ１１０、イントラ予測部１１１、および、動き補償部１１２は、図２の逆量子化部１８、逆直交変換部１９、加算部２０、デブロックフィルタ２１、フレームメモリ２２、スイッチ２３、イントラ予測部２４、および、動き予測・補償部２５とそれぞれ同様の処理を行い、これにより、画像が復号される。
　具体的には、逆量子化部１０３は、可逆復号部１０２からの量子化された係数を逆量子化し、その結果得られる係数を逆直交変換部１０４に供給する。
　逆直交変換部１０４は、逆量子化部１０３からの係数に対して逆直交変換を施し、その結果得られる残差情報を加算部１０５に供給する。
　加算部１０５は、逆直交変換部１０４から供給される復号対象の画像としての残差情報と、スイッチ１１３から供給される予測画像を加算することにより、復号を行う。加算部１０５は、復号の結果得られる画像をデブロックフィルタ１０６に供給するとともに、フレームメモリ１０９に供給する。なお、スイッチ１１３から予測画像が供給されない場合、加算部１０５は、逆直交変換部１０４から供給される残差情報である画像を復号の結果得られる画像として、デブロックフィルタ１０６に供給するとともに、フレームメモリ１０９に供給して蓄積させる。
　デブロックフィルタ１０６は、加算部１０５から供給される画像をフィルタリングすることにより、ブロック歪を除去する。デブロックフィルタ１０６は、その結果得られる画像を適応オフセットフィルタ１４１に供給する。
　適応オフセットフィルタ１４１は、可逆復号部１０２から供給されるオフセットを順に格納するバッファを有する。また、適応オフセットフィルタ１４１は、LCUごとに、可逆復号部１０２から供給されるオフセットフィルタ情報に基づいて、デブロックフィルタ１０６による適応デブロックフィルタ処理後の画像に対して、適応オフセットフィルタ処理を行う。
　具体的には、オフセットフィルタ情報に含まれる格納フラグが０である場合、適応オフセットフィルタ１４１は、LCU単位のデブロックフィルタ処理後の画像に対して、そのオフセットフィルタ情報に含まれるオフセットを用いて、種類情報が示す種類の適応オフセットフィルタ処理を行う。
　一方、オフセットフィルタ情報に含まれる格納フラグが１である場合、適応オフセットフィルタ１４１は、LCU単位のデブロックフィルタ処理後の画像に対して、そのオフセットフィルタ情報に含まれるインデックスが示す位置に格納されるオフセットを読み出す。そして、適応オフセットフィルタ１４１は、読み出されたオフセットを用いて、種類情報が示す種類の適応オフセットフィルタ処理を行う。適応オフセットフィルタ１４１は、適応オフセットフィルタ処理後の画像を、適応ループフィルタ１４２に供給する。
　適応ループフィルタ１４２は、適応オフセットフィルタ１４１から供給される画像に対して、可逆復号部１０２から供給されるフィルタ係数を用いて、LCUごとに適応ループフィルタ処理を行う。適応ループフィルタ１４２は、その結果得られる画像をフレームメモリ１０９および画面並べ替えバッファ１０７に供給する。
　フレームメモリ１０９に蓄積された画像は、参照画像としてスイッチ１１０を介して読み出され、動き補償部１１２またはイントラ予測部１１１に供給される。
　画面並べ替えバッファ１０７は、デブロックフィルタ１０６から供給される画像をフレーム単位で記憶する。画面並べ替えバッファ１０７は、記憶した符号化のための順番のフレーム単位の画像を、元の表示の順番に並び替え、D/A変換部１０８に供給する。
　D/A変換部１０８は、画面並べ替えバッファ１０７から供給されるフレーム単位の画像をD/A変換し、出力信号として図示せぬ後段に出力する。
　イントラ予測部１１１は、タイルおよびスライス単位で、フレームメモリ１０９からスイッチ１１０を介して読み出されたデブロックフィルタ１０６でフィルタリングされていない参照画像を用いて、可逆復号部１０２から供給されるイントラ予測モード情報が示すイントラ予測モードのイントラ予測処理を行う。イントラ予測部１１１は、その結果生成される予測画像をスイッチ１１３に供給する。
　動き補償部１１２は、タイルおよびスライス単位で、可逆復号部１０２から供給される参照画像を特定するための情報に基づいて、フレームメモリ１０９からスイッチ１１０を介して、デブロックフィルタ１０６でフィルタリングされた参照画像を読み出す。動き補償部１１２は、動きベクトルと参照画像を用いて、インター予測モード情報が示す最適インター予測モードの動き補償処理を行う。動き補償部１１２は、その結果生成される予測画像をスイッチ１１３に供給する。
　スイッチ１１３は、可逆復号部１０２からイントラ予測モード情報が供給された場合、イントラ予測部１１１から供給される予測画像を加算部１０５に供給する。一方、可逆復号部１０２からインター予測モード情報が供給された場合、スイッチ１１３は、動き補償部１１２から供給される予測画像を加算部１０５に供給する。
　［ファイル復号処理の例］
　次に、図１１のフローチャートを参照して、図８の復号装置のファイル復号処理を説明する。なお、このファイル復号処理は、図４のファイル生成処理により生成されたファイルに対する処理である。すなわち、このファイルにおけるHRDパラメータの特性は、startcodeとfiller dataが削除されていたとしても、再度設定されている。
　ステップＳ７１において、ファイル受け取り部７１は、ＭＰ４のファイルを受け取り、受け取ったファイルをパラメータ取得部７２に供給する。
　ステップＳ７２において、パラメータ取得部７２は、ＭＰ４のファイルから管理情報であるmoovを取得し、取得したmoovをデータ読み出し部７４に供給する。データ読み出し部７４は、ステップＳ７３において、moovからSPSおよびPPSを取得する。ステップＳ７４において、パラメータ取得部７２は、ステップＳ７２により取得されたmoovに基づいて、mdatの復号対象のUnit sizeを取得する。
　ステップＳ７５において、パラメータ取得部７２は、ステップＳ７４により取得されたUnit sizeに基づいて、NALを検出する。このとき、図１７および図１８を参照して後述されるファイル構造に応じて、例えば、startcodeも取得されて参照される。
　ステップＳ７６において、データ読み出し部７４は、ステップＳ７５により検出されたNALからデータを読み出し、デコーダ５２に供給する。なお、ここで、NALがSPSまたはPPSの場合、ステップＳ７３で取得されたmoovのSPSまたはPPSは、デフォルトの値となり、NALのSPSまたはPPSが用いられる。
　ステップＳ７７において、デコーダ５２は、復号処理を行う。その際、デコーダ５２は、HRDパラメータに従って、復号処理を行う。
　ここで、本技術においては、HRDパラメータの特性を保持するように、startcodeとfiller dataが設定されたまま、削除されず、ファイルが構成されているので、正しく復号処理を行うことができる。
　なお、仮に、このHRDパラメータが、startcodeとfiller dataが削除されていたとしても、図４のファイル生成処理において再度設定されているので、正しく復号処理を行うことができる。
　例えば、MP4ファイルの場合、外部よりVBRまたはCBRの伝送レートの指定がある。VBRの場合、データ読み出し部７４から、デコーダ５２に対して、ストリームがそのまま出力されるが、CBRの場合、データ読み出し部７４において、CBRとなるように、Filler dataまたはstuffing bitが追加されて、HRDパラメータが書き換えられる。その際にも、MP4ファイルのHRDパラメータは正常であるので、復号側においても正常に書き換えることができる。
　［ファイル復号処理の他の例］
　次に、図１２のフローチャートを参照して、図８の復号装置のファイル復号処理を説明する。なお、このファイル復号処理は、図５のファイル生成処理により生成されたファイルに対する処理である。すなわち、このファイルのmoovには、HRDパラメータの特性が正しいか異なっているかを識別する識別パラメータが設定されている。
　ステップＳ９１において、ファイル受け取り部７１は、ＭＰ４のファイルを受け取り、受け取ったファイルをパラメータ取得部７２に供給する。
　ステップＳ９２において、パラメータ取得部７２は、ＭＰ４のファイルから管理情報であるmoovを取得し、取得したmoovをデータ読み出し部７４に供給する。データ読み出し部７４は、ステップＳ９３において、moovからSPSおよびPPSを取得する。ステップＳ９４において、パラメータ取得部７２は、ステップＳ９２により取得されたmoovから、HRDの識別パラメータを取得し、取得したHRDの識別パラメータを、復号制御部７３に供給する。ステップＳ９５において、パラメータ取得部７２は、ステップＳ９２により取得されたmoovに基づいて、mdatの復号対象のUnit sizeを取得する。
　ステップＳ９６において、パラメータ取得部７２は、ステップＳ９５により取得されたUnit sizeに基づいて、NALを検出する。このとき、図１７および図１８を参照して後述されるファイル構造に応じて、例えば、startcodeも取得されて参照される。
　ステップＳ９７において、データ読み出し部７４は、ステップＳ９６により検出されたNALからデータを読み出し、デコーダ５２に供給する。なお、ここで、NALがSPSまたはPPSの場合、ステップＳ９３で取得されたmoovのSPSまたはPPSは、デフォルトの値となり、NALのSPSまたはPPSが用いられる。
　ステップＳ９８において、復号制御部７３は、パラメータ取得部７２からのHRDの識別パラメータが１であるか否かを判定する。ステップＳ９８において、HRDの識別パラメータが１であると判定された場合、処理は、ステップＳ９９に進む。
　ステップＳ９９において、デコーダ５２は、復号制御部７３の制御のもと、HRDパラメータに従って、復号処理を行う。
　一方、ステップＳ９８において、HRDの識別パラメータが１ではないと判定された場合、処理は、ステップＳ１００に進む。
　ステップＳ１００において、デコーダ５２は、復号制御部７３の制御のもと、HRDパラメータを無視して、復号処理を行う。
　ここで、本技術においては、HRDパラメータの特性を保持するように、startcodeとfiller dataが設定されたまま、削除されず、ファイルが構成されているので、正しく復号処理を行うことができる。
　なお、仮に、このHRDパラメータが、startcodeとfiller dataが削除されていたとしても、図５のファイル生成処理において、正しいか否かを識別する識別パラメータが設定されているので、正しく復号処理を行うことができる。
　＜２．第２の実施の形態＞
　［エンコーダの構成例］
　図１３は、上述したＭＰ４のファイルを生成するための、一実施形態に係る画像符号化装置２０１の構成の一例を示すブロック図である。図１３を参照すると、画像符号化装置２０１は、符号化部２１１、ＶＣＬバッファ２１２、非ＶＣＬバッファ２１３、ファイル生成部２１４及び制御部２１５を備える。
　なお、図１３の符号化部２１１は、図１のエンコーダ１に対応している。図１３のＶＣＬバッファ２１２、非ＶＣＬバッファ２１３、ファイル生成部２１４及び制御部２１５は、図１のファイル生成部２に対応している。
　符号化部２１１は、ＨＥＶＣ方式に従って動作するエンコーダである。符号化部２１１は、画像符号化装置２０１に接続されるカメラ又はテレビジョンチューナなどの動画ソースから、符号化すべき画像を順次取得する。そして、符号化部２１１は、取得した画像をＳＰＳ、ＰＰＳ及びＡＰＳに含まれるパラメータを用いて符号化し、画像データのビットストリームを生成する。また、符号化部２１１は、ＳＰＳ及びＰＰＳを非ＶＣＬ　ＮＡＬユニットとして生成する。一方、符号化部２１１は、filler data及び画像データのビットストリームをＶＣＬ　ＮＡＬユニットとして生成する。符号化部２１１は、filler data及び画像データのビットストリームを、ＶＣＬバッファ２１２を介してファイル生成部２１４へ出力する。また、符号化部２１１は、ＳＰＳ及びＰＰＳを、非ＶＣＬバッファ２１３を介してファイル生成部２１４へ出力する。ＶＣＬバッファ２１２は、ＶＣＬ　ＮＡＬユニットをバッファリングする。非ＶＣＬバッファ２１３は、非ＶＣＬ　ＮＡＬユニットをバッファリングする。ファイル生成部２１４は、符号化された一連の画像データを格納するＨＥＶＣファイル１５１を生成する。より具体的には、ファイル生成部２１４は、ＨＥＶＣファイル１５１のデータ領域（例えば、ｍｄａｔボックス）に、filler data及び画像データのビットストリームを、ＶＣＬ　ＮＡＬユニットとして復号順（decoding　order）で挿入する。また、ファイル生成部２１４は、ＨＥＶＣファイル１５１のヘッダ領域（例えば、ｍｏｏｖボックス）に、ＳＰＳ及びＰＰＳを、非ＶＣＬ　ＮＡＬユニットとして挿入する。制御部２１５は、画像符号化装置２０１において実行される符号化処理を制御する。
　なお、制御部２１５は、ＨＲＤ（Hypothetical　Reference　Decoder；仮想参照デコーダ）と呼ばれる仮想的なデコーダのモデルを用いて、デコーダのバッファを破綻させないように、符号化ストリームの生成を制御し得る。ＨＥＶＣ方式では、符号化ストリームが満たすべきコンフォーマンスポイント（規格適合性のチェックポイント）として、タイプ１及びタイプ２という２種類のコンフォーマンスポイントが定義されている。タイプ１のコンフォーマンスポイントは、ＶＣＬ　ＮＡＬユニット及びフィルタデータＮＡＬユニットに適用され、非ＶＣＬ　ＮＡＬユニットには適用されない。タイプ２のコンフォーマンスポイントは、ＶＣＬ　ＮＡＬユニット、フィルタデータＮＡＬユニット及び非ＶＣＬ　ＮＡＬユニットに適用される。本実施形態では、filler dataが非ＶＣＬ　ＮＡＬユニットではなくＶＣＬ　ＮＡＬユニットとして定義される。そのため、制御部２１５は、画像データのビットストリームのみならず、filler dataもまたタイプ１のコンフォーマンスポイントを満たすように、符号化ストリームの生成を制御してよい。
　［デコーダの構成例］
　図１４は、上述したＭＰ４のファイルから画像を復号するための、一実施形態に係る画像復号装置の構成の一例を示すブロック図である。図１４を参照すると、画像復号装置２５１は、ＶＣＬバッファ２６１、非ＶＣＬバッファ２６２、パラメータメモリ２６３、復号部２６４及び制御部２６５を備える。
　なお、図１４のＶＣＬバッファ２６１、非ＶＣＬバッファ２６２、パラメータメモリ２６３、及び制御部２６５は、図８のファイル読取部５１に対応している。また、図１４の復号部２６４は、図８のデコーダ５２に対応している。
　ＶＣＬバッファ２６１は、ファイルのデータ領域（例えば、ｍｄａｔボックス）から読み込まれる画像データのビットストリーム及びfiller dataをバッファリングする。非ＶＣＬバッファ２６２は、ファイルのヘッダ領域（例えば、ｍｏｏｖボックス）から読み込まれるパラメータセットをバッファリングする。パラメータメモリ２６３は、非ＶＣＬバッファ２６２を介して取得されるファイルのヘッダ領域内のパラメータセットを、一括的に記憶する。復号部２６４は、ＨＥＶＣ方式に従って動作するデコーダである。復号部２６４は、ＶＣＬバッファ２６１を介してファイルのデータ領域から逐次的に取得されるビットストリームから、画像を復号する。復号部２６４は、画像を復号する際 に、パラメータメモリ２６３により記憶されるＳＰＳ及びＰＰＳ内のパラメータを使用する。制御部２６５は、画像復号装置２５１において実行される復号処理を制御する。
　＜３．第３の実施の形態＞
　［従来のMP4ビデオサンプル構造］
　図１５は、従来のMP4ビデオサンプル構造の例を示す図である。ビデオサンプルを構成するNALユニットは、図１５に示されるように規定されている。
　図１５の例においては、複数のNALユニットで構成されているAVCストリームが示されている。AVCストリームにおいて、１ピクチャが１アクセスユニットとされている。アクセスユニットを構成するNALユニットの種類としては、SPS、PPS、アクセスユニットデリミタ(access unit delimiter)、SEI、IDRピクチャ、non IDRピクチャ、エンドオブシーケンス(end of sequence)、およびfiller　dataなどのユニットがある。
　従来のMP4の規定では、１ビデオサンプルには、１アクセスユニットが格納される。すなわち、１アクセスユニットを構成するNALユニットは、それぞれ、Unit sizeが付加されて、１ビデオサンプルに格納される。しかしながら、アクセスユニットを構成するNALユニットに、SPS、PPS、filler dataのNALユニットが存在する場合、SPS、PPS、filler dataのNALユニットは、ビデオサンプルから除外されていた。
　例えば、左から１番目のアクセスユニットは、アクセスユニットデリミタ、SPS、PPS、SEI、IDRピクチャのNALユニットで構成されているが、そのアクセスユニットをサンプルに格納する際、SPS、PPSのNALユニットは、除外されている。
　左から２番目のアクセスユニットは、アクセスユニットデリミタ、SPS、SEI、nonIDRピクチャ、およびfiller data のNALユニットで構成されているが、そのアクセスユニットをサンプルに格納する際、SPSおよびfiller dataのNALユニットは、除外されている。
　左から３番目のアクセスユニットは、アクセスユニットデリミタ、SPS、SEI、およびnonIDRピクチャのNALユニットで構成されているが、そのアクセスユニットをサンプルに格納する際、SPSのNALユニットは、除外されている。
　［AVCストリームの１アクセスユニットの構成例］
　図１６は、AVCストリームの１アクセスユニットの構成例を示す図である。
　図１６に示されるように、実際には、AVCストリームの１アクセスユニットにおいては、各NALユニットの前に、識別子（startcode）が付加されているが、従来においては、サンプルに格納する際、この識別子も除外されている。
　この識別子（startcode）やfiller data のNALユニットが除外されてしまうと、上述したように、HRDパラメータの特性が保持されない。そこで、本技術においては、MP4のサンプルに、そのままアクセスユニットを格納する。
　［本技術のアクセスユニットの格納例］
　図１７および図１８は、本技術のMP4ビデオサンプル構造の例を示す図である。
　図１７のＡの例においては、アクセスユニットの先頭に、アクセスユニットのサイズが記述されるユニットサイズが付加されて、MP4サンプルに、アクセスユニットがそのまま格納されている。そのままとは、startcodeを付けたままであって、filler dataがある場合には、filler dataを削除しないままのことである。すなわち、そのままとは、startcodeとfiller dataとが設定されたままのことである。
　図１７のＡの場合、上述した図１１のステップＳ７５または図１２のステップＳ９６において、Unit size分のアクセスユニットが検出され、その中で、startcodeに基づいて、NALが検出される。そして、図１１のステップＳ７６または図１２のステップＳ９７において、次のstartcode までのNALのデータが取得される。図１７のＡの場合、とてもシンプルな構造である。
　図１７のＢの例においては、アクセスユニットを構成する各NALユニットの先頭に、startcode含む各NALユニットのサイズが記述されるユニットサイズが付加されて、MP4サンプルに、アクセスユニットがそのまま格納されている。
　図１７のＢの場合、上述した図１１のステップＳ７５または図１２のステップＳ９６において、Unit size分のstartcode + NALが検出される。そして、図１１のステップＳ７６または図１２のステップＳ９７において、その中から、startcodeが破棄されて、NALのデータが取得される。この場合、従来のsize＋dataという構造に近く、実装はこれまで通りであるが、得られたデータ構造から、startcodeを解釈する必要がある。
　図１８のＣの例においては、アクセスユニットを構成する各NALユニットの先頭に、各NALユニットのサイズが記述されるユニットサイズが付加されており、さらに、０dataを含むstartcodeのサイズ、すなわち、NALまでのオフセットサイズが付加されている。そして、MP4サンプルに、ユニットサイズとオフセットサイズとが付加されたNALユニットが、そのまま格納されている。
　図１８のＣの場合、上述した図１１のステップＳ７５または図１２のステップＳ９６において、オフセットサイズが取得されて、オフセット分読み飛ばされた位置から、NALが検出される。そして、図１１のステップＳ７６または図１２のステップＳ９７において、ユニットサイズ分のNALのデータが取得される。
　なお、図１８のＣは、後述する図１９に示されるHRD Conformance BoxのFixedStartCodeSizeFlagが０の場合の例である。FixedStartCodeSizeFlagが０の場合、start code sizeが固定ではないので、offset size fieldにstartcodeのサイズが格納されている。
　これに対して、HRD Conformance BoxのFixedStartCodeSizeFlagが１の場合、MP４サンプルは、図１８のＣ´に示される構造になる。
　図１８のＣ´の例においては、アクセスユニットを構成する各NALユニットの先頭に、各NALユニットのサイズが記述されるユニットサイズが付加されて、MP4サンプルに、NALユニットが、そのまま格納されている。
　すなわち、FixedStartCodeSizeFlagが１の場合、start code size＝４bytes固定となるので、offset size fieldはstartcodeの前に不要となる。
　この場合、新しいパース構造となる。
　図１８のＤの例においては、アクセスユニットを構成する各NALユニットの先頭に、各NALユニットのサイズ、startcodeのサイズ、およびstartcodeが記述されるユニットサイズが付加されており、さらに、０dataを含むstartcodeのサイズ、すなわち、NALまでのオフセットサイズが付加されている。そして、MP4サンプルに、ユニットサイズとオフセットサイズとが付加されたNALユニットが、そのまま格納されている。
　図１８のＤの場合、上述した図１１のステップＳ７５または図１２のステップＳ９６において、ユニットサイズ分のオフセットサイズ＋startcode＋NALが検出されて、オフセットサイズが取得されて、オフセット分読み飛ばされた位置から、NALが検出される。そして、図１１のステップＳ７６または図１２のステップＳ９７において、Unit size－（オフセットサイズ＋startcode）分のNALのデータが取得される。
　なお、図１８のＤは、HRD Conformance BoxのFixedStartCodeSizeFlagが０の場合の例である。FixedStartCodeSizeFlagが０の場合、start code sizeが固定ではないので、offset size fieldにstartcodeのサイズが格納されている。
　これに対して、HRD Conformance BoxのFixedStartCodeSizeFlagが１の場合、MP４サンプルは、図１８のＤ´に示される構造になる。
　図１８のＤ´の例においては、アクセスユニットを構成する各NALユニットの先頭に、startcode含む各NALユニットのサイズが記述されるユニットサイズが付加されて、MP4サンプルに、NALユニットが、そのまま格納されている。
　すなわち、FixedStartCodeSizeFlagが１の場合、start code size＝４bytes固定となるので、offset size fieldはstartcodeの前に不要となり、図１８のＤ´の構造は、上述した図１７のＢの構造と同様になる。
　この場合、従来のsize＋dataという構造に近く、実装はこれまで通りであるが、得られたデータ構造の先頭にあるオフセットサイズ分読み飛ばすパース構造となる。また、この場合、startcodeを解釈する必要がある。
　［HRD Conformance Box拡張の例］
　図１９は、HRD Conformance Box拡張の例を示す図である。以下にも、HRD Conformance Box拡張の例を同様に示す。
AVCSampleEntry() extends VisualSampleEntry(‘type’) {
                // type is ‘avc3’ or ‘avc4’, (and all hevc)
    AVCConfigurationBox  config;
    MPEG4BitRateBox();  //Optional
    MPEG4ExtensionDescriptorsBox();  //Optional
    HRDConformanceBox();  //Optional
}

Add HRDConformanceBox into AVCSampleEntry and AVC2SVVSampleEntry in 5.4.2.1 
Add HRDConformanceBox into AVCSVCSampleEntry, AVC2SVCSampleEntry and  SVCSampleEntry in 6.5.3.1.
Add HRDConformanceBox into AVCMVCSampleEntry, AVC2MVCSampleEntry and MVCSampleEntry in section7.6.3.3.
Add  HRDConformanceBox into　HEVC SampleEntry in section 8.4.1.1.
Sample entry without HRDConformanceBox is used only for samples without start codes nor fillers.

HRDConformanceBox can be defined as follows.
class HRDConformanceBox extends Box('hrdc') {
    HRDConformanceData() HRDConformance;
}
aligned(8) class HRDConformanceData {
    unsigned int(1) HRDConformanceFlag;
    unsigned int(1) FixedStartCodeSizeFlag;
    unsigned int(2) OffsetSizeMinusOne;
    unsigned int(4) reserved =0;
    unsigned int(24) reserved;
    Box[] any_box;  //Optional
}

HRDConformanceFlag is the identifier if HRD characteristics was changed by removing startcode, filler data, etc from the elementary stream. When HRDConformanceFlag is equal to1, the HRD parameters, e.g. buffering period SEI, picture timing SEI, was changed by removing startcode, filler data, etc from the elementary stream.

FixedStartCodeSizeFlag is the idetifier when startcode in each NAL is fixed size of 4 bytes. When FixedStartCodeSizeFlag is equal to 1, no offset field is for each NAL in sample data to indicate the size of Start Code.

OffsetSizeMinusOne indicates the length in bytes of the StartcodeLength field in a video sample minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.

HRDConformanceBox is useful to indicate the status of HRD conformance even in the other options.
　図１９および上述した例においては、HRD Conformance Boxに、startcodeのサイズ情報の有無を識別するフラグであるFixedStartCodeSizeFlagが追加定義されている。これにより、図１８のＣ’および図１８のＤ'に示したように、startcodeのサイズが固定の場合、ファイル構造をシンプルにすることができる。
　［本技術のアクセスユニットの他の格納例］
　図２０は、本技術のMP4ビデオサンプル構造の他の例を示す図である。
　図２０のＥの例においては、mdatからユニットサイズが除去されて、そして、startcodeが含まれているエレメンタリーストリームは、そのまま変更なしにストア（貯蔵）されている。
　図２０のＥの場合、各アクセスユニットのオフセットを維持するための新しいboxは、図２１および以下に示されるように、sample tableに加えられる。
　aligned(8) class NALunitOffsetBox
    extends FullBox(‘nalo’, version=0, 0) {
    unsigned int(32) sample_count;
    for (i=1; i <= sample_count; i++){
        unsigned int(8) offset_count;
        unsigned int(8) offset_size;
        for (j=1; j <= offset_count; j++){
            unsigned int(offset_size*8) offset;
        }
    }
}
sample_count is an integer that gives the number of entries in the following table.
offset_count is an integer that gives the number of entries in the following subtable.
offset_size is an integer that gives the byte size of the offset field in the following subtable.
offset is an integer that gives the offset of the start of a NAL unit into its containing sample.
　なお、図２０のＥの例の代わりとして、上述したboxを加える代わりに、図２２のＥ´の例に示されるように、各サンプルの先頭に、そのオフセットのリストが含められるようにしてもよい。
　図２２のＥ´の例においては、サンプルの先頭に、例えば、５つのアクセスユニットの５つのオフセットのリストが含められている。
　なお、図１７および図１８のMP4ビデオサンプルのファイルは、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。図２０および図２２のMP4ビデオサンプルのファイルも、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。
　また、図１７および図１８のMP4ビデオサンプルのファイルは、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。図２０および図２２のMP4ビデオサンプルのファイルも、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。
　［本技術のアクセスユニットのさらに他の格納例］
　図２３は、本技術のMP4ビデオサンプル構造の、さらに他の例を示す図である。
　図２３のFの例においては、mdatからユニットサイズが除去されて、そして、startcodeが含まれているエレメンタリーストリームは、そのまま変更なしにストア（貯蔵）されている。また、各スタートコード（startcode）およびNALユニット（NAL unit）の長さを格納するために、ISO/IEC 14496-12において規定されるサンプル補助情報機能が適用されている。
　各スタートコードおよびNALユニットの長さには、サンプル補助情報機能として、aux_info_type = 'nalz'とaux_info_type_parameter = 0が与えられる。サンプル補助情報機能は、使用されるサンプル補助情報機能サイズボックス（SampleAuxiliaryInformationSizesBox）である'saiz'と、サンプル補助情報機能オフセットボックスである'saio'により参照される。
　［サンプル補助情報機能のフォーマット例］
　図２４は、サンプル補助情報機能のフォーマットの例を示す図である。以下にも、サンプル補助情報機能のフォーマットの例を同様に示す。
aligned(8) class NalsizeSampleAuxiliaryDataFormat
{
    unsigned int(2) StartcodeSizeMinusOne;
    unsigned int(2) NALunitSizeMinusOne;
    unsigned int(4) reserved;
    unsigned int(32) subsample_count;
    for (i=1; i <= subsample_count; i++){
        switch (StartcodeSizeMinusOne){
            case 0:
            unsigned int(8) Startcode Size;
            break;
            case 1:
            unsigned int(16) Startcode Size;
            break;
            case 3:
            unsigned int(32) Startcode Size;
            break;

            }

            switch (NALUnitSizeMinusOne){
            case 0:
            unsigned int(8) NALUnit Size;
            break;
            case 1:
            unsigned int(16) NALUnit Size;
            break;
            case 3:
            unsigned int(32) NALUnit Size;
            break;

            }

      }
}

StartcodeSizeMinusOne indicates the length in bytes of the Startcode Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
NALUnitSizeMinusOne indicates the length in bytes of the NALUnit Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
StartcodeSize indicates the length in bytes of the Startcode of subsample in a sampleNALUnitSize indicates the length in bytes of the Startcode of subsample in a sample
　StartcodeSizeMinusOneは、スタートコードサイズフィールド（Startcode Size field）のバイト長から１減算した値を示す。例えば、スタートコードサイズフィールドのバイト長が１バイトである場合、StartcodeSizeMinusOneの値は０である。StartcodeSizeMinusOneの値は、１バイト、２バイト、若しくは４バイトのそれぞれのコード長に対応して、０、１、若しくは３となる。
　NALUnitSizeMinusOneは、NALユニットサイズフィールド（NALUnit Size field）のバイト長から１減算した値を示す。例えば、NALユニットサイズフィールドのバイト長が１バイトである場合、NALUnitSizeMinusOneの値は０である。NALUnitSizeMinusOneの値は、１バイト、２バイト、若しくは４バイトのそれぞれのコード長に対応して、０、１、若しくは３となる。
　StartcodeSizeは、サンプル（sample）の中のサブサンプル（subsample）のスタートコード（Startcode）のバイト長を示す。
　NALUnitSizeは、サンプル（sample）の中のサブサンプル（subsample）のNALユニット（NAL unit）のバイト長を示す。
　以上のようにしても良い。また、サンプル補助情報機能のフォーマットは、以下のようにしてもよい。
　［サンプル補助情報機能のフォーマットの他の例］
　図２５は、サンプル補助情報機能のフォーマットの他の例を示す図である。以下にも、サンプル補助情報機能のフォーマットの他の例を同様に示す。
aligned(8) class NalsizeSampleAuxiliaryDataFormat
{
    unsigned int(1) FixedStartCodeSizeFlag;
    unsigned int(2) StartcodeSizeMinusOne;
    unsigned int(2) NALunitSizeMinusOne;
    unsigned int(3) reserved;
    unsigned int(32) subsample_count;
    for (i=1; i <= subsample_count; i++){
        if (FixedStartCodeSizeFlag == 0){
          switch (StartcodeSizeMinusOne){
                case 0:
                  unsigned int(8) Startcode Size;
                  break;
                case 1:
                  unsigned int(16) Startcode Size;
                  break;
                case 3:
                  unsigned int(32) Startcode Size;
                  break;
          }
        }
        switch (NALUnitSizeMinusOne){
                case 0:
                  unsigned int(8) NALUnit Size;
                  break;
                case 1:
                  unsigned int(16) NALUnit Size;
                  break;
                case 3:
                  unsigned int(32) NALUnit Size;
                  break;
        }
    }
}

FixedStartCodeSizeFlag is the identifier when startcode before each NAL unit has fixed size of 4 bytes. When FixedStartCodeSizeFlag is equal to 1.
StartcodeSizeMinusOne indicates the length in bytes of the Startcode Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
NALUnitSizeMinusOne indicates the length in bytes of the NALUnit Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
StartcodeSize indicates the length in bytes of the Startcode of subsample in a sample
NALUnitSize indicates the length in bytes of the Startcode of subsample in a sample
　FixedStartCodeSizeFlagは、フラグ情報である。各NALユニット（NAL unit）の前のスタートコード（startcode）のサイズが４バイトであるか否かを示すフラグ情報である。各NALユニット（NAL unit）の前のスタートコード（startcode）のサイズが４バイトである場合、このFixedStartCodeSizeFlagの値は１に設定され、その他の場合、０に設定される。換言するに、FixedStartCodeSizeFlagの値が１である場合、各NALユニット（NAL unit）の前のスタートコード（startcode）のサイズが４バイトであることを示し、FixedStartCodeSizeFlagの値が０である場合、各NALユニット（NAL unit）の前のスタートコード（startcode）のサイズが４バイトでないことを示す。
　StartcodeSizeMinusOne，NALUnitSizeMinusOne，StartcodeSize、およびNALUnitSizeの各パラメータは、図２４の場合と同様である。
　HRDConformanceData boxのFixedStartCodeSizeFlagが１の場合、個々のstart codeのサイズを持つと、データ量が不要に増大する可能性がある。そこで、図２５の例のようにすることにより、この場合、NALunitのサイズだけを持つ構造にすることができ、データ量の不要な増大を抑制することができる。なお、この場合、HRDConformanceBoxは、HRDConformanceFlagだけを持つことになる。
　なお、図２３のMP4ビデオサンプルのファイルは、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。
　また、図２３のMP4ビデオサンプルのファイルは、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。
In this option, unit size is removed from mdat, and elementary stream including startcode is simply stored without modification. And to store the length of each startcode and NAL unit, we propose to use the sample auxiliary information function defined in ISO/IEC 14496-12 . Figure 23 shows an example of a sample of this option.

Each length of start code and NAL unit  are provided as Sample Auxiliary Information with aux_info_type equal to 'nalz' and aux_info_type_parameter equal to 0.Sample Auxiliary Information is referenced by using a
SampleAuxiliaryInformationSizesBox ('saiz') and a
SampleAuxiliaryInformationOffsetsBox ('saio') 

The format of the sample auxiliary information for samples with this type shall be:
aligned(8) class NalsizeSampleAuxiliaryDataFormat
{
    unsigned int(1) FixedStartCodeSizeFlag;
    unsigned int(2) StartcodeSizeMinusOne;
    unsigned int(2) NALunitSizeMinusOne;
    unsigned int(3) reserved;
    unsigned int(32) subsample_count;
    for (i=1; i <= subsample_count; i++){
        if (FixedStartCodeSizeFlag == 0){
          switch (StartcodeSizeMinusOne){
                case 0:
                  unsigned int(8) Startcode Size;
                  break;
                case 1:
                  unsigned int(16) Startcode Size;
                  break;
                case 3:
                  unsigned int(32) Startcode Size;
                  break;
          }
        }
        switch (NALUnitSizeMinusOne){
                case 0:
                  unsigned int(8) NALUnit Size;
                  break;
                case 1:
                  unsigned int(16) NALUnit Size;
                  break;
                case 3:
                  unsigned int(32) NALUnit Size;
                  break;
        }
    }
}

FixedStartCodeSizeFlag is the identifier when startcode before each NAL unit has fixed size of 4 bytes. When FixedStartCodeSizeFlag is equal to 1.
StartcodeSizeMinusOne indicates the length in bytes of the Startcode Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
NALUnitSizeMinusOne indicates the length in bytes of the NALUnit Size field minus one. For example, a size of one byte is indicated with a value of 0. The value of this field shall be one of 0, 1, or 3 corresponding to a length encoded with 1, 2, or 4 bytes, respectively.
StartcodeSize indicates the length in bytes of the Startcode of subsample in a sample
NALUnitSize indicates the length in bytes of the NAL unit of subsample in a sample
　［本技術のMP4ビデオサンプル構造の比較］
　図２６の例においては、上述したMP4ビデオサンプル構造を比較するための表が示されている。
　図１７のＢのアクセスユニットの格納例においては、従来（現行）のsize＋dataという構造に近いというメリットがある。
　図１８のＣまたは図１８のＣ´のアクセスユニットの格納例においては、従来（現行）のsize＋dataという構造に近く、ユニットサイズのセマンテックスが変更されないというメリットがある。また、startcodeのサイズが固定された場合、そのデータ構造は、従来（現行）のファイルフォーマットデザインと同様であるというメリットがある。
　図１８のＤまたは図１８のＤ´のアクセスユニットの格納例においては、従来（現行）のsize＋dataという構造に近いというメリットがある。
　図２０のＥまたは図２２のＥ´のアクセスユニットの格納例においては、エレメンタリーストリームへのストアがシンプルである（すなわち、startcodeを除去する必要がなく、ユニットサイズやstartcode サイズを加える必要がない）というメリットがある。
　なお、もしサンプルのデザインの一貫性（design consistency）が重要な要因であるならば、図１８のＣまたは図１８のＣ´が最もよい提案である。しかしながら、図２０のＥまたは図２２のＥ´は、何の変更もなしにエレメンタリーストリームをストアするための最もよい方法である。
　以上、上述したアクセスユニットの格納例は、すべて、mdatにstartcodeをストアするために提案されている（In this contribution, the following options are proposed to store startcode in mdat. (for both AVC and HEVC file format)）。
　なお、上述した図２３のMP4ビデオサンプル構造は、次の図２７のように構成することも可能である。
　［本技術のアクセスユニットの他の格納例］
　図２７は、図２３のMP4ビデオサンプル構造の他の例を示す図である。
　図２７のＧの例においては、図２３のＦの例と同様に、mdatからユニットサイズが除去されて、そして、startcodeが含まれているエレメンタリーストリームは、そのまま変更なしにストア（貯蔵）されている。ただし、図２３のＦの例と異なり、エレメンタリーストリームにおいて、各スタートコード（startcode）はNALユニット（NAL unit）に含められ、スタートコードを含めたNALユニットの長さを格納するために、ISO/IEC 14496-12において規定されるサンプル補助情報機能が適用されている。
　各NALユニットの長さには、サンプル補助情報機能として、aux_info_type = 'nalz'とaux_info_type_parameter = 0が与えられる。サンプル補助情報機能は、使用されるサンプル補助情報機能サイズボックス（SampleAuxiliaryInformationSizesBox）である'saiz'と、サンプル補助情報機能オフセットボックスである'saio'により参照される。
　すなわち、図２７のＧの例においては、サンプル補助情報機能として、スタートコードの長さは格納されず、スタートコードを含めたNALユニットの長さのみが格納される。したがって、図２７のＧの例については、スタートコードの長さが格納されない以外のことは、図２３のＦの例と同様である。
　なお、図２７のMP4ビデオサンプルのファイルは、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。
　また、図２７のMP4ビデオサンプルのファイルは、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。
　＜４．第４の実施の形態＞
  ここで、従来、MP4のエレメンタリーストリームをMPEG2-PSに格納しようとしたとき、ユニットサイズを抜いて、スタートコードを入れて作らないといけなかった。逆に、MPEG2-PSのエレメンタリーストリームをMP4に格納しようとしたとき、スタートコードを抜いて、ユニットサイズを入れて作らないといけなかった。すなわち、少なくとも、２種類のストリームが存在し、ファイル化をする際に、ストリームの変更が必要であり、HRD conformanceに準拠しているのかどうかを示すフラグが必要であった。
　また、startcodeの有無によりストリームに様々なバリエーションがあると、互換性がなくなってしまう恐れがあった。
　これに対して、MPEG2-PSのファイルに格納する、startcodeを含むストリームであるバイトストリームフォーマットが定義されている。MP4ファイルへの格納を可能にすることで、両ファイルでの互換性が向上する。
　本技術においては、サンプルの中に、バイトストリームがあるか否かを識別できるように、バイトストリームフォーマットの情報を格納するためのバイトストリームフォーマットインフォメーションボックスを定義する。
　［バイトストリームフォーマットインフォメーションボックス］
　次に、図２８を参照して、バイトストリームフォーマットインフォメーションボックスについて説明する。
　バイトストリームフォーマットインフォメーションボックスは、パラメータセットなどを入れることができるサンプルエントリに対してオプショナルで定義される。パラメータセットなどを入れることができるサンプルエントリは、バイトストリームとしても格納することができる。なお、その際、バイトストリームであることをシグナルするために、このボックスが格納される。
　図２８の例においては、バイトストリームフォーマットインフォメーションボックスの仕様について示されている。
　The Byte Stream Format Information Box may be stored in  'avc3', 'avc4‘, 'mvc3' ,'mvc4‘  or ‘hev1‘ Sample Entry (in Sample entry box of media track).
This box SHALL be stored when sample data is structured by Byte Stream Format as defined in ISO/IEC 14496-10.
The Sub-Sample Information Box may be used to store one or more contiguous Byte stream NAL unit size
a sub-sample is defined as one or more contiguous Byte stream NAL units as defined in ISO/IEC 14496-10.

Box Type:　　‘bsfi’
Container:　　Sample Entry (‘avc3’, ‘avc4’, ‘mvc3’, ‘mvc4’ or ‘hev1‘ )Mandatory:　　No
Quantity:　　Zero or one


Class ByteStreamFormatInformationBox extends Box(‘bsfi') {
    ByteStreamFormatInformation() ByteStreamInformation;
}
　バイトストリームフォーマットインフォメーションボックスは、メディアトラックのサンプルエントリーボックスにおける、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’のサンプルエントリにストア（格納）されるようにする。’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’のサンプルエントリは、パラメータセットなどを入れることができるサンプルエントリである。
　このボックスは、サンプルデータが、ISO/IEC 14496-10で定められているバイトストリームフォーマットによって構成されているとき、ストア（格納）されるようにする。
　サブサンプルインフォメーションボックスは、１またはそれ以上の連続したstartcode を含めたNALユニットサイズをストア（格納）するために用いられてもよい。
　サブサンプルは、ISO/IEC 14496-10で定められている、１またはそれ以上の連続したバイトストリームNALユニットとして定義される。
　ボックスタイプ(Box Type)は’bsfi’であり、含まれるもの(Container)は、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’のサンプルエントリである。マンダトリ(必須事項：Mandatory)はなく、クアンティティ(量：Quantity)は、０か１である。
　バイトストリームフォーマットインフォメーションボックスは、バイトストリームフォーマットインフォメーションが記述される’bsfi’のボックスを拡張する。
　以上のように構成されるバイトストリームフォーマットインフォメーションボックスにおいては、図２９に示されるように、新しいフォーマットである’avc5’,’avc6’,’mvc5’,’mvc6’,または’hevc2’のサンプルエントリを入れるだけで、サンプルエントリの拡張が可能である。
　図２９は、バイトストリームフォーマットインフォメーションボックスの他の例を示す図である。
　The Byte Stream Format Information Box SHALL be stored in  'avc5', 'avc6‘, 'mvc5' ,'mvc6‘  or ‘hev2‘ Sample Entry (in Sample entry box of media track).
This box SHALL be stored when sample data is structured by Byte Stream Format as defined in ISO/IEC 14496-10.
The Sub-Sample Information Box may be used to store one or more contiguous Byte stream NAL unit size
a sub-sample is defined as one or more contiguous Byte stream NAL units as defined in ISO/IEC 14496-10.

Box Type:　　‘bsfi’
Container:　　Sample Entry (‘avc5’, ‘avc6’, ‘mvc5’, ‘mvc6’ or ‘hev2‘ )Mandatory:　　No
Quantity:　　Zero or one


Class ByteStreamFormatInformationBox extends Box(‘bsfi') {
    ByteStreamFormatInformation() ByteStreamInformation;
}
　なお、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’は、パラメータセットを入れることができるコーデックのタイプであるが、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’の場合、startcodeが入っているときと入っていないときがある。
　これに対して、図２９のようにサンプルエントリを、例えば、すべてstartcodeが入っているコーデックのタイプとして、‘avc5’, ‘avc6’, ‘mvc5’, ‘mvc6’ or ‘hev2‘などに拡張し、このサンプルエントリを参照することにより、サンプルの中にバイトストリームがあるか否かを識別することができる。
　また、サンプルエントリが、’avc3’,’avc4’,’mvc3’,’mvc4’,または’hevc1’の場合には、以下のように、バイトストリームフォーマットインフォメーションを構成することにより、サンプルの中にバイトストリームがあるか否か（すなわち、startcodeが入っているか否か）を識別することができる。
　さらに、サブサンプルのバイトストリームの構造を示すことができる。
　また、‘avc5’, ‘avc6’, ‘mvc5’, ‘mvc6’ or ‘hev2‘の場合には、以下のように、バイトストリームフォーマットインフォメーションを構成することにより、サブサンプルのバイトストリームの構造を示すことができる。
　［バイトストリームフォーマットインフォメーションのデータ構造例］
　図３０は、各サンプルエントリに格納されるバイトストリームフォーマットインフォメーションのデータ構造例を説明する図である。
　aligned(8) class ByteStreamFormatInformation {
      unsigned int(1) StartcodePresentFlag;
      unsigned int(1) ZeroBytePresentFlag;
　    unsigned int(1) LeadingZeroBytesPresentFlag;
　    unsigned int(1) TrailingZeroBytesPresentFlag; 
　    unsigned int(4) reserved =0;
      unsigned int(24) reserved;
      Box[] any_box;  //Optional
  }
　StartcodePresentFlagは、サンプルにおけるStartcodeの有無を示すフラグである。サンプル中のすべてのサブサンプルがNALユニットの前に、３バイトのStartcodeを含む場合、StartcodePresentFlag が１となる。ZeroBytePresentFlagは、Startcodeの前に１byteのゼロデータの有無を示すフラグであり、このFlagが１の場合、Startcodeが４バイトであることを示す。
　なお、StartcodePresentFlagとZeroBytePresentFlagの代わりに、２ビットのフラグを使用して、Startcodeが３バイトであるか、４バイトであるかを示すようにしてもよい。
　LeadingZeroBytePresentFlagは、サンプルにおける０データの有無を示すフラグである。サンプル中のサブサンプルのうち、少なくとも１つのサブサンプルの３バイトあるいは４バイトの前に、１バイトの0x00を複数含む場合に、LeadingZeroBytePresentFlagが１となる。LeadingZeroBytePresentFlagが０の場合、サブサンプルの先頭が固定長スタートコードであることがわかる。
　TrailingZeroBytePresentFlagは、サンプルにおける０データの有無を示すフラグである。サンプル中のサブサンプルのうち、少なくとも１つのサブサンプルの３バイトのNALユニットの後に、１バイトの0x00を複数含む場合に、TrailingZeroBytePresentFlagが１となる。
　なお、これらのフラグのうちのすべてがあってもよいが、必須ではなく、また、他のフラグが追加されてもよい。
　［本技術のNALユニットの格納例］
　次に、上述したバイトストリームフォーマットインフォメーションを用いた場合のNALユニットの格納例について説明する。図３１は、NALユニットの前後に0x00（０データ）があるパターン１の場合のMP4ビデオサンプル構造の例を示す図である。すなわち、図３１の例においては、上述したバイトストリームフォーマットインフォメーションのフラグであるStartcodePresentFlag、ZeroBytePresentFlag、LeadingZeroBytePresentFlag、およびTrailingZeroBytePresentFlagがすべて１の場合のMP4ビデオサンプル構造の例が示されている。
　図３１の例の場合、サンプルが、５サブサンプルにより構成される例が示されており、５サブサンプルのサイズが、サンプルサイズとして、サンプルサイズボックスに格納されている。
　サブサンプルは、先頭の０データ(LeadingZeroBytes)、Startcode（４バイト）、NALユニット、および後尾の０データ(TrailingZeroBytes)により構成されており、先頭の０データから、後尾の０データまでのサイズがサブサンプルのサイズとして、サブサンプルインフォメーションボックスに格納されている。すなわち、サブサンプルインフォメーションボックスにサブサンプルのサイズがあるので、サブサンプルの境界がわかる。
　このサブサンプルインフォメーションボックスの代わりに、図２７のＧの例と同様の構造でも実施可能である。サンプル補助情報機能として、aux_info_type = 'bsfi'とaux_info_type_parameter = 0が与えられる。サンプル補助情報機能は、使用されるサンプル補助情報機能サイズボックス（SampleAuxiliaryInformationSizesBox）である'saiz'と、サンプル補助情報機能オフセットボックスである'saio'により参照される。
　なお、業務用のCBR（constant bitrate：固定ビットレート）においては、このような運用をする場合がある。したがって、このパターン１は、例えば、業務用のすべてがイントラピクチャで構成されるストリームに用いられる場合に好適である。
　また、LeadingZeroBytesとTrailingZeroBytesとの区切りは、例えば、アプリケーションの運用によって設定されてもよい。
　図３２は、サブサンプルがStartcodeから始まり、0x00（０データ）がないパターン２の場合のMP4ビデオサンプル構造の例を示す図である。すなわち、図３２の例においては、StartcodePresentFlagとZeroBytePresentFlagとが１であり、LeadingZeroBytePresentFlag、およびTrailingZeroBytePresentFlagとが０である場合のMP4ビデオサンプル構造の例が示されている。
　図３２の例の場合、サンプルが、５サブサンプルにより構成される例が示されており、５サブサンプルのサイズが、サンプルサイズとして、サンプルサイズボックスに格納されている。
　サブサンプルは、Startcode（４バイト）、およびNALユニットにより構成されており、StartcodeからNALユニットまでのサイズがサブサンプルのサイズとして、サブサンプルインフォメーションボックスに格納されている。すなわち、サブサンプルインフォメーションボックスにサブサンプルのサイズがあるので、サブサンプルの境界がわかる。
　このパターン２は、最もシンプルな例である。
　図３３は、サブサンプルがStartcodeから始まり、NALの後に0x00（０データ）があるパターン３の場合のMP4ビデオサンプル構造の例を示す図である。すなわち、図３３の例においては、StartcodePresentFlag、ZeroBytePresentFlag、およびTrailingZeroBytePresentFlag が１であり、LeadingZeroBytePresentFlagが０の場合のMP4ビデオサンプル構造の例が示されている。
　図３３の例の場合、サンプルが、５サブサンプルにより構成される例が示されており、５サブサンプルのサイズが、サンプルサイズとして、サンプルサイズボックスに格納されている。
　サブサンプルは、Startcode（４バイト）、NALユニット、および後尾の０データ(TrailingZeroBytes)により構成されており、Startcodeから後尾の０データまでのサイズがサブサンプルのサイズとして、サブサンプルインフォメーションボックスに格納されている。すなわち、サブサンプルインフォメーションボックスにサブサンプルのサイズがあるので、サブサンプルの境界がわかる。
　なお、このパターン３の場合、例えば、業務用のすべてがイントラピクチャで構成されるストリームの編集機において、TrailingZeroで固定長にしていることがわかるので、編集しやすいという利点がある。また、３byte start codeもテレビジョン会議システムなどで用いられていることがある。
　以上のように、バイトストリームフォーマットインフォメーションをボックス化し、バイトストリームフォーマットインフォメーションを定義するようにした。例えば、サブサンプルが、図３１乃至図３３を参照して上述したパターン１乃至３のいずれかのように構成されるので、サンプル内にバイトストリームか否かを識別することができる。
　なお、図３１乃至図３３の各MP4ビデオサンプルのファイルは、上述した図３の構成のファイル生成部２により上述した図４または図５のファイル生成処理で生成される。
　また、図３１乃至図３３の各MP4ビデオサンプルのファイルは、上述した図９の構成のファイル読取部５１により上述した図１１または図１２のファイル復号処理で復号される。
　［バイトストリームフォーマットインフォメーションのデータ構造の他の例］
　図３４は、各サンプルエントリに格納されるバイトストリームフォーマットインフォメーションのデータ構造例を説明する図である。すなわち、図３４の例においては、図３０を参照して上述したデータ構造の他の例が示されている。
  aligned(8) class ByteStreamFormatInformation {
      unsigned int(2) StartcodePresentFlag;
      unsigned int(1) LeadingZeroBytesPresentFlag;
　    unsigned int(1) TrailingZeroBytesPresentFlag; 
　    unsigned int(4) reserved =0;
      unsigned int(24) reserved;
      Box[] any_box;  //Optional
}
  StartcodePresentFlagは、すべてのサブサンプルのStartcodeの構造を示す2bitのフラグである。
  StartcodePresentFlag = 00bは、reservedを示す。
　StartcodePresentFlag = 01bは、サンプル中のすべてのサブサンプルはNALユニットの前に、3byteのStartcodeを含むことを示す。
　StartcodePresentFlag = 10bは、サンプル中のすべてのサブサンプルはNALユニットの前に、3byteのStartcodeと、1byteのZeroByteデータを含む（すなわち、4byteで構成される）ことを示す。
  StartcodePresentFlag = 11bは、サンプル中のすべてのサブサンプルはNALユニットの前に、3byteのStartcodeを含み、1byteのZeroByteデータを含むことがあることを示す。すなわち、この場合、3byteと4byteのStartcodeが混在している可能性があるため、01bであるか10bであるかが保証できない。
　なお、この例は、図３０を参照して説明した構造例の他の例であり、Startcodeのサイズがわかるようにした例である。また、2bitsのフラグにより、3byte、4byte、またはそれらの混在が示される。
　LeadingZeroBytePresentFlagは、サンプル中のサブサンプルのうち、少なくとも１つのサブサンプルの3byteまたは4byteのStartcodeの前に、1byteの0x00を複数含むことがあることを示す。
　TrailingZeroBytePresentFlagは、サンプル中のサブサンプルのうち、少なくとも１つのサブサンプルのNALユニットの後に、1byteの0x00を複数含むことがあることを示す。
　なお、図３４の例においても、これらのフラグのうちのすべてがあってもよいが、必須ではなく、また、他のフラグが追加されてもよい。
　＜５．第５の実施の形態＞
　［ファイル変換装置の構成例］
　図３５は、本技術を適用した画像処理装置としての、ファイル変換装置の構成例を示すブロック図である。図３５のファイル変換装置３００は、例えば、MPEG-2 TS を MP4ファイルに変換する。
　図３５の例において、ファイル変換装置３００は、ビデオストリーム解析部３１１、および、図１のファイル生成部２を含むように構成されている。
　ビデオストリーム解析部３１１は、入力されるビデオストリームのフォーマットを解析し、MPEG-2 TSであると解析した場合、ビデオストリームを、ファイル生成部２に供給する。
　ファイル生成部２は、MPEG-2 TS を MP4ファイルに変換する処理を行う。すなわち、ファイル生成部２は、図１の例と同様に、MPEG-2 TSを格納するMP4ファイルを生成する。
　［ファイル変換処理の例］
　次に、図３６のフローチャートを参照して、図３５のファイル変換装置３００のファイル変換処理について説明する。
　ビデオストリーム解析部３１１は、ステップＳ３１１において、入力されるビデオストリームのフォーマットを解析し、MPEG-2 TSであると解析した場合、ビデオストリームを、ファイル生成部２に供給する。
　ファイル生成部２は、ステップＳ３１２において、MPEG-2 TSを格納するMP4ファイルを生成する。なお、このファイル生成処理は、図５を参照して上述したファイル生成処理と同様の処理であるので、その説明は繰り返しになるため省略される。
　以上のように、ファイル変換装置３００を構成することも可能である。
　なお、上記説明においては、HEVC方式による符号化装置および復号装置について説明したが、本技術は、以下に説明するように、AVC方式による符号化装置および復号装置にも適用することができる。
　＜６．第６の実施の形態＞
　［符号化装置の構成例］
　図３７は、本技術を適用した画像処理装置としての、符号化装置の他の構成例を示すブロック図である。
　図３７に示す構成のうち、図１の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。
　図３７の符号化装置の構成は、エンコーダ１の代わりに、エンコーダ４０１が設けられる点が図１の構成と異なる。図３７の符号化装置の構成は、ファイル生成部２が設けられている点が図１の構成と共通している。
　すなわち、エンコーダ４０１には、フレーム単位の撮影画像等の画像が入力信号として入力される。また、図示せぬエンコーダ４０１の前段で設定されたSPS、符号化データに対応する画像の特性をシーケンスごとに示すVUI、SEIなども入力される。
　エンコーダ４０１は、SPS、PPS、VUI、SEIに含まれるパラメータを用いて、入力信号をAVC方式で符号化する。そして、エンコーダ４０１は、SPS、PPS、VUI、SEIと、その結果得られる符号化データとから、MPEG-2 TSなどの符号化ストリームを生成し、生成した符号化ストリームを、ファイル生成部２に供給する。エンコーダ４０１の詳細は、図３８を参照して後述される。
　ファイル生成部２は、エンコーダ４０１からの符号化ストリーム（符号化された一連の画像データ）を格納するファイルを生成する。
　すなわち、図３６の符号化装置においては、AVC方式による符号化処理が行われる点のみが、図１の符号化装置と異なっている。
　［符号化部の構成例］
　図３８は、図３７のエンコーダ４０１の構成例を示すブロック図である。
　図３８に示す構成のうち、図２の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。
　図３８のエンコーダ４０１は、A/D変換部１１、画面並べ替えバッファ１２、演算部１３、直交変換部１４、量子化部１５、可逆符号化部１６、蓄積バッファ１７、逆量子化部１８、逆直交変換部１９、加算部２０、デブロックフィルタ２１、フレームメモリ２２、スイッチ２３、イントラ予測部２４、動き予測・補償部２５、予測画像選択部２６、およびレート制御部２７を含むように構成される。
　すなわち、図３８のエンコーダ４０１の構成は、適応オフセットフィルタ１４１と適応ループフィルタ１４２が除かれている点、および可逆符号化部１６がHEVC方式ではなく、AVC方式により符号化を行う点のみが図２の構成と異なる。したがって、エンコーダ４０１においては、CU単位ではなく、ブロック単位に符号化処理が行われる。
　可逆符号化部１６の符号化処理の対象は、適応オフセットフィルタおよび適応ループフィルタのパラメータを除き、図２の可逆符号化部１６の場合と基本的に同様である。すなわち、可逆符号化部１６は、図２の可逆符号化部１６と同様に、イントラ予測モード情報をイントラ予測部２４から取得する。また、インター予測モード情報、動きベクトル、参照画像を特定するための情報などを動き予測・補償部２５から取得する。
　可逆符号化部１６は、図２の可逆符号化部１６と同様に、量子化部１５から供給される量子化された係数に対して、可変長符号化（例えば、CAVLCなど）、算術符号化（例えば、CABACなど）などの可逆符号化を行う。
　また、可逆符号化部１６は、図２の可逆符号化部１６と同様に、イントラ予測モード情報、または、インター予測モード情報、動きベクトル、参照画像を特定する情報、オフセットフィルタ情報、およびフィルタ係数などを、符号化に関する符号化情報として可逆符号化する。可逆符号化部１６は、可逆符号化された符号化情報と係数を、符号化データとして蓄積バッファ１７に供給し、蓄積させる。なお、可逆符号化された符号化情報は、可逆符号化された係数のヘッダ情報とされてもよい。
　デブロックフィルタ２１は、加算部２０から供給される局部的に復号された画像をフィルタリングすることにより、ブロック歪を除去する。デブロックフィルタ２１は、その結果得られる画像をフレームメモリ２２に供給し、蓄積させる。
　フレームメモリ２２に蓄積された画像は、参照画像としてスイッチ２３を介してイントラ予測部２４または動き予測・補償部２５に出力される。
　本技術は、このようなAVC方式の符号化装置にも適用することができる。
　［復号装置の構成例］
　図３９は、図３７の符号化装置により生成されたファイルを読み取って復号する、本技術を適用した復号装置の他の構成例を示すブロック図である。
　図３９に示す構成のうち、図８の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。
　図３９の復号装置２５１の構成は、デコーダ５２の代わりにデコーダ４５１が設けられる点が図８の構成と異なる。復号装置２５１の構成は、ファイル読取部５１が設けられている点が図８の構成と共通している。
　復号装置のファイル読取部５１は、図３７の符号化装置により生成されたＭＰ４のファイルを受け取り、受け取ったファイルから、図３７のエンコーダ４０１により符号化された符号化ストリームを構成するSPS,PPS,VUI,SEI、符号化データ等を読み取る。ファイル読取部５１は、SPS,PPS,VUI,SEI、符号化データをデコーダ４５１に供給する。
　デコーダ４５１は、ファイル読取部５１の制御のもと、ファイル読取部５１から供給されるSPS,PPS,VUI,SEI等を参照し、ファイル読取部５１から供給される符号化データをAVC方式で復号する。デコーダ４５１は、復号の結果得られる画像を、出力信号として後段に供給する。
　すなわち、図３９の復号装置においては、AVC方式による復号処理が行われる点のみが、図８の復号装置と異なっている。
　［復号部の構成例］
　図４０は、図３９の復号部２６１の構成例を示すブロック図である。
　図４０に示す構成のうち、図１０の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。
　図４０のデコーダ４５１は、蓄積バッファ１０１、可逆復号部１０２、逆量子化部１０３、逆直交変換部１０４、加算部１０５、デブロックフィルタ１０６、画面並べ替えバッファ１０７、D/A変換部１０８、フレームメモリ１０９、スイッチ１１０、イントラ予測部１１１、動き補償部１１２、およびスイッチ１１３により構成される。
　図４０のデコーダ４５１の構成は、適応オフセットフィルタ１４１と適応ループフィルタ１４２が除かれている点、および可逆復号部１０２がHEVC方式ではなく、AVC方式により復号を行う点のみが図１０の構成と異なる。したがって、復号部２６１においては、CU単位ではなく、ブロック単位に復号処理が行われる。
　可逆復号部１０２の復号処理の対象は、適応オフセットフィルタおよび適応ループフィルタのパラメータを除き、図１０の可逆復号部１０２の場合と基本的に同様である。すなわち、可逆復号部１０２は、図１０の可逆復号部１０２と同様に、蓄積バッファ１０１からの符号化データに対して、可変長復号や、算術復号等の可逆復号を施すことで、量子化された係数と符号化情報を得る。可逆復号部１０２は、量子化された係数を逆量子化部１０３に供給する。
　また、可逆復号部１０２は、図１０の可逆復号部１０２と同様に、符号化情報としてのイントラ予測モード情報などをイントラ予測部１１１に供給し、動きベクトル、参照画像を特定するための情報、インター予測モード情報などを動き補償部１１２に供給する。さらに、可逆復号部１０２は、符号化情報としてのイントラ予測モード情報またはインター予測モード情報をスイッチ１１３に供給する。
　デブロックフィルタ１０６は、加算部１０５から供給される画像をフィルタリングすることにより、ブロック歪を除去する。デブロックフィルタ１０６は、その結果得られる画像をフレームメモリ１０９および画面並べ替えバッファ１０７に供給する。
　本技術は、このようなAVC方式の復号装置にも適用することができる。
　なお、上記説明においては、MP4ファイルフォーマットの例を説明したが、ファイルフォーマットは、MP4ファイルフォーマットまたはAVCファイルフォーマットには限定されない。本技術による課題・効果が同じであれば、別のファイルフォーマット、伝送する際に用いるストリーム、ファイルに格納する際に用いるストリームに対して、同様に適用することができる。
　また、本開示は、例えば、HEVC方式等の様に、離散コサイン変換等の直交変換と動き補償によって圧縮された画像情報（ビットストリーム）を、衛星放送、ケーブルテレビジョン、インターネット、または携帯電話機などのネットワークメディアを介して受信する際に用いられる画像符号化装置および画像復号装置に適用することができる。また、本開示は、光、磁気ディスク、およびフラッシュメモリのような記憶メディア上で処理する際に用いられる画像符号化装置および画像復号装置に適用することができる。
　なお、上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
　図４１は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
　コンピュータ８００において、CPU（Central Processing Unit）８０１，ROM（Read Only Memory）８０２，RAM（Random Access Memory）８０３は、バス８０４により相互に接続されている。
　バス８０４には、さらに、入出力インタフェース８０５が接続されている。入出力インタフェース８０５には、入力部８０６、出力部８０７、記憶部８０８、通信部８０９、及びドライブ８１０が接続されている。
　入力部８０６は、キーボード、マウス、マイクロホンなどよりなる。出力部８０７は、ディスプレイ、スピーカなどよりなる。記憶部８０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部８０９は、ネットワークインタフェースなどよりなる。ドライブ８１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア８１１を駆動する。
　以上のように構成されるコンピュータでは、CPU８０１が、例えば、記憶部８０８に記憶されているプログラムを、入出力インタフェース８０５及びバス８０４を介して、RAM８０３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ８００（CPU８０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア８１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
　コンピュータでは、プログラムは、リムーバブルメディア８１１をドライブ８１０に装着することにより、入出力インタフェース８０５を介して、記憶部８０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部８０９で受信し、記憶部８０８にインストールすることができる。その他、プログラムは、ROM８０２や記憶部８０８に、あらかじめインストールしておくことができる。
　なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
　また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
　また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表すものである。
　また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。つまり、本技術は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　また、例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
　また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
　さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
　上述した実施形態に係る画像符号化装置及び画像復号装置は、衛星放送、ケーブルＴＶなどの有線放送、インターネット上での配信、及びセルラー通信による端末への配信などにおける送信機若しくは受信機、光ディスク、磁気ディスク及びフラッシュメモリなどの媒体に画像を記録する記録装置、又は、これら記憶媒体から画像を再生する再生装置などの様々な電子機器に応用され得る。以下、４つの応用例について説明する。
　＜７．応用例＞
［第１の応用例：テレビジョン受像機］
　図４２は、上述した実施形態を適用したテレビジョン装置の概略的な構成の一例を示している。テレビジョン装置９００は、アンテナ９０１、チューナ９０２、デマルチプレクサ９０３、デコーダ９０４、映像信号処理部９０５、表示部９０６、音声信号処理部９０７、スピーカ９０８、外部インタフェース９０９、制御部９１０、ユーザインタフェース９１１、及びバス９１２を備える。
　チューナ９０２は、アンテナ９０１を介して受信される放送信号から所望のチャンネルの信号を抽出し、抽出した信号を復調する。そして、チューナ９０２は、復調により得られた符号化ビットストリームをデマルチプレクサ９０３へ出力する。即ち、チューナ９０２は、画像が符号化されている符号化ストリームを受信する、テレビジョン装置９００における伝送手段としての役割を有する。
　デマルチプレクサ９０３は、符号化ビットストリームから視聴対象の番組の映像ストリーム及び音声ストリームを分離し、分離した各ストリームをデコーダ９０４へ出力する。また、デマルチプレクサ９０３は、符号化ビットストリームからEPG（Electronic Program Guide）などの補助的なデータを抽出し、抽出したデータを制御部９１０に供給する。なお、デマルチプレクサ９０３は、符号化ビットストリームがスクランブルされている場合には、デスクランブルを行ってもよい。
　デコーダ９０４は、デマルチプレクサ９０３から入力される映像ストリーム及び音声ストリームを復号する。そして、デコーダ９０４は、復号処理により生成される映像データを映像信号処理部９０５へ出力する。また、デコーダ９０４は、復号処理により生成される音声データを音声信号処理部９０７へ出力する。
　映像信号処理部９０５は、デコーダ９０４から入力される映像データを再生し、表示部９０６に映像を表示させる。また、映像信号処理部９０５は、ネットワークを介して供給されるアプリケーション画面を表示部９０６に表示させてもよい。また、映像信号処理部９０５は、映像データについて、設定に応じて、例えばノイズ除去などの追加的な処理を行ってもよい。さらに、映像信号処理部９０５は、例えばメニュー、ボタン又はカーソルなどのGUI（Graphical User Interface）の画像を生成し、生成した画像を出力画像に重畳してもよい。
　表示部９０６は、映像信号処理部９０５から供給される駆動信号により駆動され、表示デバイス（例えば、液晶ディスプレイ、プラズマディスプレイ又はOELD（Organic ElectroLuminescence Display）（有機ELディスプレイ）など）の映像面上に映像又は画像を表示する。
　音声信号処理部９０７は、デコーダ９０４から入力される音声データについてD/A変換及び増幅などの再生処理を行い、スピーカ９０８から音声を出力させる。また、音声信号処理部９０７は、音声データについてノイズ除去などの追加的な処理を行ってもよい。
　外部インタフェース９０９は、テレビジョン装置９００と外部機器又はネットワークとを接続するためのインタフェースである。例えば、外部インタフェース９０９を介して受信される映像ストリーム又は音声ストリームが、デコーダ９０４により復号されてもよい。即ち、外部インタフェース９０９もまた、画像が符号化されている符号化ストリームを受信する、テレビジョン装置９００における伝送手段としての役割を有する。
　制御部９１０は、CPUなどのプロセッサ、並びにRAM及びROMなどのメモリを有する。メモリは、CPUにより実行されるプログラム、プログラムデータ、EPGデータ、及びネットワークを介して取得されるデータなどを記憶する。メモリにより記憶されるプログラムは、例えば、テレビジョン装置９００の起動時にCPUにより読み込まれ、実行される。CPUは、プログラムを実行することにより、例えばユーザインタフェース９１１から入力される操作信号に応じて、テレビジョン装置９００の動作を制御する。
　ユーザインタフェース９１１は、制御部９１０と接続される。ユーザインタフェース９１１は、例えば、ユーザがテレビジョン装置９００を操作するためのボタン及びスイッチ、並びに遠隔制御信号の受信部などを有する。ユーザインタフェース９１１は、これら構成要素を介してユーザによる操作を検出して操作信号を生成し、生成した操作信号を制御部９１０へ出力する。
　バス９１２は、チューナ９０２、デマルチプレクサ９０３、デコーダ９０４、映像信号処理部９０５、音声信号処理部９０７、外部インタフェース９０９及び制御部９１０を相互に接続する。
　このように構成されたテレビジョン装置９００において、デコーダ９０４は、上述した実施形態に係る画像復号装置（例えば、図８のファイル読取部５１およびデコーダ５２よりなる復号装置）の機能を有する。それにより、テレビジョン装置９００での画像の復号に際して、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを復号する際の処理の負担を軽減することができる。
　［第２の応用例：携帯電話機］
　図４３は、上述した実施形態を適用した携帯電話機の概略的な構成の一例を示している。携帯電話機９２０は、アンテナ９２１、通信部９２２、音声コーデック９２３、スピーカ９２４、マイクロホン９２５、カメラ部９２６、画像処理部９２７、多重分離部９２８、記録再生部９２９、表示部９３０、制御部９３１、操作部９３２、及びバス９３３を備える。
　アンテナ９２１は、通信部９２２に接続される。スピーカ９２４及びマイクロホン９２５は、音声コーデック９２３に接続される。操作部９３２は、制御部９３１に接続される。バス９３３は、通信部９２２、音声コーデック９２３、カメラ部９２６、画像処理部９２７、多重分離部９２８、記録再生部９２９、表示部９３０、及び制御部９３１を相互に接続する。
　携帯電話機９２０は、音声通話モード、データ通信モード、撮影モード及びテレビ電話モードを含む様々な動作モードで、音声信号の送受信、電子メール又は画像データの送受信、画像の撮像、及びデータの記録などの動作を行う。
　音声通話モードにおいて、マイクロホン９２５により生成されるアナログ音声信号は、音声コーデック９２３に供給される。音声コーデック９２３は、アナログ音声信号を音声データへ変換し、変換された音声データをA/D変換し圧縮する。そして、音声コーデック９２３は、圧縮後の音声データを通信部９２２へ出力する。通信部９２２は、音声データを符号化及び変調し、送信信号を生成する。そして、通信部９２２は、生成した送信信号を、アンテナ９２１を介して基地局（図示せず）へ送信する。また、通信部９２２は、アンテナ９２１を介して受信される無線信号を増幅し及び周波数変換し、受信信号を取得する。そして、通信部９２２は、受信信号を復調及び復号して音声データを生成し、生成した音声データを音声コーデック９２３へ出力する。音声コーデック９２３は、音声データを伸張し及びD/A変換し、アナログ音声信号を生成する。そして、音声コーデック９２３は、生成した音声信号をスピーカ９２４に供給して音声を出力させる。
　また、データ通信モードにおいて、例えば、制御部９３１は、操作部９３２を介するユーザによる操作に応じて、電子メールを構成する文字データを生成する。また、制御部９３１は、文字を表示部９３０に表示させる。また、制御部９３１は、操作部９３２を介するユーザからの送信指示に応じて電子メールデータを生成し、生成した電子メールデータを通信部９２２へ出力する。通信部９２２は、電子メールデータを符号化及び変調し、送信信号を生成する。そして、通信部９２２は、生成した送信信号を、アンテナ９２１を介して基地局（図示せず）へ送信する。また、通信部９２２は、アンテナ９２１を介して受信される無線信号を増幅し及び周波数変換し、受信信号を取得する。そして、通信部９２２は、受信信号を復調及び復号して電子メールデータを復元し、復元した電子メールデータを制御部９３１へ出力する。制御部９３１は、表示部９３０に電子メールの内容を表示させると共に、電子メールデータを記録再生部９２９の記憶媒体に記憶させる。
　記録再生部９２９は、読み書き可能な任意の記憶媒体を有する。例えば、記憶媒体は、RAM又はフラッシュメモリなどの内蔵型の記憶媒体であってもよく、ハードディスク、磁気ディスク、光磁気ディスク、光ディスク、USB（Universal Serial Bus）メモリ、又はメモリカードなどの外部装着型の記憶媒体であってもよい。
　また、撮影モードにおいて、例えば、カメラ部９２６は、被写体を撮像して画像データを生成し、生成した画像データを画像処理部９２７へ出力する。画像処理部９２７は、カメラ部９２６から入力される画像データを符号化し、符号化ストリームを記憶再生部９２９の記憶媒体に記憶させる。
　また、テレビ電話モードにおいて、例えば、多重分離部９２８は、画像処理部９２７により符号化された映像ストリームと、音声コーデック９２３から入力される音声ストリームとを多重化し、多重化したストリームを通信部９２２へ出力する。通信部９２２は、ストリームを符号化及び変調し、送信信号を生成する。そして、通信部９２２は、生成した送信信号を、アンテナ９２１を介して基地局（図示せず）へ送信する。また、通信部９２２は、アンテナ９２１を介して受信される無線信号を増幅し及び周波数変換し、受信信号を取得する。これら送信信号及び受信信号には、符号化ビットストリームが含まれ得る。そして、通信部９２２は、受信信号を復調及び復号してストリームを復元し、復元したストリームを多重分離部９２８へ出力する。多重分離部９２８は、入力されるストリームから映像ストリーム及び音声ストリームを分離し、映像ストリームを画像処理部９２７、音声ストリームを音声コーデック９２３へ出力する。画像処理部９２７は、映像ストリームを復号し、映像データを生成する。映像データは、表示部９３０に供給され、表示部９３０により一連の画像が表示される。音声コーデック９２３は、音声ストリームを伸張し及びD/A変換し、アナログ音声信号を生成する。そして、音声コーデック９２３は、生成した音声信号をスピーカ９２４に供給して音声を出力させる。
　このように構成された携帯電話機９２０において、画像処理部９２７は、上述した実施形態に係る画像符号化装置（例えば、図１のエンコーダ１およびファイル生成部２よりなる符号化装置）及び画像復号装置（例えば、図８のファイル読取部５１およびデコーダ５２よりなる復号装置）の機能を有する。それにより、携帯電話機９２０での画像の符号化及び復号に際して、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを復号する際の処理の負担を軽減することができる。
　［第３の応用例：記録再生装置］
　図４４は、上述した実施形態を適用した記録再生装置の概略的な構成の一例を示している。記録再生装置９４０は、例えば、受信した放送番組の音声データ及び映像データを符号化して記録媒体に記録する。また、記録再生装置９４０は、例えば、他の装置から取得される音声データ及び映像データを符号化して記録媒体に記録してもよい。また、記録再生装置９４０は、例えば、ユーザの指示に応じて、記録媒体に記録されているデータをモニタ及びスピーカ上で再生する。このとき、記録再生装置９４０は、音声データ及び映像データを復号する。
　記録再生装置９４０は、チューナ９４１、外部インタフェース９４２、エンコーダ９４３、HDD（Hard Disk Drive）９４４、ディスクドライブ９４５、セレクタ９４６、デコーダ９４７、OSD（On-Screen Display）９４８、制御部９４９、及びユーザインタフェース９５０を備える。
　チューナ９４１は、アンテナ（図示せず）を介して受信される放送信号から所望のチャンネルの信号を抽出し、抽出した信号を復調する。そして、チューナ９４１は、復調により得られた符号化ビットストリームをセレクタ９４６へ出力する。即ち、チューナ９４１は、記録再生装置９４０における伝送手段としての役割を有する。
　外部インタフェース９４２は、記録再生装置９４０と外部機器又はネットワークとを接続するためのインタフェースである。外部インタフェース９４２は、例えば、IEEE1394インタフェース、ネットワークインタフェース、USBインタフェース、又はフラッシュメモリインタフェースなどであってよい。例えば、外部インタフェース９４２を介して受信される映像データ及び音声データは、エンコーダ９４３へ入力される。即ち、外部インタフェース９４２は、記録再生装置９４０における伝送手段としての役割を有する。
　エンコーダ９４３は、外部インタフェース９４２から入力される映像データ及び音声データが符号化されていない場合に、映像データ及び音声データを符号化する。そして、エンコーダ９４３は、符号化ビットストリームをセレクタ９４６へ出力する。
　HDD９４４は、映像及び音声などのコンテンツデータが圧縮された符号化ビットストリーム、各種プログラムおよびその他のデータを内部のハードディスクに記録する。また、HDD９４４は、映像及び音声の再生時に、これらデータをハードディスクから読み出す。
　ディスクドライブ９４５は、装着されている記録媒体へのデータの記録及び読み出しを行う。ディスクドライブ９４５に装着される記録媒体は、例えばDVDディスク（DVD-Video、DVD-RAM、DVD-R、DVD-RW、DVD+R、DVD+RW等）又はBlu-ray（登録商標）ディスクなどであってよい。
　セレクタ９４６は、映像及び音声の記録時には、チューナ９４１又はエンコーダ９４３から入力される符号化ビットストリームを選択し、選択した符号化ビットストリームをHDD９４４又はディスクドライブ９４５へ出力する。また、セレクタ９４６は、映像及び音声の再生時には、HDD９４４又はディスクドライブ９４５から入力される符号化ビットストリームをデコーダ９４７へ出力する。
　デコーダ９４７は、符号化ビットストリームを復号し、映像データ及び音声データを生成する。そして、デコーダ９４７は、生成した映像データをOSD９４８へ出力する。また、デコーダ９０４は、生成した音声データを外部のスピーカへ出力する。
　OSD９４８は、デコーダ９４７から入力される映像データを再生し、映像を表示する。また、OSD９４８は、表示する映像に、例えばメニュー、ボタン又はカーソルなどのGUIの画像を重畳してもよい。
　制御部９４９は、CPUなどのプロセッサ、並びにRAM及びROMなどのメモリを有する。メモリは、CPUにより実行されるプログラム、及びプログラムデータなどを記憶する。メモリにより記憶されるプログラムは、例えば、記録再生装置９４０の起動時にCPUにより読み込まれ、実行される。CPUは、プログラムを実行することにより、例えばユーザインタフェース９５０から入力される操作信号に応じて、記録再生装置９４０の動作を制御する。
　ユーザインタフェース９５０は、制御部９４９と接続される。ユーザインタフェース９５０は、例えば、ユーザが記録再生装置９４０を操作するためのボタン及びスイッチ、並びに遠隔制御信号の受信部などを有する。ユーザインタフェース９５０は、これら構成要素を介してユーザによる操作を検出して操作信号を生成し、生成した操作信号を制御部９４９へ出力する。
　このように構成された記録再生装置９４０において、エンコーダ９４３は、上述した実施形態に係る画像符号化装置（例えば、図１のエンコーダ１およびファイル生成部２よりなる符号化装置）の機能を有する。また、デコーダ９４７は、上述した実施形態に係る画像復号装置（例えば、図８のファイル読取部５１およびデコーダ５２よりなる復号装置）の機能を有する。それにより、記録再生装置９４０での画像の符号化及び復号に際して、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを復号する際の処理の負担を軽減することができる。
　［第４の応用例：撮像装置］
　図４５は、上述した実施形態を適用した撮像装置の概略的な構成の一例を示している。撮像装置９６０は、被写体を撮像して画像を生成し、画像データを符号化して記録媒体に記録する。
　撮像装置９６０は、光学ブロック９６１、撮像部９６２、信号処理部９６３、画像処理部９６４、表示部９６５、外部インタフェース９６６、メモリ９６７、メディアドライブ９６８、OSD９６９、制御部９７０、ユーザインタフェース９７１、及びバス９７２を備える。
　光学ブロック９６１は、撮像部９６２に接続される。撮像部９６２は、信号処理部９６３に接続される。表示部９６５は、画像処理部９６４に接続される。ユーザインタフェース９７１は、制御部９７０に接続される。バス９７２は、画像処理部９６４、外部インタフェース９６６、メモリ９６７、メディアドライブ９６８、OSD９６９、及び制御部９７０を相互に接続する。
　光学ブロック９６１は、フォーカスレンズ及び絞り機構などを有する。光学ブロック９６１は、被写体の光学像を撮像部９６２の撮像面に結像させる。撮像部９６２は、CCD（Charge Coupled Device）又はCMOS（Complementary Metal Oxide Semiconductor）などのイメージセンサを有し、撮像面に結像した光学像を光電変換によって電気信号としての画像信号に変換する。そして、撮像部９６２は、画像信号を信号処理部９６３へ出力する。
　信号処理部９６３は、撮像部９６２から入力される画像信号に対してニー補正、ガンマ補正、色補正などの種々のカメラ信号処理を行う。信号処理部９６３は、カメラ信号処理後の画像データを画像処理部９６４へ出力する。
　画像処理部９６４は、信号処理部９６３から入力される画像データを符号化し、符号化データを生成する。そして、画像処理部９６４は、生成した符号化データを外部インタフェース９６６又はメディアドライブ９６８へ出力する。また、画像処理部９６４は、外部インタフェース９６６又はメディアドライブ９６８から入力される符号化データを復号し、画像データを生成する。そして、画像処理部９６４は、生成した画像データを表示部９６５へ出力する。また、画像処理部９６４は、信号処理部９６３から入力される画像データを表示部９６５へ出力して画像を表示させてもよい。また、画像処理部９６４は、OSD９６９から取得される表示用データを、表示部９６５へ出力する画像に重畳してもよい。
　OSD９６９は、例えばメニュー、ボタン又はカーソルなどのGUIの画像を生成して、生成した画像を画像処理部９６４へ出力する。
　外部インタフェース９６６は、例えばUSB入出力端子として構成される。外部インタフェース９６６は、例えば、画像の印刷時に、撮像装置９６０とプリンタとを接続する。また、外部インタフェース９６６には、必要に応じてドライブが接続される。ドライブには、例えば、磁気ディスク又は光ディスクなどのリムーバブルメディアが装着され、リムーバブルメディアから読み出されるプログラムが、撮像装置９６０にインストールされ得る。さらに、外部インタフェース９６６は、LAN又はインターネットなどのネットワークに接続されるネットワークインタフェースとして構成されてもよい。即ち、外部インタフェース９６６は、撮像装置９６０における伝送手段としての役割を有する。
　メディアドライブ９６８に装着される記録媒体は、例えば、磁気ディスク、光磁気ディスク、光ディスク、又は半導体メモリなどの、読み書き可能な任意のリムーバブルメディアであってよい。また、メディアドライブ９６８に記録媒体が固定的に装着され、例えば、内蔵型ハードディスクドライブ又はSSD（Solid State Drive）のような非可搬性の記憶部が構成されてもよい。
　制御部９７０は、CPUなどのプロセッサ、並びにRAM及びROMなどのメモリを有する。メモリは、CPUにより実行されるプログラム、及びプログラムデータなどを記憶する。メモリにより記憶されるプログラムは、例えば、撮像装置９６０の起動時にCPUにより読み込まれ、実行される。CPUは、プログラムを実行することにより、例えばユーザインタフェース９７１から入力される操作信号に応じて、撮像装置９６０の動作を制御する。
　ユーザインタフェース９７１は、制御部９７０と接続される。ユーザインタフェース９７１は、例えば、ユーザが撮像装置９６０を操作するためのボタン及びスイッチなどを有する。ユーザインタフェース９７１は、これら構成要素を介してユーザによる操作を検出して操作信号を生成し、生成した操作信号を制御部９７０へ出力する。
　このように構成された撮像装置９６０において、画像処理部９６４は、上述した実施形態に係る画像符号化装置（例えば、図１のエンコーダ１およびファイル生成部２よりなる符号化装置）及び画像復号装置（例えば、図８のファイル読取部５１およびデコーダ５２よりなる復号装置）の機能を有する。それにより、撮像装置９６０での画像の符号化及び復号に際して、伝送する際に用いるストリーム又はファイルに格納する際に用いるストリームを復号する際の処理の負担を軽減することができる。
＜８．第７の実施の形態＞
[実施のその他の例]
  以上において本技術を適用する装置やシステム等の例を説明したが、本技術は、これに限らず、このような装置またはシステムを構成する装置に搭載するあらゆる構成、例えば、システムLSI（Large Scale Integration）等としてのプロセッサ、複数のプロセッサ等を用いるモジュール、複数のモジュール等を用いるユニット、ユニットにさらにその他の機能を付加したセット等（すなわち、装置の一部の構成）として実施することもできる。
 [ビデオセット]
  本技術をセットとして実施する場合の例について、図４６を参照して説明する。図４６は、本技術を適用したビデオセットの概略的な構成の一例を示している。
  近年、電子機器の多機能化が進んでおり、その開発や製造において、その一部の構成を販売や提供等として実施する場合、１機能を有する構成として実施を行う場合だけでなく、関連する機能を有する複数の構成を組み合わせ、複数の機能を有する１セットとして実施を行う場合も多く見られるようになってきた。
  図４６に示されるビデオセット１３００は、このような多機能化された構成であり、画像の符号化や復号（いずれか一方でもよいし、両方でも良い）に関する機能を有するデバイスに、その機能に関連するその他の機能を有するデバイスを組み合わせたものである。
  図４６に示されるように、ビデオセット１３００は、ビデオモジュール１３１１、外部メモリ１３１２、パワーマネージメントモジュール１３１３、およびフロントエンドモジュール１３１４等のモジュール群と、コネクティビティ１３２１、カメラ１３２２、およびセンサ１３２３等の関連する機能を有するデバイスとを有する。
  モジュールは、互いに関連するいくつかの部品的機能をまとめ、まとまりのある機能を持った部品としたものである。具体的な物理的構成は任意であるが、例えば、それぞれ機能を有する複数のプロセッサ、抵抗やコンデンサ等の電子回路素子、その他のデバイス等を配線基板等に配置して一体化したものが考えられる。また、モジュールに他のモジュールやプロセッサ等を組み合わせて新たなモジュールとすることも考えられる。
  図４６の例の場合、ビデオモジュール１３１１は、画像処理に関する機能を有する構成を組み合わせたものであり、アプリケーションプロセッサ、ビデオプロセッサ、ブロードバンドモデム１３３３、およびRFモジュール１３３４を有する。
  プロセッサは、所定の機能を有する構成をSoC（System On a Chip）により半導体チップに集積したものであり、例えばシステムLSI（Large Scale Integration）等と称されるものもある。この所定の機能を有する構成は、論理回路（ハードウエア構成）であってもよいし、CPU、ROM、RAM等と、それらを用いて実行されるプログラム（ソフトウエア構成）であってもよいし、その両方を組み合わせたものであってもよい。例えば、プロセッサが、論理回路とCPU、ROM、RAM等とを有し、機能の一部を論理回路（ハードウエア構成）により実現し、その他の機能をCPUにおいて実行されるプログラム（ソフトウエア構成）により実現するようにしてもよい。
  図４６のアプリケーションプロセッサ１３３１は、画像処理に関するアプリケーションを実行するプロセッサである。このアプリケーションプロセッサ１３３１において実行されるアプリケーションは、所定の機能を実現するために、演算処理を行うだけでなく、例えばビデオプロセッサ１３３２等、ビデオモジュール１３１１内外の構成を必要に応じて制御することもできる。
  ビデオプロセッサ１３３２は、画像の符号化・復号（その一方若しくは両方）に関する機能を有するプロセッサである。
  ブロードバンドモデム１３３３は、インターネットや公衆電話回線網等の広帯域の回線を介して行われる有線若しくは無線（またはその両方）の広帯域通信に関する処理を行うプロセッサ（若しくはモジュール）である。例えば、ブロードバンドモデム１３３３は、送信するデータ（デジタル信号）をデジタル変調する等してアナログ信号に変換したり、受信したアナログ信号を復調してデータ（デジタル信号）に変換したりする。例えば、ブロードバンドモデム１３３３は、ビデオプロセッサ１３３２が処理する画像データや画像データが符号化されたストリーム、アプリケーションプログラム、設定データ等、任意の情報をデジタル変調・復調することができる。
  RFモジュール１３３４は、アンテナを介して送受信されるRF（Radio Frequency）信号に対して、周波数変換、変復調、増幅、フィルタ処理等を行うモジュールである。例えば、RFモジュール１３３４は、ブロードバンドモデム１３３３により生成されたベースバンド信号に対して周波数変換等を行ってRF信号を生成する。また、例えば、RFモジュール１３３４は、フロントエンドモジュール１３１４を介して受信されたRF信号に対して周波数変換等を行ってベースバンド信号を生成する。
  なお、図４６において点線１３４１に示されるように、アプリケーションプロセッサ１３３１とビデオプロセッサ１３３２を、一体化し、１つのプロセッサとして構成されるようにしてもよい。
  外部メモリ１３１２は、ビデオモジュール１３１１の外部に設けられた、ビデオモジュール１３１１により利用される記憶デバイスを有するモジュールである。この外部メモリ１３１２の記憶デバイスは、どのような物理構成により実現するようにしてもよいが、一般的にフレーム単位の画像データのような大容量のデータの格納に利用されることが多いので、例えばDRAM（Dynamic Random Access Memory）のような比較的安価で大容量の半導体メモリにより実現するのが望ましい。
  パワーマネージメントモジュール１３１３は、ビデオモジュール１３１１（ビデオモジュール１３１１内の各構成）への電力供給を管理し、制御する。
  フロントエンドモジュール１３１４は、RFモジュール１３３４に対してフロントエンド機能（アンテナ側の送受信端の回路）を提供するモジュールである。図４６に示されるように、フロントエンドモジュール１３１４は、例えば、アンテナ部１３５１、フィルタ１３５２、および増幅部１３５３を有する。
  アンテナ部１３５１は、無線信号を送受信するアンテナおよびその周辺の構成を有する。アンテナ部１３５１は、増幅部１３５３から供給される信号を無線信号として送信し、受信した無線信号を電気信号（RF信号）としてフィルタ１３５２に供給する。フィルタ１３５２は、アンテナ部１３５１を介して受信されたRF信号に対してフィルタ処理等を行い、処理後のRF信号をRFモジュール１３３４に供給する。増幅部１３５３は、RFモジュール１３３４から供給されるRF信号を増幅し、アンテナ部１３５１に供給する。
  コネクティビティ１３２１は、外部との接続に関する機能を有するモジュールである。コネクティビティ１３２１の物理構成は、任意である。例えば、コネクティビティ１３２１は、ブロードバンドモデム１３３３が対応する通信規格以外の通信機能を有する構成や、外部入出力端子等を有する。
  例えば、コネクティビティ１３２１が、Bluetooth（登録商標）、IEEE 802.11（例えばWi-Fi（Wireless Fidelity、登録商標））、NFC（Near Field Communication）、IrDA（InfraRed Data Association）等の無線通信規格に準拠する通信機能を有するモジュールや、その規格に準拠した信号を送受信するアンテナ等を有するようにしてもよい。また、例えば、コネクティビティ１３２１が、USB（Universal Serial Bus）、HDMI（登録商標）（High-Definition Multimedia Interface）等の有線通信規格に準拠する通信機能を有するモジュールや、その規格に準拠した端子を有するようにしてもよい。さらに、例えば、コネクティビティ１３２１が、アナログ入出力端子等のその他のデータ（信号）伝送機能等を有するようにしてもよい。
  なお、コネクティビティ１３２１が、データ（信号）の伝送先のデバイスを含むようにしてもよい。例えば、コネクティビティ１３２１が、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等の記録媒体に対してデータの読み出しや書き込みを行うドライブ（リムーバブルメディアのドライブだけでなく、ハードディスク、SSD（Solid State Drive）、NAS（Network Attached Storage）等も含む）を有するようにしてもよい。また、コネクティビティ１３２１が、画像や音声の出力デバイス（モニタやスピーカ等）を有するようにしてもよい。
  カメラ１３２２は、被写体を撮像し、被写体の画像データを得る機能を有するモジュールである。カメラ１３２２の撮像により得られた画像データは、例えば、ビデオプロセッサ１３３２に供給されて符号化される。
  センサ１３２３は、例えば、音声センサ、超音波センサ、光センサ、照度センサ、赤外線センサ、イメージセンサ、回転センサ、角度センサ、角速度センサ、速度センサ、加速度センサ、傾斜センサ、磁気識別センサ、衝撃センサ、温度センサ等、任意のセンサ機能を有するモジュールである。センサ１３２３により検出されたデータは、例えば、アプリケーションプロセッサ１３３１に供給されてアプリケーション等により利用される。
  以上においてモジュールとして説明した構成をプロセッサとして実現するようにしてもよいし、逆にプロセッサとして説明した構成をモジュールとして実現するようにしてもよい。
  以上のような構成のビデオセット１３００において、後述するようにビデオプロセッサ１３３２に本技術を適用することができる。したがって、ビデオセット１３００は、本技術を適用したセットとして実施することができる。
[ビデオプロセッサの構成例]
  図４７は、本技術を適用したビデオプロセッサ１３３２（図４６）の概略的な構成の一例を示している。
  図４７の例の場合、ビデオプロセッサ１３３２は、ビデオ信号およびオーディオ信号の入力を受けてこれらを所定の方式で符号化する機能と、符号化されたビデオデータおよびオーディオデータを復号し、ビデオ信号およびオーディオ信号を再生出力する機能とを有する。
  図４７に示されるように、ビデオプロセッサ１３３２は、ビデオ入力処理部１４０１、第１画像拡大縮小部１４０２、第２画像拡大縮小部１４０３、ビデオ出力処理部１４０４、フレームメモリ１４０５、およびメモリ制御部１４０６を有する。また、ビデオプロセッサ１３３２は、エンコード・デコードエンジン１４０７、ビデオES（Elementary Stream）バッファ１４０８Ａおよび１４０８Ｂ、並びに、オーディオESバッファ１４０９Ａおよび１４０９Ｂを有する。さらに、ビデオプロセッサ１３３２は、オーディオエンコーダ１４１０、オーディオデコーダ１４１１、多重化部（MUX（Multiplexer））１４１２、逆多重化部（DMUX（Demultiplexer））１４１３、およびストリームバッファ１４１４を有する。
  ビデオ入力処理部１４０１は、例えばコネクティビティ１３２１（図４６）等から入力されたビデオ信号を取得し、デジタル画像データに変換する。第１画像拡大縮小部１４０２は、画像データに対してフォーマット変換や画像の拡大縮小処理等を行う。第２画像拡大縮小部１４０３は、画像データに対して、ビデオ出力処理部１４０４を介して出力する先でのフォーマットに応じて画像の拡大縮小処理を行ったり、第１画像拡大縮小部１４０２と同様のフォーマット変換や画像の拡大縮小処理等を行ったりする。ビデオ出力処理部１４０４は、画像データに対して、フォーマット変換やアナログ信号への変換等を行って、再生されたビデオ信号として例えばコネクティビティ１３２１（図４６）等に出力する。
  フレームメモリ１４０５は、ビデオ入力処理部１４０１、第１画像拡大縮小部１４０２、第２画像拡大縮小部１４０３、ビデオ出力処理部１４０４、およびエンコード・デコードエンジン１４０７によって共用される画像データ用のメモリである。フレームメモリ１４０５は、例えばDRAM等の半導体メモリとして実現される。
  メモリ制御部１４０６は、エンコード・デコードエンジン１４０７からの同期信号を受けて、アクセス管理テーブル１４０６Ａに書き込まれたフレームメモリ１４０５へのアクセススケジュールに従ってフレームメモリ１４０５に対する書き込み・読み出しのアクセスを制御する。アクセス管理テーブル１４０６Ａは、エンコード・デコードエンジン１４０７、第１画像拡大縮小部１４０２、第２画像拡大縮小部１４０３等で実行される処理に応じて、メモリ制御部１４０６により更新される。
  エンコード・デコードエンジン１４０７は、画像データのエンコード処理、並びに、画像データが符号化されたデータであるビデオストリームのデコード処理を行う。例えば、エンコード・デコードエンジン１４０７は、フレームメモリ１４０５から読み出した画像データを符号化し、ビデオストリームとしてビデオESバッファ１４０８Ａに順次書き込む。また、例えば、ビデオESバッファ１４０８Ｂからビデオストリームを順次読み出して復号し、画像データとしてフレームメモリ１４０５に順次書き込む。エンコード・デコードエンジン１４０７は、これらの符号化や復号において、フレームメモリ１４０５を作業領域として使用する。また、エンコード・デコードエンジン１４０７は、例えばマクロブロック毎の処理を開始するタイミングで、メモリ制御部１４０６に対して同期信号を出力する。
  ビデオESバッファ１４０８Ａは、エンコード・デコードエンジン１４０７によって生成されたビデオストリームをバッファリングして、多重化部（MUX）１４１２に供給する。ビデオESバッファ１４０８Ｂは、逆多重化部（DMUX）１４１３から供給されたビデオストリームをバッファリングして、エンコード・デコードエンジン１４０７に供給する。
  オーディオESバッファ１４０９Ａは、オーディオエンコーダ１４１０によって生成されたオーディオストリームをバッファリングして、多重化部（MUX）１４１２に供給する。オーディオESバッファ１４０９Ｂは、逆多重化部（DMUX）１４１３から供給されたオーディオストリームをバッファリングして、オーディオデコーダ１４１１に供給する。
  オーディオエンコーダ１４１０は、例えばコネクティビティ１３２１（図４６）等から入力されたオーディオ信号を例えばデジタル変換し、例えばMPEGオーディオ方式やAC3（AudioCode number 3）方式等の所定の方式で符号化する。オーディオエンコーダ１４１０は、オーディオ信号が符号化されたデータであるオーディオストリームをオーディオESバッファ１４０９Ａに順次書き込む。オーディオデコーダ１４１１は、オーディオESバッファ１４０９Ｂから供給されたオーディオストリームを復号し、例えばアナログ信号への変換等を行って、再生されたオーディオ信号として例えばコネクティビティ１３２１（図４６）等に供給する。
  多重化部（MUX）１４１２は、ビデオストリームとオーディオストリームとを多重化する。この多重化の方法（すなわち、多重化により生成されるビットストリームのフォーマット）は任意である。また、この多重化の際に、多重化部（MUX）１４１２は、所定のヘッダ情報等をビットストリームに付加することもできる。つまり、多重化部（MUX）１４１２は、多重化によりストリームのフォーマットを変換することができる。例えば、多重化部（MUX）１４１２は、ビデオストリームとオーディオストリームとを多重化することにより、転送用のフォーマットのビットストリームであるトランスポートストリームに変換する。また、例えば、多重化部（MUX）１４１２は、ビデオストリームとオーディオストリームとを多重化することにより、記録用のファイルフォーマットのデータ（ファイルデータ）に変換する。
  逆多重化部（DMUX）１４１３は、多重化部（MUX）１４１２による多重化に対応する方法で、ビデオストリームとオーディオストリームとが多重化されたビットストリームを逆多重化する。つまり、逆多重化部（DMUX）１４１３は、ストリームバッファ１４１４から読み出されたビットストリームからビデオストリームとオーディオストリームとを抽出する（ビデオストリームとオーディオストリームとを分離する）。つまり、逆多重化部（DMUX）１４１３は、逆多重化によりストリームのフォーマットを変換（多重化部（MUX）１４１２による変換の逆変換）することができる。例えば、逆多重化部（DMUX）１４１３は、例えばコネクティビティ１３２１やブロードバンドモデム１３３３等（いずれも図４６）から供給されたトランスポートストリームを、ストリームバッファ１４１４を介して取得し、逆多重化することにより、ビデオストリームとオーディオストリームとに変換することができる。また、例えば、逆多重化部（DMUX）１４１３は、例えばコネクティビティ１３２１により（図４６）各種記録媒体から読み出されたファイルデータを、ストリームバッファ１４１４を介して取得し、逆多重化することにより、ビデオストリームとオーディオストリームとに変換することができる。
  ストリームバッファ１４１４は、ビットストリームをバッファリングする。例えば、ストリームバッファ１４１４は、多重化部（MUX）１４１２から供給されたトランスポートストリームをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等に供給する。
  また、例えば、ストリームバッファ１４１４は、多重化部（MUX）１４１２から供給されたファイルデータをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、例えばコネクティビティ１３２１（図４６）等に供給し、各種記録媒体に記録させる。
  さらに、ストリームバッファ１４１４は、例えばコネクティビティ１３２１やブロードバンドモデム１３３３等（いずれも図４６）を介して取得したトランスポートストリームをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、逆多重化部（DMUX）１４１３に供給する。
  また、ストリームバッファ１４１４は、例えばコネクティビティ１３２１（図４６）等において各種記録媒体から読み出されたファイルデータをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、逆多重化部（DMUX）１４１３に供給する。
  次に、このような構成のビデオプロセッサ１３３２の動作の例について説明する。例えば、コネクティビティ１３２１（図４６）等からビデオプロセッサ１３３２に入力されたビデオ信号は、ビデオ入力処理部１４０１において４：２：２Ｙ／Ｃｂ／Ｃｒ方式等の所定の方式のデジタル画像データに変換され、フレームメモリ１４０５に順次書き込まれる。このデジタル画像データは、第１画像拡大縮小部１４０２または第２画像拡大縮小部１４０３に読み出されて、４：２：０Ｙ／Ｃｂ／Ｃｒ方式等の所定の方式へのフォーマット変換および拡大縮小処理が行われ、再びフレームメモリ１４０５に書き込まれる。この画像データは、エンコード・デコードエンジン１４０７によって符号化され、ビデオストリームとしてビデオESバッファ１４０８Ａに書き込まれる。
  また、コネクティビティ１３２１（図４６）等からビデオプロセッサ１３３２に入力されたオーディオ信号は、オーディオエンコーダ１４１０によって符号化され、オーディオストリームとして、オーディオESバッファ１４０９Ａに書き込まれる。
  ビデオESバッファ１４０８Ａのビデオストリームと、オーディオESバッファ１４０９Ａのオーディオストリームは、多重化部（MUX）１４１２に読み出されて多重化され、トランスポートストリーム若しくはファイルデータ等に変換される。多重化部（MUX）１４１２により生成されたトランスポートストリームは、ストリームバッファ１４１４にバッファされた後、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等を介して外部ネットワークに出力される。また、多重化部（MUX）１４１２により生成されたファイルデータは、ストリームバッファ１４１４にバッファされた後、例えばコネクティビティ１３２１（図４６）等に出力され、各種記録媒体に記録される。
  また、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等を介して外部ネットワークからビデオプロセッサ１３３２に入力されたトランスポートストリームは、ストリームバッファ１４１４にバッファされた後、逆多重化部（DMUX）１４１３により逆多重化される。また、例えばコネクティビティ１３２１（図４６）等において各種記録媒体から読み出され、ビデオプロセッサ１３３２に入力されたファイルデータは、ストリームバッファ１４１４にバッファされた後、逆多重化部（DMUX）１４１３により逆多重化される。つまり、ビデオプロセッサ１３３２に入力されたトランスポートストリームまたはファイルデータは、逆多重化部（DMUX）１４１３によりビデオストリームとオーディオストリームとに分離される。
  オーディオストリームは、オーディオESバッファ１４０９Ｂを介してオーディオデコーダ１４１１に供給され、復号されてオーディオ信号が再生される。また、ビデオストリームは、ビデオESバッファ１４０８Ｂに書き込まれた後、エンコード・デコードエンジン１４０７により順次読み出されて復号されてフレームメモリ１４０５に書き込まれる。復号された画像データは、第２画像拡大縮小部１４０３によって拡大縮小処理されて、フレームメモリ１４０５に書き込まれる。そして、復号された画像データは、ビデオ出力処理部１４０４に読み出されて、４：２：２Ｙ／Ｃｂ／Ｃｒ方式等の所定の方式にフォーマット変換され、さらにアナログ信号に変換されて、ビデオ信号が再生出力される。
  このように構成されるビデオプロセッサ１３３２に本技術を適用する場合、エンコード・デコードエンジン１４０７に、上述した各実施形態に係る本技術を適用すればよい。つまり、例えば、エンコード・デコードエンジン１４０７が、第１の実施の形態に係るエンコーダ１およびファイル生成部２よりなる符号化装置（図１）やファイル読取部５１およびデコーダ５２よりなる復号装置（図８）の機能を有するようにすればよい。このようにすることにより、ビデオプロセッサ１３３２は、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。
  なお、エンコード・デコードエンジン１４０７において、本技術（すなわち、上述した各実施形態に係る画像符号化装置や画像復号装置の機能）は、論理回路等のハードウエアにより実現するようにしてもよいし、組み込みプログラム等のソフトウエアにより実現するようにしてもよいし、それらの両方により実現するようにしてもよい。
[ビデオプロセッサの他の構成例]
  図４８は、本技術を適用したビデオプロセッサ１３３２（図４６）の概略的な構成の他の例を示している。図４８の例の場合、ビデオプロセッサ１３３２は、ビデオデータを所定の方式で符号化・復号する機能とを有する。
  より具体的には、図４８に示されるように、ビデオプロセッサ１３３２は、制御部１５１１、ディスプレイインタフェース１５１２、ディスプレイエンジン１５１３、画像処理エンジン１５１４、および内部メモリ１５１５を有する。また、ビデオプロセッサ１３３２は、コーデックエンジン１５１６、メモリインタフェース１５１７、多重化・逆多重化部（MUX DMUX）１５１８、ネットワークインタフェース１５１９、およびビデオインタフェース１５２０を有する。
  制御部１５１１は、ディスプレイインタフェース１５１２、ディスプレイエンジン１５１３、画像処理エンジン１５１４、およびコーデックエンジン１５１６等、ビデオプロセッサ１３３２内の各処理部の動作を制御する。
  図４８に示されるように、制御部１５１１は、例えば、メインCPU１５３１、サブCPU１５３２、およびシステムコントローラ１５３３を有する。メインCPU１５３１は、ビデオプロセッサ１３３２内の各処理部の動作を制御するためのプログラム等を実行する。メインCPU１５３１は、そのプログラム等に従って制御信号を生成し、各処理部に供給する（つまり、各処理部の動作を制御する）。サブCPU１５３２は、メインCPU１５３１の補助的な役割を果たす。例えば、サブCPU１５３２は、メインCPU１５３１が実行するプログラム等の子プロセスやサブルーチン等を実行する。システムコントローラ１５３３は、メインCPU１５３１およびサブCPU１５３２が実行するプログラムを指定する等、メインCPU１５３１およびサブCPU１５３２の動作を制御する。
  ディスプレイインタフェース１５１２は、制御部１５１１の制御の下、画像データを例えばコネクティビティ１３２１（図４６）等に出力する。例えば、ディスプレイインタフェース１５１２は、デジタルデータの画像データをアナログ信号に変換し、再生されたビデオ信号として、またはデジタルデータの画像データのまま、コネクティビティ１３２１（図４６）のモニタ装置等に出力する。
  ディスプレイエンジン１５１３は、制御部１５１１の制御の下、画像データに対して、その画像を表示させるモニタ装置等のハードウエアスペックに合わせるように、フォーマット変換、サイズ変換、色域変換等の各種変換処理を行う。
  画像処理エンジン１５１４は、制御部１５１１の制御の下、画像データに対して、例えば画質改善のためのフィルタ処理等、所定の画像処理を施す。
  内部メモリ１５１５は、ディスプレイエンジン１５１３、画像処理エンジン１５１４、およびコーデックエンジン１５１６により共用される、ビデオプロセッサ１３３２の内部に設けられたメモリである。内部メモリ１５１５は、例えば、ディスプレイエンジン１５１３、画像処理エンジン１５１４、およびコーデックエンジン１５１６の間で行われるデータの授受に利用される。例えば、内部メモリ１５１５は、ディスプレイエンジン１５１３、画像処理エンジン１５１４、またはコーデックエンジン１５１６から供給されるデータを格納し、必要に応じて（例えば、要求に応じて）、そのデータを、ディスプレイエンジン１５１３、画像処理エンジン１５１４、またはコーデックエンジン１５１６に供給する。この内部メモリ１５１５は、どのような記憶デバイスにより実現するようにしてもよいが、一般的にブロック単位の画像データやパラメータ等といった小容量のデータの格納に利用することが多いので、例えばSRAM（Static Random Access Memory）のような比較的（例えば外部メモリ１３１２と比較して）小容量だが応答速度が高速な半導体メモリにより実現するのが望ましい。
  コーデックエンジン１５１６は、画像データの符号化や復号に関する処理を行う。このコーデックエンジン１５１６が対応する符号化・復号の方式は任意であり、その数は１つであってもよいし、複数であってもよい。例えば、コーデックエンジン１５１６は、複数の符号化・復号方式のコーデック機能を備え、その中から選択されたもので画像データの符号化若しくは符号化データの復号を行うようにしてもよい。
  図４８に示される例において、コーデックエンジン１５１６は、コーデックに関する処理の機能ブロックとして、例えば、MPEG-2 Video１５４１、AVC/H.264１５４２、HEVC/H.265１５４３、HEVC/H.265(Scalable)１５４４、HEVC/H.265(Multi-view)１５４５、およびMPEG-DASH１５５１を有する。
  MPEG-2 Video１５４１は、画像データをMPEG-2方式で符号化したり復号したりする機能ブロックである。AVC/H.264１５４２は、画像データをAVC方式で符号化したり復号したりする機能ブロックである。HEVC/H.265１５４３は、画像データをHEVC方式で符号化したり復号したりする機能ブロックである。HEVC/H.265(Scalable)１５４４は、画像データをHEVC方式でスケーラブル符号化したりスケーラブル復号したりする機能ブロックである。HEVC/H.265(Multi-view)１５４５は、画像データをHEVC方式で多視点符号化したり多視点復号したりする機能ブロックである。
  MPEG-DASH１５５１は、画像データをMPEG-DASH（MPEG-Dynamic Adaptive Streaming over HTTP）方式で送受信する機能ブロックである。MPEG-DASHは、HTTP（HyperText Transfer Protocol）を使ってビデオのストリーミングを行う技術であり、予め用意された解像度等が互いに異なる複数の符号化データの中から適切なものをセグメント単位で選択し伝送することを特徴の１つとする。MPEG-DASH１５５１は、規格に準拠するストリームの生成やそのストリームの伝送制御等を行い、画像データの符号化・復号については、上述したMPEG-2 Video１５４１乃至HEVC/H.265(Multi-view)１５４５を利用する。
  メモリインタフェース１５１７は、外部メモリ１３１２用のインタフェースである。画像処理エンジン１５１４やコーデックエンジン１５１６から供給されるデータは、メモリインタフェース１５１７を介して外部メモリ１３１２に供給される。また、外部メモリ１３１２から読み出されたデータは、メモリインタフェース１５１７を介してビデオプロセッサ１３３２（画像処理エンジン１５１４若しくはコーデックエンジン１５１６）に供給される。
  多重化・逆多重化部（MUX DMUX）１５１８は、符号化データのビットストリーム、画像データ、ビデオ信号等、画像に関する各種データの多重化や逆多重化を行う。この多重化・逆多重化の方法は任意である。例えば、多重化の際に、多重化・逆多重化部（MUX DMUX）１５１８は、複数のデータを１つにまとめるだけでなく、所定のヘッダ情報等をそのデータに付加することもできる。また、逆多重化の際に、多重化・逆多重化部（MUX DMUX）１５１８は、１つのデータを複数に分割するだけでなく、分割した各データに所定のヘッダ情報等を付加することもできる。つまり、多重化・逆多重化部（MUX DMUX）１５１８は、多重化・逆多重化によりデータのフォーマットを変換することができる。例えば、多重化・逆多重化部（MUX DMUX）１５１８は、ビットストリームを多重化することにより、転送用のフォーマットのビットストリームであるトランスポートストリームや、記録用のファイルフォーマットのデータ（ファイルデータ）に変換することができる。もちろん、逆多重化によりその逆変換も可能である。
  ネットワークインタフェース１５１９は、例えばブロードバンドモデム１３３３やコネクティビティ１３２１（いずれも図４６）等向けのインタフェースである。ビデオインタフェース１５２０は、例えばコネクティビティ１３２１やカメラ１３２２（いずれも図４６）等向けのインタフェースである。
  次に、このようなビデオプロセッサ１３３２の動作の例について説明する。例えば、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等を介して外部ネットワークからトランスポートストリームを受信すると、そのトランスポートストリームは、ネットワークインタフェース１５１９を介して多重化・逆多重化部（MUX DMUX）１５１８に供給されて逆多重化され、コーデックエンジン１５１６により復号される。コーデックエンジン１５１６の復号により得られた画像データは、例えば、画像処理エンジン１５１４により所定の画像処理が施され、ディスプレイエンジン１５１３により所定の変換が行われ、ディスプレイインタフェース１５１２を介して例えばコネクティビティ１３２１（図４６）等に供給され、その画像がモニタに表示される。また、例えば、コーデックエンジン１５１６の復号により得られた画像データは、コーデックエンジン１５１６により再符号化され、多重化・逆多重化部（MUX DMUX）１５１８により多重化されてファイルデータに変換され、ビデオインタフェース１５２０を介して例えばコネクティビティ１３２１（図４６）等に出力され、各種記録媒体に記録される。
  さらに、例えば、コネクティビティ１３２１（図４６）等により図示せぬ記録媒体から読み出された、画像データが符号化された符号化データのファイルデータは、ビデオインタフェース１５２０を介して多重化・逆多重化部（MUX DMUX）１５１８に供給されて逆多重化され、コーデックエンジン１５１６により復号される。コーデックエンジン１５１６の復号により得られた画像データは、画像処理エンジン１５１４により所定の画像処理が施され、ディスプレイエンジン１５１３により所定の変換が行われ、ディスプレイインタフェース１５１２を介して例えばコネクティビティ１３２１（図４６）等に供給され、その画像がモニタに表示される。また、例えば、コーデックエンジン１５１６の復号により得られた画像データは、コーデックエンジン１５１６により再符号化され、多重化・逆多重化部（MUX DMUX）１５１８により多重化されてトランスポートストリームに変換され、ネットワークインタフェース１５１９を介して例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図４６）等に供給され図示せぬ他の装置に伝送される。
  なお、ビデオプロセッサ１３３２内の各処理部の間での画像データやその他のデータの授受は、例えば、内部メモリ１５１５や外部メモリ１３１２を利用して行われる。また、パワーマネージメントモジュール１３１３は、例えば制御部１５１１への電力供給を制御する。
  このように構成されるビデオプロセッサ１３３２に本技術を適用する場合、コーデックエンジン１５１６に、上述した各実施形態に係る本技術を適用すればよい。つまり、例えば、コーデックエンジン１５１６が、第１の実施の形態に係るエンコーダ１およびファイル生成部２よりなる符号化装置(図１)やファイル読取部５１およびデコーダ５２よりなる復号装置（図８）を実現する機能ブロックを有するようにすればよい。このようにすることにより、ビデオプロセッサ１３３２は、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。
  なお、コーデックエンジン１５１６において、本技術（すなわち、上述した各実施形態に係る画像符号化装置や画像復号装置の機能）は、論理回路等のハードウエアにより実現するようにしてもよいし、組み込みプログラム等のソフトウエアにより実現するようにしてもよいし、それらの両方により実現するようにしてもよい。
  以上にビデオプロセッサ１３３２の構成を２例示したが、ビデオプロセッサ１３３２の構成は任意であり、上述した２例以外のものであってもよい。また、このビデオプロセッサ１３３２は、１つの半導体チップとして構成されるようにしてもよいが、複数の半導体チップとして構成されるようにしてもよい。例えば、複数の半導体を積層する３次元積層LSIとしてもよい。また、複数のLSIにより実現されるようにしてもよい。
 [装置への適用例]
  ビデオセット１３００は、画像データを処理する各種装置に組み込むことができる。例えば、ビデオセット１３００は、テレビジョン装置９００（図４２）、携帯電話機９２０（図４３）、記録再生装置９４０（図４４）、撮像装置９６０（図４５）等に組み込むことができる。ビデオセット１３００を組み込むことにより、その装置は、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。
  なお、上述したビデオセット１３００の各構成の一部であっても、ビデオプロセッサ１３３２を含むものであれば、本技術を適用した構成として実施することができる。例えば、ビデオプロセッサ１３３２のみを本技術を適用したビデオプロセッサとして実施することができる。また、例えば、上述したように点線１３４１により示されるプロセッサやビデオモジュール１３１１等を、本技術を適用したプロセッサやモジュール等として実施することができる。さらに、例えば、ビデオモジュール１３１１、外部メモリ１３１２、パワーマネージメントモジュール１３１３、およびフロントエンドモジュール１３１４を組み合わせ、本技術を適用したビデオユニット１３６１として実施することもできる。いずれの構成の場合であっても、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。
  つまり、ビデオプロセッサ１３３２を含むものであればどのような構成であっても、ビデオセット１３００の場合と同様に、画像データを処理する各種装置に組み込むことができる。例えば、ビデオプロセッサ１３３２、点線１３４１により示されるプロセッサ、ビデオモジュール１３１１、または、ビデオユニット１３６１を、テレビジョン装置９００（図４２）、携帯電話機９２０（図４３）、記録再生装置９４０（図４４）、撮像装置９６０（図４５）等に組み込むことができる。そして、本技術を適用したいずれかの構成を組み込むことにより、その装置は、ビデオセット１３００の場合と同様に、図１乃至図３６を参照して上述した効果と同様の効果を得ることができる。
　なお、本明細書では、startcodeとfiller data、デコーダバッファを管理するパラメータ、識別パラメータ、FixedStartCodeSizeFlag等の各種情報が、符号化ストリームに多重化されて、符号化側から復号側へ伝送される例について説明した。しかしながら、これら情報を伝送する手法はかかる例に限定されない。例えば、これら情報は、符号化ビットストリームに多重化されることなく、符号化ビットストリームと関連付けられた別個のデータとして伝送され又は記録されてもよい。ここで、「関連付ける」という用語は、ビットストリームに含まれる画像（スライス若しくはブロックなど、画像の一部であってもよい）と当該画像に対応する情報とを復号時にリンクさせ得るようにすることを意味する。即ち、情報は、画像（又はビットストリーム）とは別の伝送路上で伝送されてもよい。また、情報は、画像（又はビットストリーム）とは別の記録媒体（又は同一の記録媒体の別の記録エリア）に記録されてもよい。さらに、情報と画像（又はビットストリーム）とは、例えば、複数フレーム、１フレーム、又はフレーム内の一部分などの任意の単位で互いに関連付けられてよい。
　以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示はかかる例に限定されない。本開示の属する技術の分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
１　エンコーダ，　２　ファイル生成部，　３１　制御部，　３２　設定部，　３３　ファイル書き出し部，　５１　ファイル読取部，　５２　デコーダ，　７１　ファイル受け取り部，　 ７２　パラメータ取得部，　７３　復号制御部，　７４　データ読み出し部，　２０１　画像符号化装置，　２５１　画像復号装置，　３００　ファイル変換装置，　３１１　ビデオストリーム解析部，　４０１　エンコーダ，　４５１　デコーダ

Claims (15)

  1. 　画像を符号化したビットストリームを含むファイルを対象として、startcodeとfiller dataとを設定する設定部と、
    　前記設定部において設定されたstartcodeとfiller dataとを、ファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、前記設定部を制御する制御部と
    　を備える画像処理装置。
  2. 　前記デコーダバッファを管理するパラメータは、VUI(Video Usability Information)に含まれるパラメータ、またはbuffering period SEI（Supplemental Enhancement Information）に含まれるパラメータ、または、picture timing SEIに含まれるパラメータである
    　請求項１に記載の画像処理装置。
  3. 　前記設定部は、filler dataを、VCLデータとして設定する
    　請求項１に記載の画像処理装置。
  4. 　画像処理装置が、
    　画像を符号化したビットストリームを含むファイルを対象として、startcodeとfiller dataとを設定し、
    　設定されたstartcodeとfiller dataとを、ファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように、startcodeとfiller dataとの設定を制御する
    　画像処理方法。
  5. 　画像を符号化したビットストリームを含み、startcodeとfiller dataとがファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように制御されて設定されているファイルを受け取る受け取り部と、
    　前記受け取り部により受け取られたファイルから、前記startcodeとfiller dataとを読み取り、前記デコーダバッファを管理するパラメータを用いて、前記ビットストリームを復号する復号部と
    　を備える画像処理装置。
  6. 　前記デコーダバッファを管理するパラメータは、VUI(Video Usability Information)に含まれるパラメータ、または、buffering period SEI（Supplemental Enhancement Information）、に含まれるパラメータ、または、picture timing SEIに含まれるパラメータである
    　請求項５に記載の画像処理装置。
  7. 　前記filler dataは、VCLデータとして設定されている
    　請求項５に記載の画像処理装置。
  8. 　画像処理装置が、
    　画像を符号化したビットストリームを含み、startcodeとfiller dataとがファイルのmedia dataにおいて、デコーダバッファを管理するパラメータの特性を保持してファイルを構成するように制御されて設定されているファイルを受け取り、
    　受け取られたファイルから、前記startcodeとfiller dataとを読み取り、前記デコーダバッファを管理するパラメータを用いて、前記ビットストリームを復号する
    　画像処理方法。
  9. 　画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性を設定する設定部と、
    　前記設定部により設定された特性を用いて、前記ファイルを生成する生成部と
    　を備える画像処理装置。
  10. 　前記設定部は、デコーダバッファを管理するパラメータの特性が変更されたことを識別する識別パラメータを設定する
    　請求項９に記載の画像処理装置。
  11. 　前記設定部は、前記識別パラメータを、前記ファイルのサンプルエントリにおけるオプショナルボックスとして設定する
    　請求項１０に記載の画像処理装置。
  12. 　画像処理装置が、
    　画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性を設定し、
    　設定された特性を用いて、前記ファイルを生成する
    　画像処理方法。
  13. 　画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataが削除された場合に、デコーダバッファを管理するパラメータの特性が設定され、設定された特性を用いて生成されているファイルを受け取る受け取り部と、
    　前記受け取り部により受け取られたファイルから、前記デコーダバッファを管理するパラメータを読み取り、読み取ったパラメータを用いて前記ビットストリームを復号する復号部と
    　を備える画像処理装置。
  14. 　前記ファイルには、デコーダバッファを管理するパラメータの特性が変更されたことを識別する識別パラメータが設定されている
    　請求項１３に記載の画像処理装置。
  15. 　画像処理装置が、
    　画像を符号化したビットストリームを含むファイルのmedia dataにおいて、startcodeとfiller dataがビットストリームから削除された場合に、デコーダバッファを管理するパラメータの特性が設定され、設定された特性を用いて生成されているファイルを受け取り、
    　受け取られたファイルから、前記デコーダバッファを管理するパラメータを読み取り、読み取ったパラメータを用いて前記ビットストリームを復号する
    　画像処理方法。
PCT/JP2013/076486 2012-10-09 2013-09-30 画像処理装置および方法 WO2014057832A1 (ja)

Priority Applications (14)

Application Number Priority Date Filing Date Title
JP2014540806A JP6492661B2 (ja) 2012-10-09 2013-09-30 画像処理装置および方法
EP13845300.6A EP2908523B1 (en) 2012-10-09 2013-09-30 Image-processing device and method
MX2015004140A MX340964B (es) 2012-10-09 2013-09-30 Dispositivo y metodo de procesamiento de imagenes.
CN201380051814.1A CN104704823B (zh) 2012-10-09 2013-09-30 图像处理装置和方法
BR112015007530A BR112015007530A2 (pt) 2012-10-09 2013-09-30 dispositivo e método de processamento de imagem
MX2016009728A MX358606B (es) 2012-10-09 2013-09-30 Dispositivo y metodo de procesamiento de imagenes.
US14/432,786 US10313694B2 (en) 2012-10-09 2013-09-30 Image processing device and method
RU2015112109A RU2653308C2 (ru) 2012-10-09 2013-09-30 Устройство и способ обработки изображений
KR1020157007429A KR102134049B1 (ko) 2012-10-09 2013-09-30 화상 처리 장치 및 방법
CA2886943A CA2886943C (en) 2012-10-09 2013-09-30 Image processing device and method
EP19197683.6A EP3618434B1 (en) 2012-10-09 2013-09-30 Image-processing device and method
AU2013327962A AU2013327962A1 (en) 2012-10-09 2013-09-30 Image-processing device and method
AU2017204793A AU2017204793B2 (en) 2012-10-09 2017-07-12 Image-processing device and method
AU2019219782A AU2019219782B2 (en) 2012-10-09 2019-08-21 Image-processing device and method

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
JP2012224597 2012-10-09
JP2012-224597 2012-10-09
JP2012225159 2012-10-10
JP2012-225159 2012-10-10
JP2012-262803 2012-11-30
JP2012262803 2012-11-30
JP2013004988 2013-01-15
JP2013-004988 2013-01-15
JP2013010585 2013-01-23
JP2013-010585 2013-01-23
JP2013-060438 2013-03-22
JP2013060438 2013-03-22

Publications (1)

Publication Number Publication Date
WO2014057832A1 true WO2014057832A1 (ja) 2014-04-17

Family

ID=50477300

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/076486 WO2014057832A1 (ja) 2012-10-09 2013-09-30 画像処理装置および方法

Country Status (13)

Country Link
US (1) US10313694B2 (ja)
EP (2) EP2908523B1 (ja)
JP (2) JP6492661B2 (ja)
KR (1) KR102134049B1 (ja)
CN (1) CN104704823B (ja)
AU (3) AU2013327962A1 (ja)
BR (1) BR112015007530A2 (ja)
CA (1) CA2886943C (ja)
MX (2) MX340964B (ja)
MY (1) MY174138A (ja)
RU (1) RU2653308C2 (ja)
TW (1) TWI652938B (ja)
WO (1) WO2014057832A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015178112A1 (ja) * 2014-05-19 2015-11-26 ソニー株式会社 情報処理装置、情報生成装置、情報記録媒体、および情報処理方法、並びにプログラム
WO2016132836A1 (ja) * 2015-02-16 2016-08-25 ソニー株式会社 情報処理装置、情報記録媒体、および情報処理方法、並びにプログラム

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6329246B2 (ja) * 2014-03-14 2018-05-23 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 画像復号装置
JP6706784B2 (ja) * 2014-09-12 2020-06-10 パナソニックＩｐマネジメント株式会社 送信装置、受信装置、送信方法及び受信方法
KR102299573B1 (ko) * 2014-10-22 2021-09-07 삼성전자주식회사 실시간으로 인-루프 필터링을 수행할 수 있는 애플리케이션 프로세서, 이의 작동 방법, 및 이를 포함하는 시스템
US10257107B1 (en) 2016-06-30 2019-04-09 Amazon Technologies, Inc. Encoder-sensitive stream buffer management
JP7431330B2 (ja) 2019-12-26 2024-02-14 バイトダンス インコーポレイテッド ビデオコーディングにおけるプロファイル、層及びレイヤの指示
CN114868158A (zh) 2019-12-26 2022-08-05 字节跳动有限公司 层级视频中的解码图片缓冲区参数的信令通知
CN117395441A (zh) 2020-01-09 2024-01-12 字节跳动有限公司 视频流中的填充数据单元的处理

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999031888A1 (en) * 1997-12-15 1999-06-24 Matsushita Electric Industrial Co., Ltd. Optical disc and computer-readable storage medium, and recording method and apparatus therefor
JP2004079087A (ja) * 2002-08-20 2004-03-11 Sony Corp 記録装置および方法、記録媒体、並びにプログラム
AU2004214313B2 (en) * 2003-02-18 2010-05-20 Nokia Technologies Oy Picture coding method
WO2005071970A1 (en) * 2004-01-16 2005-08-04 General Instrument Corporation Method and apparatus for determining timing information from a bit stream
US9143788B2 (en) * 2008-11-13 2015-09-22 Thomson Licensing Multiple thread video encoding using HRD information sharing and bit allocation waiting
US9313512B2 (en) * 2009-11-25 2016-04-12 Vudu, Inc. Multiple bit rate encoding by segments
CN101800892B (zh) * 2010-03-04 2013-03-06 青岛海信信芯科技有限公司 多媒体码流识别的方法和装置
CN103907347B (zh) * 2011-08-31 2018-01-30 诺基亚技术有限公司 多视图视频编码和解码
US9648317B2 (en) * 2012-01-30 2017-05-09 Qualcomm Incorporated Method of coding video and storing video content

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
BENJAMIN BROSS; WOO-JIN HAN; JENS-RAINER OHM; GARY J. SULLIVAN; THOMAS WIEGAND: "High efficiency video coding (HEVC) text specification draft 6", JCTVC-H1003 VER20, February 2012 (2012-02-01)
See also references of EP2908523A4
STEPHAN WENGER ET AL.: "Adaptation Parameter Set(APS)", JOINT COLLABORATIVE TEAM ON VIDEO CODING (JCT-VC) OF ITU-T SG16 WP3 AND ISO/IEC JTC1/SC29/WG11 6TH MEETING, 14 July 2011 (2011-07-14) - 22 July 2011 (2011-07-22), TORINO,IT, pages 1 - 10, XP030009770 *
STEPHAN WENGER; JILL BOYCE; YU-WEN HUANG; CHIA-YANG TSAI; PING WU; MING LI: "Adaptation Parameter Set (APS", JCTVC-F747R3, July 2011 (2011-07-01)
YE-KUI WANG: "On NAL unit header", JOINT COLLABORATIVE TEAM ON VIDEO CODING (JCT-VC) OF ITU-T SG16 WP3 AND ISO/IEC JTC1/SC29/WG11 6TH MEETING, 14 July 2011 (2011-07-14) - 22 July 2011 (2011-07-22), TORINO,IT, pages 1 - 6, XP030009486 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015178112A1 (ja) * 2014-05-19 2015-11-26 ソニー株式会社 情報処理装置、情報生成装置、情報記録媒体、および情報処理方法、並びにプログラム
JPWO2015178112A1 (ja) * 2014-05-19 2017-04-20 ソニー株式会社 情報処理装置、情報生成装置、情報記録媒体、および情報処理方法、並びにプログラム
US10535369B2 (en) 2014-05-19 2020-01-14 Sony Corporation Information processing device, information generation device, information recording medium, information processing method, and program
WO2016132836A1 (ja) * 2015-02-16 2016-08-25 ソニー株式会社 情報処理装置、情報記録媒体、および情報処理方法、並びにプログラム
JPWO2016132836A1 (ja) * 2015-02-16 2017-11-24 ソニー株式会社 情報処理装置、情報記録媒体、および情報処理方法、並びにプログラム

Also Published As

Publication number Publication date
AU2017204793B2 (en) 2019-05-23
US20150281713A1 (en) 2015-10-01
EP2908523B1 (en) 2019-09-18
AU2019219782B2 (en) 2021-02-11
CN104704823B (zh) 2019-01-29
CA2886943C (en) 2020-12-15
CA2886943A1 (en) 2014-04-17
RU2653308C2 (ru) 2018-05-07
MX2015004140A (es) 2015-07-06
KR102134049B1 (ko) 2020-07-14
EP3618434A1 (en) 2020-03-04
JP2019110567A (ja) 2019-07-04
AU2013327962A1 (en) 2015-04-02
MX340964B (es) 2016-08-01
JP6721069B2 (ja) 2020-07-08
JP6492661B2 (ja) 2019-04-03
EP2908523A1 (en) 2015-08-19
TW201419872A (zh) 2014-05-16
JPWO2014057832A1 (ja) 2016-09-05
MX358606B (es) 2018-08-24
EP3618434B1 (en) 2021-04-14
EP2908523A4 (en) 2016-09-21
MY174138A (en) 2020-03-10
US10313694B2 (en) 2019-06-04
AU2017204793A1 (en) 2017-07-27
BR112015007530A2 (pt) 2017-07-04
AU2019219782A1 (en) 2019-09-12
KR20150067147A (ko) 2015-06-17
RU2015112109A (ru) 2016-10-20
TWI652938B (zh) 2019-03-01
CN104704823A (zh) 2015-06-10

Similar Documents

Publication Publication Date Title
JP6721069B2 (ja) 画像処理装置および方法
US10779009B2 (en) Image decoding device and method
US20150010059A1 (en) Image processing device and method
US10893279B2 (en) Decoding apparatus and decoding method, and coding apparatus and coding method
JP6646883B2 (ja) 画像符号化装置および方法、並びに、プログラム
KR102197557B1 (ko) 화상 처리 장치 및 방법
JP6150134B2 (ja) 画像符号化装置および方法、画像復号装置および方法、プログラム、並びに記録媒体
JP6402802B2 (ja) 画像処理装置および方法、プログラム、並びに記録媒体
WO2014002618A1 (ja) 画像復号装置、画像復号方法、画像符号化装置及び画像符号化方法

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014540806

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20157007429

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: MX/A/2015/004140

Country of ref document: MX

ENP Entry into the national phase

Ref document number: 2886943

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 14432786

Country of ref document: US

Ref document number: 2013845300

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2013327962

Country of ref document: AU

Date of ref document: 20130930

Kind code of ref document: A

Ref document number: 2015112109

Country of ref document: RU

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: IDP00201501977

Country of ref document: ID

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112015007530

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112015007530

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20150402