[go: up one dir, main page]

WO2013115584A1 - Appareil et procédé pour la gestion d'un fichier multimédia - Google Patents

Appareil et procédé pour la gestion d'un fichier multimédia Download PDF

Info

Publication number
WO2013115584A1
WO2013115584A1 PCT/KR2013/000809 KR2013000809W WO2013115584A1 WO 2013115584 A1 WO2013115584 A1 WO 2013115584A1 KR 2013000809 W KR2013000809 W KR 2013000809W WO 2013115584 A1 WO2013115584 A1 WO 2013115584A1
Authority
WO
WIPO (PCT)
Prior art keywords
media file
information
file
media
box
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/KR2013/000809
Other languages
English (en)
Korean (ko)
Inventor
유성열
이병대
박경모
송재연
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Industry Academic Cooperation Foundation of Kyonggi University
Original Assignee
Samsung Electronics Co Ltd
Industry Academic Cooperation Foundation of Kyonggi University
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 Samsung Electronics Co Ltd, Industry Academic Cooperation Foundation of Kyonggi University filed Critical Samsung Electronics Co Ltd
Publication of WO2013115584A1 publication Critical patent/WO2013115584A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/30—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording
    • G11B27/3027—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording used signal is digitally coded
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40—Data acquisition and logging
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/30—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording
    • G11B27/309—Table of contents
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • 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/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Definitions

  • the present invention relates to an apparatus and method for managing a media file, and more particularly, to an apparatus and method for managing different versions of media files generated due to modification of the media file.
  • FIG. 1 is a diagram illustrating a logical configuration of an International Organization for Standardization (ISO) based media file.
  • ISO International Organization for Standardization
  • the media file 100 includes a header area 110, a metadata area 120, and a media data area 130.
  • the header area 110 includes basic information of data included in the media file.
  • the header area 110 may include information such as a content identifier, a content producer, a production time, and the like.
  • the media file may include map configuration information of tracks.
  • the metadata area 120 includes individual information about a plurality of media objects of data included in the media file.
  • the metadata area 120 includes various profile information for decoding the media object and information about the location of the media object.
  • the media object may correspond to one image frame displayed on the screen every unit time in the case of a video as the minimum unit of the content, and one audio frame reproduced every unit time in the case of a voice.
  • the media data area 130 is an area where media objects are actually stored.
  • the physical organization of an ISO based media file consists of boxes. Individual boxes can consist of related data and sub-boxes or exist as container boxes consisting solely of sub-boxes.
  • the track 140 illustrated in FIG. 1 is physically stored as a track box, and the track box is a container box including various sub-boxes that store track header information, media information, media decoding information, and the like.
  • 2 to 4 are diagrams for explaining a packaging technique for managing an ISO-based media file.
  • a packaging scheme is used to manage ISO-based media files.
  • the packaging scheme may store individual versions of media files that exist as independent entities in a physically identical container such as a directory.
  • metadata including version information of a related media file and a physical storage location of the file may be stored in a container.
  • This file structure is generated as a single file using a packaging program such as a ZIP file format or a Tape Archive (TAR) file format, and then transmitted or stored.
  • TAR Tape Archive
  • FIG. 4 illustrates a method of packaging and storing a plurality of related media files using a container as another example of a packaging technique.
  • the actual media file is stored as a bit stream at an arbitrary location inside the container, and stores metadata such as version information, file name, size information, offset information indicating a location in the container, etc. Save all versions of media files to a file.
  • the ISO-based media files discussed so far are stored as independent objects when the media files are modified, without including information indicating their interrelationships with previous versions of the media files.
  • the pre-modification media and the post-modification media files are stored as physically separate files, and the media files after modification only store the final modified results, and do not contain the data necessary for the change history and recovery of the original data. Do not. Therefore, it is difficult to find the data required for the change history and data recovery of the media file, which makes it difficult to manage the media file.
  • the present invention provides a media file management apparatus and method for managing the media file efficiently.
  • the present invention provides an apparatus and method for managing a media file that can easily know the state before and after the modification of the media file by generating information to know the association between the media files when the media file is modified.
  • the present invention provides a media file management apparatus and method for easily plural original files by using another media file derived from the original file when the original of the media file is damaged.
  • an apparatus for managing a media file includes: an input unit configured to receive a first media file; An output unit for outputting a second media file; And a controller configured to generate the second media file including at least one of change information of the first media file and recovery information of the first media file according to whether the first media file is modified.
  • the media file includes information about the first media file, and the second media file includes location information that stores the first media file.
  • the present invention also provides a method of managing a media file. Receiving a first media file; And generating a second media file including at least one of change information of the first media file and recovery information of the first media file according to whether the first media file is modified.
  • the file includes information about the first media file, and the second media file includes location information that stores the first media file.
  • the media file when the media file is modified, the media file includes the file change information and the information for recovering the original file, so that the media file can be efficiently managed and the original file can be easily recovered.
  • FIG. 1 illustrates a logical configuration of an ISO based media file
  • 2 to 4 are diagrams for explaining a packaging technique for managing an ISO based media file
  • FIG. 5 is a diagram illustrating an apparatus for managing a media file according to an embodiment of the present invention.
  • 6 and 7 illustrate a method of generating change information of a media file and information for recovering an original file according to one embodiment of the present invention
  • 10 to 15 are diagrams illustrating a method of generating change information of a media file and information for recovering an original file according to another embodiment of the present invention
  • FIG. 16 to 20b are views illustrating a method of generating change information of a media file and information for recovering an original file according to another embodiment of the present invention.
  • FIG. 21 illustrates an operation of a media file management apparatus according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating a media file management apparatus 500 according to an embodiment of the present invention.
  • the media file management apparatus 500 includes an input unit 510, an output unit 530, and a controller 520.
  • the controller 520 When the media file is input to the input unit 510 (2100), when the media file is not needed to be modified, the controller 520 generates a final media file using the input media file and outputs the generated media file through the output unit 530. .
  • the controller 520 may recover the original file by using information about the original file included in another media file derived from the original media file.
  • 6 and 7 illustrate a method of generating change information of a media file and information for recovering an original file according to an embodiment of the present invention.
  • a media file includes a prsv (preservation) box 600, wherein the prsv box 600 is a container box and at least one of a ptbl (preservation table) box 610.
  • the ptbl box 610 provides a list of all previous versions of the media files contained in the current file and is located at the top level of the ISO based media file.
  • the current file means the most recently modified file when the original file is modified several times.
  • the pdat box 620 stores the actual data of the previous version file.
  • offset_size One of ⁇ 0, 4, 8 ⁇ and indicates the length in bytes of the offset_within_prsv field.
  • next_preservation_ID The preservation_ID value to be used next.
  • the initial value is set to 1, and a file using the same preservion_ID does not exist.
  • preservation_entry_count The number of all previous version files contained in the current file.
  • preservation_date The date the media file of this version was saved.
  • preservation_ID ID of the file.
  • offset_within_prsv The relative starting position within the prsv box of the file.
  • preservation_ID ID of the file.
  • the version # 1 file 700 which is the original file in FIG. 7, the next_preservation_ID field of the ptbl box included in the prsv box 730 and The preservation_entry_count field is set to 1 and 0, respectively.
  • the data of the version # 1 file 700 is stored as metadata inside the version # 2 file 710, and the version # The ptbl box 740 of the two file 710 is updated.
  • the next_preservation_ID field and the preservation_entry_count field of the ptbl box 740 in version # 2 are updated to 2 and 1, respectively.
  • a pdat box 750 for storing data of the version # 1 file 700 is newly created.
  • the data of the version # 2 file 710 is stored as metadata in the version # 3 file 720.
  • a pdat box 760 for storing data of the version # 2 file 710 is newly added to the version # 3 file 720, and the ptbl box 740 of the version # 3 file 720 is updated.
  • the next_preservation_ID field and the preservation_entry_count field of the ptbl box 740 of the version # 3 file 720 are updated to 3 and 2, respectively.
  • FIG 8 and 9 are views illustrating a method of generating change information of a media file and information for recovering an original file according to another embodiment of the present invention.
  • the file before modification is regarded as one metadata and stored in the file after modification, but the iloc (item location) box defined in the ISO media file format for storing the location information of the file before modification 810 and an iinf (item information) box 820 are utilized. That is, prsv box 800 provides a list of all previous versions of the files contained in the current file. The iloc box 810 and the iinf box 820 provide location information on the data of the previous version file stored in the media data (mdat) box 830.
  • next_preservation_ID Preservation_ID value to be used next. The initial value is set to 1, and there is no file using the same preservion_ID.
  • preservation_entry_count The number of all previous version files contained in the current file.
  • preservation_date The date the media file of this version was saved.
  • preservation_ID ID of the file.
  • the prsv box 930 of the current file 950 Provides a list of the two previous versions of the file, with the preservation_ID of the previous version's file set to "file_2010.12.11.09.11” and "file_2011.11.22.11.25.34".
  • the iinf box 910 search for the entry whose item_name is set to "file_2010.12.11.09.11”, and extract the item_ID of the entry.
  • the entry having the item_ID value is searched in the iloc box 900 using the retrieved item_ID (e.g., 2) to extract the offset information (e.g., 0x4500) in the mdat box 920 (2). Since the offset information indicates the location information where the previous version of the file is stored in the mdat box 920, the previous version of the file "file_2010.12.11.09.11" is extracted from the corresponding location of the mdat box 920 (3).
  • the offset information indicates the location information where the previous version of the file is stored in the mdat box 920
  • the previous version of the file "file_2010.12.11.09.11” is extracted from the corresponding location of the mdat box 920 (3).
  • 10 to 15 are diagrams illustrating a method of generating change information of a media file and information for recovering an original file according to another embodiment of the present invention.
  • the entire file is regarded as one bit stream, and the difference between the bit stream units and the change history are stored for the file before and after modification.
  • FIG. 10 is a diagram for explaining a delta part before / after a modification when a media file is modified, where the delta part is a portion of the contents of the pre-modification media file that is deleted or changed in the post-modification file.
  • the version # 2 file 1010 is a file generated by modifying the version # 1 file 1000. Looking at the two files, the (0x00 to 0x10) portions 1040 and (0) of the version # 1 file 1000 are described. The 0x10-0x50 portion 1045 and the 0xD0-0xF0 portion 1060 are retained in the version # 2 file 1010, while the (0x50-0xA0) portion 1050 of the version # 1 file 1000 is the version # 2 file.
  • the (0xA0 to 0xD0) portion 1055 of the version # 1 file 1000 is changed and stored in the (0x70 to 0xA0) portion 1070 of the version # 2 file 1010.
  • the (0x10 to 0x30) portions 1065 and (0xC0 to 0xE0) portions of the version # 2 file 1010 (1075) are newly added portions that do not exist in the version # 1 file 1000.
  • the delta portion 1020 represents the portion of the version # 1 file 1000 that has been deleted or changed from the version # 2 file 1010, and thus the delta portion 1020 represents the (0x50-0xA0) of the version # 1 file 1000.
  • the portions 1050 and (0xA0 to 0xD0) are respectively set to (0x00 to 0x50) 1080 and (0x50 to 0x80) 1085 to store the portions 1055.
  • the change information (eg, change history) 1030 includes information for restoring a file before modification in the current media file, specifically, using a version # 2 file 1010 and a delta part 1020 which are files after modification. Includes information needed to restore version # 1 file 1000.
  • the location information and the size information of the version # 1 file 1000 in the change information 1030 eg, source_offset,
  • the size (1) is used to search for an entry (1) corresponding to the (0x00 to 0x10) portion 1040 of the version # 1 file 1000 and check a location (eg, source_data_location) where data used for restoration is stored.
  • source_data_offset indicates location information in the version # 2 file 1010
  • "1" indicates location information in the delta part 1020. Since the (10x00 to 0x10) portion 1040 of the version # 1 file 1000 is used without change in the version # 2 file 1010, the source_data_location field is set to "0". Also, source_data_offset is also set to (0x00) because the location in version # 2 file 1010 starts at 0x00. Accordingly, the (0x00 to 0x10) portion 1040 of the version # 1 file 1000 may be restored using the (0x00 to 0x10) portion 1067 of the version # 2 file 1010.
  • the delta portion is used to restore this portion.
  • Data stored in (1020) should be utilized, and since source_data_offset is set to (0x00), the (0x50 ⁇ 0xA0) portion 1050 of the version # 1 file 1000 is (0x00-0x50) of the delta portion 1020. It may be recovered using the part 1080.
  • FIG. 11 is a diagram showing boxes provided for storing delta parts and change information in a media file, and relationships between these boxes.
  • a media file includes a prsv box 1110 and a number of boxes 1100 and 1130, which prsv box 1110 includes a pdat box 1120 as a container box and an ISO based media file. Located at the top level. The pdat box 1120 also stores the delta portion and the change history.
  • preservation_date The date the file was preserved before modification.
  • -data_delta The part of the file before modification that is not included in the current file.
  • offset_size One of ⁇ 0, 4, 8 ⁇ and the length in bytes of the offset field (source_base_offset, offset_within_preservation_vault).
  • length_size A value of one of ⁇ 0, 4, 8 ⁇ indicating the length in bytes of source_size.
  • source_base_offset The relative position in the file before modification.
  • source_size The size of the data to be copied from offset_within_preservation_valut.
  • preservation_vault_location Location where data needed to recover a file before modification is stored. 0 indicates the current file, and 1 indicates the data_delta of the pdat box.
  • offset_within_preservation_vault The offset within the location indicated by preservation_vault_location.
  • step 1200 a prsv box is inserted into a file after modification (1210), and a change history is modified (1220).
  • the step 1200 of calculating the delta part and the change history of the file before the modification is divided separately into a left group and a right group based on the prsv box.
  • the (0x00 to 0x20) part 1300, the (0x50 to 0xA0) part 1320, and the (0xC0 to 0xF0) part 1330 of the version # 1 file 1301 may be version # 2.
  • the file 1302 remains intact, but the (0x20-0x40) portion 1310 has been changed, the (0xA0-0xC0) portion 1325 has been deleted, and the (0x00-0x20) portion of the version # 2 file 1302 ( 1340).
  • the change information 1370 includes information on the change history of the version # 1 file 1301 as described above, and reference numerals 1345, 1350, 1355, 1360, and 1365 refer to the version # 1 file 1301, respectively. It contains information about the change history of the numbers 1300, 1310, 1320, 1325, and 1330.
  • the prsv in the version # 2 file 1302 is compared with the version # 1 file 1301 and the version # 2 file 1302.
  • the left box group is compared with the left box group, and the right box group is compared with the right box group based on the portion where the box should be located.
  • the version # 2 file 1302 is used as shown by reference number 1340 (0x00 to 0x20). Instead of using the position from the beginning of, we compute the change history by setting the position from the beginning of the box group on the right to zero.
  • the delta portion 1375 includes information about reference numerals 1310 and 1325, which are deleted or changed in the version # 1 file 1301, and reference numerals 1380 and 1385 correspond to reference numerals 1310 and 1325, respectively. do.
  • the prsv box 1315 of the version # 1 file 1301 is not used in the version # 2 file 1302, the prsv box 1315 of the version # 1 file 1301, that is, the version # 1 file 1301 is used.
  • the (0x40-0x50) portion 1315 of must be stored in the delta portion 1375.
  • reference numeral 1460 of the delta portion 1375 stores information about the prsv box 1315 of version # 1
  • reference numeral 1450 denotes the prsv box 1315 of version # 1. Change information about is shown.
  • the preservation_vault_location is '1' at reference numeral 1450
  • information about the (0x40 to 0x50) portion 1315 of the version # 1 file 1301 is stored in the (0x40 to 0x50) portion 1460 of the delta box 1375.
  • the position and size of the prsv box 1110 included in the version # 2 file 1302 are determined, and the prsv box 1110 is inserted into the version # 2 file 1302 (1210).
  • the size and location of the prsv box 1520 of the version # 2 file 1302 is determined. Since the position of the box group existing on the right side of the prsv box 1520 of the version # 2 file 1302 is set to "0", the portion of the version # 2 file 1302 that contains the change history is created. Modify the position from to with the calculated value with the position set to "0". Accordingly, in FIG. 15, reference numeral 1500 in the padt box 1530 of the version # 2 file 1302 is changed to a storage location of data used to restore the corresponding part, that is, offset_within_preservation_vault, to “0x80”. For this reason, reference numeral 1440 of FIG.
  • 16 to 20b are views illustrating a method of generating change information of a media file and information for recovering an original file according to another embodiment of the present invention.
  • the delta portion of the file before and after the modification and the change history information are similar to those described above, but the media in which the actual media object is stored is not compared to the bit stream regardless of the internal structure.
  • the data area and other areas are processed separately.
  • the box where the actual media object is stored in the ISO media file format is the mdat box.
  • the delta part, the change history, and the information where the mdat box is located are stored.
  • the original data is modified in the form of a bit stream and stored as metadata inside the file.
  • the prsv box 1600 includes a ptbl box 1610 and a pdat box 1620 as a container box, and the pdat box 1620 includes a preservation media data change history box (pmch) box. 1630.
  • the ptbl box 1610 provides a list of all previous versions of the files contained in the current file, and there is a pdat box 1620 corresponding to each previous version of the media file contained in the ptbl box 1610.
  • the pdat box 1620 stores the delta portion of the mdat box along with the original data of all boxes except the mdat box in the version of the media file.
  • the delta part of the mdat box stores the difference from the mdat box existing in the immediately previous media file. For example, if the current media file is 3.0 and the prsv box 1600 stores information about version 1.0 and 2.0 media files, there are two pdat boxes 1620 and one pdat box.
  • the pmch box 1630 includes information about the location of the mdat box and the change history of the mdat box in the previous version of the file.
  • next_preservation_ID The preservation_ID value to be used next.
  • the initial value is set to 1, and a file using the same preservion_ID does not exist.
  • preservation_entry_count The number of previous version files contained in the file.
  • preservation_date The date the media file of this version was saved.
  • preservation_ID ID of the file.
  • preservation_ID ID of the file.
  • Metadata_box Original data from all boxes except the mdat box.
  • mdat_box_delta The difference from the mdat box contained in the previous version of the media file.
  • offset_size One of ⁇ 0, 4, 8 ⁇ and the length in bytes of the offset field (mdat_box_location, mdat_source_offset, offset_within_preservation_vault).
  • length_size One of ⁇ 0, 4, 8 ⁇ , indicating the length in bytes of the size field (mdat_box_size, mdat_source_size).
  • mdat_box_location The location of the mdat box in the previous version of the file (offset from the beginning of the previous version's file)
  • mdat_box_size The size of the mdat box from the previous version of the file.
  • mdat_source_offset The offset within mdat of the previous version of the file.
  • mdat_source_size Size of data copied from offset_within_preservation_vault.
  • preservation_vault_location The location where the data needed to recover the mdat box of the file before modification is stored. 0 indicates the current file, and 1 indicates mdat_delta in the pdat box.
  • offset_within_preservation_vault The offset within the location indicated by preservation_vault_location.
  • a version # 1 file 1700 represents an original media file, and a ptbl box 1770.
  • 'S next_preservation_ID is set to 1 as its initial value.
  • Version # 1 file 1700 includes ftyp box 1710, moov box 1720, mdat box 1730, meta box 1740, and meco box 1750, and mdat box 1730 is version # 1 It is located in the (0x10 ⁇ 0x55) part of the file 1700.
  • FIG. 18 shows a version # 1 file 1700 and a version # 2 file 1800 modified from a version # 1 file 1700, the version # 2 file 1800 being a moov box 1810, a mdat box 1820. And meta box 1830 has been changed, ftyp box 1710 and meco box 1750 are the same as version # 1 file 1700. Looking at the modification of the mdat box 1820 of the version # 2 file 1800, the (0x35-0x45) portion 1845 of the version # 1 file 1700 is deleted, and the (0x45) of the version # 1 file 1700 is deleted.
  • 0x55 portion 1850 has been updated, and the (0x35-0x50) portion 1855 and (0x80-0xA0) portion 1865 of the mdat box of the version # 2 file 1800 are newly added portions.
  • Changes made in the version # 1 file (1700) are stored in the delta box (1894) of the version # 2 file (1800).
  • reference number 1885 denotes the (0x35-0x45) portion (1845) of the version # 1 file (1700).
  • reference number 1890 stores information about (0x45-0x55) portion 1850 of version # 1 file 1700.
  • the change history information of the version # 2 file 1800 and the actual data required for the restoration of the version # 1 file 1700 are stored in the pdat box 1175 and the pmch box 1880.
  • metadata_box stores all boxes 1892 except for the mdat box of the version # 1 file as it is in the pdat box 1875, and the mdat box of the version # 1 file 1700 is stored in the mdata_box_delta field and the pmch box 1880.
  • the delta portion 1894 and the change history information required for restoring the data are stored.
  • the pmch box 1880 also stores size and position information of the mdat box in the version # 1 file 1700.
  • the version # 3 file 1900 includes the moov box 1910, the mdat box 1915, and the mdat box 1915 in the version # 2 file 1800.
  • the meta box 1920 has changed, the ftyp box 1710 and the meco box 1750 are identical to the version # 2 file 1800.
  • the (0x30-0x50) portions 1930 and (0x85-0xA0) portions (1945) of the version # 2 file (1800) were deleted.
  • the (0x50 ⁇ 0x70) part 1935 and (0x70 ⁇ 0x85) part 1940 are reused in the (0x40 ⁇ 0x60) part (1950) and (0xA0 ⁇ 0xB5) part (960) of the version # 3 file (1900), respectively. It became. Also, (0x60 to 0xA0) portion 1955 of the version # 3 file 1900 has been newly added. Changes made in the version # 2 file 1800 are stored in the delta box 2060 of the version # 3 file 1900. For example, reference numeral 2030 in FIG. 20 denotes (0x30 to 0x50) of the version # 2 file 1800. Information about portion 1930 is stored, and reference numeral 2040 stores information about portion 1945 (0x85 to 0xA0) of version # 2 file 1800.
  • the information required to restore the version # 2 file 1800 in FIG. 20B is stored in the pdat box 2010, and used in the newly added pdat box 2010.
  • Preservation_ID is set to "2".
  • all the boxes 2050 except the mdat box 1820 of the version # 2 file 1800 are stored in the metadata_box in the pdat box 2010 as it is, and the mdata_box_delta field
  • the pmch box 2020 stores the delta portion 2060 and the change history information required to restore the mdat box of the version # 2 file 1800, respectively.
  • the pmch box 2020 also stores size and position information of the mdat box 1820 in the version # 2 file 1800.
  • FIG. 20A illustrates change history information of the version # 2 file 1800 included in the version # 3 file 1900 and actual data required to restore the version # 1 file 1700.
  • 21 is a diagram illustrating an operation of the media file management apparatus 500 according to an embodiment of the present invention.
  • the controller 520 may change the first media file and restore information of the first media file according to whether the first media file is modified. At least one is generated (2110), and a second media file is generated using the first media file (2120). In this case, the second media file may include at least one of generated change information and recovery information.
  • the controller 520 may change information about the media file that is modified according to whether the first media file or the second media file is modified. And recovery information (2140), and the third media file may include at least one of the generated change information and recovery information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

La présente invention concerne un appareil et un procédé pour la gestion de fichiers multimédias, ledit appareil comprenant : une unité d'entrée conçue pour l'entrée d'un premier fichier multimédia ; une unité de sortie destinée à la sortie d'un second fichier multimédia ; et une unité de commande permettant de générer le second fichier multimédia sur la base du premier, et de générer des informations de changement et/ou des informations de récupération pour le premier fichier en fonction de la modification ou de la non-modification du fichier multimédia.
PCT/KR2013/000809 2012-02-01 2013-01-31 Appareil et procédé pour la gestion d'un fichier multimédia Ceased WO2013115584A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020120010518A KR20130089114A (ko) 2012-02-01 2012-02-01 미디어 파일을 관리하기 위한 장치 및 그 방법
KR10-2012-0010518 2012-02-01

Publications (1)

Publication Number Publication Date
WO2013115584A1 true WO2013115584A1 (fr) 2013-08-08

Family

ID=48905552

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2013/000809 Ceased WO2013115584A1 (fr) 2012-02-01 2013-01-31 Appareil et procédé pour la gestion d'un fichier multimédia

Country Status (2)

Country Link
KR (1) KR20130089114A (fr)
WO (1) WO2013115584A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3342039B2 (ja) * 1992-06-12 2002-11-05 富士通株式会社 ファイルを管理する処理装置
US20060242208A1 (en) * 2000-12-27 2006-10-26 Microsoft Corporation Method and system for creating and maintaining version-specific properties in a file
KR20080082192A (ko) * 2007-03-07 2008-09-11 엘지전자 주식회사 파일 포맷을 구성하는 방법과 상기 파일 포맷을 가지는파일을 포함한 방송 신호를 처리하는 장치 및 방법
KR20090017170A (ko) * 2007-08-14 2009-02-18 삼성전자주식회사 미디어 파일 관리 방법 및 장치
JP2010231656A (ja) * 2009-03-27 2010-10-14 Nippon Telegraph & Telephone West Corp ファイル管理装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3342039B2 (ja) * 1992-06-12 2002-11-05 富士通株式会社 ファイルを管理する処理装置
US20060242208A1 (en) * 2000-12-27 2006-10-26 Microsoft Corporation Method and system for creating and maintaining version-specific properties in a file
KR20080082192A (ko) * 2007-03-07 2008-09-11 엘지전자 주식회사 파일 포맷을 구성하는 방법과 상기 파일 포맷을 가지는파일을 포함한 방송 신호를 처리하는 장치 및 방법
KR20090017170A (ko) * 2007-08-14 2009-02-18 삼성전자주식회사 미디어 파일 관리 방법 및 장치
JP2010231656A (ja) * 2009-03-27 2010-10-14 Nippon Telegraph & Telephone West Corp ファイル管理装置

Also Published As

Publication number Publication date
KR20130089114A (ko) 2013-08-09

Similar Documents

Publication Publication Date Title
WO2013141562A1 (fr) Procédé et appareil de traitement de fichier multimédia pour un service de réalité augmentée
WO2014058276A1 (fr) Appareil et procédé de transmission et de réception de données multimédias dans un réseau hybride
WO2013081282A1 (fr) Système et procédé de recommandation d'application au moyen d'un mot clé
WO2013141630A1 (fr) Terminal de communication mobile et procédé de recommandation d'une application ou d'un contenu
WO2012099400A2 (fr) Appareil et procédé d'enregistrement et de lecture de contenu dans un système de diffusion en flux multimédia
WO2011062340A1 (fr) Mise à disposition d'une interface graphique utilisateur sur la base de l'historique d'usage
WO2015076537A1 (fr) Procédé de fourniture de vidéo, et système de fourniture de vidéo
EP2543192A2 (fr) Appareil et procédé pour enregistrer et lire un fichier média et support d'enregistrement pour celui-ci
WO2014094497A1 (fr) Procédé et système pour publicité adaptative dans un contenu vidéo
WO2014084666A1 (fr) Support de stockage d'informations stockant un contenu, procédé de fourniture de contenu, procédé de reproduction de contenu et appareil associé
WO2015165150A1 (fr) Procédé et système de transfert et de partage d'informations entre dispositifs mobiles
EP2839440A1 (fr) Procédé et appareil de fourniture d'un fichier multimédia pour un service de réalité augmentée
WO2017164510A2 (fr) Procédé de marquage de contenu multimédia basé sur des données vocales, et système l'utilisant
WO2022045516A1 (fr) Procédé et dispositif de synchronisation audio et vidéo
WO2011065680A2 (fr) Gestion de contenus multimédia au moyen d'objets généraux
WO2016190472A1 (fr) Dispositif et procédé de production d'image de réalité augmentée à l'aide d'incrustation de couleur
WO2014109623A1 (fr) Appareil de composition de balisage et procédé pour prendre en charge un service basé sur de multiples écrans
WO2011059227A2 (fr) Procédé de délivrance de contenus à un appareil extérieur
WO2013115584A1 (fr) Appareil et procédé pour la gestion d'un fichier multimédia
WO2009125928A2 (fr) Appareil et procédé pour fournir un écran de recherche
WO2012070766A2 (fr) Procédé destiné à générer des données de balisage vidéo sur la base d'informations d'empreintes digitales vidéo, et procédé et système de fourniture d'informations utilisant ce procédé
WO2009142420A2 (fr) Appareil et procédé de création et d’affichage d’un fichier de contenu multimédia
WO2011118989A2 (fr) Procédé permettant de gérer des informations de sélection concernant un contenu multimédia, et dispositif utilisateur, service et support de stockage permettant d'exécuter le procédé
WO2025110367A1 (fr) Dispositif, procédé, et programme de gestion de sous-titres basés sur l'intelligence artificielle
WO2024075962A1 (fr) Procédé et dispositif de fourniture d'annotations à l'aide d'une entrée vocale

Legal Events

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

Ref document number: 13743277

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13743277

Country of ref document: EP

Kind code of ref document: A1