WO2004100545A1 - 情報処理装置及び方法，並びにプログラム及び記録媒体 - Google Patents

情報処理装置及び方法，並びにプログラム及び記録媒体 Download PDF

Info

Publication number
WO2004100545A1
WO2004100545A1 PCT/JP2004/005782 JP2004005782W WO2004100545A1 WO 2004100545 A1 WO2004100545 A1 WO 2004100545A1 JP 2004005782 W JP2004005782 W JP 2004005782W WO 2004100545 A1 WO2004100545 A1 WO 2004100545A1
Authority
WO
WIPO (PCT)
Prior art keywords
picture
stream
video
time
buffer
Prior art date
Application number
PCT/JP2004/005782
Other languages
English (en)
French (fr)
Inventor
Motoki Kato
Original Assignee
Sony Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation filed Critical Sony Corporation
Priority to EP04728909.5A priority Critical patent/EP1515553B1/en
Priority to US10/520,488 priority patent/US8086087B2/en
Publication of WO2004100545A1 publication Critical patent/WO2004100545A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305—Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23424—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/439—Processing of audio elementary streams
    • H04N21/4392—Processing of audio elementary streams involving audio buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H04N5/92—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback

Definitions

  • the present invention edits a multiplexed stream of a video stream and an audio stream with video frame accuracy, and reproduces editing points continuously (seamlessly).
  • FIG. 1 is a block diagram showing a conventional DVR-STD model (DVR MPEG2 transport stream player model) (hereinafter referred to as a player) 101.
  • DVR-STD is a conceptual model for modeling the decoding processing in the generation and verification of shea one Seamless two connected Tsu 1) 13 116 111 referenced ⁇ string Ichimu I Nyo.
  • player 1 0 In 1 the reading unit (DVRdrive) 1 1 1 or et bitrate R UD in read TS (Transport Stream) file, buffers the re one Dobaffa 1 1 2
  • the source packet is read from the read buffer 1 1 2 to the source depacketizer 1 1 3 Read at the rate R MAX .
  • the pulse generator (27 MHz X-1) 114 generates a 27 MHz pulse.
  • Arrival time clock counter (Arrival time clock counter) 115 is a binary counter that counts the pulses of the frequency of 27 MHz.
  • the source depacketizer 113 generates an Arrival time clock at time t (i). Provides the count value of the counter Arrival— time— clock (i).
  • One source packet has one transport packet and its Ume-stamp.
  • the current source When the ar rival—time—stamp of the packet is equal to the value of the least significant bit (LSB) of the arrival—time_clock (i) 30 bits, the source depacketizer section 113 sends the transformer. Port packets are output.
  • TS_recording_rate is the bit rate of the transport stream (hereinafter referred to as TS).
  • TS bit rate of the transport stream
  • T-STD transport stream system target decoder specified in ISO / IEC 13818-1 of (MPEG2 Systems standard).
  • the decoding process when playing one DVR MPEG2 TS will be described.
  • the timing for outputting a transport packet from the output unit 110 and inputting it to the TB1, TBn, or TBsys buffer of the DVR-STD, which is the decoder 120 is Arriva time of the source packet, determined by the time stamp.
  • the specification of buffering operation of TB1, MB1, EB1, TBn, Bn, TBsys and TBsys is the same as T-STD specified in IS0 / IEC 13818-1.
  • the specification of decryption operation and display operation is also the same as T-STD specified in IS0 / IEC 13818-1.
  • the time axis of TS2's initial time base is not the same as the time axis of TS1's arrival time base.
  • the time axis of the system time base of TS2 is not the same as the time axis of the system time base of TS1.
  • Video display must be seamless and continuous.
  • the presentation time of the audio presentation unit may overlap.
  • the time until time T1 is determined by the arrival timing of the source packet of TS1 at the timing of input to the buffer of TB1, TBn or TBsys of the DVR-STD.
  • TS_recording-rate (TSl) (the maximum bit rate of TS1).
  • TS_recording-rate (TSl) is a value of TS_recording-rate defined in CI iplnfo 0 corresponding to CI ip 1.
  • the time when the last byte of TS1 enters the buffer is time T2. Therefore, in the section from time T 1 ′ to T 2, arrival-Ume_stamp of the source packet is ignored.
  • T 1 Is the number of bytes of the transport packet of TS1 following the last video packet of TS1, and the time from time T1 to T2 2—T 1 is the time required for a byte to finish inputting at a bit rate of TS—recording—rate (TSl), and is calculated as in equation (1) below. From time T1 to ⁇ 2, the values of Rxn and Rxsys shown in FIG. 1 both change to the value of TS_recording rate (TSl). Buffering operations other than this rule are T-STD and Is the same.
  • the audio decoder can process the input data in the section from time T1 to T2, that is, between time T1 and T2, the values of Rxn and Rxsys shown in FIG. Since TS_recording changes to the value of one rate (TS1), an additional buffer amount (data amount of about 1 second) is required in addition to the buffer amount defined in T-STD.
  • the arrival time clock counter 1 15 is reset to the value of arrival-time-s mp of the first source packet of TS2.
  • the input timing to the TB1 TBn or TBsys buffer of the DVR-STD is determined by the arrival—time_sta instant of the source packet of TS2. Both Rxn and Rxsys change to the values defined in T-STD.
  • the presentation of the video presentation unit must be continuous without gaps through the connection points.
  • STC2 TS2 system time base time axis (Accurately, STC2 is the first PC of TS2
  • the offset value between S1 and STC2 is determined as follows.
  • PTS nd PT S on STC1 corresponding to the last video presentation unit of TS1
  • PTS2start PTS on STC2 corresponding to the first video presentation unit of TS2
  • Tpp Display period of the last video presentation unit
  • the system time clock may overlap between times T2 and T5.
  • the DVR-STD switches the system time clock from the old time base value (STC1) to the new time base value (STC2).
  • STC2 can be calculated as in the following equation (3).
  • the following describes the encoding conditions that must be satisfied by TS1 and TS2 when moving from TS1 to the next TS2 that is seamlessly connected to TS1.
  • STC vid.cend The value of the STC on the system time base STC1 when the last byte of the last video packet of TS1 arrives at the DVR-STD TBI.
  • STC2 1 video_end STC1 1 vide. in terms of the value of the _e n d to the value on the system time base Ichisu STC2 value
  • the arrival timing of the first video packet of TS2 at the TBI is determined by the following inequality
  • the size of this buffer capacity is based on the following factors. That is, in MPEG2TS, audio data synchronized with video data at a certain byte position can exist at a multiplexed phase difference within a predetermined range, and the maximum value of the multiplexed phase difference is 1 This is equivalent to the amount of data for seconds. Therefore, the maximum value of N1 in the above equation (1) corresponds to a maximum of one second of audio data. Between time T1 and T2 Since the source packet of N1 data at the maximum bit rate of TS is input to the audio buffer, ignoring time_s mp of the received packet and the time_s mp, T- In addition to the buffer amount defined in the STD, an additional buffer amount (about one second of data) was required.
  • the audio data for one second is 24bitSampleX960000 samples / secX. 8 channels: Approximately 18 Mbits, an additional buffer of about 3 Mbytes is required, and when handling such multi-channel audio data, there is a problem that this additional buffer becomes extremely large. .
  • DISCLOSURE OF THE INVENTION The present invention has been proposed in view of such a conventional situation, and seamlessly decodes two multiplexed streams in which an audio stream and a video stream are multiplexed in a seamless manner.
  • an information processing apparatus comprises a data string in units of a source packet having a transport packet and its corresponding time stamp, and In an information processing apparatus for decoding a multiplexed stream connected so that a second picture, which is the first picture of the second multiplexed stream, is continuously reproduced from a first picture, which is the last picture, The software according to the arrival time stamp of the multiplexed stream.
  • An output means for outputting a packet, a video buffer for buffering video data among the source packets, an audio buffer for buffering audio data among the source packets, and a buffer for the video buffer 7.
  • Video decoding means for decoding the ringed video data; and audio decoding means for decoding audio data buffered in the audio buffer, wherein the audio buffer converts the second picture into the video data. It has a capacity to buffer audio data for the time required for input to the buffer.
  • the size of the audio buffer is set to a capacity capable of buffering audio data for a time required for inputting the second picture to the video buffer, and the first picture is Even between the time when input to the video buffer ends and the time when input of the last source packet of the first multiplexed stream ends, the original time stamp of the source packet of the multiplexed stream (arriva and time_immediate)
  • the source packet is input to the buffer according to, so that it was necessary to input the source stream at the maximum bit rate of the transport stream (TS), ignoring the source packet's arrival_time_stainp. Eliminates the need for an additional buffer of one second, and adds the last stream of the first multiplex stream.
  • the first decoded picture of the second multiplexed stream can be input to the video buffer by its decoding timing.
  • the required capacity of the audio buffer is EBnjnax (bits), the bit amount of the second picture is Ijnax (bits), and the input bit rate to the video buffer is Rv (bps).
  • the bit rate of data is Ra (bps)
  • EBn_max (I_max / v) X Ra can be satisfied
  • the maximum value of the bit amount of the second picture for example, I picture Is Ijnax
  • the audio buffer capacity is (I_max / Rv) X Ra.
  • the audio buffer has a capacity capable of buffering audio data for 100 milliseconds, so that, for example, the data amount of MPEG-2 I picture is normally transmitted in one second. Less than 10% of data volume Therefore, if the audio buffer is set to the same size and the audio data of that size is postponed, the I picture can be input to the video buffer by the decoding timing. Data encoding restrictions are reduced. That is, by setting the audio buffer to have the above-mentioned capacity, the multiplexed stream can be multiplexed so that the input of the audio data ends 100 ms earlier than the timing at which the audio data is reproduced.
  • the multiplexed stream satisfies STC2 2 start > STC2 1 end In accordance with DVR—STD It can be.
  • the first source packet of the second multiplexed stream is output from the output means after a predetermined time ATC-delta has elapsed.
  • the predetermined time ATC_del is determined so as to satisfy the value of the time difference STC_delta, and the multiplexed stream is multiplexed so as to satisfy the value of the time difference STC_delta. This allows flexibility in the input timing of the first source packet of the second multiplexed stream and facilitates encoding of the second multiplexed stream. .
  • the value of the predetermined time ATC-delta can be managed as additional information of the first multiplexed stream.
  • the information processing method comprises a data string in units of a source packet having a transport packet and its arrival time stamp, and includes a first picture as a last picture of the first multiplexed stream.
  • the information processing method for decoding a multiplexed stream connected so that a second picture, which is the first picture of the second multiplexed stream, is continuously reproduced, the above-described arrival time of the multiplexed stream An output step of outputting the source bucket according to the stamp; a buffering step of buffering video data of the source packets in a video buffer and buffering audio data in an audio buffer 7; Video buffered in the audio buffer and A decoding step of decoding audio data, and in the buffering step, audio data for a time required for inputting the second picture to the video buffer is stored in the video buffer. It is characterized in that buffering is performed in the audio buffer 7 before buffering in the buffer.
  • a program according to the present invention causes a computer to execute the above-described information processing, and a recording medium according to the present invention stores such a program and is readable by a computer.
  • Another recording medium is a recording medium on which a multiplexed stream composed of a data stream in units of a source packet having a transport packet and an arrival time stamp thereof is recorded.
  • the multiplexed stream is connected so that the first picture, which is the last picture of the first multiplexed stream, is successively played with the second picture, which is the first picture of the second multiplexed stream,
  • the first and second multiplexing streams can be input to a decoder based on respective arrival timestamps, and the second picture is input to a decoder
  • the audio data for the time required to input the second picture to the decoder is multiplexed so that the input can be completed before the input of the second picture to the decoder starts. Since the streams are multiplexed, such a multiplexed stream has an audio buffer with a capacity capable of buffering audio data for the time required for inputting the second picture to the video buffer. After decoding by the decoder, after the last transport packet of the first multiplexed stream is input, the first decoded picture of the second multiplexed stream is input to the video buffer by the decoding timing. be able to.
  • Another information processing apparatus comprises a data string in units of a source packet having a transport bucket and its corresponding time stamp, and is read and decoded by a decoder based on the corresponding time stamp.
  • a first video coded stream that ends display at a first picture is generated, and display is started from a second picture that is displayed following the first picture.
  • Video encoding means for generating a second video encoding stream to be encoded, and multiplexing the first video encoded stream with an audio encoded stream synchronized with the first video encoding stream. To generate a first multiplexed stream, and the second video coding stream and the second video coding stream.
  • a second multiplexing stream is generated by multiplexing with the audio coding stream synchronized with the frame, and the second picture is added to the first picture, which is the last picture of the first multiplexed stream.
  • Audio data for a time required for inputting a second picture to the decoder is multiplexed so that input can be completed before inputting of the second picture to the decoder is started. .
  • the input of the second picture to the decoder is started, and the input of the second picture to the decoder is started for audio data for a time required, for example, 100 milliseconds.
  • the decoder In order to perform multiplexing so that input can be completed beforehand, the decoder must forward the audio data to the audio buffer and allow enough time to transmit the second picture, such as an I-picture, by the decoding timing. Multiplex stream can be easily encoded.
  • Another information processing method comprises a data string in units of a source packet having a transport packet and an equivalent time stamp, and is read and decoded by a decoder based on the equivalent time stamp.
  • a first video coded stream ending display at a first picture is generated, and display is started from a second picture displayed following the first picture.
  • the second multiplexed stream is generated by multiplexing the audio coded stream synchronized with the video stream, and the second picture is added to the first picture, which is the last picture of the first multiplexed stream.
  • FIG. 1 is a block diagram showing a conventional information processing apparatus.
  • FIG. 2 is a schematic diagram showing the relationship between the preceding Playltem and the current Playltem when using Bridge-Clip.
  • FIG. 3 is a schematic diagram showing the relationship between the preceding Playltem and the current Playltem when Bridge-Clip is not used.
  • Fig. 4 is a schematic diagram showing an example of seamless connection between Clipl and Clip2 as video streams in the picture display order (Presen Uon order).
  • Fig. 5 is a schematic diagram showing the data stream in each AV stream that achieves seamless connection using BridgeSeauence, which is the first method when the display video streams (ipl and Clip2) are connected seamlessly in Fig. 4. It is.
  • Fig. 6 is a schematic diagram showing the data stream of each AV stream that realizes seamless connection without using BridgeSetiuence, which is the second method, when the video streams (Clipl and Clip2) shown in Fig. 4 are connected seamlessly. is there.
  • FIG. 7 is a diagram for explaining the overlap of the display of audio, and is a schematic diagram showing a presentation unit of video and a presentation unit of audio in TS1 and TS2.
  • FIG. 8 is a block diagram showing the information processing device according to the embodiment of the present invention.
  • Fig. 9 is a timing chart of input, decoding, and display of transport packets when moving from one AV stream (TS1) to the next AV stream (TS2) that is seamlessly connected to it.
  • Figure 10 shows another example of input, decoding, and display of transport packets when moving from one AV stream (TS1) to the next AV stream (TS2) that is seamlessly connected to it. It is.
  • Figure 11 shows another example of transport packet input, decoding and display when moving from one AV stream (TS1) to the next AV stream (TS2) that is seamlessly connected to it. It is.
  • FIG. 12 is a diagram showing a data format of the additional information ClipInfoO for storing ATC_delta.
  • FIG. 13 is a schematic diagram showing the additional information ClipInfoO when there are a plurality of next AV streams (TS2) connected to a certain AV stream (TS1).
  • Fig. 14 shows the case of the conventional DVR-STD.
  • the audio buffer size is 4kBy tes
  • FIG. 7 is a graph showing an example of a change in the bit occupancy of a buffer.
  • FIG. 15 is a diagram for explaining the effect of the embodiment of the present invention.
  • the audio buffer size is 8 kBytes
  • the transition from TS1 to the next TS2 seamlessly connected to TS1 is performed.
  • FIG. 9 is a graph showing an example of a change in bit occupancy of a video buffer and an audio buffer of DVR-STD.
  • BEST MODE FOR CARRYING OUT THE INVENTION will be described in detail with reference to the drawings.
  • the present invention is applied to an information processing apparatus that seamlessly and continuously reproduces two AV streams in which a video stream and an audio stream are multiplexed.
  • the DVR-STD the DVR-STD
  • Clip indicates a multiplexed stream of a video stream and an audio stream.
  • the Play List indicates a set of playback sections in the Clip.
  • One playback section in a Clip is called Playltem, which is represented by a pair of IN point and OUT point on the time axis. Therefore, a PlayList is a collection of Playltems.
  • Playing seamlessly between Playltems means that the playback device (player) can display (play) audio video data recorded on the disc without causing pauses or gaps in the playback output of the decoder. It is.
  • the structure of two seamlessly connected Playltems will be described. Whether the connection between the previous Playltem and the current Playltem is guaranteed to be seamlessly displayed depends on the connection conditions defined in the current Playltem. You can judge from the field.
  • the seamless connection between Playltems includes a method using Bridge-Clip (BridgeSeauence) (hereinafter referred to as the first method) and a method not using it (hereinafter referred to as the second method).
  • FIG. 2 is a schematic diagram showing the relationship between the preceding Playltem PI1 and the current Playltem PI2 when Bridge-Clip is used as the first method.
  • the stream data read out by the player when Bridge-Clip is used is shaded.
  • the transport stream (TS) is composed of an integer number of Aligned units.
  • the size of the Aligned unit is 6144 bytes (2048 x 3 bytes).
  • One Aligned unit consists of 32 source packets and starts from the first byte of the source packet.
  • Each source packet is 192 bytes long.
  • One source packet consists of a TP_extra_header and a transport packet.
  • TP_extra_lieader is 4 bytes long, and a transport packet is 188 bytes long.
  • the TP—extra—header has a copy—pr emission—indicator and an arrival—time—s tamp, and the copy—p remission—indicator is an integer that indicates the copy limit of the transport packet payload.
  • arrival_time_stamp (ATS) is a time stamp indicating the time at which the corresponding transport packet arrives at the decoder in the AV stream.
  • the time axis created based on the arriva of each source packet constituting the AV stream based on the time stamp is called the arrival time base, and its clock is ATC.
  • TS1 (first multiplexed stream) shown in Fig. 2 is a stream stream showing D1 with the shadow of Clipl (Clip AV stream) and SPlarriva of Bridge-Clip, and the shadow before timejiscon tinuity.
  • Stream data D2 shown in FIG. SPN_arrival_time — discontinuity indicates the address of the source packet where there is a discontinuity in the arrival time base in the Bridge-Clip AV stream file.
  • the stream data D 1 shown with the shadow of Clipl included in TS 1 is From the address of the stream needed to decode the presentation unit corresponding to IN-time of PI ay It em (indicated by IN-time 1 in Figure 2), refer to SPN-exi from- previous_Clip Stream data up to the source packet to be transmitted.
  • stream data D 2 shown with a shadow before SPN—arrival—time—discontinuity of the Bridge-Clip included in TS1 is referred to by SPN_arriva and tinie_discontiiiuity from the first source packet of the Bridge-Clip. It is the stream data up to the source packet just before the source packet.
  • the TS2 (second multiplex stream) shown in Fig. 2 is a stream stream D4 shown with the shadow of Clip2 (Clip AV stream) and SPN_arrival-time of Bridge-Clip. It consists of stream data D 3 shown with a shadow after discontinuity.
  • the stream D3 which is indicated by the shadow after the SPN_arriva time-discontinuity of the Bridge-Clip included in TS2, is the last source of the Bridge-Clip from the source packet referenced by the SPN_arrival-tiine_discontinuity. This is a short walk to the bucket.
  • stream data D4 indicated by adding a shadow of Clip2 included in TS2 is obtained from the source packet referenced by SPN_enter—current—Clip from 0UT_time of the current Playltem (OUT—time in FIG. 2). This is indicated by 2.)
  • FIG. 3 is a schematic diagram showing the relationship between the preceding Playltem PI1 and the current Playltem PI2 when Bridge-Clip, which is the second method, is not used.
  • the stream data read out by the player is shaded.
  • TS1 (first multiplexed stream) shown in FIG. 3 is composed of stream data D5 shown with a shadow of Clipl (Clip AV stream).
  • Stream data D5 shown with the shadow of Clipl included in TS1 is necessary to decode the presentation unit corresponding to IN-time (shown as IN time 1 in Fig. 3) of the preceding Playltem. It starts with the address of the best stream and ends with the last source packet of Clip 1.
  • TS2 (second multiplexed stream) shown in FIG. 3 is composed of stream data D6 shown with a shadow of Clip2 (Clip AV stream).
  • the stream data D6 shown with the shadow of Clip2 included in TS2 starts from the first source packet source of Clip2, and corresponds to the present Playltem's 0UT_time (indicated by OUT-time2 in Fig. 3). This is a stream stream up to the stream address required to decrypt one unit.
  • TS1 and TS2 are continuous streams of source packets. Next, TS1 and TS2 stream specifications and connection conditions between them will be described.
  • TS1 and TS2 are obtained by multiplexing a video stream and an audio stream.
  • the limitation of the video bit stream in the encoding restriction for seamless connection will be described first.
  • FIG. 4 is a schematic diagram showing an example of seamless connection between Clipl and Clip2 as a video stream in a picture display order.
  • an art-point-side program which is a program temporally ahead of the out-point picture, which is the skip reproduction start point
  • an in-point picture which is a point at which skip reproduction is reached
  • the video stream In order to seamlessly connect the in-point side program, which is the program on the rear side in time, the video stream must be re-encoded in the decoding device.
  • the GOP (group of pictures), which is a unit of a group of pictures according to the MPEG2 standard, includes at least one I (Intra) picture (reference picture) in which the picture is coded without predictive coding from other pictures.
  • I Intra
  • P predict iv
  • B bi-directionally pictures, which are bi-directionally predicted coded images obtained by coding the images using coding.
  • each number of Clipl and Clip2 indicates the display order
  • I, P, B or i, p, b indicates the type of each picture.
  • Fig. 5 shows an example of seamless connection using the first method, BridgeSeauence, when seamlessly connecting video streams (Clipl and Clip2) as shown in Fig. 4.
  • the video stream of the Bridge-CI ip before the SPN—arrival—time one discontinuity consists of the coded video stream up to the picture corresponding to 0UT_Umel of Clipl shown in Fig. 4. Then, the video stream is connected to the preceding Clipl video stream, and is re-encoded so that one continuous elementary stream conforms to the MPEG2 standard.
  • the video stream of Bridge-Clip after SPN_arrival_time-discontinuity is composed of an encoded video stream after the picture corresponding to IN_time 2 of CI ip 2 in FIG.
  • the video stream can start decoding correctly, is connected to the subsequent Clip2 video stream, and is re-encoded so as to become an elementary stream according to the MPEG2 standard in one continuous stream.
  • In order to create a Bridge-Clip generally, several pictures must be re-encoded, and the other pictures can be copied from the original Clip.
  • FIG. 5 shows the Clipl shown in Fig. 4 in the decoding order, and the player changes the source packet number (SPN_exit_from_previous_Clip) of P5 of the preceding Clipl to the Bridge-Clip shown in (b).
  • D2 shown in Fig. 2 of Bridge-CI ip that is, the stream data on the OUT-timel side of Clipl corresponding to the video data before SPN-arrival-time-discontinuity in the BridgeSeduence
  • the data dl up to and including B4 consist of the data directly copied from Clipl, and subsequent data P7 and B6 originally consist of B6 and B7 of the original Clipl.
  • the image data is returned to the image data that has not been processed, and then encoded again to obtain data d2 that is P7 and B6.
  • D3 shown in Fig. 2 of Bridge-Clip that is, the video data after time_discontinuity after SPN-arrival in BridgeSeauence.
  • b4, p5, p8, b6, and b7 of the original Clip2 are image data that has not been decoded by compressing the CI ip2 once and compressed.
  • FIG. 6 shows an example of realizing a seamless connection without using BridgeSeauence, which is the second method, when seamlessly connecting video streams (Clipl and Clip2) as shown in FIG.
  • Clipl and Clip2 show pictures in their decoding order.
  • BridgeSeauence is not used, as in the case of using BridgeSeauence shown in Fig. 5, streams near the connection point (connection point) are not decoded and compressed once. And then re-decoded to the optimal picture type. That is, Clipl's video stream consists of an encoded video stream up to the picture corresponding to OUTLUmel in Fig. 4, and it is an original video stream that follows the MPEG2 standard in one continuous stream.
  • B6 and B7 of the Clipl are re-encoded data (P7, B6) d5.
  • the video stream of Clip2 consists of the coded video stream after the picture corresponding to IN_time2 of Clip2 in Fig. 4, and it is a continuous elementary stream in accordance with the MPEG2 standard.
  • b4, p5, p8, b6, and b7 of the original Clip2 are re-encoded as de-even (i0, pi, 4, b2, b3) d6.
  • FIG. 7 is a diagram for explaining the overlap of the audio display, and is a schematic diagram showing the video presentation units VPU1 and VPU2 and the audio presentation units ⁇ and APU2 in TS1 and TS2.
  • the last audio frame A_end of the audio stream of TS1 includes an audio sample having a display time equal to the display end time (OUT-time) of the last display picture of TS1.
  • the first audio frame A starU of the audio stream of TS2 or the display start of the first display picture of TS2 (IN _time2) contains an audio sample with a display time equal to
  • Lap (Audio over lap) occurs.
  • the TS at the connection point is a DVR MPEG2TS according to a DVR-STD (Digital Video Recording-System Target Decoder) described later.
  • DVR-STD is a conceptual model for modeling the decoding process when generating and verifying an AV stream referenced by two seamlessly connected yltems.
  • Figure 8 shows the DVR-STD model (DVR MPEG2 transport stream player mode 1).
  • the information processing apparatus (DVR MPEG2 transport stream player model, hereinafter referred to as a player) 1 is composed of transport packets (TS) from TSs connected to be seamlessly reproduced. It comprises an output unit 10 for reading and outputting the data, and a decoder (DVR-STD) 20 for decoding the transport packet from the output unit 10. As will be described later, this decoder 20 is obtained by changing the input timing of the transport packet and the capacity of the audio buffer in the conventional DVR-STD described above.
  • the output unit 10 the TS file read from the read unit (DVRdrive) 11 at the read rate R UD is buffered in the read buffer 12, and the source packets (Source packets) are read from the read buffer 12.
  • R MAX is the bit rate of the source packet stream.
  • the pulse generator (27 MHz X-tal) 14 generates a 27 MHz pulse.
  • Arrival time clock counter (Arrival time clock counter) 15 is a binary counter that counts the pulses of the frequency of 27 MHz.
  • the source depacketizer section 13 counts the Arrival time clock counter at time t (i). Supplies the value Arriva one time one clock one clock (i).
  • one source packet has one transport packet and its arrival time_stamp.
  • Arrival time—stamp of the current source packet
  • TS recording_rate is the bit rate of the TS.
  • n, TBn, MBn, EBn, TBsys, Bsys, Rxn, Rbxn, Rxsys, Dn, Dsys, On and Pn (k) shown in Fig. 8 is IS0 / IEC13818-1 (MPEG2 Systems standard).
  • n Index number of the elementary stream
  • MBn Multiplex buffer for elementary stream n (exists only for video stream)
  • TBsys Input buffer for system information of the program being decrypted
  • Bsys Main buffer in the system target decoder for system information of the program being decoded
  • Rxn Transmission rate at which data is stripped from TBn
  • Rbxn Transmission rate at which PES packet packets are stripped from MBn (only present for video streams)
  • Rxsys Transmission rate at which data is removed from TBsys
  • Dsys Decoder for system information of the program being decrypted
  • the timing at which transport packets are input to the TB1, TBn or TBsys buffer is determined by the arrival_time_st a of the source packet.
  • the specification of the buffering operation of TB1, MB1, EB1, TBn, Bn, TBsys and TBsys is the same as T-STD specified in IS 0 / IEC 13818-1.
  • the specification of decoding operation and display operation is also the same as T-STD specified in IS0 / IEC 13818-1.
  • Fig. 9 is a timing chart of input, decoding, and display of a transport packet when moving from one AV stream (TS1) to the next AV stream (TS2) that is seamlessly connected to it. is there.
  • TS1 is the preceding stream
  • TS2 is the current stream.
  • Each packet divided by TS1 and TS2 represents source packets SP1 and SP2 of TS1 and TS2.
  • the time axis of the TS2's initial time base (indicated by ATC2 in Figure 9) Is not the same as the time axis of TS1's arrival time base (indicated by ATC1 in Figure 9). Also, the time axis of the system time base of TS2 (indicated by STC2 in FIG. 9) is not the same as the time axis of the system time base of TS1 (indicated by STC1 in FIG. 9).
  • Video display is required to be seamless and continuous. The display time of the audio presentation unit may overlap.
  • the audio buffer is made to have an optimum capacity by changing the following two points with respect to the player 101 described in Japanese Patent Application Publication No. 2002-1585894.
  • the first change is that when moving from one AV stream (TS1) to the next AV stream (TS2) that is seamlessly connected to it, the decoder 20 up to the last packet of TS1 is transferred.
  • the input is determined by the arrival_l; ime_stamp of those source packets.
  • the arrival_Ume_stamp is ignored from the time T1 when the last video packet of TS1 ends to be input to the TBI until the time T2 when the last bit of TS1 is completely input to the TBI.
  • the input of the source packet between T1 and T2 is performed at time T1
  • the source packet of TS1 is determined according to & 1 "1: 31_1: 11116-513 ⁇ .
  • the maximum bit rate of TS is ignored, ignoring the arrival-time_stamp of the conventional source packet.
  • additional buffers of one second which is required to enter in R MAX becomes unnecessary.
  • the input of the decoder 20, TB1, TBn or TBsys to the buffer of the TS1 is performed by the source packet of the TS1. Determined by the time_stamp of the SP1 arriva.
  • the timing at which the remaining packets of TS1 are input to the decoder 20 is also determined by Ume_stamp of the source packet SP1 of TS1.
  • the time when the last byte of TS1 enters the buffer is time T2.
  • the initial time clock counter 15 is reset to the value immediately after arrival_time_sta of the first source packet of TS2.
  • the input timing to the buffer of TB1, TBn or TBsys of the decoder 20 is determined by the arrival_time stamp of the source packet SP2 of TS2.
  • the input timing to the decoder 20 is such that the input timing to the TB1, TBn or TBsys buffer of the decoder 20 is the source packet SP1 of the TS1 until the time T2 when the last byte of the TS1 is input to the buffer.
  • the time_sta is determined by the time_sta immediately, and the time after T 2 is determined by the arrival-time-stamp of the source bucket SP2 of the TS2.
  • connection point As shown in FIG. 2 or FIG. (Points) without gaps. That is,
  • the last video data of TS1 (first picture) is added to the first video data of TS2 (first picture).
  • STC1 Time axis of the system time base of TS1 (shown as STC1 in Figure 9)
  • STC2 The time axis of the system time base of TS2 (shown as STC2 in Figure 9).
  • STC2 starts from the time when the first PCR ((Program Clock Refarence)) of TS2 is input to T-STD.
  • the offset between STC1 and STC2 is determined as follows. That is, PTS nd: PTS on STC1 corresponding to the last video presentation unit of TS1
  • PTS2start PTS on STC2 corresponding to the first video presentation unit of TS2
  • T PP Display period of the last video presentation unit of TS1
  • the offset value SK_delta between the two system time bases is calculated as in the following equation (6).
  • the process performed by the player for controlling the system time clock of the decoder 20 when moving from TS1 to the next TS2 seamlessly connected to TS1 will be described.
  • the last audio presentation unit of TS1 is displayed.
  • the system time clock may overlap between times T2 and T5.
  • the decoder 20 switches the system time clock from the old time base value (STC1) to the new time base value (STC2).
  • the value of ST C2 can be calculated as in the following equation (7).
  • STCPend The value of the STC on the system time base STC1 when the last byte of the last packet of TS1 arrives at the decoder 20
  • TS2 of the first of the first byte is the system time base Ichisu STC2 on the STC value at the time of arrival to the decoder 2 0 of Baketsuto
  • FIG. 10 is another example of a timing chart of input, decoding, and display of a transport packet when moving from a certain AV stream (TS1) to the next AV stream (TS2) seamlessly connected to it.
  • the input to the decoder 20 up to the last packet of TS1 is determined by arriving and time_stainp of those source buckets in the same manner, but with one difference from the evening timing chart shown in FIG. Therefore, as shown in FIG. 10, a predetermined time interval (deltal: between times T2 and T2 ') is set so that it is not necessary to input the first packet of TS2 immediately after the last packet of TS1.
  • This makes it possible to determine the input timing of the first packet of TS2 more flexibly than in the case of FIG. 9, and thus has an effect of facilitating the encoding of TS2.
  • the input timing to the buffer of TB1, TBn or TBsys of decoder 20 is the source packet of TS1 SP1 arrival—determined by time_stamp.
  • arrival time clock counter 15 is reset to the value of arrival_time_stamp of the first source bucket of TS 2.
  • Decoder 20 input to TB1, TBn or TBsys buffer The arrival is determined by the arrival-time-stamp of the source packet SP2 of TS2.
  • STC2 2 s tart and STC2 nd above must satisfy the following relational expression (1 0).
  • FIG. 11 shows the transport when moving from one AV stream (TS1) to the next AV stream (TS2) that is seamlessly connected to it.
  • 9 is another example of a timing chart for inputting, decoding, and displaying a packet.
  • the input to the decoder 20 up to the last packet of TS1 is determined by the arriving of those source packets and time_sta immediately, but the difference from the evening timing chart shown in FIG. 10 is one point.
  • a predetermined time interval (ATC_delta: between times T2 and T2 ') is provided. This makes it possible to determine the input timing of the first packet of TS2 more flexibly than in the case of FIG. 9, and thus has an effect of facilitating the encoding of TS2.
  • the input timing of ⁇ 1, ⁇ of the decoder 20 or the buffer of TBsys is the source packet SP1 of the TS1. Arrival_time_stanip.
  • Time T 2 ′ is the time at which the first packet of TS 2 is input to decoder 20.
  • ATC_delta is an offset time from the arrival time stamp (time on the ATCl) of the last bucket of TS1 to the time T2 'projected on the ATCl.
  • arrival time clock counter 15 is reset to the value of arrival time stamp of the first source packet of TS 2.
  • Decoder 2 The input timing of 0 to the buffer of TB1, TBn or TBsys is determined by the time_stamp of the source packet SP2 of TS2.
  • ATC-delta is determined so as to satisfy STC_delta in the above equation (6).
  • ATC_delta is managed as additional information of the stream data.
  • the value of ATC-delta is managed as information attached to TS1.
  • Fig. 12 shows the data format of the additional information ClipInioO for storing ATC_delta.
  • a flag indicating whether or not is-ATC-dell ⁇ , CI iplnfo 0 has the value of ATC_delta. Multiple values can be registered in Cliplnio 0. This is to allow a plurality of TS2s to be connected to TS1 as shown in FIG. If the is_ATC_delta flag is 1, number_o ATC-delta_entries indicates the number of ATC-deltas registered in this CI iplnfo0.
  • following-Clip-Infomation-file-name is the name of the stream of TS2 connected to TSl.
  • Clip Iniomation_file If there is more than one TS2 corresponding to one name, the value of ATC_delta for each TS2 is registered in Cliplnfo 0.
  • ClipInioO contains the above-mentioned AT C-delta information, and ATC_delta is obtained by the DVR-STD model controller (not shown in FIG. 8) in a predetermined manner in switching between TS1 and TS2 as described above. Will be treated.
  • the size of the audio buffer of the decoder 20 is changed to a size large enough to satisfy the following condition.
  • This condition means that when moving from TS1 to the next TS2 that is seamlessly connected to this, after the last transport packet of TS1 is input, the first decoded picture (I picture) of TS2 is decoded. It is possible to input to the video buffer by evening.
  • the maximum required audio buffer capacity is as follows: Value. In other words, it is a size that can store the amount of audio data having a length corresponding to "the time during which the maximum bit amount of an I picture can be input to the video buffer before its decoding timing".
  • the maximum required amount of audio buffer EBnjnax can be calculated by the following equation (11).
  • EBn_max (I_max / Rv) * Ra [bits] ⁇ ⁇ ⁇ (1 1)
  • max is the maximum bit amount of the I picture, and this is the size of the video code buffer EB1 shown in Fig. 8.
  • Size. Rv is the input bit rate to the video code buffer EB1.
  • I is the bit rate of the audio stream.
  • the size of the audio buffer to be obtained, EBn-max is determined by changing the buffer occupancy of the video code buffer EB1 from zero at the input bit rate to the video elementary stream buffer (EB1). It is the value obtained by multiplying the time required to reach I_max (Lmax / Rv) by Ra.
  • the bit size of the I picture is generally 10% or less of the encoding bit rate. For example, if the coding pit rate is 10 Mbps, the size of the I picture is usually less than or equal to I Mbits.
  • the I-picture can be input to the video buffer of the decoder 20 by its decode timing.
  • the audio buffer of the decoder 20 can store 100 milliseconds of audio data
  • the audio data can be stored 100 millimeters faster than the evening when it is reproduced.
  • TS 1 can be multiplexed so that the input to the audio buffer is completed as early as seconds. Therefore, assuming that the audio buffer has a buffer size capable of storing at least 100 milliseconds of audio data, for the first and second reasons, transfer from TS1 to the next TS2 that is seamlessly connected to it.
  • the first decoded picture of TS2 At least 100 milliseconds can be secured as the time until the input of the character (I picture) to the video buffer (code timing of the I picture).
  • the following specifically calculates the capacity of the audio buffer that can store audio data for 100 milliseconds.
  • the size of the audio buffer of the DVR-STD is changed by inputting the first decoded picture (I picture) of TS2 to the video buffer by the decoding timing.
  • the effect of changing to “a size that can store the amount of audio data corresponding to the available time” will be described in further detail with reference to FIGS. 14 and 15.
  • FIG. 14 and 15 The effect of changing to “a size that can store the amount of audio data corresponding to the available time” will be described in further detail with reference to FIGS. 14 and 15.
  • the audio stream is an AC3 audio stream with a bit rate of 640 kbps and a sampling frequency of 48 kHz. Since the number of samples in one audio frame of the AC3 audio stream is 1,536 samples, the time length is 32 milliseconds. The byte size of one audio frame is 2560 Bytes.
  • FIG. 7 is a graph showing an example of a change in bit occupancy of a video buffer and an audio buffer of the DVR-STD of FIG.
  • the buffer transition of the video / audio data of TS1 is indicated by a broken line
  • the buffer transition of the video / audio data of TS2 is indicated by a solid line.
  • the 4 kBytes audio buffer stores 50 milliseconds of audio data overnight. Therefore, the time when the last byte of the last audio packet of TS 1 arrives at DVR-STD In TS1, TS1 can be multiplexed so that the input of audio data at the end of the playback is terminated 50 ms earlier. However, 50 milliseconds is not enough to input the first decoded picture (I-picture) of TS2 to the video buffer before its decoding timing. For this reason, encoding is restricted so that the size of the picture (I picture) decoded first in TS2 is reduced, and there is a problem that the image quality is deteriorated.
  • the amount of time that can be advanced is 50 ms, so the time required to input the first I picture of TS2 to the video buffer is shown in Fig. 14.
  • the start-up delay (t1) is small, up to 50 ms. Therefore, the time for inputting the first I picture of TS2 cannot be taken long enough, and the I picture size S1 becomes small, encoding is restricted, and the picture quality of the I picture deteriorates.
  • an additional buffer of about 1 second is provided in addition to 4 kBytes, and the maximum rate of TS is between T1 and T2. I had to type in RMAX.
  • the AC3 audio stream with a bit rate of 640 kbps is described. Becomes extremely large.
  • the audio buffer size of the DVR-STD is changed to, for example, 8 kBytes as in the decoder 20 in the present embodiment.
  • (A) and (b) in Fig. 15 show an example of optimizing the capacity of the audio buffer.
  • the audio buffer size is 8 kBytes
  • the next connection from TS1 to this is seamless.
  • FIG. 8 is a graph showing an example of a change in the bit occupancy of the video buffer and the audio buffer of the DVR-STD according to the present embodiment when shifting to TS2 of FIG.
  • the transition of the video / audio data buffer of TS1 is indicated by a broken line
  • the transition of the video Z audio data of TS2 is indicated by a solid line.
  • the 8 kBytes audio buffer can store 100 milliseconds of audio data. Therefore, the last byte of the last audio packet of TS1 is DVR-ST
  • TS1 is multiplexed so that the input of the audio data ends 100 ms earlier than the timing at which it is played. Wear. At least 100 ms, first decoded picture of TS2
  • I picture can be input to the video buffer before the decoding timing. That is, the time for inputting the first I picture of TS2 (startup delay) t2 can be sufficient, so that the first decoded picture (I picture) size S2 of TS2 can be increased, Therefore, the I-picture encoding restrictions are small and high picture quality can be achieved.
  • the data is composed of a data string in units of a source packet having a transport packet and its corresponding time stamp, and is read and decoded by a decoder based on the corresponding time stamp.
  • the generated TS can be generated and recorded in the multiplexing device (information processing device).
  • the multiplexing device generates a re-encoded Clipl (first video encoded stream) so as to end the display at a predetermined picture, as described with reference to FIGS. 4 to 6 above, for example.
  • a video encoding unit that generates a Cl ip2 (second video encoded stream) that is displayed following this picture and that is re-encoded so that display can be started;
  • a multiplexing unit that multiplexes the coded stream to generate TS1, multiplexes Cl ip2 and an audio coding stream synchronized with the Cl ip2 to generate TS2, and a multiplexing unit including TS1 and TS2.
  • a recording unit for recording the encrypted stream.
  • the input of the I picture, which is the second picture, to the video buffer of the decoder 20 is started by inputting audio data for the time required for the I picture to the decoder 20. Multiplex so that input can be completed before.
  • the coding unit may generate the Bridge-Clip and the multiplexing unit may also multiplex the Bridge-Clip.
  • the recording medium on which the multiplexed stream generated by such a multiplexing device is recorded includes a TS 1 that ends the display with the first picture and a second picture that is reproduced following the first picture.
  • the first picture of TS2, which is generated from the display start TS2 can be input to the decoder 20 based on the respective competition time stamps, and the first picture of the second picture TS2 is input to the decoder.
  • the time it takes to A multiplexed stream is recorded in which the audio data of the minutes is multiplexed so that the input can be completed before the input of the second picture to the decoder 20 is started.
  • the TS 1 and the TS 2 are transmitted after the last video packet of the TS 1 has been input to the TB I of the decoder 20. Even before the rest of the packets enter the decoder 20, the transport packets are entered according to the arrival time stamp, and the size of the audio buffer is reduced from 4 kBytes in the conventional DVR-STD to I picture.
  • the last bucket of TS 1 is input Is the time (start-up delay) for inputting the I picture, which is the first picture of TS2, up to its decoding timing. It is possible to correspondingly ensure, comb small the coding constraints of the I-picture can be a high quality.
  • the capacity of the audio buffer is changed as described above, and the transport packets are input in accordance with the arrival time stamp. It is possible to eliminate the need for a special buffer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Television Signal Processing For Recording (AREA)
  • Television Systems (AREA)

Abstract

　プレーヤモデル（１）は、シームレスに接続されたTS1及びTS2から、トランスポートパケット及びアライバルタイムスタンプを有するソースパケットを読み出し、そのアライバルタイムスタンプに従ってトランスポートパケットを出力する出力部（１０）と、トランスポートパケットをデコードするデコーダ（２０）とから構成される。出力部（１０）は、ソースパケットのアライバルタイムスタンプに従ってトランスポートパケットをデコーダ（２０）に入力するものとし、デコーダ（２０）は、そのオーディオバッファTBnを、TS2の最初のピクチャであるＩピクチャをビデオバッファTB1に入力するために要する時間分のオーディオデータをバッファリング可能な容量とする。

Description

明細書 情報処理装置及び方法、 並びにプログラム及び記録媒体 技術分野 本発明は、 ビデオストリームとオーディオストリームとの多重化ストリ一ムを ビデオフレーム精度で編集して、 編集点を連続的 （シームレス） に再生するため の情報処理装置、 その方法、 プログラム及び記録媒体、 並びにシームレス再生に 最適な形式で多重化ストリームを生成する情報処理装置及びその多重化されたス トリ一ムデ一夕が記録された記録媒体に関する。
本出願は、 日本国において 2 0 0 3年 5月 8日に出願された日本特許出願番号 2 0 0 3 - 1 3 0 6 6 1を基礎として優先権を主張するものであり、 この出願は 参照することにより、 本出願に援用される。 背景技術 ビデオストリ一ムとオーディォストリームの多重化ストリ一ムをビデオフレー ム精度で編集して、 編集点をシームレスに再生するための方法が例えば日本公開 特許公報 2 0 0 0— 1 7 5 1 5 2号、 日本公開特許公報 2 0 0 1— 5 44 1 1 8 号、 日本公開特許公報 2 0 0 2— 1 5 8 9 7 4号に記載されている。
図 1は、 従来の D VR— S TDモデル （DVR MPEG2 transport stream player model) (以下、 プレーヤという。 ） 1 0 1を示すブロック図である。 DVR- STDは、 シ一ムレス接続された 2っの1)13 116111にょって参照される ¥ストリ一ムの生成 及び検証の際におけるデコード処理をモデル化するための概念モデルである。
図 1に示すように、 プレーヤ 1 0 1においては、 読出部 （DVRdrive) 1 1 1か らビットレート RUDで読み出された T S (トランスポートストリーム） ファイルは， リ一ドバッファ 1 1 2にバッファリングされ、 このリードバッファ 1 1 2からソ —スパケットがソースデパケッ夕ィザ部 （source depacket izer) 1 1 3へ最大ビ ットレート RMAXで読み出される。
パルス発振器 （27MHz X- 1) 1 14は、 2 7 MH zのパルスを発生する。 ァラ ィバルクロックカウンタ （Arrival time clock counter) 1 1 5は、 この 2 7M Hzの周波数のパルスをカウントするバイナリカウンタであり、 ソースデパケッ タイザ部 1 1 3に、 時刻 t ( i ) における Arrival t ime clock counterのカウン ト値 Arrival— time— clock (i)を供給する。
1つのソースパケットは、 1つのトランスポートパケットとそれの arrivaし U me— s t ampを持つ。 現在のソ一スノヽ。ケッ卜の ar rival— t ime— stampが arrival— t ime_c lock(i)の L S B (least significant Bit :最下位ビット） 30ビットの値と等 しいとき、 ソースデパケッタイザ部 1 1 3からそのトランスポートパケットが出 力される。 TS_recording_rateは、 トランスポ一トストリ一ム （以下、 TSとい う。 ） のビットレートである。 また、 図 1 2に示す n、 TBn、 MBn、 EBn、 TBsys, B sys、 Rxn、 Rbxn、 Rxsys、 Dn、 Dsys、 On及び Pn (k)の表記方法は、 ISO/IEC13818-1
(MPEG2 Systems規格） の T- STD (ISO/IEC 13818- 1で規定される transport stre am system target decoder) に定義されているものと同.じである。
次に、 このような従来のプレーヤ 1 0 1におけるデコーディングプロセスにつ いて説明する。 先ず、 1つの DVR MPEG2 TSを再生しているときのデコーディング プロセスを説明する。 単一の DVR MPEG2 TSを再生している間は、 出力部 1 1 0か らトランスポートパケットを出力してデコーダ 1 20である DVR-STDの TB1、 TBn又 は TBsysのバッファへ入力するタイミングは、 ソースパケットの arrivaし time— st ampにより決定される。 TB1、 MB1、 EB1、 TBn, Bn、 TBsys及び TBsysのバッファリン グ動作の規定は、 IS0/IEC 13818- 1に規定されている T-STDと同じである。 復号動 作と表示動作の規定もまた、 IS0/IEC 13818-1に規定されている T-STDと同じであ る。
次に、 シ一ムレス接続された Playltemを再生している間のデコ一ディングプロ セスについて説明する。 ここでは、 シームレス接続された Playltemによって参照 される先行するストリ一ム TS1と、 現在のストリーム TS2との再生について説明を する。
ある AVストリーム （TS1) からそれにシームレスに接続された次の AVストリ ーム （TS2) へと移る間には、 TS2のァライパルタイムベースの時間軸は、 TS1のァ ライバルタイムベースの時間軸と同じ時間軸でない。 また、 TS2のシステムタイム ベースの時間軸は、 TS1のシステムタイムベースの時間軸と同じ時間軸でない。 ビ デォの表示は、 シームレスに連続していることが要求される。 オーディオのプレ ゼンテ一ションュニットの表示時間にはオーバラップがあってもよい。
次に、 ソースデパケッタイザ部から読み出される卜ランスポートバケツトの DV R - STDへの入力夕イミングについて説明する。
( 1 ) TS1の最後のビデオパケットが DVR- STDの TBIに入力終了する時刻 T 1まで の時間
時刻 T 1までの時間は、 DVR-STDの TB1、 TBn又は TBsysのバッファへの入力タイ ミングは、 TS1のソースパケットの arrival— time_s tampによって決定される。
(2) 時刻 T 1から TS1の残りのパケットの最後のバイトが入力終了する時刻 T 2まで
TS1の残りのパケットは、 TS— recording_rate (TSl) のビットレート （TS1の最 大ビットレート） で DVR-STDの TBn又は TBsysのバッファへ入力されなければならな い。 ここで、 TS_recording— rate (TSl) は、 CI ip 1に対応する CI iplnfo 0におい て定義される TS_recording— rateの値である。 TS1の最後のバイトがバッファへ入 力する時刻は、 時刻 T 2である。 したがって、 時刻 T 1'から T 2までの区間では、 ソースパケットの arrival一 Ume_s tampは無視される。
を TS1の最後のビデオパケットに続く TS1のトランスポートパケットのバイト 数とすると、 時刻 T 1から T 2までの時間
Figure imgf000005_0001
2— T 1は、 バイトが TS —recording— rate (TSl) のビットレートで入力終了するために必要な時間であり、 下記式 （1) のように計算される。
Figure imgf000005_0002
時刻 T 1から Τ 2までの間は、 図 1に示す Rxnと Rxsysの値は共に TS_recording rate (TSl) の値に変化する。 このルール以外のバッファリング動作は、 T- STDと 同じである。
オーディオデコーダは、 時刻 T 1から T 2までの区間の入力データを処理する ことができるように、 即ち、 時刻 T 1から T 2までの間は、 図 1に示す Rxnと Rxs ysの値が共に TS_recording一 rate (TS1) の値に変化するため、 T- STDで定義される バッファ量に加えて付加的なバッファ量 （約 1秒分のデータ量） が必要である。
( 3) 時刻 T 2以後
T 2の時刻において、 ァライバルタイムクロックカウンタ 1 1 5は、 TS2の最初 のソースパケットの arrival—time— s mpの値にリセットされる。 DVR- STDの TB1 TBn又は TBsysのパッファへの入力夕イミングは、 TS2のソースパケットの arrival — time_sta即によって決定される。 Rxnと Rxsysはともに、 T-STDにおいて定義され ている値に変化する。
次に、 ビデオのプレゼンテ一ション夕イミングについて説明する。 ビデオプレ ゼンテーションュニッ卜の表示は、 接続点 (コネクションボイン卜） を通してギ ャップなしに連続でなければならない。
STC (System Time Clock) 1 ： TS1のシステムタイムベースの時間軸
STC2： TS2のシステムタイムべ一スの時間軸 （正確には、 STC2は、 TS2の最初の PC
R (Program Clock Refarence) が T- STDに入力した時刻から開始する。 ） とする。
S 1と STC2との間のオフセット値は、 次のように決定される。
PTS nd： TS1の最後のビデオプレゼンテーションュニットに対応する STC1上の PT S
PTS2start ： TS2の最初のビデオプレゼンテ一ションュニッ卜に対応する STC2上の PTS
Tpp：最後のビデオプレゼンテ一ションュニッ卜の表示期間
とすると、 2つのシステムタイムベースの間のオフセット値 STC_deltaは、 下記式 (2) のように計算される。 STC_delta = PTSlend + TPp-PTS2s tar t · · · ( 2 ) 次に、 オーディオのプレゼンテーションタイミングについて説明する。 TS1と T S2との接続点において、 オーディオプレゼンテーションュニットの表示夕イミン グのオーバラップがあってもよく、 それは 0から 2オーディオフレーム未満であ る。 プレーヤ 1 0 1には、 どちらのォ一ディオサンプルを選択するかということ と、 オーディオプレゼンテーションュニットの表示を接続点の後の補正された夕 ィムベースに再同期する制御が要求される。
TS1からそれにシームレスに接続された次の TS2へと移るとき、 DVR-STDのシステ ムタイムクロックの制御について、 プレーヤ 1 0 1が行う処理を説明する。 TS1の 最後のォ一ディオプレゼンテーションュニットが表示される時刻 T 5において、 システムタイムクロックは、 時刻 T 2から T 5の間にオーバ一ラップしていても よい。 この区間では、 DVR- STDは、 システムタイムクロックを古いタイムベースの 値 （STC1) から新しいタイムべ一スの値 （STC2) の値に切り替える。 STC2の値は、 下記式 （3 ) のように計算できる。
STC2 = STCl-STC_delta · · · ( 3)
TSlから、 これにシームレスに接続された次の TS2へと移るとき、 TS1及び TS2が 満たさなければいけない符号化条件を説明する。
STC vid.cend： TS1の最後のビデオパケットの最後のバイトが DVR-STDの TBIへ到 着するときのシステムタイムベース STC1上の STCの値
STC22vi deo.start ： TS2の最初のビデオパケットの最初のバイトが DVR- STDの TB 1へ 到着するときのシステムタイムベース STC2上の STCの値
STC21video_end： STC 11 v i d e。_e n dの値をシステムタイムべ一ス STC2上の値に換算し た値
とした場合、
Figure imgf000007_0001
dは、 下記式 （4) のようにして計算される。 STC21 v i d e o.e n d = STCl1 v i d e o.e n d-STC_delta · · · (4) ここで、 デコーダ 1 2 0が DVR-STDに従うために、 次の 2つの条件を満たすこと が要求される。
(条件 1)
TS2の最初のビデオパケットの TBIへの到着タイミングは、 次に示す不等式
(5) を満たさなければならない。 irLZ2 v i d e o_s t a r t/>STC21 v i d e o_e n d+ l 2 - 1 · · · 、5) この上記不等式 （5) を満たすように、 CUpl及び/又は Clip2の部分的なス トリ一ムを再エンコード及び 又は再多重化することが必要になる。
(条件 2)
STC1と STC2とを同じ時間軸上に換算したシステムタイムベースの時間軸上にお いて、 TS1からのビデオパケットの入力とそれに続く TS2からのビデオパケットの 入力は、 ビデオバッファをオーバフロー及びアンダフ口一させてはならない。
しかしながら、 上述したように、 D VR— S TDモデルを使用した従来のプレ —ャ 1 0 1においては、 時刻 T 1から T 2までの区間の入力データを処理するこ とができるように、 即ち、 時刻 T 1から T 2までの間は、 TS1の残りのパケットは、 TS_recording_rate (TS1) のビットレート （TS1の最大ビットレート） で DVR- STD の TBn又は TBsysのバッファへ入力されていたため、 T- STDで定義されるバッファに 加えて、 約 1秒分のデ一夕をバッファリング可能な容量の付加的なバッファが必 要である。
このバッファ容量の大きさは、 次の要因に基づく。 即ち、 MPEG2TSの中において、 あるバイト位置にあるビデオデータに同期再生されるオーディオデータが、 所定 範囲内の多重化位相差を離れて存在することができ、 この多重化位相差の最大値 が 1秒分のデータ量に相当する。 したがって、 上記式 （1) の N 1の最大値は、 最大 1秒分のオーディオデータに相当する。 時刻 T 1から T 2までの間は、 ソー スパケットの arrivaし time_s mpを無視して、 TSの最大ビットレートで N 1のデ 一夕量のソースパケットが、 オーディオバッファに入力されるので、 このデータ 量をバッファリングするために、 T-STDで定義されるバッファ量に加えて付加的な バッファ量 （約 1秒分のデ一夕量） が必要になっていた。
この付加的なバッファの大きさを具体的に計算すると次のようになる。 即ち、 例えば 640 kbpsのドルビー AC 3方式により符号化されたオーディォストリ一 ムの場合、 1秒分のオーディオデータは、 640 kbits= 80 kBytesとなり、 80 kBytesの付加的なバッファが必要となる。
また、 Linear PCM方式により符号化されたオーディオストリームであって、 2 4 bi tSample, 96 kHz sampling f reauency, 8cha匿 Isの場合、 1秒分のオーデ ィォデータは、 24bitSampleX 9 6 00 0 samples/sec X 8 channels:約 1 8M bitsとなり、 約 3 Mbytesの付加的なバッファが必要となり、 このようなマルチチ ャンネルのオーディォデ一夕を扱う場合、 この付加的なバッファが極めて大きく なってしまうという問題点がある。 発明の開示 本発明は、 このような従来の実情に鑑みて提案されたものであり、 オーディオ ストリ一ムとビデオストリームとが多重化された 2つの多重化ストリームをシ一 ムレスに連続して復号するために、 最適な容量のオーディォバッファとした情報 処理装置、 その方法、 プログラム及び記録媒体、 並びにこのようなオーディオバ ッファ容量に対応した多重化ストリームを生成する情報処理装置及びその方法、 並びにその多重化ストリ一ムが記録された記録媒体を提供することを目的とする。 上述した目的を達成するために、 本発明に係る情報処理装置は、 トランスポー トパケットとそのァライパルタイムスタンプとを有するソースパケットを単位と するデータ列からなり、 第 1の多重化ストリームの最後のピクチャである第 1の ピクチャに第 2の多重化ストリームの最初のピクチャである第 2のピクチャが連 続して再生されるよう接続された多重化ストリームを復号する情報処理装置にお いて、 上記多重化ストリ一ムの上記ァライバルタイムスタンプに従って上記ソ一 スパケットを出力する出力手段と、 上記ソースバケツトのうちビデオデ一夕をバ ッファリングするビデオバッファと、 上記ソースパケットのうちオーディオデ一 夕をバッファリングするオーディォバッファと、 上記ビデオバッフ 7にバッファ リングされたビデオデ一夕を復号するビデオ復号手段と、 上記オーディオバッフ ァにバッファリングされたオーディォデータを復号するオーディォ復号手段とを 有し、 上記オーディオバッファは、 上記第 2のピクチャを上記ビデオバッファに 入力するために要する時間分のオーディオデータをバッファリング可能な容量を 有することを特徴とする。
本発明においては、 オーディオバッファのサイズを、 上記第 2のピクチャを上 記ビデオバッファに入力するために要する時間分のオーディォデータをバッファ リング可能な容量とするとともに、 上記第 1のピクチャが上記ビデオバッファに 入力終了する時刻から第 1の多重化ストリームの最後のソースパケットを入力終 了する時刻までの間においても、 多重化ストリームのソースパケットのァライパ ルタイムスタンプ （arr ivaし t ime_s ta即） に従ってソースパケットをバッファに 入力するようにしたので、 従来ソースパケットの arr ivaし t ime_s t ainpを無視して、 トランスポートストリーム （TS) の最大ビットレートで入力するために必要とさ れていた 1秒分の付加的なバッファを不要とするとともに、 第 1の多重化ストリ —ムの最後のトランスポートバケツトを入力した後に、 第 2の多重化ストリーム の最初にデコ一ドされるピクチャをそのデコードタイミングまでにビデオバッフ ァへ入力することができる。
また、 上記オーディオバッファの必要な容量を EBnjnax (b i ts) とし、 上記第 2 のピクチャのビット量を Ijnax (b i t s) とし、 上記ビデオバッファへの入力ビット レ一トを Rv (bps) とし、 オーディオデ一夕のビットレートを Ra (bps) としたと き、 EBn_max= ( I_max/ v) X Raを満たすものとすることができ、 第 2のピクチ ャとなる例えば I ピクチャのビット量の最大値を Ijnaxとした場合、 オーディオバ ッファの容量は、
Figure imgf000010_0001
( I_max/Rv) X Raとすることができる。
更に、 上記オーディオバッファは、 1 0 0ミリ秒分のオーディオデータをバッ ファリング可能な容量を有することが好ましく、 これにより、 例えば MPEG2の I ピ クチャのデータ量は、 通常 1秒間で伝送されるデータ量の 1 0 %以下の大きさで あるため、 オーディオバッファをこれと同じ大きさの容量としておき、 その大き さ分のオーディオデータを先送りしておくことで、 I ピクチャをそのデコード夕 ィミングまでにビデオパッファへ入力することができ、 ビデオデータのェンコ一 ド制限が少なくなる。 即ち、 オーディオバッファを上記容量とすることで、 ォー ディォデータをそれが再生されるタイミングよりも 1 0 0ミリ秒だけ早く入力終 了するように多重化ストリームを多重化することができる。
更にまた、 上記第 1の多重化ストリ一ムの時間軸における上記第 1のピクチャ の表示終了時刻と上記第 2の多重化ストリームの時間軸における上記第 2のピク チヤの表示開始時刻との時間差を STC_dell:aとし、 上記第 1の多重化ストリームの 最後のソースパケットの最後のバイトが上記出力手段から出力される該第 1の多 重化ストリームの時間軸上の値 STC endを上記時間差 STC— deltaにより上記第 2の 多重化ストリ一ムの時間軸上の値に換算した値を STCZiend ( = STCl1enc.-STC_de lta) とし、 上記第 2の多重化ストリームの最初のソースパケットの最初のバイト が上記出力手段から出力される該第 2の多重化ストリームの時間軸上の値を STC2 2 s tartとしたとき、 上記多重化ストリームは、 STC22 s t a r t>STC21 endを満たすも のとすることにより、 D VR— S TDに従ったものとすることができる。
更にまた、 上記第 1の多重化ストリームの最後のソースパケットが上記出力手 段から出力された後、 所定時間 del talの経過後、 上記第 2の多重化ストリームの 最初のソースパケットを上記出力手段から出力するものとし、 STC22 s t a r t>STC2 ^nd + deltalを満たすものとしてもよく、 これにより、 第 2の多重化ストリーム の最初のソースパケッ卜の入力夕イミングに柔軟性を持たせ、 第 2の多重化スト リームの符号化を容易にすることができる。
更にまた、 上記第 1の多重化ストリ一ムの時間軸における上記第 1のピクチャ の表示終了時刻と上記第 2の多重化ストリームの時間軸における上記第 2のピク チヤの表示開始時刻との時間差を STC_deltaとし、 上記第 1の多重化ストリームの 最後のソースバケツトの出力を開始した後、 所定時間 ATC— deltaの経過後に上記第 2の多重化ストリームの最初のソースパケットを上記出力手段から出力するもの とし、 上記所定時間 ATC_del を、 上記時間差 STC_deltaの値を満たすように決定 し、 上記多重化ストリームは、 上記時間差 STC_deltaの値を満たすように多重化さ れたものとしてもよく、 これにより、 第 2の多重化ストリームの最初のソースパ ケッ卜の入力タイミングに柔軟性を持たせ、 第 2の多重化ス卜リームの符号化を 容易にすることができる。
このとき、 上記所定時間 ATC一 de l taの値は、 上記第 1の多重化ストリームの付属 情報として管理することができる。
本発明に係る情報処理方法は、 トランスポートパケットとそのァライバルタイ ムスタンプとを有するソースパケットを単位とするデータ列からなり、 第 1の多 重化ストリームの最後のピクチャである第 1のピクチャに第 2の多重化ストリ一 ムの最初のピクチャである第 2のピクチャが連続して再生されるよう接続された 多重化ストリームを復号する情報処理方法において、 上記多重化ストリームの上 記ァライバルタイムスタンプに従って上記ソースバケツトを出力する出力工程と、 上記ソースパケットのうちビデオデータをビデオバッファにバッファリングし、 オーディォデ一夕をオーディォバッフ 7にバッファリングするバッファリングェ 程と、 上記ビデオバッファ及びオーディォバッファにバッファリングされたビデ ォデ一夕及びオーディォデ一夕を復号する復号工程とを有し、 上記バッフアリン グ工程では、 上記第 2のピクチャを上記ビデオバッファに入力するために要する 時間分のオーディォデータを、 上記第 2のピクチャを上記ビデオバッファにバッ ファリングする前に上記オーディォバッフ 7にバッファリングすることを特徴と する。
また、 本発明に係るプログラムは、 上述した情報処理をコンピュータに実行さ せるものであり、 本発明に係る記録媒体は、 そのようなプログラムが記録された コンピュータ読取可能なものである。
本発明に係る他の記録媒体は、 トランスポートパケットとそのァライバルタイ ムスタンプとを有するソースパケットを単位とするデ一夕列からなる多重化スト リームが記録された記録媒体であって、 上記多重化ストリームは、 第 1の多重化 ストリ一ムの最後のピクチャである第 1のピクチャに第 2の多重化ストリームの 最初のピクチャである第 2のピクチャが連続して再生されるよう接続され、 上記 第 1及び第 2の多重化ストリ一ムが夫々のァライバルタイムスタンプに基づいて デコーダに入力可能であって、 且つ、 上記第 2のピクチャをデコーダに入力する ために要する時間分のオーディオデータを該第 2のピクチャが該デコーダに入力 開始される前までに入力終了可能なように多重化された多重化ストリームが記録 されたことを特徴とする。
本発明においては、 第 2のピクチャを上記デコーダに入力するために要する時 間分のオーディオデータを該第 2のピクチャが該デコーダに入力開始される前ま でに入力終了可能なように多重化ストリームが多重化されているため、 このよう な多重化ストリームを、 第 2のピクチャをビデオバッファに入力するために要す る時間分のオーディォデータをバッファリング可能な容量のオーディォバッファ を有するデコーダにより復号すれば、 第 1の多重化ストリ一ムの最後のトランス ポートパケットを入力した後に、 第 2の多重化ストリームの最初にデコードされ るピクチャをそのデコード夕イミングまでにビデオバッファへ入力することがで きる。
本発明に係る他の情報処理装置は、 トランスポートバケツトとそのァライバル タイムスタンプとを有するソースパケットを単位とするデータ列からなり、 該ァ ライバルタイムスタンプに基づきデコーダにより読み出されてデコードされる多 重化ストリームを生成する情報処理装置において、 第 1のピクチャで表示終了す る第 1のビデオ符号化ストリームを生成し、 この第 1のピクチャに続けて表示さ れる第 2のピクチャから表示開始する第 2のビデオ符号化ストリ一ムを生成する ビデオ符号化手段と、 上記第 1のビデオ符号化ストリームとこの上記第 1のビデ ォ符号化ストリ一ムに同期したオーディォ符号化ストリームとを多重化して第 1 の多重化ストリームを生成し、 上記第 2のビデオ符号化ス卜リームとこの第 2の ビデオ符号化ストリームに同期したオーディォ符号化ストリ一ムとを多重化して 第 2の多重化ストリ一ムを生成し、 上記第 1の多重化ストリームの最後のピクチ ャである上記第 1のピクチャに上記第 2の多重化ストリームの最初のピクチャで ある上記第 2のピクチャが連続して再生されるよう接続された多重化ストリ一ム を生成する多重化手段とを有し、 上記多重化手段は、 上記第 2のピクチャを上記 デコーダに入力するために要する時間分のオーディオデータを上記第 2のピクチ ャが該デコーダに入力開始される前までに入力終了可能なように多重化すること を特徴とする。 本発明においては、 上記第 2のピクチャを上記デコーダに入力するために要す .る時間分の、 例えば 1 0 0ミリ秒分のオーディオデータを上記第 2のピクチャが 該デコーダに入力開始される前までに入力終了可能なように多重化するため、 デ コーダにおいて、 オーディオデータをオーディオバッファに先送りして、 I ピク チヤ等の第 2のピクチャを、 そのデコードタイミングまでに伝送する時間を十分 に確保することができ、 多重化ストリ一ムの符号化が容易になる。
本発明に係る他の情報処理方法は、 トランスポートパケットとそのァライバル タイムスタンプとを有するソースパケットを単位とするデータ列からなり、 該ァ ライパルタイムスタンプに基づきデコーダにより読み出されてデコードされる多 重化ストリームを生成する情報処理方法において、 第 1のピクチャで表示終了す る第 1のビデオ符号化ストリームを生成し、 この第 1のピクチャに続けて表示さ れる第 2のピクチャから表示開始する第 2のビデオ符号化ストリームを生成する ビデオ符号化工程と、 上記第 1のビデオ符号化ストリームとこの上記第 1のビデ ォ符号化ストリームに同期したオーディオ符号化ストリームとを多重化して第 1 の多重化ストリ一ムを生成し、 上記第 2のビデオ符号化ストリームとこの第 2の ビデオ符号化ストリームに同期したォ一ディォ符号化ストリームとを多重化して 第 2の多重化ストリ一ムを生成し、 上記第 1の多重化ストリームの最後のピクチ ャである上記第 1のピクチャに上記第 2の多重化ストリームの最初のピクチャで ある上記第 2のピクチャが連続して再生されるよう接続された多重化ストリーム を生成する多重化工程とを有し、 上記多重化工程では、 上記第 2のピクチャを上 記デコーダに入力するために要する時間分のオーディオデータを上記第 2のピク チヤが該デコーダに入力開始される前までに入力終了可能なように多重化するこ とを特徴とする。
本発明の更に他の目的、 本発明によって得られる具体的な利点は、 以下に説明 される実施例の説明から一層明らかにされるであろう。 図面の簡単な説明 図 1は、 従来の情報処理装置を示すブロック図である。 図 2は、 Bridge- Clipを使用する場合の先行する Playltemと現在の Playltemとの 関係を示す模式図である。
図 3は、 Bridge- Clipを使用しない場合の先行する Playltemと現在の Playltemの 関係を示す模式図である。
図 4は、 ビデオストリームとしての Cliplと Clip2とをシームレス接続する例を ピクチャの表示順序 （Presen Uon order) で示す模式図である。
図 5は、 図 4に表示ビデオストリーム （ ipl及び Clip2) をシームレス接続す る場合に、 第 1の方法である BridgeSeauenceを使用してシームレス接続を実現す る各 A Vストリームにおけるデータ列を示す模式図である。
図 6は、 図 4示すビデオストリーム （Clipl及び Clip2) をシームレス接続する 場合に、 第 2の方法である BridgeSetiuenceを使用しないでシームレス接続を実現 する各 AVストリームにおけるデ一夕列を示す模式図である。
図 7は、 オーディオの表示のオーバラップを説明する図であって、 TS1及び TS2 におけるビデオのプレゼンテ一ションュニット及びオーディォのプレゼンテーシ ョンュニットを示す模式図である。
図 8は、 本発明の実施の形態における情報処理装置を示すプロック図である。 図 9は、 ある AVストリーム （TS1) から、 これにシームレスに接続された次の AVストリーム （TS2) へと移るときのトランスポートパケットの入力、 復号、 及 び表示のタイミングチヤ一卜である。
図 1 0は、 ある AVストリーム （TS1) からそれにシームレスに接続された次の AVストリーム （TS2) へと移るときのトランスポートパケットの入力、 復号、 表 示の他の例を示す夕イミングチヤ一トである。
図 1 1は、 ある AVストリーム （TS1) からそれにシームレスに接続された次の AVストリーム （TS2) へと移るときのトランスポートパケットの入力、 復号、 表 示の他の例を示す夕イミングチヤ一トである。
図 1 2は、 ATC_deltaを格納するための付属情報 ClipInfoOのデータフォ一マツ トを示す図である。
図 1 3は、 ある AVストリーム （TS1) に接続されるところの次の AVストリー ム （TS2) が複数存在する場合の付属情報 ClipInfoOを示す模式図である。 図 14は、 従来の DVR- STDの場合であり、 オーディオのバッファサイズが 4kBy tesである場合に、 TS1からそれにシームレスに接続される次の TS2へと移るときの DVR-STDのビデオバッファ及びオーディオバッファのビット占有量の変化の例を示 すグラフ図である。
図 1 5は、 本発明の実施の形態における効果を説明する図であって、 オーディ ォのバッファサイズが 8 kBytesである場合に、 TS1からそれにシームレスに接続さ れる次の TS2へと移るときの D VR— S TDのビデオパッファ及びオーディォバッ ファのビット占有量の変化の例を示すグラフ図である。 発明を実施するための最良の形態 以下、 本発明を適用した具体的な実施の形態について、 図面を参照しながら詳 細に説明する。 この実施の形態は、 本発明を、 ビデオストリームとオーディオス トリームとが多重化された 2つの A Vストリームをシームレスで連続再生する情 報処理装置に適用したものである。 そして、 本実施の形態においては、 DVR-STD
(Digital Video Recording-System Target Decoder) において、 シームレスに接 続された 2つの A Vストリームを再生する際に最適な容量としたオーディォバッ ファを提案するものである。
はじめに、 以下の説明において使用する用語について説明する。 Clipは、 ビデ ォストリームとオーディオストリームとの多重化ストリームを示す。 また、 Play Listは、 Clipの中の再生区間の集まりを示す。 ある Clipの中の 1つの再生区間は、 Playltemと呼ばれ、 それは、 時間軸上の I N点と OUT点のペアで表される。 そ れゆえ、 PlayListは、 Playltemの集まりである。
Playltem間をシームレスに再生するとは、 再生装置 （プレーヤ） が、 デコーダ の再生出力にポーズやギヤップを起こさせることなく、 ディスクに記録されたォ —ディォビデオデータを表示 （再生） することができることである。
シームレス接続されている 2つの Playltemsの構造について説明する。 先行する Playltemと現在の Playltemとの接続が、 シームレス表示できるように保証されて いるかどうかは、 現在の Playltemにおいて定義されている connection condition フィールドから判断することができる。 そして、 Playltem間のシームレス接続は、 Bridge-Clip (BridgeSeauence) を使用する方法 （以下、 第 1の方法とする。 ） と 使用しない方法 （以下、 第 2の方法とする。 ） がある。
先ず、 先行する Playltem (previous Playltem) と現在の Playltem (current P lay Item) とが、 第 1の方法である Br idgeSeauenceを使用して接続されている場 合の TS1及び TS2について説明する。 図 2は、 第 1の方法である Bridge- Clipを使用 する場合における、 先行する Playltemである P I 1と現在の Playltemである P I 2との関係を示す模式図である。 この図 2において、 Bridge- Clipを使用する場合 にプレーヤが読み出すストリームデ一夕を影を付けて示す。 ここで、 DVR MPEG
(Moving Picture Experts Group) 2トランスポートストリーム （TS) は、 整数個 の Aligned unitから構成される。 Aligned unitの大きさは、 6144バイト （20 48X3バイト） である。 1つの Aligned unitは、 32個のソースパケットからなり， ソースパケッ卜の第 1バイト目から始まる。
各ソースパケットは、 192バイト長である。 1つのソースパケットは、 TP— e xtra_headerとトランスポートパケットとからなり、 TP_extra_lieaderは、 4バイ ト長であり、 またトランスポートパケットは、 188バイ ト長である。 TP— extra —headerは、 copy— pr emission— indicatorと arrival— t ime— s tampとを有し、 copy— p remission— indicatorは、 トランスポートパケットのペイロード （Payload) のコ ピー制限を表す整数、 arrival_time_stamp (ATS) は、 A Vストリームの中で、 対 応するトランスポートパケットがデコーダに到着する時刻を示すタイムスタンプ である。 A Vストリ一ムを構成する各ソースパケットの arrivaし time— stampに基 づいて作られる時間軸をァライバルタイムべ一スといい、 そのクロックを ATC
(Arrival Time Clock) と呼ぶ。
図 2に示す TS1 (第 1の多重化ストリーム） は、 Clipl (Clip AVストリーム） の 影を付けて示すストリ一ムデ一夕 D 1と Bridge- Clipの SPlarrivaし timejiscon tinuityより前の影を付けて示すストリームデータ D 2からなる。 SPN_arrival_t ime— discontinuityは、 the Bridge-Clip AVストリームファイルの中でァライバル タイムベースの不連続点があるところのソースパケットのァドレスを示す。
そして、 TS1に含まれる Cliplの影を付けて示すストリームデータ D 1は、 先行 する PI ay It emの IN— time (図 2において IN— time 1で示す。 ) に対応するプレゼン テ一ションュニットを復号するために必要なストリームのァドレスから、 SPN— ex iし from— previous_Clipで参照されるソースパケットまでのストリームデータであ る。
また、 TS1に含まれる Bridge-Clipの SPN— arrival— time— discontinuityより前の 影を付けて示すストリ一ムデータ D 2は、 Bridge-Clipの最初のソースパケットか ら、 SPN_arrivaし tinie_discontiiiuityで参照されるソースパケットの直前のソ一 . スパケットまでのストリームデータである。
また、 図 2に示す TS2 (第 2の多重化ストリ一ム） は、 Clip2 (Clip AVストリ —ム） の影を付けて示すストリ一ムデ一夕 D 4と Bridge- Clipの SPN_arrival—tim e— discontinuity以後の影を付けて示すストリームデータ D 3からなる。
そして、 TS2に含まれる Bridge- Clipの SPN_arrivaし time— discontinuity以後の 影を付けて示すストリ一ムデ一夕 D 3は、 SPN_arrival一 tiine_discontinuityで参 照されるソースパケットから、 Bridge- Clipの最後のソースバケツトまでのストリ —ムデ一夕である。
また、 TS2に含まれる Clip2の影を付けて示すストリームデータ D 4は、 SPN_e nter— to— current— Clipで参照されるソースパケットから、 現在の Playltemの 0UT_ time (図 2において、 OUT—t ime 2で示す。 ） に対応するプレゼンテーションュニ ットを復号するために必要なストリームのァドレスまでのストリームデータであ る。
次に、 先行する Playltemと現在の Playltemが、 第 2の方法である BridgeSetiuen ceを使用しないで接続されている場合の TSl及び TS2について説明する。 図 3は、 第 2の方法である Bridge- Clipを使用しない場合における、 先行する Playltemであ る P I 1と現在の Playltemである P I 2との関係を示す模式図である。 この図 3 において、 プレーヤが読み出すストリームデ一夕は、 影を付けて示す。
図 3に示す TS1 (第 1の多重化ストリーム） は、 Clipl (Clip AVストリーム） の影を付けて示すストリームデ一タ D 5からなる。 TS1に含まれる Cliplの影を付 けて示すストリームデータ D 5は、 先行する Playltemの IN— time (図 3において I N time 1で示す） に対応するプレゼンテーションユニットを復号するために必要 なストリ一ムのァドレスから始まり、 Clip 1の最後のソースパケットまでのデー 夕である。
また、 図 3に示す TS2 (第 2の多重化ストリーム） は、 Clip2 (Clip AVストリ —ム） の影を付けて示すストリームデータ D 6からなる。 TS2に含まれる Clip2の 影を付けて示すストリ一ムデータ D 6は、 Clip2の最初のソースパケットカ、ら始 まり、 現在の Playltemの 0UT_time (図 3において OUT— time 2で示す） に対応する プレゼンテ一ションュニットを復号するために必要なストリ一ムのァドレスまで のストリ一ムデ一夕である。
図 2及び図 3の両方において、 TS1及び TS2は、 ソースパケットの連続したスト リームである。 次に、 TS1及び TS2のストリーム規定とそれらの間の接続条件につ いて説明する。
TS1及び TS2は、 ビデオストリームとオーディォストリームとが多重化されたも のであるが、 ここでは、 先ず、 シームレス接続のための符号化制限におけるビデ オビットストリームの制限について説明する。
図 4は、 ビデオストリ一ムとしての Cliplと Clip2とをシームレス接続する例を ピクチャの表示順序 （Presentation order) で示す模式図である。 動画像プログ ラムの一部分をスキップ再生する際に、 スキップ再生開始点であるアウト点ピク チヤより時間的に前側のプログラムであるァゥト点側プログラムと、 スキップ再 生到達点であるィン点ピクチャより時間に後側のプログラムであるイン点側プロ グラムとをシームレスに接続するには、 復号装置においてビデオストリームの再 エンコード処理を行う必要がある。
MPEG2規格に準じた画像群の単位である GO P (group of pictures) には、 他 の画像からの予測符号化なしに画像が符号化された参照画像である少なくとも 1 つの I (Intra) ピクチャ （フレーム内符号化画像） と、 表示順序に順方向の予測 符号化を用いて画像が符号化された順方向予測符号化画像である P (predict iv e) ピクチャと、 順方向及び逆方向の予測符号化を用いて画像が符号化された双方 向予測符号化画像である B (bidirectionally) ピクチャとの 3種類の符号化画像 が含まれている。 図 4においては、 Clipl及び Clip2の各数字は表示順序を示し、 I、 P、 B、 又は i、 p、 bは各ピクチャの種類を示す。 例えば図 4には、 Clip 1の B 7と Clip2の b 4とを接続する例を示すが、 この接続点においてビデオスト リームをシームレスに表示できるためには、 0UT_timel (CI ip 1の OUTjime) の後 と IN— time2 (CI ip2の IN— t ime) の前に表示される不必要なピクチャは、 接続点付 近の Clipの部分的なストリームを再エンコードするプロセスにより、 除去されな ければならない。
図 4に示すようなビデオストリーム （Clipl及び Clip2) をシームレス接続する 場合に、 上記第 1の方法である BridgeSeauenceを使用してシームレス接続を実現 する例を図 5に示す。 SPN— arrival— time一 discontinuityより前の Br idge- CI ipのビ デォストリームは、 図 4に示す Cliplの 0UT_Umelに対応するピクチャまでの符号 化ビデオストリームからなる。 そして、 そのビデオストリームは先行する Clipl のビデオストリ一ムに接続され、 1つの連続で MPEG2規格に従ったエレメンタリス トリームとなるように再エンコードされている。 同様にして、 SPN_arrival_time —discontinuity以後の Bridge-Clipのビデオストリ一ムは、 図 4の CI ip 2の IN_ti me 2に対応するピクチャ以後の符号化ビデオストリームからなる。 そして、 その ビデオストリームは、 正しくデコード開始することができて、 これに続く Clip2の ビデオストリ一ムに接続され、 1つの連続で MPEG2規格に従つたエレメン夕リスト リームとなるように再エンコードされている。 Bridge-Clipを作るためには、 一般 に、 数枚のピクチャは再エンコードしなければならず、 それ以外のピクチャはォ リジナルの Clipからコピーすることができる。
図 5の （a) は、 図 4に示す Cliplをその復号順に示したものであり、 プレーヤ は、 先行する Cliplの P 5のソースパケット番号 （SPN_exit_from_previous_Cli p) から （b) に示す Bridge- Clipにジャンプする。 ここで、 Bridge- CI ipの図 2に 示した D 2、 即ち、 Br idgeSeduenceにおける SPN— arrival— time— discontinuityの 前までのビデオデ一夕に相当する Cliplの OUT— timel側のストリ一ムデータにおい て、 B 4までのデータ d lは、 Cliplをそのままコピーしたデータからなり、 これ に続くデ一夕 P 7， B 6は本来はオリジナルの Cliplの B 6及び B 7からなるが、 Cliplを復号し圧縮していない画像データに戻してから再びェンコ一ドして P 7及 び B 6としたデータ d 2となっている。 また、 Bridge- Clipの図 2に示した D 3、 即ち、 BridgeSeauence における SPN— arrivaし time_discontinuity以降のビデオデ —夕に相当する Clip2の IN— time2側のストリームデータにおいても、 オリジナルの Clip2の b 4、 p 5、 p 8、 b 6、 b 7は、 CI ip2を一旦復号して圧縮していない 画像デ一夕に戻してから再びエンコードして新たに作成されたデータ （ i 0、 p 1、 4, b 2、 b 3 ) d 3となり、 それ以降 CI ip2の SPN_enter_to_currenr— CI ipにジャンプするまでの間のデータ d 4は、 Clip2をそのままコピーしたものとな つている。
次に、 図 4に示すようなビデオストリーム （Clipl及び Clip2) をシームレス接 続する場合に、 上記第 2の方法である BridgeSeauenceを使用しないでシ一ムレス 接続を実現する例を図 6に示す。 図 6において、 Clipl及び Clip2は、 その復号順 序にピクチャを示したものである。 BridgeSeauenceを使用しない場合であっても、 図 5に示した BridgeSeauenceを使用する場合と同様に、 接続点 （コネクションポ イント ： conection point) 付近のストリームは、 一旦復号して圧縮していないデ 一夕に戻してから最適なピクチャタイプに再デコードされる。 即ち、 Cliplのビ デォストリームは、 図 4の OUTLUmelに対応するピクチャまでの符号化ビデオスト リームからなり、 それは、 1つの連続で MPEG2規格に従ったエレメン夕リストリー ムとなるように、 オリジナルの Cliplの B 6， B 7が再エンコードされたデータ (P 7 , B 6 ) d 5とされている。 同様にして、 Clip2のビデオストリームは、 図 4の Clip2の IN_time2に対応するピクチャ以後の符号化ビデオストリ一ムからな り、 それは、 1つの連続で MPEG2規格に従ったエレメン夕リストリームとなるよう に、 オリジナルの Clip2の b 4， p 5， p 8 , b 6 , b 7が再エンコードされたデ —夕 （ i 0, p i, 4, b 2 , b 3 ) d 6とされている。
次に、 TS1及び TS2のそれぞれの多重化ストリームの符号化制限について説明す る。 図 7は、 オーディオの表示のオーバラップを説明する図であって、 TS1及び T S2におけるビデオのプレゼンテ一ションュニット VPU1, VPU2及びオーディォのプ レゼンテ一ションュニット ΑΡϋΙ, APU2を示す模式図である。
図 7に示すように、 TS1のオーディオストリームの最後のオーディオフレーム A _endは、 TS1の最後の表示ピクチャの表示終了時 （OUT— t imel) に等しい表示時刻 を持つオーディオサンプルを含んでいる。 また、 TS2のオーディオストリームの最 初のオーディオフレーム A starUま、 TS2の最初の表示ピクチャの表示開始時 （IN _time2) に等しい表示時刻を持つオーディオサンプルを含んでいる。 これにより、 TS1と TS2との接続点において、 オーディオプレゼンテーションュニットのシ一ケ ンスにギヤップは存在せず、 2オーディオフレーム区間未満のオーディオプレゼ ンテ一ションュニッ卜の長さで定義されるオーディォオーバラップ （Audio over lap) が生じる。 接続点における TSは、 後述する DVR- STD (Digital VideoRecordi ng-System Target Decoder) に従った DVR MPEG2TSである。
D VR— S TDは、 シームレス接続された 2つの P yltemによって参照される AVストリ一ムの生成及び検証の際におけるデコード処理をモデル化するための 概念モデルである。 DVR- STDモデル （DVR MPEG2 transport stream player mode 1) を図 8に示す。
図 8に示すように、 本実施の形態における情報処理装置 （DVR MPEG2 transpor t stream player model, 以下プレーヤという。 ） 1は、 シームレスに再生される よう接続された TSからトランスポートパケット （Transport packets) を読み出し 出力する出力部 1 0と、 出力部 1 0からのトランスポートパケットをデコードす るデコーダ （D VR— S TD) 2 0とから構成される。 このデコーダ 20は、 後 述するように、 上述した従来の D VR— S TDにおけるトランスポートパケット の入力夕イミングとオーディォバッファの容量とを変更したものである。 出力部 1 0において、 読出部 （DVRdrive) 1 1から読出しレート RUDで読み出された TSフ アイルは、 リードバッファ 1 2にパッファリングされ、 このリードバッファ 1 2 からソースパケット （Source packets) がソ一スデパケッタイザ部 （source dep acketizer) 1 3へビットレート RMAXで読み出される。 RMAXは、 ソースパケットス 卜リームのビットレー卜である。
パルス発振器 （27MHz X-tal) 14は、 2 7 MH zのパルスを発生する。 ァライ バルクロックカウンタ （Arrival time clock counter) 1 5は、 この 2 7MHz の周波数のパルスをカウントするバイナリカウンタであり、 ソースデパケッタイ ザ部 1 3に、 時刻 t (i)における Arrival time clock counterのカウント値 Arriva 1一 time一 clock(i)を供給する。
上述したように、 1つのソースパケットは、 1つのトランスポートパケットと それの arrival t ime_stampを持つ。 現在のソースパケットの arrival— time— stamp が arrival— time_clock(i)の L S B 3 0ビットの値と等しいとき、 ソースデパケッ タイザ部 1 3からそのトランスポートパケットが出力される。 TS— recording_rat eは、 TSのビットレ一トである。
また、 図 8に示す n、 TBn、 MBn、 EBn、 TBsys, Bsys、 Rxn、 Rbxn、 Rxsys、 Dn、 D sys、 On及び Pn(k)の表記方法は、 IS0/IEC13818-1 (MPEG2 Systems規格）の T-STD
(ISO/IEC 13818- 1で規定される transport stream system target decoder) に定 義されているものと同じである。 即ち、 次の通りである。
n :エレメンタリストリ一ムのィンデクス番号
TBn：エレメンタリストリ—ム nのトランスポートバッファ
MBn：エレメンタリストリーム nの多重バッファ （ビデオストリ一ムについてのみ 存在）
EBn：エレメンタリストリーム nのエレメン夕リストリ一ムバッファ、 ビデオスト リ一ムについてのみ存在
TBsys：復号中のプログラムのシステム情報のための入力バッファ
Bsys：復号中のプログラムのシステム情報のためのシステム夕ーゲットデコーダ 内のメインバッファ
Rxn：データが TBnから取り除かれる伝送レート
Rbxn： PESパケットぺイロ一ドが MBnから取り除かれる伝送レート （ビデオストリ ームについてのみ存在）
Rxsys：データが TBsysから取り除かれる伝送レ一ト
Dn：エレメンタリストリ一ム nのデコーダ
Dsys：復号中のプログラムのシステム情報に関するデコーダ
On : ビデオストリーム nの再配列バッファ （re-ordering buffer)
Pn(k) ：エレメン夕リストリーム nの k番目のプレゼンテーションュニット
次に、 デコーダ 2 0のデコーディングプロセスについて説明する。 先ず、 1つ の DVR MPEG2 TSを再生しているときのデコ一ディングプロセスを説明する。
単一の DVR MPEG2TSを再生している間は、 トランスポートパケットを TB1、 TBn又 は TBsysのバッファへ入力するタイミングは、 ソースパケットの arrival_time_st a即により決定される。 TB1、 MB1、 EB1、 TBn、 Bn、 TBsys及び TBsysのバッファリング動作の規定は、 IS 0/IEC 13818- 1に規定されている T-STDと同じである。 復号動作と表示動作の規定 もまた、 IS0/IEC 13818- 1に規定されている T-STDと同じである。
次に、 シームレス接続された Playltemを再生している間のデコーディングプロ セスについて説明する。 図 9は、 ある AVストリーム （TS1) から、 これにシ一ム レスに接続された次の AVストリーム (TS2) へと移るときのトランスポートパケ ットの入力、 復号、 及び表示のタイミングチャートである。
ここでは、 シームレス接続された Playltemによって参照される 2つの AVスト リームの再生について説明をすることにし、 以後の説明では、 図 2又は図 3に示 した、 シームレス接続された TS1及び TS2の再生について説明する。 したがって、 TS1は、 先行するストリームであり、 TS2は、 現在のストリームである。 また、 TS 1及び TS2で区分された各パケットは、 TS1及び TS2のソースパケット SP1, SP2を表 している。
ある AVストリーム (TS1) からそれにシームレスに接続された次の A Vストリ ーム （TS2) へと移る間には、 TS2のァライパルタイムベースの時間軸 （図 9にお いて ATC2で示される） は、 TS1のァライバルタイムベースの時間軸 （図 9における ATC1で示される） と同じ時間軸でない。 また、 TS2のシステムタイムベースの時間 軸 （図 9において STC2で示される） は、 TS1のシステムタイムベースの時間軸 （図 9において STC1で示される） と同じ時間軸でない。 ビデオの表示は、 シームレス に連続していることが要求される。 オーディォのプレゼンテ一ションュニットの 表示時間にはオーバラップがあってもよい。
ここで、 本実施の形態におけるプレーヤ 1においては、 上述した日本公開特許 公報 2 0 0 0— 1 7 5 1 5 2号、 日本公開特許公報 2 0 0 1 - 5 44 1 1 8号及 び日本公開特許公報 2 0 0 2— 1 5 8 9 7 4号に記載のプレーヤ 1 0 1に対し、 以下の 2点を変更することで、 オーディォバッファを最適な容量とするものであ る。 先ず、 1つ目の変更点について説明する。 1つ目の変更点は、 ある A Vス卜 リーム（TS1)からそれにシームレスに接続された次の AVストリ一ム（TS2)へと移 るとき、 TS1の最後のパケットまでのデコーダ 2 0への入力をそれらソースパケッ トの arrival_l;ime_stampによって決定することとする点である。 即ち、 上述した如く、 従来は、 TS1の最後のビデオパケットが TBIに入力終了す る時刻 T 1から、 TS1の最後のパイトが入力終了するまでの時刻 T 2までの間は、 arrival_Ume_stampを無視して、 TSの最大ビットレートで、 トランスポートパケ ットがバッファに入力されていたのに対し、 本実施の形態においては、 T 1から T 2までの間のソースパケットの入力を、 時刻 T 1までと同様にして、 TS1のソー スパケットの&1"1： 31_1：11116—513卹にょって決定する。 これにより、 従来ソースパ ケットの arrival— time_s tampを無視して、 TSの最大ビットレ一ト RMAXで入力する ために必要とされていた 1秒分の付加的なバッファは、 不要となる。
この場合のデコーダ 2 0への入カタイミングについて、 図 9を参照して説明す る。
( 1 ) 時刻 T 1までの時間
時刻 T 1までの時間、 即ち、 TS1の最後のビデオパケットがデコーダ 2 0の TBI に入力終了するまでは、 デコーダ 2 0の TB1、 TBn又は TBsysのバッファへの入カタ ィミングは、 TS1のソースパケット SP1の arrivaし time_stampによって決定される。
( 2 ) 時刻 T 1から T 2まで
TS1の残りのパケッ卜がデコーダ 2 0へ入力するタイミングもまた、 TS1のソ一 スパケット SP1の arrivaし Ume_stampによって決定される。 TS1の最後のバイトが バッファへ入力する時刻は、 時刻 T 2である。
( 3) 時刻 T 2以後
T 2の時刻において、 ァライパルタイムクロックカウンタ 1 5は、 TS2の最初の ソースパケットの arrival_time_sta即の値にリセットされる。 デコーダ 2 0の TB 1、 TBn又は TBsysのバッファへの入力タイミングは、 TS2のソースパケット SP2の a rrival_t ime— stampによって決定される。
即ち、 デコーダ 2 0への入力タイミングは、 TS1の最後のバイトがバッファへ入 力する時刻 T 2までは、 デコーダ 2 0の TB1、 TBn又は TBsysのバッファへの入カタ ィミングを TS1のソースパケット SP1の arrivaし time_sta即によって決定し、 T 2 以降は、 TS2のソースバケツト SP2の arrival— time— stampによって決定する。
次に、 ビデオのプレゼンテーションタイミングについて説明する。 ビデオプレ ゼンテーシヨンユニットの表示は、 上述の図 2又は図 3に示すような接続点 （コ ネクシヨンポイント） を通して、 ギャップなしに連続しなければならない。 即ち、
TS1の最後のビデオデータ （第 1のピクチャ） に、 TS2の最初のビデオデータ （第
2のピクチャ） が連続して再生される。 ここで、
STC1： TS1のシステムタイムベースの時間軸 （図 9では STC1と示す。 ）
STC2： TS2のシステムタイムベースの時間軸 （図 9では STC2と示す。 ） 正確には、
STC2は、 TS2の最初の PCR ( (Program Clock Refarence) ) が T- STDに入力した時 刻から開始される。
とする。
また、 STC1と STC2との間のオフセットは、 次のように決定される。 即ち、 PTS nd： TS1の最後のビデオプレゼンテ一ションュニットに対応する STC1上の PT S
PTS2start ： TS2の最初のビデオプレゼンテ一ションュニットに対応する STC2上の PTS
T PP： TS1の最後のビデオプレゼンテ一ションュニットの表示期間
とすると、 2つのシステムタイムベースの間のオフセット値 SK_deltaは、 下記式 (6 ) のように計算される。
STC_delta=PTSlend + TpP-PTS2s tar t · . · ( 6 ) 次に、 オーディオのプレゼンテーションタイミングについて説明する。 TS1と T S2との接続点において、 オーディオプレゼンテーションュニットの表示夕イミン グのオーバラップがあってもよく、 それは 0以上であって 2オーディオフレーム 未満である （図 9のオーディオオーバラップを参照） 。 プレーヤには、 どちらの オーディオサンプルを選択するかということ及び、 オーディオプレゼンテ一ショ ンュニットの表示を接続点の後の補正されたタイムベースに再同期する制御が要 求される。
TS1からそれにシームレスに接続された次の TS2へと移るとき、 デコーダ 2 0の システムタイムクロックの制御について、 プレーヤが行う処理を説明する。 時刻で 5において、 TS1の最後のオーディオプレゼンテ一ションュニットが表示 される。 システムタイムクロックは、 時刻 T 2から T 5の間にオーバーラップし ていてもよい。 この区間では、 デコーダ 2 0は、 システムタイムクロックを古い タイムベースの値 （STC1) を新しいタイムベースの値 （STC2) に切り替える。 ST C2の値は、 下記式 （7 ) のように計算できる。
STC2 = STCl-STC_delta · · · (7) 次に、 TS1から、 この TS1にシームレスに接続される次の TS2へと移るとき、 TS1 及び T S 2が満たさなければいけない符号化条件を説明する。 ここで、
STCPend： TS1の最後のパケットの最後のバイトがデコーダ 2 0へ到着するときの システムタイムベース STC1上の STCの値
STC22s tart ： TS2の最初のバケツトの最初のバイトがデコーダ 2 0へ到着するとき のシステムタイムべ一ス STC2上の STCの値
STC21e„d： STCl ndの値をシステムタイムべ一ス STC2上の値に換算した値 とすると、
Figure imgf000027_0001
は、 下記式 （8 ) のようにして計算される。
STC21end = STCl1end -STC_delta · · · (8) ここで、 デコーダ 2 0が D VR— S TDに従うために、 次の 2つの条件を満た すことが要求される。
(条件 1 )
TS2の最初のパケットのデコーダ 2 0への到着夕イミングは、 次に示す不等式 ( 9 ) を満たさなければならない。
STC22s tar t>STC21end · · · (9) この上記不等式 （9) を満たすように、 Clipl及び 又は Clip2の部分的なスト リームを再エンコード及び Z又は再多重化することが必要になる。
(条件 2)
STC1と STC2とを同じ時間軸上に換算したシステムタイムベースの時間軸上にお いて、 TS1からのビデオパケットの入力とそれに続く TS2からのビデオパケットの 入力は、 ビデオバッファをオーバフロー及びアンダフ口一させてはならない。 ま た、 STC1と STC2とを同じ時間軸上に換算したシステムタイムベースの時間軸上に おいて、 TS1からのパケットの入力とそれに続く TS2からのパケットの入力は、 デ コーダ 20のすベてのバッファをオーバフロー及びアンダフローさせてはならな い。
図 1 0は、 ある AVストリーム（TS1)からそれにシームレスに接続された次の A Vストリーム（TS2)へと移るときのトランスポートパケットの入力、 復号、 表示の タイミングチャートの他の例である。 この場合もまた、 TS1の最後のパケットまで のデコーダ 20への入力をそれらソースバケツトの arrivaし time_stainpによって 決定することは同様であるが、 図 9に示す夕イミングチャートとの一点の違いと して、 図 1 0に示すように、 TS1の最後のパケットの直後に TS2の最初のパケット を入力する必要がないように、 所定の時間間隔 （deltal：時刻 T 2〜T 2 ' の 間） を設けている。 これにより、 TS2の最初のパケットの入力タイミングの決定が 図 9の場合よりも柔軟であるので、 TS2の符号化を容易にする効果がある。
この場合のデコーダ 2 0への入力タイミングについて、 図 1 0を参照して説明 する。
( 1 ) 時刻 Τ 2までの時間
時刻 Τ 2までの時間、 即ち、 TS1の最後のパケットの最後のバイトがデコーダ 2 0へ入力終了するまでは、 デコーダ 2 0の TB1、 TBn又は TBsysのバッファへの入力 タイミングは、 TS1のソースパケット SP1の arrival— time_stampによって決定され る。
(2) 時刻 T 2 ' 以後
時刻 T 2から de alの時間の後、 時刻 T 2 'の時刻において、 ァライバルタイム クロックカウンタ 1 5は、 TS2の最初のソースバケツ卜の arrival_time_stampの値 にリセットされる。 デコーダ 20の TB1、 TBn又は TBsysのバッファへの入力夕イミ ングは、 TS2のソースパケット SP2の arrival— time— stampによって決定される。 ここで、 図 1 0に示すように、 del lを設ける場合、 上述の STC22 s tartと STC2 ndは下記の関係式 （ 1 0) を満たさなければならない。
STC22s t ar t>STC21end + deltal · · · ( 1 0 ) 図 1 1は、 ある A Vストリーム（TS1)からそれにシームレスに接続された次の A Vストリーム（TS2)へと移るときのトランスポートパケットの入力、 復号、 表示の タイミングチャートの他の例である。 この場合もまた、 TS1の最後のパケットまで のデコーダ 20への入力をそれらソースパケットの arrivaし time_sta即によって 決定することは同様であるが、 図 1 0に示す夕イミングチャートとの一点の違い として、 図 1 1に示すように、 所定の時間間隔 （ATC_delta：時刻 T 2〜T 2 ' の 間） を設けている。 これにより、 TS2の最初のパケットの入力タイミングの決定が 図 9の場合よりも柔軟であるので、 TS2の符号化を容易にする効果がある。
この場合のデコーダ 2 0への入カタイミングについて、 図 1 1を参照して説明 する。
( 1 ) 時刻 Τ 2までの時間
時刻 Τ 2までの時間、 即ち、 TS1の最後のパケットの最後のバイトがデコーダ 2 0へ入力終了するまでは、 デコーダ 20の ΤΒ1、 ΤΒη又は TBsysのバッファへの入力 タイミングは、 TS1のソースパケット SP1の arrival_time_stanipによって決定され る。
(2) 時刻 T 2から T 2 ' までの時間
時刻 T 2 ' は、 TS2の最初のパケットがデコーダ 2 0に入力される時刻である。 ATC_deltaは、 TS1の最後のバケツトの arrivaし t ime— stamp時刻 (ATCl上の時刻) から ATCl上に投射された時刻 T 2 ' までのオフセット時間である。
(3) 時刻 T 2 ' 以後
時刻 T 2 'の時刻において、 ァライバルタイムクロックカウンタ 1 5は、 TS2の 最初のソースパケットの arrival time stampの値にリセットされる。 デコーダ 2 0の TB1、 TBn又は TBsysのバッファへの入力タイミングは、 TS2のソースパケット SP2の arrivaし time_stampによって決定される。
ここで、 ATC— deltaの値は、 上記式 （6) の STC_del taを満たすように値が決定 される。
この ATC_deltaの値は、 ストリームデ一夕の付属情報として管理される。 TS1と TS2とが図 1 1のようにシームレスに接続される場合、 ATC— deltaの値は、 TS1の付 属情報として管理される。
図 12には、 ATC_deltaを格納するための付属情報 ClipInioOのデ一タフォ一マ ッ卜を示す。
図 12において、 is—ATC—dell^、 CI iplnfo 0が ATC_deltaの値を持つか否かを 示すフラグである。 Cliplnio 0には複数の値を登録することができる。 これは、 TS1に接続されるところの TS2を図 1 3に示すように複数持たせることができるよ うにするためである。 is_ATC_deltaフラグが 1である場合、 number_oし ATC— del t a_entriesは、 この CI iplnf o 0に登録されている ATC— deltaの個数を示す。
また、 図 12において、 following— Clip— Infomat ion— file— nameは、 TSlに接続 されるところの TS2のストリ一ムの名前である。 following— Clip— Iniomation_fil e一 nameに対応するところの TS2が複数存在する場合、 それぞれの TS2に対する ATC_ deltaの値が Cliplnfo 0に登録される。
図 8の DVR- STDモデルに TS1及び TS2が入力される場合、 それぞれの多重化ストリ —ムとともに、 その付属情報 ClipInfoOが入力される。 ClipInioOは、 上述の AT C— deltaの情報を含み、 ATC_deltaは、 DVR-STDモデルのコントローラ （図 8で図示 せず） によって、 上述のように TS1と TS2との切替わりにおいて所定の方法で取り 扱われる。
2つ目の変更点としては、 デコーダ 20のオーディオバッファのサイズを、 次 の条件が満たされるような十分な大きさに変更する。 この条件とは、 TS1からこれ にシームレスに接続される次の TS2へと移るとき、 TS1の最後のトランスポ一トパ ケットを入力後に、 TS2の最初にデコードされるピクチャ （ Iピクチャ） をそのデ コード夕イミングまでにビデオパッファへ入力できることである。
この条件を満たすために、 オーディオバッファの必要な容量の最大値は次のよ うな値である。 即ち、 「 I ピクチャの最大のビット量をそのデコードタイミング までにビデオバッファへ入力できる時間」 に相当する長さのオーディォのデータ 量を蓄えられる大きさである。 ォ一ディォバッファの必要量の最大値 EBnjnaxは、 次の式 （ 1 1 ) で計算できる。
EBn_max= (I_max/Rv) * Ra [b i t s] · · · ( 1 1 ) ここで、 し maxは、 Iピクチャの最大のビット量であり、 これは、 図 8に示すビ デォコードバッファ EB1の大きさである。 Rvは、 ビデオコードバッファ EB 1への入 力ビットレートである。 また、 は、 オーディオストリームのビットレートであ る。 上記式 （ 1 1 ) に示すように、 求めるべきオーディオバッファの大きさ EBn一 maxは、 ビデオエレメンタリストリ一ムバッファ （EB 1) への入力ビットレートで ビデオコードバッファ EB1のバッファ占有量をゼロから I_maxにするまでにかかる 時間 (Lmax/Rv)に Raを掛けた値である。
また、 具体的な値として、 少なくとも 1 0 0ミリ秒分のオーディオデータを蓄 えられるバッファサイズを推奨する。 これは以下の理由による。 即ち、 I ピクチ ャを 0 . 5秒ごとに符号化する場合、 I ピクチャのビットサイズは、 一般的に、 符号化ビットレートの 1 0 %以下である。 例えば、 符号化ピットレートが 1 0 Mb psの場合、 I ピクチャのサイズは、 通常 I Mb i ts以下である。
したがって、 第 1に、 少なくとも、 1 0 0ミリ秒分の時間があれば、 I ピクチ ャをそのデコ一ドタイミングまでにデコーダ 2 0のビデオバッファへ入力できる。 また、 第 2にデコーダ 2 0のオーディオバッファが、 1 0 0ミリ秒分のオーディ ォデ一夕を蓄えられるのであれば、 オーディォデータをそれが再生される夕イミ ングよりも 1 0 0ミリ秒だけ早く、 オーディオバッファに入力終了するように TS 1を多重化できる。 したがって、 オーディオバッファを、 少なくとも 1 0 0ミリ秒 分のオーディォデ一夕を蓄えられるバッファサイズとすれば、 上記第 1及び第 2 の理由により、 TS1からそれにシームレスに接続される次の TS2へと移るとき、 TS 1の最後のトランスポートパケットを入力後に、 TS2の最初にデコードされるピク チヤ （ I ピクチャ） をビデオバッファへ入力終了する （ I ピクチャのコードタイ ミング） までの時間として少なくとも 1 0 0ミリ秒分を確保することができる。
1 0 0ミリ秒分のオーディォデータを蓄えられるオーディオバッファの容量を 具体的に計算すると次のようになる。
6 4 0 kbpsのドルビー AC3オーディォストリ一ムの場合： 6 4 0 kbpsX 0. Is ec= 64kbitS= 8 kBytes
Linear PCMオーディオス卜リ一ム、 24bitSa即 le、 96 kHz sampling f re ue ncy、 8 chaimalsの場合： （24bUSample*96000samples/sec*8cli) x 0. 1 sec = 23040 0 Bytes
次に、 以上説明した本実施の形態のデコーダ 20のように、 DVR- STDのオーディ ォバッファのサイズを、 「TS2の最初にデコードされるピクチャ （ I ピクチャ） を そのデコードタイミングまでにビデオバッファへ入力できる時間に相当するォー ディォのデータ量を蓄えられる大きさ」 に変更することによる効果を図 14及び 図 1 5を用いて更に詳細に説明する。
例として、 オーディオストリームが、 ビットレート 640 kbps、 サンプリング 周波数 48kHzの AC3オーディォストリ一ムの場合を説明する。 AC3オーディォスト リームの 1オーディオフレームのサンプル数は 1 5 3 6 samplesであるので、 その 時間長は、 3 2ミリ秒である。 また、 1オーディオフレームのバイトサイズは、 256 0 Bytesである。
図 14の （a) 及び （b) は、 従来の DVR- STDの場合であり、 オーディオのバッ ファサイズが 4 kBytesである場合に、 TS1からそれにシームレスに接続される次の TS2へと移るときの DVR-STDの夫々ビデオバッファ及びオーディォバッファのビッ ト占有量の変化の例を示すグラフ図である。 この図 14において、 TS1のビデオ/ オーディオデータのバッファ遷移を破線で示し、 また、 TS2のビデオ/オーディオ データのバッファ遷移を実線で示す。
4 kBytesのオーディォバッファは、 5 0ミリ秒分のオーディォデ一夕を蓄えら れる。 したがって、 TS 1の最後のオーディオパケットの最後のバイトが DVR-STDに 到着する時刻であ
Figure imgf000032_0001
において、 オーディォデータをそれが再生され る夕イミングょりも 50ミリ秒だけ早く入力終了するように TS1を多重化できる。 しかしながら、 50ミリ秒は、 TS2の最初にデコードされるピクチャ （ I ピクチ ャ） をそのデコードタイミングまでにビデオバッファへ入力するためには、 不十 分である。 そのため、 TS2の最初にデコードされるピクチャ （ Iピクチャ） のサイ ズを小さくするようにエンコードを制限することになり、 画質が悪くなる問題が ある。
即ち、 4kBytesのオーディオバッファでは、 先送りすることができるォ一ディ ォデ一夕は 50ミリ秒であるので、 TS2の最初の I ピクチャをビデオバッファに入 力するための時間である図 14に示すスタートアップディレイ （start- up dela y) t 1は、 最大 50ミリ秒と小さくなる。 したがって、 TS2の最初の I ピクチャ を入力する時間を十分とれず、 I ピクチャサイズ S 1が小さくなり、 符号化が制 限され I ピクチャの画質が劣化する。 なお、 この start-up delayを大きくするた め、 上述した如く、 従来は、 4 kBytesに加えて 1秒分程度の付加的なバッファを 設け、 且つ T 1〜T 2の間は TSの最大レート RMAXで入力する必要があった。 こ こでは、 ビットレート 640 kbpsの AC3オーディォストリ一ムについて説明してい るが、 上述した如く、 マルチチャンネルの LPCMオーディオに対応可能なように設 計すると、 1秒分程度の付加的なバッファは極めて大きくなつてしまう。
この問題を解決するために、 本実施の形態におけるデコーダ 20のように、 DV R - STDのオーディオバッファサイズを例えば 8 kBytesに変更する。 図 1 5の （a) 及び （b) は、 オーディオバッファの容量を最適化した例を示すものであって、 オーディォのバッファサイズが 8kBytesである場合に、 TS1からこれにシームレス に接続される次の TS2へと移るときの本実施の形態における DVR— S TDの夫々 ビデオパッファ及びオーディォパッファのビット占有量の変化の例を示すグラフ 図である。 この図 1 5において、 TS1のビデオ/オーディオデータのバッファ遷移 を破線で示し、 また、 TS2のビデオ Zオーディオデータのバッファ遷移を実線で示 す。
8 kBytesのオーディォバッファは、 1 0 0ミリ秒分のォ一ディォデータを蓄え られる。 したがって、 TS1の最後のオーディオパケットの最後のバイトが DVR-ST
Dに到着する時刻である STC aucM c^ndにおいて、 オーディォデ一夕をそれが再生 されるタイミングよりも 1 00ミリ秒だけ早く入力終了するように TS1を多重化で きる。 少なくとも、 1 0 0ミリ秒あれば、 TS2の最初にデコードされるピクチャ
( I ピクチャ） をそのデコードタイミングまでにビデオバッファへ入力する余裕 ができる。 即ち、 TS2の最初の Iピクチャを入力する時間 （スタートアップディレ ィ） t 2を十分とることができ、 そのため、 TS2の最初にデコードされるピクチャ ( I ピクチャ） サイズ S 2を大きくすることができ、 したがって I ピクチャのェ ンコード制限が小さく、 高画質にすることができる。
また、 図 8に示すようなプレーヤモデル 1において、 トランスポートパケット とそのァライバルタイムスタンプとを有するソースパケットを単位とするデータ 列からなり、 そのァライバルタイムスタンプに基づきデコーダにより読み出され てデコードされる TSは、 多重化装置 （情報処理装置） において生成され記録され たものとすることができる。
多重化装置は、 例えば上述の図 4乃至 6を参照して説明したように、 所定のピ クチャで表示終了するよう、 再符号化した Cl ipl (第 1のビデオ符号化ストリー ム） を生成し、 このピクチャに続けて表示され、 且つ表示開始できるよう再符号 化した Cl ip2 (第 2のビデオ符号化ストリーム） を生成するビデオ符号化部と、 C l ip lとこの Cl iplに同期したオーディォ符号化ストリームとを多重化して TS 1を生 成し、 Cl ip2とこの Cl ip2に同期したオーディォ符号化ストリ一ムとを多重化して TS2を生成する多重化部と、 TS1及び TS2からなる多重化ストリームを記録する記録 部とを備える。 ここで、 多重化部においては、 上記第 2のピクチャである I ピク チヤをデコーダ 2 0のビデオバッファに入力するために要する時間分のオーディ ォデータを当該 I ピクチャがデコーダ 2 0に入力開始される前までに入力終了可 能なように多重化する。 なお、 図 5に示すように、 符号化部において Br idge-Cl i Pを生成し、 多重化部において Br idge-Cl ipも合わせて多重化するようにしてもよ いことはもちろんである。
このような多重化装置により生成された多重化ストリームが記録された記録媒 体には、 第 1のピクチャで表示終了する TS 1と、 この第 1のピクチャに続けて再生 する第 2のピクチャから表示開始する TS2とから生成され、 TS 1及び TS2が夫々のァ ライバルタイムスタンプに基づいてデコーダ 2 0に入力可能であって、 且つ、 第 2のピクチャである TS2の最初のピクチャをデコーダに入力するために要する時間 分のオーディォデータを第 2のピクチャがデコーダ 2 0に入力開始される前まで に入力終了可能なように多重化された多重化ストリームが記録されたものとなつ ている。
このように構成された本実施の形態においては、 シームレスに接続された TS 1及 び TS2を再生する際、 TS 1の最後のビデオパケットがデコーダ 2 0の TB Iに入力終了 した後から TS 1の残りのパケットがデコーダ 2 0へ入力するまでにおいても、 トラ ンスポートパケットをァライバルタイムスタンプに従って入力するようにし、 ォ 一ディォバッファのサイズを、 従来の D V R— S T Dにおける 4 k Bytesから、 I ピクチャの最大のビット量をそのデコードタイミングまでにビデオバッファへ入 力できる時間に相当する長さのオーディォのデータ量を蓄えられる大きさに変更 することにより、 TS 1の最後のバケツトが入力終了してから TS2の最初のピクチャ である I ピクチャをそのデコードタイミングまでに入力する時間 （スタートアツ プディレイ） を十分確保することができるので、 I ピクチャの符号化制限を小さ くし、 高画質とすることができる。
また、 従来のように付加的なバッファを設ける方法であると、 例えば TSにおけ るオーディォデータをマルチチヤンネルの LPCMオーディォデータとした場合に極 めて大きい容量の付加的なバッファが必要になるのに対し、 本実施の形態におい ては、 オーディオバッファの容量を上記のように変更し、 ァライバルタイムス夕 ンプに従ってトランスポートパケットを入力するようにすることで、 従来必要と なっていた付加的なバッファを不要とすることができる。
なお、 本発明は、 図面を参照して説明した上述の実施例に限定されるものでは なく、 添付の請求の範囲及びその主旨を逸脱することなく、 様々な変更、 置換又 はその同等のものを行うことができることは当業者にとって明らかである。 産業上の利用可能性 上述した本発明によれば、 ビデオストリ一ムとォ一ディォストリームの多重化 ストリームをビデオフレーム精度で編集して、 編集点をシームレスに再生するこ とが可能であり、 従来ソースパケットの arr ival— t ime_s t anipを無視して、 TSの最 大ビットレートで入力するために必要とされていた 1秒分の付加的なパッファを 不要とし、 従来よりもデコーダに必要なバッファ量を小さくできると共に、 ォ一 ディォパッファのサイズを、 上記第 2のピクチャを上記ビデオバッファに入力す るために要する時間分のオーディォデータをバッファリング可能な容量とするこ とにより第 2のピクチャのエンコード制限が小さく、 高画質とすることができる <

Claims

請求の範囲
1 . トランスポートパケッ卜とそのァライバルタイムスタンプとを有するソース パケットを単位とするデータ列からなり、 第 1の多重化ストリームの最後のピク チヤである第 1のピクチャに第 2の多重化ストリームの最初のピクチャである第 2のピクチャが連続して再生されるよう接続された多重化ストリ一ムを復号する 情報処理装置において、
上記多重化ストリームの上記ァライバルタイムスタンプに従って上記ソースパ ケッ 1、を出力する出力手段と、
上記ソースパケットのうちビデオデータをパッフアリングするビデオバッファ と、
上記ソースバケツトのうちオーディオデータをバッファリングするオーディオ バッファと、
上記ビデオバッファにバッファリングされたビデオデ一夕を復号するビデオ復 号手段と、
上記オーディォバッファにバッファリングされたオーディォデ一タを復号する ォ一ディォ復号手段とを有し、
上記オーディォパッファは、 上記第 2のピクチャを上記ビデオバッファに入力 するために要する時間分のオーディォデ一夕をバッファリング可能な容量を有す る情報処理装置。
2 . 上記オーディオバッファに必要な容量を EBnjnax (b i t s) とし、 上記第 2のピ クチャのビット量をし max (b i t s) とし、 上記ビデオバッファへの入力ビットレ一 トを Rv (bps)とし、 オーディオデータのビットレートを Ra (bps) としたとき、 EBn_max= (し腹/ Rv) x Ra
を満たす請求の範囲第 1項記載の情報処理装置。
3 . 上記第 2のピクチャは、 フレーム内符号化画像である請求の範囲第 1項記載 の情報処理装置。
4 . 上記オーディオバッファは、 少なくとも 1 0 0ミリ秒分のオーディオデータ をバッファリング可能な容量を有する請求の範囲第 1項記載の情報処理装置。
5. 上記第 1の多重化ストリームの時間軸における上記第 1のピクチャの表示終 了時刻と上記第 2の多重化ストリームの時間軸における上記第 2のピクチャの表 示開始時刻との時間差を STC_deltaとし、 上記第 1の多重化ストリ一ムの最後のソ ースパケッ卜の最後のバイトが上記出力手段から出力される該第 1の多重化スト リ一ムの時間軸上の値 STC e n aを上記時間差 STC— deltaにより上記第 2の多重化ス トリ一ムの時間軸上の値に換算した値を STC e nd ( = STCl1 e n d - STC_delta) とし、 上記第 2の多重化ストリームの最初のソースバケツ卜の最初のバイトが上記出力 手段から出力される該第 2の多重化ストリームの時間軸上の値を STC22 s tar tとし たとき、 上記多重化ストリームは、
STCl s t a r t / STb2 e n d
を満たす請求の範囲第 1項記載の情報処理装置。
6. 上記第 1の多重化ストリ一ムの時間軸における上記第 1のピクチャの表示終 了時刻と上記第 2の多重化ストリームの時間軸における上記第 2のピクチャの表 示開始時刻との時間差を STC— deltaとし、 上記第 1の多重化ストリームの最後のソ ースパケッ卜の最後のバイトが上記出力手段から出力される該第 1の多重化スト リームの時間軸上の値 STCl n dを上記時間差 STC一 deltaにより上記第 2の多重化ス トリ一ムの時間軸上の値に換算した値を STCZ^ nd ( = STCl1 e n d-STC_delta) とし, 上記第 2の多重化ストリームの最初のソースパケットの最初のバイトが上記出力 手段から出力される該第 2の多重化ストリ一ムの時間軸上の値を STC22 s t a r tとし、 上記第 1の多重化ストリームの最後のソースパケッ卜が上記出力手段から出力さ れた後、 所定時間 del talの経過後に上記第 2の多重化ストリ一ムの最初のソース パケットを上記出力手段から出力するものとしたとき、 上記多重化ストリームは、
STC22 s t a r t>STC21 e n d + deltal
を満たす請求の範囲第 1項記載の情報処理装置。
7. 上記第 1の多重化ストリームの時間軸における上記第 1のピクチャの表示終 了時刻と上記第 2の多重化ストリームの時間軸における上記第 2のピクチャの表 示開始時刻との時間差を STC_deltaとし、 上記第 1の多重化ストリームの最後のソ —スパケットの出力を開始した後、 所定時間 ATC_deltaの経過後に上記第 2の多重 化ストリームの最初のソースパケットを上記出力手段から出力するものとし、 上記所定時間 ATC_d e 1 1 aは、 上記時間差 S T C— d e 1 1 aの値を満たすように決定され たものであり、
上記多重化ストリームは、 上記時間差 STC— de l t aの値を満たすように多重化され たものである請求の範囲第 1項記載の情報処理装置。
8 . 上記所定時間 ATC— de l t aの値を上記第 1の多重化ストリ一ムの付属情報として 管理する範囲第 7項記載の情報処理装置。
9 . 上記第 1及び第 2の多重化ストリームにおけるオーディオデータは、 マルチ チヤンネルのオーディォデータからなる請求の範囲第 1項記載の情報処理装置。
1 0 . トランスポートパケッ卜とそのァライバルタイムスタンプとを有するソー スパケットを単位とするデータ列からなり、 第 1の多重化ストリームの最後のピ クチャである第 1のピクチャに第 2の多重化ストリ一ムの最初のピクチャである 第 2のピクチャが連続して再生されるよう接続された多重化ストリ一ムを復号す る情報処理方法において、
上記多重化ストリ一ムの上記ァライバルタイムスタンプに従って上記ソースパ ケッ卜を出力する出力工程と、
上記ソースバケツトのうちビデオデ一夕をビデオバッファにバッファリングし、 ォ一ディォデ一夕をオーディォバッファにバッファリングするバッファリングェ 程と、
上記ビデオバッファ及びオーディォバッファにバッファリングされた夫々ビデ ォデ一夕及びオーディォデータを復号する復号工程とを有し、
上記バッフアリング工程では、 上記第 2のピクチャを上記ビデオバッファに入 力するために要する時間分のオーディオデータを、 上記第 2のピクチャを上記ビ デォバッファにバッファリングする前に上記オーディォバッファにバッファリン グする情報処理方法。
1 1 . 上記オーディオバッファの必要ビット量を EBnjax ( b i t s) とし、 上記第 2 のピクチャのビット量をし max (b i t s) とし、 上記ビデオバッファへの入力ビット レートを Rv (bps)、 オーディオデータのビットレートを Ra (bps) としたとき、 EBn_max= ( I— maxZRv) x Ra
を満たす請求の範囲第 1 0項記載の情報処理方法。
1 2 . トランスポートパケッ卜とそのァライバルタイムスタンプとを有するソー スパケットを単位とするデータ列からなり、 第 1の多重化ストリームの最後のピ クチャである第 1のピクチャに第 2の多重化ストリ一ムの最初のピクチャである 第 2のピクチャが連続して再生されるよう接続された多重化ストリ一ムを復号す る処理をコンピュータに実行させるためのプログラムであって、
上記多重化ストリームの上記ァライバルタイムスタンプに従って上記ソースパ ケットを出力する出力工程と、
上記ソースパケットのうちビデオデ一夕をビデオバッファにバッファリングし、 オーディォデ一夕をオーディォバッファにバッファリングするバッファリングェ 程と、
上記ビデオバッファ及びオーディォバッファにバッファリングされた夫々ビデ ォデータ及びオーディォデ一夕を復号する復号工程とを有し、
上記バッファリング工程では、 上記第 2のピクチャを上記ビデオバッファに入 力するために要する時間分のオーディオデータを、 上記第 2のピクチャを上記ビ デォバッファにバッファリングする前に上記オーディォバッファにバッフアリン グするプログラム。
1 3 . 上記オーディオバッファの必要ビット量を EBnjnax (b i ts) とし、 上記第 2 のピクチャのビット量をし max (b i t s) とし、 上記ビデオバッファへの入力ビット レートを Rv (bps) 、 オーディオデータのビットレートを Ra (bps) としたとき、 EBn_max= ( I— maxZRv) X Ra
を満たす請求の範囲第 1 2項記載のプログラム。
1 4 . トランスポートパケットとそのァライバルタイムスタンプとを有するソー スパケットを単位とするデ一夕列からなり、 第 1の多重化ストリ一ムの最後のピ クチャである第 1のピクチャに第 2の多重化ストリームの最初のピクチャである 第 2のピクチャが連続して再生されるよう接続された多重化ストリ一ムを復号す る処理をコンピュータに実行させるためのプログラムが記録されたコンピュータ 読取可能な記録媒体であって、
上記多重化ストリームの上記ァライバルタイムスタンプに従って上記ソースパ ケットを出力する出力工程と、 上記ソースパケットのうちビデオデ一夕をビデオバッファにバッファリングし、 オーディォデ一夕をオーディォパッファにバッファリングするパッファリングェ 程と、
上記ビデオバッファ及びオーディォバッファにバッファリングされた夫々ビデ ォデータ及びオーディォデ一夕を復号する復号工程とを有し、
上記バッフアリング工程では、 上記第 2のピクチャを上記ビデオバッファに入 力するために要する時間分のオーディォデ一夕を、 上記第 2のピクチャを上記ビ デォバッファにバッファリングする前に上記オーディォバッファにバッフアリン グするプログラムが記録された記録媒体。
1 5 . 上記オーディオバッファの必要ピット量を EBnjnax (b i t s) とし、 上記第 2 のピクチャのビット量をし max (b i t s) とし、 上記ビデオバッファへの入力ビット レートを Rv (bps) 、 オーディオデ一夕のビットレートを Ra (bps) としたとき、 EBn_max= ( I— max/Rv) X Ra
を満たす請求の範囲第 1 4項記載の記録媒体。
1 6 . トランスポートパケットとそのァライバルタイムスタンプとを有するソ一 スバケツトを単位とするデータ列からなる多重化ストリームが記録された記録媒 体であって、
上記多重化ストリ一ムは、 第 1の多重化ストリ一ムの最後のピクチャである第 1のピクチャに第 2の多重化ストリ一ムの最初のピクチャである第 2のピクチャ が連続して再生されるよう接続され、 上記第 1及び第 2の多重化ストリームが夫 々のァライバルタイムスタンプに基づいてデコーダに入力可能であって、 且つ、 上記第 2のピクチャを該デコーダに入力するために要する時間分のオーディオデ —夕を該第 2のピクチャが該デコーダに入力開始される前までに入力終了可能な ように多重化された多重化ストリームが記録された記録媒体。
1 7 . 上記第 2のピクチャを上記デコーダに入力するために要する時間分のォー ディォデ一夕は、 上記第 2のピクチャのビット量を I_max (b i t s) とし、 上記デコ —ダのビデオバッファへの入力ビットレ一トを Rv (bps)、 オーディォデータのビッ トレ一トを Ra (bps) としたとき、 （し maxZRv) X Raである請求の範囲第 1 6項 記載の記録媒体。
1 8 . 上記第 2のピクチャは、 フレーム内符号化画像である請求の範囲第 1 6項 記載の記録媒体。
1 9 . トランスポートパケットとそのァライバルタイムスタンプとを有するソ一 スパケットを単位とするデータ列からなり、 該ァライバルタイムスタンプに基づ きデコーダにより読み出されてデコードされる多重化ストリームを生成する情報 処理装置において、
第 1のピクチャで表示終了する第 1のビデオ符号化ストリームを生成し、 この 第 1のピクチャに続けて表示される第 2のピクチャから表示開始する第 2のビデ ォ符号化ストリームを生成するビデオ符号化手段と、
上記第 1のビデオ符号化ストリームとこの上記第 1のビデオ符号化ストリ一ム に同期したオーディォ符号化ス卜リームとを多重化して第 1の多重化ス卜リーム を生成し、 上記第 2のビデオ符号化ス卜リームとこの第 2のビデオ符号化ストリ —ムに同期したオーディォ符号化ストリームとを多重化して第 2の多重化ストリ —ムを生成し、 上記第 1の多重化ストリームの最後のピクチャである上記第 1の ピクチャに上記第 2の多重化ストリームの最初のピクチャである上記第 2のピク チヤが連続して再生されるよう接続された多重化ストリームを生成する多重化手 段とを有し、
上記多重化手段は、 上記第 2のピクチャを上記デコーダに入力するために要す る時間分のオーディオデータを上記第 2のピクチャが該デコーダに入力開始され る前までに入力終了可能なように多重化する情報処理装置。
2 0 . 上記第 2のピクチャを上記デコーダに入力するために要する時間分のォ一 ディォデ一夕は、 上記第 2のピクチャのビット量をし max (b i ts) とし、 上記デコ —ダのビデオバッファへの入力ピットレ一トを Rv (bps)、 オーディォデータのビッ トレ一トを Ra (bps) としたとき、 （IjaxZRv) X Raである請求の範囲第 1 9項 記載の情報処理装置。
2 1 . 上記第 2のピクチャは、 フレーム内符号化画像である請求の範囲第 1 9項 記載の情報処理装置。
2 2 . トランスポートパケットとそのァライバルタイムスタンプとを有するソ一 スパケットを単位とするデ一夕列からなり、 該ァライパルタイムスタンプに基づ きデコーダにより読み出されてデコードされる多重化ス卜リ一ムを生成する情報 処理方法において、
第 1のピクチャで表示終了する第 1のビデオ符号化ストリ一ムを生成し、 この 第 1のピクチャに続けて表示される第 2のピクチャから表示開始する第 2のビデ ォ符号化ストリームを生成するビデオ符号化工程と、
上記第 1のビデオ符号化ストリームとこの上記第 1のビデオ符号化ストリ一ム に同期したオーディオ符号化ストリームとを多重化して第 1の多重化ストリーム を生成し、 上記第 2のビデオ符号化ストリームとこの第 2のビデオ符号化ストリ ームに同期したオーディォ符号化ストリームとを多重化して第 2の多重化ストリ ームを生成し、 上記第 1の多重化ストリームの最後のピクチャである上記第 1の ピクチャに上記第 2の多重化ストリームの最初のピクチャである上記第 2のピク チヤが連続して再生されるよう接続された多重化ストリームを生成する多重化工 程とを有し、
上記多重化工程では、 上記第 2のピクチャを上記デコーダに入力するために要 する時間分のオーディオデータを上記第 2のピクチャが該デコーダに入力開始さ れる前までに入力終了可能なように多重化する情報処理方法。
PCT/JP2004/005782 2003-05-08 2004-04-22 情報処理装置及び方法，並びにプログラム及び記録媒体 WO2004100545A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP04728909.5A EP1515553B1 (en) 2003-05-08 2004-04-22 Information processing device and method, program, and recording medium
US10/520,488 US8086087B2 (en) 2003-05-08 2004-04-22 Information processing device and method, program, and recording medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003-130661 2003-05-08
JP2003130661A JP4902935B2 (ja) 2003-05-08 2003-05-08 情報処理装置、情報処理方法、プログラム、及び記録媒体

Publications (1)

Publication Number Publication Date
WO2004100545A1 true WO2004100545A1 (ja) 2004-11-18

Family

ID=33432113

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/005782 WO2004100545A1 (ja) 2003-05-08 2004-04-22 情報処理装置及び方法，並びにプログラム及び記録媒体

Country Status (7)

Country Link
US (1) US8086087B2 (ja)
EP (1) EP1515553B1 (ja)
JP (1) JP4902935B2 (ja)
KR (1) KR100975175B1 (ja)
CN (1) CN100380959C (ja)
TW (1) TWI246330B (ja)
WO (1) WO2004100545A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070226432A1 (en) * 2006-01-18 2007-09-27 Rix Jeffrey A Devices, systems and methods for creating and managing media clips
KR100788685B1 (ko) * 2006-03-10 2007-12-26 삼성전자주식회사 데이터 스트림 포맷의 변환 방법 및 장치, 이를 이용한데이터 스트림 기록 방법 및 장치
KR101488729B1 (ko) * 2008-05-13 2015-02-06 삼성전자주식회사 디지털 방송 송신장치 및 수신장치와 그 방법들
JP4719250B2 (ja) * 2008-06-20 2011-07-06 株式会社ソニー・コンピュータエンタテインメント 画面記録装置、画面記録方法、画面記録プログラム及び情報記憶媒体
US8817725B2 (en) * 2012-01-13 2014-08-26 Blackberry Limited Scheduling transmission of traffic treated less preferentially despite timing requirements
US20130336379A1 (en) * 2012-06-13 2013-12-19 Divx, Llc System and Methods for Encoding Live Multimedia Content with Synchronized Resampled Audio Data
US10231001B2 (en) 2016-05-24 2019-03-12 Divx, Llc Systems and methods for providing audio content during trick-play playback
SE541208C2 (en) * 2016-07-04 2019-04-30 Znipe Esports AB Methods and nodes for synchronized streaming of a first and a second data stream
US10148722B2 (en) * 2016-07-04 2018-12-04 Znipe Esports AB Methods and nodes for synchronized streaming of a first and a second data stream
KR102090070B1 (ko) * 2018-10-31 2020-03-17 카테노이드 주식회사 스트리밍 서버, 클라이언트 단말 및 이를 이용한 av 라이브 스트리밍 시스템
JP6992104B2 (ja) * 2020-02-26 2022-01-13 株式会社Ｊストリーム コンテンツ編集装置、コンテンツ編集方法およびコンテンツ編集プログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000057691A (ja) 1998-08-10 2000-02-25 Sony Corp システムターゲットデコーダのオーディオバッファ
JP2000175152A (ja) 1998-12-04 2000-06-23 Sony Corp 多重化装置、多重化方法及び記録媒体
JP2000183957A (ja) * 1998-12-16 2000-06-30 Samsung Electronics Co Ltd デ―タ列間の連続再生を保障するための付加情報生成方法、この情報を貯蔵する記録媒体及び記録、編集及び／または再生装置
JP2001054118A (ja) 1999-06-01 2001-02-23 Sony Corp 符号化装置及び符号化方法並びに多重化装置及び多重化方法
JP2002158974A (ja) * 2000-04-21 2002-05-31 Sony Corp 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体
JP2003130661A (ja) 2001-10-24 2003-05-08 Matsushita Electric Ind Co Ltd ナビゲーション装置

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9424429D0 (en) * 1994-12-02 1995-01-18 Philips Electronics Uk Ltd Audio/video timing discrepancy management
EP0847198B1 (en) * 1995-09-29 1999-04-28 Matsushita Electric Industrial Co., Ltd. Method, device and disc for recording and reproducing interleaved bit stream on and from the disk
US6181383B1 (en) * 1996-05-29 2001-01-30 Sarnoff Corporation Method and apparatus for preserving synchronization of audio and video presentation when splicing transport streams
GB9813831D0 (en) * 1998-06-27 1998-08-26 Philips Electronics Nv Frame-accurate editing of encoded A/V sequences
EP0971542A3 (en) * 1998-07-10 2001-08-01 Tektronix, Inc. Readjustment of bit rates when switching between compressed video streams
US6507592B1 (en) * 1999-07-08 2003-01-14 Cisco Cable Products And Solutions A/S (Av) Apparatus and a method for two-way data communication
GB9930788D0 (en) * 1999-12-30 2000-02-16 Koninkl Philips Electronics Nv Method and apparatus for converting data streams
US6678332B1 (en) * 2000-01-04 2004-01-13 Emc Corporation Seamless splicing of encoded MPEG video and audio
GB0007868D0 (en) * 2000-03-31 2000-05-17 Koninkl Philips Electronics Nv Methods and apparatus for editing digital video recordings and recordings made by such methods
JP4599740B2 (ja) * 2000-04-21 2010-12-15 ソニー株式会社 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体
JP4355988B2 (ja) * 2000-04-21 2009-11-04 ソニー株式会社 情報処理装置、情報処理方法、プログラム記録媒体、プログラム、および情報記録媒体
JP4682434B2 (ja) * 2000-04-21 2011-05-11 ソニー株式会社 情報処理装置および方法、記録媒体、並びにプログラム
EP1198133A4 (en) * 2000-04-21 2004-10-06 Sony Corp INFORMATION PROCESSING DEVICE AND METHOD, PROGRAM AND RECORDED MEDIUM
EP1164796B1 (en) * 2000-06-14 2006-12-20 Eads Astrium Sas Process and system for video on demand
WO2003019512A2 (en) * 2001-08-22 2003-03-06 Gary Alfred Demos Method and apparatus for providing computer-compatible fully synchronized audio/video information
US7386223B2 (en) * 2001-11-30 2008-06-10 Matsushita Electric Industrial Co., Ltd. Method and an apparatus for stream conversion a method and an apparatus for data recording and data recording medium
WO2004019530A1 (en) * 2002-02-15 2004-03-04 Visible World, Inc. System and method for seamless switching through buffering

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000057691A (ja) 1998-08-10 2000-02-25 Sony Corp システムターゲットデコーダのオーディオバッファ
JP2000175152A (ja) 1998-12-04 2000-06-23 Sony Corp 多重化装置、多重化方法及び記録媒体
JP2000183957A (ja) * 1998-12-16 2000-06-30 Samsung Electronics Co Ltd デ―タ列間の連続再生を保障するための付加情報生成方法、この情報を貯蔵する記録媒体及び記録、編集及び／または再生装置
JP2001054118A (ja) 1999-06-01 2001-02-23 Sony Corp 符号化装置及び符号化方法並びに多重化装置及び多重化方法
JP2002158974A (ja) * 2000-04-21 2002-05-31 Sony Corp 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体
JP2003130661A (ja) 2001-10-24 2003-05-08 Matsushita Electric Ind Co Ltd ナビゲーション装置

Also Published As

Publication number Publication date
EP1515553B1 (en) 2015-06-03
US8086087B2 (en) 2011-12-27
JP4902935B2 (ja) 2012-03-21
TW200425740A (en) 2004-11-16
JP2004336488A (ja) 2004-11-25
CN100380959C (zh) 2008-04-09
KR20060009807A (ko) 2006-02-01
KR100975175B1 (ko) 2010-08-10
CN1698374A (zh) 2005-11-16
TWI246330B (en) 2005-12-21
EP1515553A4 (en) 2012-05-09
EP1515553A1 (en) 2005-03-16
US20050249202A1 (en) 2005-11-10

Similar Documents

Publication Publication Date Title
US6795499B1 (en) Encoding apparatus and method, and multiplexing apparatus and method
JP3900050B2 (ja) データ処理装置、ビデオカメラ及びデータ処理方法
JP2002158974A (ja) 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体
JP2002158972A (ja) 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体
KR20030012761A (ko) 데이터 다중화 방법, 데이터 기록 매체, 데이터 기록 장치및 데이터 기록 프로그램
KR20020020916A (ko) 정보 처리 장치와 방법, 프로그램 및 기록매체
JP2002519917A (ja) 符号化されたａｖ系列のフレームの正確な編集
JP2010061803A (ja) オーディオ／ビデオ記録装置、記録方法、再生装置、再生方法、再生プログラム及び記録プログラム
JP2006260762A (ja) データ列間の連続再生を保障するための付加情報生成方法、この情報を貯蔵する記録媒体及び記録、編集及び／または再生装置
US7974281B2 (en) Multiplexer and multiplexing method, program, and recording medium
WO2004100545A1 (ja) 情報処理装置及び方法，並びにプログラム及び記録媒体
JP2002159004A (ja) 符号化装置および方法、記録媒体、並びにプログラム
JP3918332B2 (ja) 多重化装置、多重化方法及び記録媒体
KR100677110B1 (ko) 데이터열간의 연속 재생을 보장하는 데이터의 기록및/또는 편집 장치
KR100657262B1 (ko) 데이터열간의 연속 재생을 보장하기 위한 부가 정보를저장하는 기록 매체
KR100532113B1 (ko) 데이터열간의 연속 재생을 보장하는 데이터의 기록및/또는 재생 장치
Kelly et al. Virtual editing of MPEG-2 streams
JP2009100303A (ja) 動画像符号化装置およびそのデータ処理方法
WO2004086397A1 (en) Method and apparatus for guaranteeing seamless reproduction of a plurality of data streams

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 2004728909

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 1020057000185

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 10520488

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 20048004774

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 2004728909

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1020057000185

Country of ref document: KR