JP2010183247A - Recording device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To restore imperfect MXF data in a short time when recording is incompletely stopped because of an instantaneous interruption or the like. <P>SOLUTION: A file header, a file body, and a file footer of MXF data are sequentially stored in a temporary accumulation memory 16. A recording medium control part 18 records the MXF data in a recording medium 20 from the temporary accumulation memory 16 with a range up to an index table border, an index table and a border of a subsequent fill, or an MXF data end as a write unit under the control of a control part 22. By a storage start position offset of a footer partition pack of the MXF data in the recording medium 20, the concerned position of a header partition pack is overwritten. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a recording apparatus.

JP 2007-235570 A

  Conventionally, MXF (Material Exchange Format) is known as a format for recording video data on a recording medium. A recording apparatus that records video data in the MXF format is described in Patent Document 1, for example.

  MXF data is a format in which an index table composed of access information for digital video data is combined with digital video data. The MXF data index table (IT) indicates frame boundaries of digital video data. By using IT, random access to digital video data in units of frames becomes possible.

  If the recording is incompletely stopped due to a momentary interruption or the like while the MXF data is being recorded on the recording medium, the MXF data needs to be restored. To repair MXF data, in addition to discarding incomplete video frames, it is necessary to repair an index table.

  The index table is used to randomly access moving image data included in MXF data in units of frames. Therefore, it is necessary to store the boundaries of all video frames included in the index table. Therefore, the frame boundary of MXF data is searched for repairing the index table. As another method, there is a method in which a frame boundary is stored in advance in a nonvolatile memory or the like at the time of recording, and the stored data in the nonvolatile memory is referred to.

  The former method takes time to search for a frame boundary. The latter method requires mounting a non-volatile memory, leading to an increase in cost.

  It is an object of the present invention to provide a recording apparatus that can perform index table repair in a short time without requiring a special memory.

  A recording apparatus according to the present invention is a recording apparatus that records moving image data on a recording medium in MXF (Material Exchange Format), and includes an MXF generation unit that generates MXF data including an index table, and temporarily stores the MXF data. Storage means, and recording medium control means for controlling exchange of data between the storage means and the recording medium, and among the MXF data stored in the storage means, an index table boundary, an index table The MXF data is written out from the storage means to the recording medium with the boundary between the next fill or the end of the MXF data as a writing unit.

  According to the present invention, by adopting the above-mentioned writing unit, when recording is incompletely stopped due to a momentary interruption or the like, it becomes unnecessary to repair the index table, and incomplete MXF data can be repaired in a short time. it can.

It is a schematic block diagram of a present Example. It is a figure explaining the decoding process in the case of long GOP. It is a figure explaining an interleave MXF file. It is a figure explaining an interleave MXF file. It is a figure explaining an interleave MXF file. In this embodiment, it is an example of state transition of an interleaved MXF file recorded on the recording medium 20. It is a flowchart of the operation | movement which repairs the incomplete interleave MXF file of a present Example.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  Before describing one embodiment of the present invention, the configuration of the MXF format will be described by taking as an example the case of using in combination with the MPEG (Movie Pictures Experts Group) 2 system, which is a typical compression encoding format of digital video data. To do.

  MPEG2 is a combination of motion compensation predictive coding and transform coding by DCT (Discrete Cosine Transform). The data structure of MPEG2 has a hierarchical structure, and includes a block layer, a macroblock layer, a slice layer, a picture layer, a GOP layer, and a sequence layer from the lower layer. The block layer is composed of DCT blocks that are units for performing DCT. The macroblock layer is composed of a plurality of DCT blocks. The slice layer includes a header part and one or more macro blocks. The picture layer is composed of a header part and one or more slices. A picture corresponds to one screen. Each layer boundary can be identified by a predetermined identification code.

  The GOP layer includes a header portion (sequence header) and encoded image data for a predetermined number of screens. In MPEG2, as the encoding method of each screen, intra-frame encoding, forward prediction encoding, and bidirectional prediction encoding are prepared. An intra-frame encoded image (intra-encoded image) is called an I (Intra-coded) picture. The forward prediction encoded image is called a P (Predictive-coded) picture. The bi-directional predictive coded image is called a B (Bi-directionally predictive coded) picture.

  An I picture can be decoded only with its own information. On the other hand, the P picture and the B picture require a previous image or previous and subsequent images as reference images, and cannot be decoded alone. For example, a P picture is encoded using an I picture or P picture that is temporally prior to itself as a reference image. A B picture is encoded using two images consisting of I and P pictures before and after itself as reference images. Decoding requires image data of these reference images. However, the P picture and B picture may also be encoded in the screen for small blocks in the screen.

  A group including at least one I picture and completed by itself is called a GOP (Group Of Picture). In the MPEG stream, the GOP is the smallest unit that can be accessed independently. A GOP is composed of one or more pictures. Hereinafter, for convenience, a GOP composed of only one I picture is referred to as a single GOP, and a GOP composed of a plurality of pictures including an I picture and a P / B picture is referred to as a long GOP. Furthermore, among long GOPs, a GOP having a closed structure that can be completely decoded within the GOP is called a closed GOP, and a GOP that requires an image included in the previous GOP for decoding is called an open GOP. And

  The long GOP decoding process will be described with reference to FIG. 2A shows the input frame order, FIG. 2B shows the transmission order, and FIG. 2C shows the display order after decoding. Here, it is assumed that the open GOP is composed of a total of 15 I pictures, 4 P pictures, and 10 B pictures. Each frame in the GOP is represented by I, P, or B indicating the picture type, and the frame number following this. As shown in FIG. 2A, the I / B / P position of the input frame in the GOP is B0, B1, I2, B3, B4, P5, B6, B7, P8, B9, B10, P11, B12, B13, P14. In this example, the frames B0 and B1 are decoded using the frame P14 of the previous GOP and the frame I2 in this GOP. The frame P5 is predicted from the frame I2, and the frames P8 / P11 / P14 are each predicted from the frame that is the previous P picture.

  A B picture is predicted from frames of previous and subsequent I and P pictures. For this reason, on the transmission path or the recording medium, it is necessary to determine the arrangement order of the I / B / P pictures in consideration of the decoding order. In the example of FIG. 2, as shown in FIG. 2B, the order is I2, B0, B1, P5, B3, B4, P8, B6, B7, P11, B9, B10, P14, B12, and B13. .

  As shown in FIG. 2C, the decoder first decodes the frame I2. Then, using this frame I2 and frame P14 of the previous GOP, the frames B0 and B1 are decoded and output, and then the frame I2 is output.

  Next, the frame P5 is decoded using the frame I2. Frames B3 and B4 are decoded and output using frames I2 and P5, and then frame P5 is output.

  Similarly, an I picture and a P picture necessary for decoding a B picture are decoded and output before the B picture, and then an I / P picture is output.

  An example of a mapping structure for the MXF format MPEG stream will be described with reference to FIGS.

  MXF is a file format standard defined by SMPTE (Society of Motion Picture and Television Engineers). The mapping structure for the MPEG stream described here is defined in SMPTE-381M. Hereinafter, an MXF file having a structure in which video data and audio data are frame-interleaved in accordance with the MXF specification such as MSPTE-381M is referred to as an interleaved MXF file.

  FIG. 3A shows the file structure of an interleaved MXF file. As shown in FIG. 3A, the interleaved MXF file includes a file header (FH), a file body (FB), and a file footer (FF). The file header includes a header partition pack (HPP) and header metadata. The HPP includes a header identifier, information indicating the format or file format of data arranged in the file body, a footer partition pack (FPP) storage start offset, and the like. The header metadata stores metadata in units of files such as file creation date and time.

  The file body includes a body partition pack (BPP), an edit unit (EU), and an index table (IT). The BPP includes a body identifier, a partition pack (which is HPP or BPP) arranged immediately before, a storage start offset of itself and FPP, and the like. In the area divided by the BPP, 0 or 1 IT and 1 or a plurality of edit units (EU) are arranged. In the EU, video / audio data for each frame is possible. The IT stores EU information included in the previous area delimited by the BPP. Details of EU and IT will be described later.

  The file footer (FF) includes a footer partition pack (FPP), an index table (IT), and a random index pack (RIP). The FPP includes a footer identifier, a BPP arranged immediately before, a storage start offset of the FPP, and the like. The RIP includes a header indicating the RIP, a storage start offset of each partition pack in the interleaved MXF file, and the data size of the RIP itself. A fill item (NULL data) for boundary adjustment is arranged immediately after each element (PP, IT, etc.) constituting the interleaved MXF file. However, for simplification of description, it is omitted from the drawings and the following description.

  A collection of EUs for each region delimited by BPP is called an essence container. That is, the essence container accommodates video / audio data that is actually reproduced based on the interleaved MXF file.

  IT arranged in the file body and the file footer is an aggregate of index table segments as shown in FIG. For example, when the system reads the interleaved MXF, each IT is searched and read, and the IT of the entire MXF file is reconstructed. Thereby, the information regarding EU of the whole MXF file can be obtained.

  FIG. 3C shows a configuration example of IT. The IT is encoded using a KLV (Key-Length-Value) code. In the KLV code, the key part is an identifier indicating a data item conforming to SMPTE-335M / RP210A, and has a data length of 16 bytes. The lens part has a data length of 4 bytes, and holds a value representing the data length after the lens part in bytes. The Value part is an area for storing the data body. The Value part includes a local tag part having a length of 2 bytes, a length part having a length of 2 bytes, and a data part having a variable length for storing a data body.

  The contents of IT will be specifically described. At the head of IT, a 16-byte index table segment key is arranged. In the Value section, first, a local tag indicating an instance ID, a length (Length), and an instance ID are stored in UUID (Universal Unique ID) format with respect to the instance ID information.

  Subsequently, a local tag, a length (Length), and an entity of the index edit rate are stored for an index edit rate. The index edit rate indicates whether the frame rate of the video data is 29.97 Hz / 25.00 Hz / 23.98 Hz.

  Subsequently, the index start position is similarly stored in the order of the local tag, the length (Length), and the substance. The index start position indicates the number of the EU managed by this IT from the beginning of the interleaved MXF file.

  Subsequently, the index duration is similarly stored in the order of the local tag, the length (Length), and the substance. The index duration holds information on the number of EUs managed by this IT.

  Subsequently, the edit unit byte count is similarly stored in the order of the local tag, the length (Length), and the substance. The edit unit byte count holds the data length of the video frame when the video frame has a fixed length, and holds “0” when the video frame has a variable length.

  Subsequently, the index SID is similarly stored in the order of the local tag, the length (Length), and the substance. Subsequently, the body SID is similarly stored in the order of the local tag, the length (Length), and the substance. The index SID and the body SID are fixed values in the MXF file.

  Subsequently, a slice count, a delta entry array (DEA), and an index entry array (IEA) are stored in a similar structure. The slice count, delta entry array, and index entry array will be described later.

  FIG. 4 shows an example of EU and DEA. That is, FIG. 4A shows the configuration of the EU. FIG. 4B shows the configuration of the DE DE of IT shown in FIG. The EU holds one frame of data. The EU includes system items, picture items, and sound items each including metadata corresponding to the frame, MPEG2 data, and audio ES. The system item (SYS-I) and the sound item (SI) are fixed length (CBE: Constant Bytes per Element). The picture item (PI) has a variable length (VBE: Variable Bytes per Element). One EU is sliced for each variable length data. In the example shown in FIG. 4, since PI has a variable length, the slice is cut at the end of PI, and the first half is slice 0 and the second half is slice 1. (Slice number-1) is stored in the slice count of IT. The DEA stores the offset and size from the head of each slice of SYS-I, PI, and SI included in the EU.

  FIG. 5 shows a configuration example of the essence container and the IEA. That is, FIG. 5A shows the configuration of the essence container. FIG. 5B shows the configuration of the IT IEA shown in FIG. Each index entry includes a temporal offset, a key frame offset, a flag, a stream offset, and a slice offset. Temporal offset indicates information on rearrangement of decoding order and output order. The key frame offset (Key-Frame Offset) indicates position information of a key frame used for decoding. Flags stores the type of frame. The stream offset indicates an offset in the essence container of the EU. The slice offset (Slice Offset) stores an offset from the EU head of each slice in the EU.

  FIG. 1 is a schematic block diagram of a recording apparatus which is an embodiment of the present invention and records moving image data on a recording medium using MXF. Audio data to be recorded is input to the audio input terminal 10, and video data to be recorded is input to the video input terminal 12. The MXF generation unit 14 generates interleaved MXF file data from the audio data and video data from the input terminals 10 and 12 and stores them in the temporary storage memory 16. The MXF generation unit 14 supplies information related to the interleaved MXF file data stored in the temporary storage memory 16 to the control unit 22.

  The temporary storage memory 16 temporarily stores interleaved MXF file data from the MXF generation unit 14. The temporary storage memory 16 is also used as a work memory of the control unit 22 as a write / read buffer for the recording medium 20. The recording medium control unit 18 can write data stored in the temporary storage memory 16 to the recording medium 20, and can read data stored in the recording medium 20 and store it in the temporary storage memory 16.

  The control unit 22 controls the entire recording apparatus shown in the figure. The control unit 22 also has a function of checking the contents of a file read from the recording medium 20 to the temporary storage memory 16 and developed, and rewriting / adding data. The recording medium control unit 18 reads the file whose data has been rewritten / added from the temporary storage memory 16 and records it on the recording medium 20. The control unit 22 further checks the integrity of the recorded interleaved MXF file on the recording medium 20 via the recording medium control unit 18 and performs a repair operation if it is incomplete.

  The configuration and basic functions of the MXF generation unit 14 will be described. The MPEG2 encoding unit 30 compresses and encodes the video data from the video input terminal 12 in the MPEG2 format, and outputs the compressed data to the picture item (PI) generation unit 32. The PI generation unit 32 adds a predetermined header to the compressed data in frame units in the MPEG2 format from the MPEG2 encoding unit 30 to form a picture item. The sound item (SI) generation unit 34 divides the audio data from the audio input terminal 10 in frame units of the corresponding video data, and adds a predetermined header to make a sound item. The system item (SYS-I) generation unit 36 generates a system item (SYS-I) attached to each EU head of the interleaved MXF file. Each of the PI generation unit 32, the SI generation unit 34, and the SYS-I generation unit 36 supplies the generated item to the sound item (EU) generation unit 38.

  The EU generation unit 38 combines the items input from the PI generation unit 32, the SI generation unit 34, and the SYS-I generation unit 36 to generate an EU. The generated EU is supplied to the file body generation unit 40. The EU generation unit 38 also supplies the generated EU total size and the size of each slice to the index table (IT) generation unit 42.

  The IT generation unit 42 generates IEA and DEA from the overall size and each slice size received from the EU generation unit 38 and sets it as an index table (IT). Then, the IT generation unit 42 outputs the generated IT to the file body generation unit 40 and the file footer generation unit 46. Note that the IT generated by the IT generation unit 42 has a fixed size in the present embodiment, and fill items are filled when the EU size is insufficient for the fixed size.

  The file body generation unit 40 outputs the EU from the EU generation unit 38 to the temporary storage memory 16. The file body generation unit 40 also outputs data obtained by connecting IT to the body partition pack (BPP) to the temporary storage memory 16 each time a predetermined number of EUs are output to the temporary storage memory 16. Although details will be described later, the BPP is generated using the file header size from the file header generation unit 48, and IT is supplied from the IT generation unit 42. The file body generation unit 40 counts the EU data size output to the temporary storage memory 16 before outputting the BPP, and outputs the count value plus the file header size to the RIP generation unit 44.

  The RIP generation unit 44 generates a random index pack (RIP) based on the BPP insertion position acquired from the file body generation unit 40 and outputs the random index pack (RIP) to the file footer generation unit 46.

  The file header generation unit 48 generates a file header and outputs it to the temporary storage memory 16. The file header generation unit 48 outputs the generated file header size information to the file body generation unit 40 and the file footer generation unit 46.

  The file footer generation unit 46 generates a footer partition pack (FPP) based on the file header size information from the file header generation unit 48 and the RIP from the RIP generation unit 44. The file footer generation unit 46 supplies the generated FPP to the temporary storage memory 16. The file footer generation unit 46 also concatenates the RIP generated by the RIP generation unit 44 to the IT generated by the IT generation unit 42 and outputs it to the temporary storage memory 16.

  The characteristic operation of the embodiment shown in FIG. 1 will be described with reference to FIG. FIG. 6 shows an example of the contents of an interleaved MXF file generated on the recording medium 20.

  When receiving a recording instruction from an instruction unit (not shown) of the user interface, the control unit 22 instructs the MXF generation unit 14 to start generating an interleaved MXF file. In the MXF generation unit 14, upon receiving a recording instruction from the control unit 22, the file header generation unit 48 generates a file header adapted to the encoding method and stores it in the temporary storage memory 16. However, since the FPP storage start offset value is undetermined at this time, a dummy value (here, “0”) is substituted. The file header generation unit 48 also notifies the file body generation unit 40 and the file footer generation unit 46 of the size of the generated file header.

  The MPEG2 encoding unit 30 of the MXF generation unit 14 compresses and encodes the uncompressed video data input from the video input terminal 12 using the MPEG2 method, and supplies the compressed video data to the PI generation unit 32. The PI generation unit 32 adds a predetermined header in units of frames to the compressed video data from the MPEG2 encoding unit 30 and outputs the result to the EU generation unit 38. At the same time, the SI generation unit 34 divides the uncompressed audio data from the audio input terminal 10 in accordance with the frame interval of encoding by the MPEG2 encoding unit 30, adds a predetermined header, and outputs it to the EU generation unit 38. . The SYS-I generation unit 36 generates a SYS-I in accordance with the interval of the frame encoded by the MPEG2 encoding unit 30 and outputs it to the EU generation unit 38.

  The EU generation unit 38 combines the PI, SI, and SYS-I from the item generation units 32, 34, and 36 to generate an EU, and outputs the EU to the file body generation unit 40. At the same time, the EU generation unit 38 supplies information necessary for generating an IT to the IT generation unit 42. For example, DEA, generated EU size, included SYS-I, PI and SI sizes, and MPEG2 frame data encoding format (I / B / P) included in PI.

  The IT generation unit 42 generates IT each time the information received from the EU generation unit 38 is accumulated for a predetermined number of EUs. The generated IT is supplied to the file body generation unit 40 and the file footer generation unit 46.

  In response to a recording instruction from the control unit 22, the file body generation unit 40 outputs the head body partition to the temporary storage memory 16 and notifies the control unit 22 of the output to the temporary storage memory 16. However, since the FPP storage start offset value is undetermined at this time, a dummy value (here, “0”) is substituted. Thereafter, the file body generation unit 40 outputs the EU from the EU generation unit 38 to the temporary storage memory 16. Each time the input / output EU reaches a predetermined number, the file body generation unit 40 counts the file header size input from the file header generation unit 48 and the data size output to the temporary storage memory 16 by itself. Then, the file body generation unit 40 determines a storage start offset on the interleaved MXF file of the immediately preceding and own partition pack, and generates a BPP using those values. However, since the FPP storage start offset value is undetermined at this time, a dummy value (here, “0”) is substituted.

  Further, the file body generation unit 40 combines the generated BPP with the IT from the IT generation unit 42 and outputs it to the temporary storage memory 16. Then, the file body generation unit 40 notifies the control unit 22 that the IT has been output to the temporary storage memory 16. The file body generation unit 40 outputs the calculated BPP storage start position offset to the RIP generation unit 44.

  The control unit 22 acquires the output status from the MXF generation unit 14 to the temporary storage memory 16. Immediately after the start of recording, when the MXF generation unit 14 notifies the output of the file header and the first BPP to the temporary storage memory 16, the control unit 22 controls the recording medium control unit 18 to control the file header and the first BPP. Is written in the recording medium 20 (FIG. 6A).

  Thereafter, every time the notification of outputting IT to the temporary storage memory 16 is received from the MXF generation unit 14, the control unit 22 similarly notifies the recording medium 20 to the IT notified from the unoutput EU. (FIG. 6B). By continuously outputting to the recording medium 20 up to this IT, the file body portion of the interleaved MXF file is formed on the recording medium 20 (FIG. 6C). That is, in this embodiment, the index table boundary is used as a writing unit. When a fill continues in the index table, the fill boundary or end is used as a writing unit.

  When receiving a recording stop instruction from an instruction unit (not shown) of the user interface, the control unit 22 instructs the MXF generation unit 14 to stop recording. When the recording stop instruction is received, the MPEG2 encoding unit 30, the item generation units 32, 34, and 36, the EU generation unit 38, and the file body generation unit 40 end the recording operation at the EU boundary. The IT generation unit 42 outputs the last generated IT to the file footer generation unit 46. The RIP generation unit 44 generates an RIP based on the information received from the file body generation unit 40 and outputs the RIP to the file footer generation unit 46.

  When the file footer generation unit 46 confirms that the file body generation unit 40 has output the final EU to the temporary storage memory 16, the file footer generation unit 46 refers to the RIP from the RIP generation unit 44 to generate a footer partition pack (FPP). That is, the file footer generation unit 46 acquires information such as the BPP arranged immediately before and the FPP storage start offset from the RIP, and generates an FPP using these. Next, the file footer generation unit 46 sequentially outputs the generated FPP, the input final IT, and the RIP to the temporary storage memory 16 and notifies the control unit 22 to that effect.

  When the control unit 22 receives the notification that the FPP, the final IT, and the RIP are output from the temporary storage memory 16 from the MXF generation unit 14, the control unit 22 causes the recording medium control unit 18 to output them to the recording medium 20 (FIG. 6 ( D)). Next, the control unit 22 causes the recording medium 20 to output HPP and BPP to the temporary storage memory 16 using the RIP stored in the temporary storage memory 16. The FPP storage start offset is acquired using the RIP on the temporary storage memory. Then, the FPP storage start offset in the HPP and BPP read out to the temporary storage memory 16 (it is undecided during the recording operation and substituted with “0”) is overwritten in the order of BPP and HPP (see FIG. 6 (E)). Thereafter, HPP and BPP are recorded from the temporary storage memory 16 to the recording medium 20 by overwriting. Thus, an interleaved MXF file is completed on the recording medium 20.

  With reference to FIG. 7, a method for checking and repairing an incomplete interleaved MXF file due to the occurrence of an instantaneous interruption will be described. FIG. 7 shows an operation flowchart of the control unit 22 that checks and repairs the incompletely interleaved MXF file of the recording medium 20.

  When returning from the momentary interruption, the control flow shown in FIG. 7 starts. The end of the interleaved MXF file is read from the recording medium 20 to the temporary storage memory 16, and the control unit 22 checks whether or not a RIP is assigned (S1). Specifically, the determination is made based on whether or not there is a header indicating RIP at a position returned by the data size of the RIP itself stored at the end.

  When there is RIP (S1), it is checked whether or not the FPP storage start offset has been registered in the HPP (S2). When not registered, that is, when the dummy value “0” is stored (S2), it is determined that the interleaved MXF file is in the state shown in FIG. 6D. In this case, the storage start offset of the HPP and each BPP is acquired from the RIP (S3). Next, using the BPP storage start offset acquired in S3, each BPP is read from the recording medium 20 to the temporary storage memory 16, and the correct FPP storage start offset is set and written back to the recording medium 20. Similarly, the FPP storage start offset of the HPP of the recording medium 20 is updated (S5). This completes the repair process for the interleaved MXF file.

  When the FPP storage start offset is stored in the HPP (S2), it is determined that the interleaved MXF file is in the state shown in FIG. Therefore, the process ends without performing the repair process.

  If it is determined that there is no RIP at the end (S1), it is checked whether the end of the interleaved MXF file is IT (S6). The IT generated by the recording apparatus of the present embodiment is a fixed size. Therefore, it is possible to determine whether or not the end is IT by detecting whether or not a header indicating IT can be detected by going back the fixed size from the end.

  If the end is not IT (S6), the interleaved MXF file is in the state shown in FIG. 6A, and it is determined that there is no valid video data. Therefore, the interleaved MXF file is deleted from the recording medium 20 (S7), and the process ends.

  If the end is IT (S6), it is determined that the interleaved MXF file is in the state shown in FIG. 6B or FIG. The header area of the PP arranged immediately before IT (if there is no momentary interruption during the restoration process, this PP is BPP) is changed to FPP by rewriting it to indicate FPP (S8). . The storage start offset of the PP itself that has been converted to FPP in S8 is acquired, and is stored in the work area of the temporary storage memory 16 as the FPP storage start offset. Next, the FPP storage start offset saved in S9 is extracted and set in the PP being processed (S10). The storage start offset of the PP being processed is acquired and saved in the work area of the temporary storage memory 16 (S11).

  It is judged from the header whether the PP being processed is HPP (S12). If it is an HPP (S12), a RIP is generated using each PP storage start offset saved in the temporary storage memory 16 in S79 and S11, and added to the end of the interleaved MXF file (S13). If the PP being processed is not an HPP (S12), the storage start offset of the previous PP is acquired from the PP being processed (S14), and the PP is changed to the previous PP to be processed (S15). Then, the previous partition pack is similarly read from the recording medium 20 to the temporary storage memory 16, and the processing after S10 is repeated.

  In the present embodiment, it is not necessary to search for the frame boundary in the MXF data in order to restore the index table that stores the boundaries of all video frames in units of frames. Further, it is not necessary to store the frame boundary in advance in a nonvolatile memory or the like at the time of recording in order to restore the MXF file data. Therefore, in this embodiment, incomplete MXF data can be repaired in a short time, and cost increase factors such as a nonvolatile memory can be avoided.

Claims (2)

A recording device for recording moving image data on a recording medium in MXF (Material Exchange Format),
MXF generation means for generating MXF data including an index table;
Storage means for temporarily storing the MXF data;
Recording medium control means for controlling exchange of data between the storage means and the recording medium,
Of the MXF data stored in the storage means, the MXF data from the storage means to the recording medium with the index table boundary, the index table and the subsequent fill boundary, or the end of the MXF data as write units. A recording apparatus characterized by writing out the data. further,
Whether the MXF data recorded on the recording medium is incomplete is determined based on whether the end of the MXF data recorded on the recording medium is an index table or a boundary between the index table and the subsequent fill. Means to
Means for restoring the MXF data when the MXF data recorded on the recording medium is incomplete, and means for changing a partition pack including a final index table of the MXF data into a footer partition pack. The recording apparatus according to claim 1.

Images