WO2017061299A1 - 情報処理装置および情報処理方法 - Google Patents

情報処理装置および情報処理方法 Download PDF

Info

Publication number
WO2017061299A1
WO2017061299A1 PCT/JP2016/078352 JP2016078352W WO2017061299A1 WO 2017061299 A1 WO2017061299 A1 WO 2017061299A1 JP 2016078352 W JP2016078352 W JP 2016078352W WO 2017061299 A1 WO2017061299 A1 WO 2017061299A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
repair
information
missing
information processing
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/JP2016/078352
Other languages
English (en)
French (fr)
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.)
Sony Corp
Original Assignee
Sony Corp
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 Corp filed Critical Sony Corp
Priority to US15/747,964 priority Critical patent/US20180232287A1/en
Priority to EP16853453.5A priority patent/EP3319327A4/en
Priority to JP2017544459A priority patent/JP6834967B2/ja
Priority to CN201680057561.2A priority patent/CN108141640B/zh
Publication of WO2017061299A1 publication Critical patent/WO2017061299A1/ja
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
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1471—Error detection or correction of the data by redundancy in operations involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • 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/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • 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/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/4425—Monitoring of client processing errors or hardware failure
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/82—Solving problems relating to consistency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Definitions

  • the present disclosure relates to an information processing apparatus and an information processing method, and more particularly, to an information processing apparatus and an information processing method that can appropriately restore a missing data in a file of ISO “Base” media “file” format.
  • Partial File Storage is a method of encapsulating file data in which a defect occurs in accordance with ISO base media file format (ISO / IEC 14496-12).
  • ⁇ File data saved with Partial File Storage may be repaired after saving. However, if the repair is interrupted in the middle, the file repair device does not know the information about the repair at the time of restart, so the repaired missing data can be repaired again, or the missing data that failed to be repaired Will also repair.
  • This disclosure has been made in view of such a situation, and makes it possible to appropriately resume restoration of missing data in a file of ISO “Base” media “file” format.
  • An information processing apparatus includes a setting unit that sets repair information indicating a repair state of missing data in a file that conforms to ISO Base media file format, and the repair information that is set by the setting unit
  • the information processing apparatus includes a repair unit that repairs the missing data.
  • the information processing method according to the first aspect of the present disclosure corresponds to the information processing apparatus according to the first aspect of the present disclosure.
  • repair information indicating a state of repair of missing data of a file compliant with ISO Base media file format is set, and the missing data is repaired based on the set repair information.
  • An information processing apparatus is an information processing apparatus including a playback unit that plays back the file in which repair information indicating a repair state of missing data of a file conforming to ISO Base media file format is set. is there.
  • the information processing method according to the second aspect of the present disclosure corresponds to the information processing apparatus according to the second aspect of the present disclosure.
  • the file in which the repair information indicating the repair status of the missing data of the file conforming to the ISO Base file format is set is reproduced.
  • the information processing apparatuses according to the first and second aspects of the present disclosure can be realized by causing a computer to execute a program.
  • a program to be executed by a computer is provided by being transmitted via a transmission medium or by being recorded on a recording medium. be able to.
  • missing data can be repaired. Further, according to the first aspect of the present disclosure, it is possible to appropriately resume restoration of missing data in a file of ISO Base media file format.
  • the file can be played back according to the second aspect of the present disclosure. Further, according to the second aspect of the present disclosure, it is possible to reproduce an ISO Base media file format file that can appropriately resume restoration of missing data.
  • FIG. 4 is a diagram illustrating an example of the syntax of Partial File Container Box in FIGS. 2 and 3.
  • FIG. 5 is a diagram illustrating an example of syntax and semantics of Original Source URL Box in FIG. 4.
  • FIG. 5 is a diagram illustrating an example of the syntax of Partially Corrupted File Box of FIG. 4.
  • FIG. 6 is a diagram illustrating an example of semantics of Partially Corrupted File Box of FIG. 4.
  • generation process of the receiver of FIG. 6 is a flowchart for explaining file restoration processing of the receiving apparatus of FIG. 1. It is a flowchart explaining the detail of the missing data repair process of FIG. It is a figure which shows the example of the syntax of Partially
  • FIG. 18 is a diagram illustrating a first example of syntax of Recovery
  • FIG. 18 is a diagram illustrating a second example of the syntax of Recovery
  • FIG. 29 is a block diagram illustrating a configuration example of an eighth embodiment of an information processing system to which the present disclosure is applied.
  • FIG. 30 is a block diagram illustrating a configuration example of a ninth embodiment of an information processing system to which the present disclosure is applied. It is a block diagram which shows the structural example of the hardware of a computer.
  • First embodiment Information processing system (FIGS. 1 to 10) 2.
  • Second embodiment Information processing system (FIGS. 11 to 13) 3.
  • Third embodiment Information processing system (FIGS. 14 and 15) 4).
  • Fourth embodiment Information processing system (FIGS. 16 to 20) 5.
  • Fifth embodiment Information processing system (FIGS. 21 to 24) 6).
  • Sixth embodiment information processing system (FIGS. 25 to 27) 7).
  • Seventh embodiment Information processing system (FIGS. 28 to 30) 8).
  • Eighth embodiment Information processing system (FIG. 31) 9.
  • Ninth embodiment information processing system (FIG. 32) 10.
  • Tenth Embodiment Computer (FIG. 33)
  • FIG. 1 is a block diagram illustrating a configuration example of a first embodiment of an information processing system to which the present disclosure is applied.
  • the information processing system 10 in FIG. 1 includes a broadcasting station 11, a receiving device 12 (information processing device), and an HTTP (HyperText Transfer Protocol) server 13.
  • the receiving device 12 receives a broadcast data file from the broadcast station 11 and repairs the missing data of the broadcast data file using the data acquired from the HTTP server 13.
  • the broadcast station 11 of the information processing system 10 receives a file that conforms to a format such as ISO base media file format of broadcast data encoded by the MPEG2 method or the like via an antenna (not shown) or the like. 12 to send.
  • the receiving device 12 includes a broadcast receiving unit 31, a file generating unit 32, a setting unit 33, a recording unit 34, a restoration unit 35, and an HTTP receiving unit 36.
  • the broadcast receiving unit 31 of the receiving device 12 receives a broadcast data file transmitted from the broadcast station 11 via an antenna (not shown) and the like and supplies the file to the file generating unit 32.
  • the file generator 32 determines whether or not there is missing data in the broadcast data file supplied from the broadcast receiver 31. When it is determined that there is no missing data in the broadcast data file, the file generation unit 32 generates an ISO Base media file format file (hereinafter referred to as a non-missing file) from the broadcast data.
  • a non-missing file an ISO Base media file format file
  • the file generation unit 32 uses a method called Partial File Storage to create a file that conforms to ISO Base media file ⁇ ⁇ format from the broadcast data (hereinafter referred to as a missing file). Is generated.
  • the default value of the repair information indicating the repair status of the missing data of the missing file is set by the setting unit 33 for the missing file.
  • the file generation unit 32 supplies the recording unit 34 with the missing file and the missing file in which the default value of the repair information is set.
  • the setting unit 33 sets the default value of the repair information in the missing file generated by the file generation unit 32. Further, the setting unit 33 updates the repair information set in the missing file recorded in the recording unit 34 based on the repaired information indicating the number of repaired missing data supplied from the repair unit 35. .
  • the recording unit 34 records the missing file and the missing file supplied from the file generating unit 32.
  • the restoration unit 35 selects one of the missing files recorded in the recording unit 34 as a restoration target file.
  • the repair unit 35 determines predetermined missing data as repair target data based on the repair information included in the repair target file.
  • the restoration unit 35 obtains the URL (Uniform Resource Locator) information of a file (hereinafter referred to as a restoration file) corresponding to the broadcast data file used to generate the restoration target file when no missing data exists. Information is acquired from the repair target file and supplied to the HTTP receiver 36. The restoration unit 35 restores the missing data using the restoration file supplied from the HTTP reception unit 36 in response to the supply of the acquisition destination information. The repair unit 35 supplies the repaired information to the setting unit 33.
  • URL Uniform Resource Locator
  • the HTTP reception unit 36 communicates with the HTTP server 13 based on the acquisition destination information supplied from the restoration unit 35 and obtains a restoration file held in the HTTP server 13.
  • the HTTP receiving unit 36 supplies the acquired repair file to the repair unit 35.
  • FIG. 2 is a diagram illustrating a first structure example of a file with a defect.
  • a file with a defect is composed of a Partial File File Container Box with a Box structure of ISO base file format.
  • Partial File Container Box a broadcast data file containing missing data received by the broadcast receiving unit 31 is encapsulated.
  • Partial File Box Container is a top-level Box consisting of Top Level Box Index Index Box, Original Source URL Box, Partially Corrupted File Box, and file_data.
  • Top Box Level Box Index Box information indicating the position of a box at a predetermined level is described.
  • URL information is described as the acquisition destination information of the restoration file.
  • Partially Corrupted File Box missing information indicating the position and size of missing data, repair information, and the like are described.
  • the file_data is broadcast data in which dummy data is arranged in the missing data (Corrupted data) portion of the file received by the broadcast receiving unit 31. Therefore, the size of file_data is the same as the size of the file to be received by the broadcast receiving unit 31.
  • FIG. 3 is a diagram illustrating a second structure example of a missing file.
  • the structure of the missing file in FIG. 3 is the same as the structure in FIG. 2 except for file_data.
  • the file_data in FIG. 3 is broadcast data in which dummy data is not arranged in the missing data portion of the file received by the broadcast receiving unit 31 and the missing data portion is packed.
  • FIG. 4 is a diagram illustrating an example of syntax of the Partial File Container Box in FIGS. 2 and 3.
  • the Top File Level Container Box Top Top Level Box Index Original Box and Original Box URL Box may or may not be arranged.
  • Partially Corrupted File Box is a Box (mandatory Box) that is always placed.
  • FIG. 5 is a diagram illustrating an example of syntax and semantics of Original Source URL Box. Specifically, FIG. 5A is a diagram illustrating an example of the syntax of Original Source URL Box, and FIG. 5B is a diagram illustrating an example of semantics.
  • URL information (url) of a repair file corresponding to file_data is described in Original ⁇ ⁇ Source URL Box.
  • the HTTP reception unit 36 in FIG. 1 acquires a repair file from the HTTP server 13 based on the URL information.
  • the restoration unit 35 replaces the dummy data of file_data with the broadcast data that is not missing of the restoration file corresponding to the dummy data. to repair.
  • the restoration unit 35 restores the missing data by inserting broadcast data that does not exist in the file_data of the restoration file into the file_data.
  • FIG. 6 is a diagram illustrating an example of syntax of Partially Corrupted File Box
  • FIG. 7 is a diagram illustrating an example of semantics.
  • “version” and “flags” are described in the Partially Corrupted File Box. As shown in FIG. 7, “version” is information indicating the version of this Partially Corrupted File Box. “Flags” includes a PCFB_BYTES_REMOVED flag, an All_Corrupted_Data_was_tried_to_recover flag, and a NOW_recovering flag.
  • the PCFB_BYTES_REMOVED flag is a flag indicating whether or not dummy data exists in file_data, in which a value is set in the least significant bit of flags.
  • the PCFB_BYTES_REMOVED flag is 1 when indicating that dummy data does not exist in file_data, and 0 when dummy data exists in file_data. That is, when the structure of the file with missing is the structure of FIG. 3, the PCFB_BYTES_REMOVED flag is set to 1, and when the structure of the file with missing is the structure of FIG. 2, the PCFB_BYTES_REMOVED flag is set to 0.
  • the All_Corrupted_Data_was_tried_to_recover flag is a flag that is set in the second bit from the bottom of flags and indicates whether or not repair of all missing data in file_data has been completed at least once, and is one piece of repair information.
  • the All_Corrupted_Data_was_tried_to_recover flag is 1 when it indicates that the repair of all missing data in file_data has been completed at least once, and 0 when it indicates that it has not been completed yet.
  • the NOW_recovering flag is a flag that is set in the third bit from the bottom of flags and indicates whether all missing data in file_data is being repaired, and is one piece of repair information.
  • the NOW_recovering flag is 1 when indicating that all missing data in file_data is being repaired, and 0 when indicating that it is not in the middle.
  • the All_Corrupted_Data_was_tried_to_recover flag and NOW_recovering flag are set to 0. If all missing data in file_data has been repaired but is still being repaired, the All_Corrupted_Data_was_tried_to_recover flag is set to 0, but the NOW_recovering flag is set to 1. Furthermore, when all the missing data in file_data is repaired at least once, the All_Corrupted_Data_was_tried_to_recover flag is set to 1, but the NOW_recovering flag is set to 0.
  • entry_count and num_of_recovered are also described in Partially Corrupted File Box. As shown in FIG. 7, entry_count is the number of missing data in file_data. num_of_recovered is information indicating the number of missing data that has been repaired, and is one piece of repair information.
  • the flags All_Corrupted_Data_was_tried_to_recover and NOW_recovering are 0.
  • the All_Corrupted_Data_was_tried_to_recover flag in flags is 0 and the NOW_recovering flag is 1.
  • the All_Corrupted_Data_was_tried_to_recover flag in flags is 1 and the NOW_recovering flag is 0.
  • byte_offset is offset information indicating the start position of missing data as an offset amount from the beginning of file_data.
  • version is 1
  • bit length of the offset information is 64 bits, and when it is not 1, it is 32 bits.
  • Corrupted_size is information indicating the size of missing data.
  • num_of_recovered is information indicating the number of entries from the beginning corresponding to the missing data that has been repaired last.
  • the repair unit 35 determines whether the repair target file has not been repaired based on the flags of the repair target file. It can be recognized whether it is present or completed. In addition, when the repair of the repair target file is interrupted, the repair unit 35 can restart the repair from the interrupt position based on the entry_count of the repair target file.
  • FIG. 8 is a flowchart for explaining file generation processing of the receiving device 12 of FIG. This file generation process is started when a broadcast data file is transmitted from the broadcast station 11.
  • the broadcast reception unit 31 of the reception device 12 receives a broadcast data file transmitted from the broadcast station 11 via an antenna (not shown) and supplies the file to the file generation unit 32.
  • step S12 the file generation unit 32 determines whether or not missing data exists in the broadcast data file supplied from the broadcast receiving unit 31.
  • step S13 the file generation unit 32 generates a missing file from the broadcast data by using a method of Partial File Storage.
  • step S14 the setting unit 33 sets the default value of the repair information in the Partially Corrupted File File Box of the missing file generated by the file generation unit 32. Note that the default value of the repair information is 0.
  • step S15 the setting unit 33 supplies the recording unit 34 with the missing file in which the default value of the repair information is set, and records the file. Then, the process ends.
  • step S16 the file generation unit 32 generates a missing file from the broadcast data.
  • step S17 the file generation unit 32 supplies the missing file to the recording unit 34 and records it. Then, the process ends.
  • FIG. 9 is a flowchart for explaining the file restoration process of the receiving device 12 of FIG. This file repair process is started, for example, when the repair unit 35 selects one of the missing files recorded in the recording unit 34 as a repair target file.
  • the restoration unit 35 of the receiving device 12 reads the partial file container container box of the file to be restored recorded in the recording unit 34.
  • the repair unit 35 acquires Partially Corrupted File File Box from the Partial File File Container box read out in Step S31.
  • step S33 the repair unit 35 acquires flags from the Partially Corrupted File box acquired in Step S32.
  • step S34 the restoration unit 35 determines whether the All_Corrupted_Data_was_tried_to_recover flag is set to 1 based on flags, that is, whether 1 is set in the second bit from the bottom of flags.
  • step S34 If it is determined in step S34 that the All_Corrupted_Data_was_tried_to_recover flag is set to 1, that is, if all of the missing data in the repair target file has been repaired at least once, the process ends.
  • step S34 if it is determined in step S34 that the All_Corrupted_Data_was_tried_to_recover flag is not set to 1, that is, if repair of all missing data in the repair target file has not been completed yet, the process proceeds to step S35.
  • step S35 the restoration unit 35 determines, based on flags, whether the NOW_recovering flag is set to 1, that is, whether 1 is set in the third bit from the bottom of flags.
  • step S35 If it is determined in step S35 that the NOW_recovering flag is set to 1, that is, if the repair of all missing data in the repair target file is interrupted, the process proceeds to step S36.
  • step S36 the restoration unit 35 acquires num_of_recovered from the Partially Corrupted File box acquired in step S32, and advances the processing to step S37.
  • step S35 determines that the NOW_recovering flag is not set to 1, that is, if the repair of all missing data of the repair target file has not yet started, the repair unit 35 determines that num_of_recovered is 0. recognize. Then, the process proceeds to step S37.
  • step S35 when it is determined in step S35 that the NOW_recovering flag is not set to 1, the restoration unit 35 recognizes that num_of_recovered is 0, but from Partially Corrupted File File Box, num_of_recovered As a result, 0 may be acquired.
  • step S37 the restoration unit 35 obtains Original Source URL Box from the read Partial File Container Box.
  • step S38 the repair unit 35 performs a missing data repair process for repairing the missing data in the repair target file in order. Details of this missing data repair processing will be described with reference to FIG.
  • FIG. 10 is a flowchart for explaining the details of the missing data repair process in step S38 of FIG.
  • step S51 of FIG. 10 the restoration unit 35 sets the count value i to a value obtained by adding 1 to the acquired or recognized num_of_recovered.
  • step S ⁇ b> 52 the restoration unit 35 determines whether the count value i is equal to or less than entry_count included in Partially Corrupted File Box.
  • step S52 When it is determined in step S52 that the count value is equal to or smaller than entry_count, that is, when the repair of all the missing data of the repair target file has not yet been completed, the repair unit 35 is i th from the beginning of the Partially Corrupted File File Box. The missing data corresponding to the entry is determined as the data to be repaired.
  • step S53 the restoration unit 35 supplies the URL information described in Original Source URL Box to the HTTP receiving unit 36, thereby corresponding to the i-th entry of the restoration file held in the HTTP server 13. Broadcast data to be acquired is acquired as repair data via the HTTP receiver 36.
  • step S54 the repair unit 35 repairs the repair target data corresponding to the entry based on the missing information and the repair data of the i-th entry from the beginning described in Partially Corrupted File File Box. Then, the restoration unit 35 supplies the count value i to the setting unit 33 as restored information.
  • step S55 the restoration unit 35 determines whether to stop the missing data restoration process. If it is determined in step S55 that the missing data repair process is not to be stopped, the repair unit 35 increments the count value by 1 in step S56. Then, the process returns to step S52.
  • step S55 if it is determined in step S55 that the missing data repair process is to be stopped, the process proceeds to step S57.
  • step S57 the setting unit 33 sets (updates) the NOW_recovering flag of the repair target file recorded in the recording unit 34, and advances the process to step S59.
  • step S52 If it is determined in step S52 that the count value is larger than entry_count, that is, if the restoration of all missing data is completed, the process proceeds to step S58.
  • step S58 the setting unit 33 sets the All_Corrupted_Data_was_tried_to_recover flag of the repair target file recorded in the recording unit 34 to 1 and sets the NOW_recovering flag to 0. Then, the process proceeds to step S59.
  • step S59 the setting unit 33 sets the count value i represented by the repaired information supplied from the repair unit 35 to num_of_recovered of the repair target file recorded in the recording unit 34. Then, the process returns to step S38 in FIG. 9, and the process ends.
  • the receiving device 12 sets the repair information of the file with the defect, the repair state of the file with the defect can be easily recognized when the file with the defect is repaired. As a result, the receiving device 12 can repair the repaired data again when the repair of the defective file whose repair has been interrupted is resumed, or repair the data that has failed to be repaired many times. Therefore, the repair can be resumed appropriately from the interrupt position. As a result, the load of the file repair process is reduced.
  • the receiving device recognizes the state when the repair is suspended when repair is resumed by performing entry_count update and deletion of missing information at the same time as repair. Can do.
  • this processing is complicated, and the size of the Partially Corrupted File Box is changed as a result of the processing, so it is necessary to rewrite data after the Partially Corrupted File Box. Therefore, the load of the file repair process is large.
  • FIG. 11 is a diagram showing an example of the syntax of Partially Corrupted File Box in the second embodiment
  • FIG. 12 is a diagram showing an example of semantics.
  • Partially Corrupted File File Boxes in FIGS. 11 and 12 is that flags are composed of only the PCFB_BYTES_REMOVED flag, num_of_recovered is not described, and recovered_flag is newly described for each entry.
  • the configuration is different. That is, the repair information in the second embodiment is recovered_flag, not flags and num_of_recovered.
  • “Recovered_flag” of each entry is a flag indicating the state in which the repair of the missing data corresponding to the entry is successful, the state in which the repair has failed, or the state in which the repair has not been performed, and is repair information.
  • the recovered_flag is composed of a Recovered flag and a Failed_to_recover flag.
  • the Recovered flag is a flag that indicates whether or not the repair is successful, in which a value is set in the least significant bit of recovered_flag.
  • the Recovered flag is 1 when indicating that the repair is successful, and is 0 when indicating that the repair is not successful.
  • the Failed_to_recover flag is a flag that indicates whether or not the repair has failed, in which a value is set in the second bit from the bottom of the recovered_flag.
  • the Failed_to_recover flag is 1 when indicating that the repair has failed, and 0 when indicating that the repair has not failed.
  • the repair unit 35 executes the repair of the missing data corresponding to the entry based on the recovered_flag of each entry of the repair target file. And the presence or absence of success.
  • the file generation process in the second embodiment is the same as the file generation process of FIG.
  • FIG. 13 is a flowchart for explaining the file restoration processing of the receiving device 12 in the second embodiment.
  • step S73 is the same as the processing in step S37 in FIG.
  • step S74 the restoration unit 35 of the receiving device 12 sets the count value i to 1.
  • step S75 the restoration unit 35 acquires recovered_flag of the i-th entry from the top described in Partially Corrupted File Box acquired in step S72.
  • step S76 the restoration unit 35 determines whether the recovered_flag acquired in step S75 is 0, that is, whether the Recovered flag and the Failed_to_recover flag are 0.
  • step S76 If it is determined in step S76 that recovered_flag is 0, that is, if the missing data corresponding to the i-th entry has not yet been repaired, the restoration unit 35 provides the missing data corresponding to the i-th entry. Is determined as data to be repaired.
  • step S77 the restoration unit 35 supplies the URL information described in Original Source URL Box to the HTTP reception unit 36, thereby corresponding to the i-th entry of the restoration file held in the HTTP server 13. Broadcast data to be acquired is acquired as repair data via the HTTP receiver 36.
  • step S78 the repair unit 35 repairs the repair target data corresponding to the entry based on the missing information and the repair data of the i-th entry.
  • step S79 the restoration unit 35 determines whether or not the restoration in step S78 is successful. For example, if the restoration file 35 does not exist in the HTTP server 13 corresponding to the URL information described in Original Source URL Box and acquisition of the restoration file has failed in step S77, the restoration unit 35 35 determines that the repair is not successful.
  • step S79 If it is determined in step S79 that the repair is successful, the repair unit 35 supplies the setting unit 33 with repair result information indicating the successful repair of the repair target data corresponding to the i-th entry.
  • step S80 the setting unit 33 sets the Recovered flag of the i-th entry of the repair target file recorded in the recording unit 34 to 1, and advances the process to step S82.
  • the repair unit 35 supplies the setting unit 33 with repair result information indicating a repair failure of the repair target data corresponding to the i-th entry.
  • step S81 the setting unit 33 sets the Failed_to_recover flag of the i-th entry of the repair target file recorded in the recording unit 34 to 1, and advances the process to step S82.
  • step S76 If it is determined in step S76 that recovered_flag is not 0, that is, if the missing data corresponding to the i-th entry has already been repaired, the process proceeds to step S82.
  • step S82 the restoration unit 35 determines whether or not to stop the file restoration process. If it is determined in step S82 that the file repair process is not stopped, the process proceeds to step S83. In step S83, the setting unit 33 increments the count value i by 1.
  • step S84 the setting unit 33 determines whether or not the count value i is equal to or smaller than entry_count described in Partially Corrupted File Box. If it is determined in step S84 that the count value i is equal to or smaller than entry_count, the process returns to step S75, and the subsequent processes are repeated.
  • step S82 if it is determined in step S82 that the file repair process is to be stopped, the process ends. If it is determined in step S84 that the count value i is greater than entry_count, that is, if all missing data has been repaired, the process ends.
  • the repair information is information indicating a state where the repair of each missing data is successful, a state where it has failed, or a state where it has not been performed. Therefore, the receiving device 12 can recognize not only whether or not each missing data is repaired but also whether or not the repair is successful.
  • the third embodiment of the information processing system to which the present disclosure is applied is a combination of the first embodiment and the second embodiment. That is, in the third embodiment, the repair information is flags, num_of_recovered, and recovered_flag, and the repaired information and the repair result information are supplied from the repair unit 35 to the setting unit 33. Therefore, in the following, only the processes relating to the repair information, the repaired information, and the repair result information will be described using the respective parts in FIG. 1 as the respective parts of the third embodiment of the information processing system.
  • FIG. 14 is a diagram showing an example of the syntax of Partially Corrupted File Box in the third embodiment.
  • Partially Corrupted File Box in FIG. 14 differs from the configuration in FIG. 6 in that recovered_flag is newly described for each entry.
  • the file generation process in the third embodiment is the same as the file generation process of FIG. Further, the file repair process in the third embodiment is the same as the file repair process of FIG. 9 except for the missing data repair process in step S38, so only the missing data repair process will be described below.
  • FIG. 15 is a flowchart for explaining the missing data repair process of the receiving device 12 in the third embodiment.
  • steps S51 to S54 of FIG. 10 is the same as the processing of steps S51 to S54 of FIG. 10
  • steps S104 to S106 is the same as the processing of steps S79 to S81 of FIG.
  • steps S107 to S111 is the same as the processing in steps S55 to S59 in FIG.
  • ⁇ Fourth embodiment> (First structure example of missing file)
  • the fourth embodiment of the information processing system to which the present disclosure is applied is the same as the third embodiment except that the repair information is set in a new Box different from the Partially Corrupted File Box. Therefore, in the following, only the structure of a file with a defect will be described using each part of FIG. 1 as each part of the fourth embodiment of the information processing system.
  • FIG. 16 is a diagram illustrating a first structure example of a missing file according to the fourth embodiment.
  • the structure of a missing file in FIG. 16 is composed of two Boxes: Recovery Status Box where repair information is not described in Partially Corrupted File Box, and Partial File Container Box and repair information are placed in the missing file The point is different from the structure of FIG.
  • Partially Corrupted File Box in FIG. 16 is the same as the syntax in FIG. 6 except that the flags are composed only of the PCFB_BYTES_REMOVED flag and num_of_recovered is not arranged, so the description is omitted.
  • ⁇ Recovery Status Box is a Box in the same hierarchy as Partial File Container Box.
  • FIG. 17 is a diagram illustrating a second structure example of a file with a defect according to the fourth embodiment.
  • FIG. 17 The structure of the missing file in FIG. 17 is different from the structure of FIG. 16 in that the Recovery Status Box is placed in the Partial File Container box.
  • the repair information is arranged in a Box different from the Partially Corrupted File Box, so that the repair information can be easily set.
  • dummy data may not be arranged in file_data in the missing file of FIGS. 16 and 17 as in the case of FIG.
  • FIG. 18 is a diagram illustrating an example of the syntax of the Partial File Container Box in FIG.
  • FIG. 19 is a diagram illustrating a first example of the syntax of the Recovery Status Box in FIGS. 16 and 17.
  • FIG. 20 is a diagram illustrating a second example of the syntax of the Recovery Status Box in FIGS. 16 and 17.
  • Recovery Status Box in FIG. 20 is different from the syntax in FIG. 19 in that entry_count is not described and only the recovered_flag of missing data that has been repaired out of missing data in file_data is arranged. .
  • either the recovered flag or the failed_to_recover flag of recovered_flag is always set to 1. That is, recovered_flag does not become 0 indicating a state in which restoration is not performed.
  • the repair information of the third embodiment is set to a new Box different from Partially Corrupted File File Box, but the repair information of the first embodiment or the second embodiment is Partially It may be set to a new Box different from Corrupted File Box.
  • the file generation unit 32 includes an MPD (Media Presentation Description) of the file.
  • MPD Media Presentation Description
  • the configuration of the first to fourth embodiments, except that the file is set with missing file information for identifying the missing file and the setting unit 33 also sets the repair information for the MPD file. Is the same. Therefore, in the following, only the processing relating to the MPD file will be described using the respective units in FIG. 1 as respective units in the fifth embodiment of the information processing system.
  • FIG. 21 is a diagram for explaining the processing of the file generation unit 32 in the fifth embodiment.
  • the broadcast data file is a file conforming to MPEG-DASH
  • the file is segmented, and one Initialization Segment file, one or more (n in the example of FIG. 21) Media It consists of a Segment file and an MPD file (not shown).
  • a Segment file when there is no need to distinguish between the Initialization Segment file and the MediaSSegment file, they are collectively referred to as a Segment file.
  • the file generation unit 32 determines whether missing data exists in the Segment file supplied from the broadcast reception unit 31.
  • the file generation unit 32 determines the missing file from the broadcast data of the Media Segment file. Generate.
  • a missing file is generated as in the first to third embodiments, but a missing file including RecoveryReStatus Box is generated as in the fourth embodiment. You may make it do.
  • the file generation unit 32 sets the Segment file as it is as a missing file.
  • the file generation unit 32 supplies the generated missing file and missing file to the recording unit 34 for recording.
  • FIG. 22 is a diagram illustrating a first configuration example of an MPD file in which missing file information and repair information are set.
  • the MPD file is a file that manages the Segment file.
  • information such as encoding information (Configuration information) of broadcast data, image size, audio language, etc. are layered and described in XML format.
  • hierarchization in the MPD file is performed using elements such as a period, an adaptation set, and a representation.
  • the broadcast data stored in the Segment file that it manages is divided in a predetermined time range.
  • the period element is described for each divided broadcast data.
  • the adaptation set element is included in the period element and groups representation elements of broadcast data corresponding to the period element.
  • the representation elements are grouped according to the type of broadcast data (image, sound in the example of FIG. 22A).
  • the representation element has URL information of the acquisition destination of the divided broadcast data.
  • ⁇ EssentialProperty schemeIdUri “urn: mpeg: dash: corrupted: 2015”> is an EssentialProperty indicating that at least one of the Segment files corresponding to the representation element included in the element including the element is a missing file.
  • at least one of all the segment files (video.mp4, audio.mp4) managed by the MPD file is a missing file.
  • file_name is information indicating the file name of a file with a defect as missing file information.
  • the file_recovered_status_flag is composed of an All_Corrupted_data_was_tired_to_recover flag and a NOW_recovering flag as repair information for the missing file.
  • the setting unit 33 sets not only the repair information set in the missing file recorded in the recording unit 34 but also the repair information set in the MPD file based on the repaired information supplied from the repair unit 35. Also update.
  • FIG. 24 is a diagram illustrating a second configuration example of the MPD file in which the missing file information and the repair information are set.
  • the file generation unit 32 uses a method called Partial File Storage as shown in A of FIG.
  • the MPD file supplied from the broadcast receiving unit 31 is encapsulated.
  • the file generation unit 32 stores the MPD file supplied from the broadcast receiving unit 31 in the Original MPD element, and stores the Original MPD element in the Encapsulated MPD element. Therefore, the restoration unit 35 can recognize whether or not at least one of the segment files managed by the MPD file is a missing file depending on whether or not the Encapsulated MPD element exists in the MPD file.
  • the setting unit 33 sets not only the repair information set in the missing file recorded in the recording unit 34 but also the repair information set in the MPD file based on the repaired information supplied from the repair unit 35. Also update.
  • missing file information and repair information are set in the MPD file. Therefore, the repair unit 35 can recognize a missing file that has not been repaired and is recorded in the recording unit 34 only by acquiring the MPD file. Therefore, the repairing unit 35 can repair a missing file that has not been repaired without wastefully reading the missing file that has been repaired.
  • a playback device that plays back a file with a defect recorded in the recording unit 34 can recognize a file with a defect that has been repaired by only acquiring the MPD file. Therefore, the playback device can play back a file with a defect that has been repaired without wastefully reading a file with a defect that has not been repaired.
  • ⁇ Sixth embodiment> (Description of processing of file generation unit)
  • the setting unit 33 sets the repair information in the Corrupted File Index file
  • the file generation unit 32 is the same as that of the fifth embodiment except that the MPD file sets not the missing file information and the repair information, but the Corrupted File Index file information that identifies the Corrupted File Index file. Therefore, in the following, only the processing related to the Corrupted File Index file and the MPD file will be described using the respective units in FIG. 1 as the respective units of the sixth embodiment of the information processing system.
  • FIG. 25 is a diagram for explaining the processing of the file generation unit 32 in the sixth embodiment.
  • the file generation unit 32 determines whether or not missing data exists in the Segment file supplied from the broadcast reception unit 31 as in the fifth embodiment. As shown in FIG. 25, when it is determined that missing data exists in the xth and yth Media Segment files (Media Segment x, Media Segment y) from the beginning, the file generation unit 32 broadcasts the Media Segment file. Generate missing files from the data.
  • a file with a defect having the configuration of FIG. 17 is generated.
  • a file with a defect whose repair information is set in Partially Corrupted File File Box. May be generated.
  • a file with a defect in which repair information is set in a Recovery Status box different from a Partial File Status Container Box may be generated.
  • the file generation unit 32 uses the Segment file as it is as a missing file.
  • the file generation unit 32 supplies the generated missing file and missing file to the recording unit 34 for recording.
  • the file generation unit 32 generates a new Corrupted File Index file that is different from the broadcast data file.
  • the setting unit 33 sets the repair information of each missing file as File Recovery Status Box in the generated Corrupted File Index file.
  • FIG. 26 is a diagram illustrating an example of the syntax of the File Recovery Status Box.
  • Corrupted File Index file has a missing File Recovery Status box for each file. As shown in FIG. 26, file_name, file_recovered_status_flag, and Recovery Status Box are described in File Recovery Status Box.
  • Recovery Status Box does not have to be placed in the File Recovery Status Box.
  • Recovery Status Box does not have to be placed in a missing file.
  • FIG. 27 is a diagram illustrating a configuration example of an MPD file in which Corrupted File Index file information is set.
  • the file generation unit 32 When the file generation unit 32 acquires the MPD file of FIG. 27A from the broadcast reception unit 31 and there is missing data in at least one of the segment files, the file generation unit 32 stores the Corrupted File Index file in the MPD file. Information indicating the file name is set as Corrupted File Index file information.
  • FIG. 28 is a diagram for explaining the processing of the file generation unit 32 in the seventh embodiment.
  • the file generation unit 32 determines whether or not missing data exists in the Segment file supplied from the broadcast reception unit 31 as in the sixth embodiment. As shown in FIG. 28, when it is determined that there is missing data in the xth and yth Media Segment files (Media Segment x, Media Segment y) from the beginning, the file generation unit 32 broadcasts the Media Segment file. Generate missing files from the data.
  • the file generation unit 32 generates a missing file from the InitializationInSegment file regardless of whether or not missing data exists in the Initialization ⁇ ⁇ ⁇ ⁇ Segment file.
  • the setting unit 33 sets repair information of all the missing files as Segment Corrupted Information Box in the missing file generated from the Initialization Segment file (hereinafter referred to as a missing Initialization Segment file).
  • the file generation unit 32 supplies the generated missing file and missing file to the recording unit 34 for recording.
  • the missing file having the configuration of FIG. 17 is generated, but the missing file in which the repair information is set in Partially Corrupted File File as in the first to third embodiments. May be generated. Further, as shown in FIG. 16, a file with a defect in which repair information is set in a Recovery Status box different from a Partial File Status Container Box may be generated.
  • FIG. 29 is a diagram illustrating a configuration example of a defective initialization segment file.
  • the configuration of the missing initialization segment file in FIG. 29 is the same as the configuration of the missing file in FIG. 18 except that the segment corrupted information box is arranged.
  • FIG. 30 is a diagram illustrating an example of the syntax of the Segment Corrupted Information Box in FIG.
  • a File Recovery Status box is arranged for each missing file.
  • ⁇ EssentialProperty schemeIdUri “urn: mpeg: dash: corrupted: index: initialization: 2015”> indicates that at least one of the Segment files managed by the MPD file is a missing file, and the repair information for the missing file is an Initialization Segment file It is an EssentialProperty indicating that it is set to.
  • restoration information is set in the Initialization Segment file that is reproduced before the Media Segment file when the Media Segment file is reproduced. Therefore, the playback device can recognize the repair information of the Media Segment file before playing the Media Segment file.
  • FIG. 31 is a block diagram illustrating a configuration example of an eighth embodiment of an information processing system to which the present disclosure is applied.
  • the cache proxy 51 receives and stores a broadcast data file compliant with MPEG-DASH, and the player 52 reproduces the file stored in the cache proxy 51.
  • the cache proxy 51 of the information processing system 50 is, for example, a home server for home use, and includes the receiving device 12 and the DASH server 61.
  • the receiving device 12 receives and records a broadcast data file compliant with MPEG-DASH transmitted from the broadcast station 11, and restores missing data in the file.
  • the DASH server 61 acquires and stores a missing file and a missing file for which all of the missing data recorded in the recording unit 34 of the receiving device 12 has been repaired.
  • the player 52 includes a DASH client 71 and the like.
  • the DASH client 71 (playback unit) reads the MPD file stored in the DASH server 61.
  • the DASH client 71 refers to the MPD file, reads a necessary segment file from the DASH server 61, and reproduces broadcast data acquired based on the segment file.
  • FIG. 32 is a block diagram illustrating a configuration example of the ninth embodiment of the information processing system to which the present disclosure has been applied.
  • the cache proxy 101 is provided instead of the cache proxy 51 and the player 102 is provided instead of the player 52. Different.
  • the player 102 performs restoration.
  • the cache proxy 101 of the information processing system 100 is, for example, a home server for home use, and includes a broadcast receiving unit 31, a file generating unit 32, a setting unit 111, and a DASH server 112.
  • the setting unit 111 performs a process of setting a default value of repair information in the process of the setting unit 33 in FIG.
  • the DASH server 112 records the non-missing file generated by the file generating unit 32 and the missing file and the MPD file in which the default value of the repair information is set in at least one of them.
  • the player 102 includes a recording unit 34, a restoration unit 35, an HTTP reception unit 36, a DASH client 121, and a setting unit 122.
  • the DASH client 121 (playback unit) reads the MPD file recorded in the DASH server 112.
  • the DASH client 121 refers to the MPD file, reads a necessary Segment file from the DASH server 112, and records it in the recording unit 34.
  • the DASH client 121 reads a segment file in which all missing data recorded in the recording unit 34 has been repaired, acquires broadcast data based on the segment file, and plays it back.
  • the setting unit 122 performs a process of updating the repair information in the process of the setting unit 33 in FIG.
  • ⁇ Tenth embodiment> (Description of computer to which the present disclosure is applied)
  • the series of processes of the receiving device 12 described above can be executed by hardware or can be executed by software.
  • a program constituting the software is installed in the computer.
  • the computer includes, for example, a general-purpose personal computer capable of executing various functions by installing various programs by installing a computer incorporated in dedicated hardware.
  • FIG. 33 is a block diagram illustrating a configuration example of hardware of a computer that executes the series of processes of the receiving device 12 described above by a program.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • An input / output interface 205 is further connected to the bus 204.
  • An input unit 206, an output unit 207, a storage unit 208, a communication unit 209, and a drive 210 are connected to the input / output interface 205.
  • the input unit 206 includes a keyboard, a mouse, a microphone, and the like.
  • the output unit 207 includes a display, a speaker, and the like.
  • the storage unit 208 includes a hard disk, a nonvolatile memory, and the like.
  • the communication unit 209 includes a network interface and the like.
  • the drive 210 drives a removable medium 211 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 201 loads the program stored in the storage unit 208 to the RAM 203 via the input / output interface 205 and the bus 204 and executes the program. A series of processing is performed.
  • the program executed by the computer 200 can be provided by being recorded in, for example, a removable medium 211 such as a package medium.
  • the program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • the program can be installed in the storage unit 208 via the input / output interface 205 by attaching the removable medium 211 to the drive 210.
  • the program can be received by the communication unit 209 via a wired or wireless transmission medium and installed in the storage unit 208.
  • the program can be installed in the ROM 202 or the storage unit 208 in advance.
  • the program executed by the computer 200 may be a program that is processed in time series in the order described in this specification, or a necessary timing such as in parallel or when a call is made. It may be a program in which processing is performed.
  • the system means a set of a plurality of components (devices, modules (parts), etc.), and it does not matter whether all the components are in the same housing. Accordingly, a plurality of devices housed in separate housings and connected via a network and a single device housing a plurality of modules in one housing are all systems. .
  • the same description as the Segment Corrupted Information Box may be performed in the MPD file.
  • the present technology is applied not only to a device that receives broadcast data, but also to a device (for example, a portable terminal) that receives data multicast according to LTE (Long Term Evolution) or Wi-Fi. You can also.
  • LTE Long Term Evolution
  • Wi-Fi Wireless Fidelity
  • this indication can also take the following structures.
  • An information processing apparatus comprising: a repair unit that repairs the missing data based on the repair information set by the setting unit.
  • the setting unit is configured to set the restoration information in a box different from a box in which data of the file is arranged.
  • the setting unit is configured to set the repair information in a box different from a box in which missing information indicating a position and a size of the missing data is included in a box in which data of the file is arranged.
  • the information processing apparatus configured to set the repair information in a repair information file that is a file different from the file.
  • the setting unit is configured to set missing file specifying information for specifying the file in the repair information file.
  • the information processing apparatus according to (9) or (10), further including: a file generation unit that sets information for specifying the repair information file in a management file for managing the file.
  • the information processing apparatus according to any one of (9) to (11), wherein the repair information file is configured as an initialization segment file.
  • the repair information is information indicating that all of the missing data in the file is being repaired.
  • the information processing apparatus according to any one of (1) to (13), wherein the repair information is information indicating that repair of all the missing data of the file is completed.
  • the repair information is information indicating the missing data that has been repaired by the repair unit.
  • the repair information is configured to be information indicating a state in which the repair of each missing data has been successful, a state in which the repair has failed, or a state in which the repair has not been performed.
  • the repair information is information indicating the missing data that has been repaired by the repair unit, and information indicating whether the repair of each missing data that has been repaired has succeeded or failed.
  • Information processing device A setting step for setting repair information indicating the repair status of missing data in a file conforming to the ISO Base media file format; A repairing step of repairing the missing data based on the repair information set by the processing of the setting step.
  • An information processing apparatus comprising: a playback unit that plays back the file in which repair information indicating a repair state of missing data of a file that conforms to the ISO Base media file format is set.
  • Information processing device An information processing method including a reproduction step of reproducing the file in which restoration information indicating a restoration state of missing data of a file compliant with ISO Base media file format is set.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本開示は、ISO Base media file formatのファイルの欠損データの修復の再開を適切に行うことができるようにする情報処理装置および情報処理方法に関する。 設定部は、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する。修復部は、設定部により設定された修復情報に基づいて、欠損データを修復する。本開示は、例えば、ISO Base media file formatなどのフォーマットの放送データのファイルを受信し、記録する受信装置等に適用することができる。

Description

情報処理装置および情報処理方法
　本開示は、情報処理装置および情報処理方法に関し、特に、ISO Base media file formatのファイルの欠損データの修復の再開を適切に行うことができるようにした情報処理装置および情報処理方法に関する。
　現在、MPEG（Moving Picture Experts Group phase）の会合において、UDP(User Datagram Protocol)や放送などのデータの欠損が起き得るプロトコルで伝送されたファイルデータを保存する手法として、Partial File Storageという手法が検討されている（例えば、非特許文献１参照）。Partial File Storageとは、ISO base media file format(ISO/IEC 14496-12)に準拠して、欠損が発生したファイルデータをカプセル化する手法である。
INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND AUDIO,ISO/IEC JTC1/SC29/WG11,MPEG2015/N15478,June 2015
　Partial File Storageで保存されたファイルデータは、保存後に欠損データが修復されることがある。しかしながら、修復が途中で中断されると、ファイル修復装置は、再開時に中断時の修復に関する情報がわからないため、修復済みの欠損データを再度修復したり、修復に失敗した欠損データに対して何度も修復を行ったりしてしまう。
　本開示は、このような状況に鑑みてなされたものであり、ISO Base media file formatのファイルの欠損データの修復の再開を適切に行うことができるようにするものである。
　本開示の第１の側面の情報処理装置は、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定部と、前記設定部により設定された前記修復情報に基づいて、前記欠損データを修復する修復部とを備える情報処理装置である。
　本開示の第１の側面の情報処理方法は、本開示の第１の側面の情報処理装置に対応する。
　本開示の第１の側面においては、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定され、設定された前記修復情報に基づいて、前記欠損データが修復される。
　本開示の第２の側面の情報処理装置は、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生部を備える情報処理装置である。
　本開示の第２の側面の情報処理方法は、本開示の第２の側面の情報処理装置に対応する。
　本開示の第２の側面においては、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルが再生される。
　なお、本開示の第１および第２の側面の情報処理装置は、コンピュータにプログラムを実行させることにより実現することができる。
　また、本開示の第１および第２の側面の情報処理装置を実現するために、コンピュータに実行させるプログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。
　本開示の第１の側面によれば、欠損データを修復することができる。また、本開示の第１の側面によれば、ISO Base media file formatのファイルの欠損データの修復の再開を適切に行うことができる。
　本開示の第２の側面によれば、ファイルを再生することができる。また、本開示の第２の側面によれば、欠損データの修復の再開を適切に行うことができるISO Base media file formatのファイルを再生することができる。
　なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本開示を適用した情報処理システムの第１実施の形態の構成例を示すブロック図である。 欠損ありファイルの第１の構造例を示す図である。 欠損ありファイルの第２の構造例を示す図である。 図２および図３のPartial File Container Boxのシンタックスの例を示す図である。 図４のOriginal Source URL Boxのシンタックスとセマンティクスの例を示す図である。 図４のPartially Corrupted File Boxのシンタックスの例を示す図である。 図４のPartially Corrupted File Boxのセマンティクスの例を示す図である。 図１の受信装置のファイル生成処理を説明するフローチャートである。 図１の受信装置のファイル修復処理を説明するフローチャートである。 図９の欠損データ修復処理の詳細を説明するフローチャートである。 第２実施の形態におけるPartially Corrupted File Boxのシンタックスの例を示す図である。 第２実施の形態におけるPartially Corrupted File Boxのセマンティクスの例を示す図である。 第２実施の形態におけるファイル修復処理を説明するフローチャートである。 第３実施の形態におけるPartially Corrupted File Boxのシンタックスの例を示す図である。 第３実施の形態における欠損データ修復処理を説明するフローチャートである。 第４実施の形態における欠損ありファイルの第１の構造例を示す図である。 第４実施の形態における欠損ありファイルの第２の構造例を示す図である。 図１７のPartial File Container Boxのシンタックスの例を示す図である。 図１６および図１７のRecovery Status Boxのシンタックスの第１の例を示す図である。 図１６および図１７のRecovery Status Boxのシンタックスの第２の例を示す図である。 第５実施の形態におけるファイル生成部の処理を説明する図である。 欠損ありファイル情報と修復情報が設定されたMPDファイルの第１の構成例を示す図である。 file_nameとfile_recovered_status_flagのセマンティクスの例を示す図である。 欠損ありファイル情報と修復情報が設定されたMPDファイルの第２の構成例を示す図である。 第６実施の形態におけるファイル生成部の処理を説明する図である。 File Recovery Status Boxのシンタックスの例を示す図である。 Corrupted File Indexファイル情報が設定されたMPDファイルの構成例を示す図である。 第７実施の形態におけるファイル生成部３２の処理を説明する図である。 欠損ありInitialization Segmentファイルの構成例を示す図である。 Segment Corrupted Information Boxのシンタックスの例を示す図である。 本開示を適用した情報処理システムの第８実施の形態の構成例を示すブロック図である。 本開示を適用した情報処理システムの第９実施の形態の構成例を示すブロック図である。 コンピュータのハードウエアの構成例を示すブロック図である。
　以下、および本開示を実施するための形態（以下、実施の形態という）について説明する。なお、説明は以下の順序で行う。
　１．第１実施の形態：情報処理システム（図１乃至図１０）
　２．第２実施の形態：情報処理システム（図１１乃至図１３）
　３．第３実施の形態：情報処理システム（図１４および図１５）
　４．第４実施の形態：情報処理システム（図１６乃至図２０）
　５．第５実施の形態：情報処理システム（図２１乃至図２４）
　６．第６実施の形態：情報処理システム（図２５乃至図２７）
　７．第７実施の形態：情報処理システム（図２８乃至図３０）
　８．第８実施の形態：情報処理システム（図３１）
　９．第９実施の形態：情報処理システム（図３２）
　１０．第１０実施の形態：コンピュータ（図３３）
　＜第１実施の形態＞
　（情報処理システムの第１実施の形態の構成例）
　図１は、本開示を適用した情報処理システムの第１実施の形態の構成例を示すブロック図である。
　図１の情報処理システム１０は、放送局１１、受信装置１２（情報処理装置）、およびHTTP（HyperText Transfer Protocol）サーバ１３により構成される。情報処理システム１０では、受信装置１２が、放送局１１から放送データのファイルを受信し、その放送データのファイルの欠損データをHTTPサーバ１３から取得したデータを用いて修復する。
　具体的には、情報処理システム１０の放送局１１は、MPEG2方式などで符号化された放送データのISO Base media file formatなどのフォーマットに準拠したファイルを、図示せぬアンテナなどを介して受信装置１２に送信する。
　受信装置１２は、放送受信部３１、ファイル生成部３２、設定部３３、記録部３４、修復部３５、およびHTTP受信部３６により構成される。
　受信装置１２の放送受信部３１は、図示せぬアンテナなどを介して、放送局１１から送信されてくる放送データのファイルを受信し、ファイル生成部３２に供給する。
　ファイル生成部３２は、放送受信部３１から供給される放送データのファイルに欠損データが存在するかどうかを判定する。放送データのファイルに欠損データが存在しないと判定された場合、ファイル生成部３２は、放送データからISO Base media file formatのファイル（以下、欠損なしファイルという）を生成する。
　一方、放送データのファイルに欠損データが存在すると判定された場合、ファイル生成部３２は、Partial File Storageという手法で、放送データからISO Base media file formatに準拠したファイル（以下、欠損ありファイルという）を生成する。欠損ありファイルには、その欠損ありファイルの欠損データの修復の状態を示す修復情報のデフォルト値が、設定部３３により設定される。ファイル生成部３２は、欠損なしファイルと、修復情報のデフォルト値が設定された欠損ありファイルを、記録部３４に供給する。
　設定部３３は、ファイル生成部３２により生成される欠損ありファイルに修復情報のデフォルト値を設定する。また、設定部３３は、修復部３５から供給される修復済みの欠損データの数を表す修復済み情報に基づいて、記録部３４に記録されている欠損ありファイルに設定された修復情報を更新する。
　記録部３４は、ファイル生成部３２から供給される欠損なしファイルと欠損ありファイルを記録する。
　修復部３５は、記録部３４に記録されている欠損ありファイルのうちの１つを修復対象ファイルとして選択する。修復部３５は、修復対象ファイルに含まれる修復情報に基づいて、所定の欠損データを修復対象データに決定する。
　修復部３５は、修復対象ファイルの生成に用いられた放送データのファイルに対応する、欠損データが存在しない場合のファイル（以下、修復用ファイルという）のURL（Uniform Resource Locator）情報などの取得先情報を、修復対象ファイルから取得し、HTTP受信部３６に供給する。修復部３５は、取得先情報の供給に応じてHTTP受信部３６から供給される修復用ファイルを用いて欠損データを修復する。修復部３５は、修復済み情報を設定部３３に供給する。
　HTTP受信部３６は、修復部３５から供給される取得先情報に基づいてHTTPサーバ１３と通信を行い、HTTPサーバ１３に保持されている修復用ファイルを取得する。HTTP受信部３６は、取得された修復用ファイルを修復部３５に供給する。
　（欠損ありファイルの第１の構造例）
　図２は、欠損ありファイルの第１の構造例を示す図である。
　図２に示すように、欠損ありファイルは、ISO base media file formatのBox構造のPartial File Container Boxにより構成される。Partial File Container Boxでは、放送受信部３１により受信された欠損データが存在する放送データのファイルがカプセル化される。
　具体的には、Partial File Container Boxは、Top Level Box Index Box, Original Source URL Box, Partially Corrupted File Box、およびfile_dataにより構成される最上位のBoxである。
　Top Level Box Index Boxには、所定のレベルのBoxの位置を示す情報が記述される。Original Source URL Boxには、修復用ファイルの取得先情報としてURL情報が記述される。Partially Corrupted File Boxには、欠損データの位置とサイズを表す欠損情報、修復情報等が記述される。file_dataは、放送受信部３１により受信されたファイルの欠損データ(Corrupted data)の部分にダミーデータが配置された放送データである。従って、file_dataのサイズは、放送受信部３１により受信されるべきファイルのサイズと同一である。
　（欠損ありファイルの第２の構造例）
　図３は、欠損ありファイルの第２の構造例を示す図である。
　図３の欠損ありファイルの構造は、file_dataを除いて、図２の構造と同一である。図３のfile_dataは、放送受信部３１により受信されたファイルの欠損データの部分にダミーデータを配置せず、欠損データの部分を詰めた放送データである。
　（Partial File Container Boxのシンタックスの例）
　図４は、図２および図３のPartial File Container Boxのシンタックス(syntax)の例を示す図である。
　図４に示すように、Partial File Container BoxのTop Level Box Index BoxとOriginal Source URL Boxは、配置されてもされなくてもよいBox（Optional Box）である。Partially Corrupted File Boxは、必ず配置されるBox(mandatory Box)である。
　（Original Source URL Boxのシンタックスとセマンティクスの例）
　図５は、Original Source URL Boxのシンタックスとセマンティクス（semantics）の例を示す図である。具体的には、図５のＡは、Original Source URL Boxのシンタックスの例を示す図であり、図５のＢは、セマンティクスの例を示す図である。
　図５に示すように、Original Source URL Boxには、file_dataに対応する修復用ファイルのURL情報（url）が記述される。図１のHTTP受信部３６は、このURL情報に基づいてHTTPサーバ１３から修復ファイルを取得する。
　欠損ありファイルの構造が図２の構造である場合、修復部３５は、file_dataのダミーデータを、そのダミーデータに対応する修復用ファイルの欠損していない放送データに置換することにより、欠損データを修復する。一方、欠損ありファイルの構造が図３の構造である場合、修復部３５は、修復用ファイルのfile_dataに存在しない放送データをfile_dataに挿入することにより、欠損データを修復する。
　（Partially Corrupted File Boxのシンタックスとセマンティクスの例）
　図６は、Partially Corrupted File Boxのシンタックスの例を示す図であり、図７は、セマンティクスの例を示す図である。
　図６に示すように、Partially Corrupted File Boxには、「version」と「flags」が記述される。図７に示すように、「version」は、このPartially Corrupted File Boxのバージョンを示す情報である。「flags」は、PCFB_BYTES_REMOVEDフラグ、All_Corrupted_Data_was_tried_to_recoverフラグ、およびNOW_recoveringフラグにより構成される。
　PCFB_BYTES_REMOVEDフラグは、flagsの最下位ビットに値が設定される、file_dataにダミーデータを存在しないかどうかを示すフラグである。PCFB_BYTES_REMOVEDフラグは、file_dataにダミーデータが存在しないことを示す場合１であり、file_dataにダミーデータが存在する場合０である。即ち、欠損ありファイルの構造が図３の構造である場合、PCFB_BYTES_REMOVEDフラグは１に設定され、欠損ありファイルの構造が図２の構造である場合、PCFB_BYTES_REMOVEDフラグは０に設定される。
　All_Corrupted_Data_was_tried_to_recoverフラグは、flagsの下から２ビット目に値が設定される、file_dataの全ての欠損データの修復が少なくとも１度完了したかどうかを示すフラグであり、修復情報の１つである。All_Corrupted_Data_was_tried_to_recoverフラグは、file_dataの全ての欠損データの修復が少なくとも１度完了したことを示す場合１であり、まだ完了していないことを示す場合０である。
　NOW_recoveringフラグは、flagsの下から３ビット目に値が設定される、file_dataの全ての欠損データの修復が途中であるかどうかを示すフラグであり、修復情報の１つである。NOW_recoveringフラグは、file_dataの全ての欠損データの修復の途中であることを示す場合１であり、途中ではないことを示す場合０である。
　以上により、file_dataの全ての欠損データの修復がまだ開始されていない場合、All_Corrupted_Data_was_tried_to_recoverフラグとNOW_recoveringフラグは０に設定される。また、file_dataの全ての欠損データの修復が開始されたが、まだ修復の途中である場合、All_Corrupted_Data_was_tried_to_recoverフラグは０に設定されるが、NOW_recoveringフラグは１に設定される。さらに、file_dataの全ての欠損データの修復が少なくとも１度完了した場合、All_Corrupted_Data_was_tried_to_recoverフラグは１に設定されるが、NOW_recoveringフラグは０に設定される。
　図６に示すように、Partially Corrupted File Boxにはまた、entry_countとnum_of_recoveredが記述される。図７に示すように、entry_countは、file_dataの欠損データの数である。num_of_recoveredは修復が行われた欠損データの数を示す情報であり、修復情報の１つである。
　従って、num_of_recoveredが０である場合、flagsのAll_Corrupted_Data_was_tried_to_recoverフラグとNOW_recoveringフラグは０である。また、num_of_recoveredが、０以外であり、かつ、entry_countより小さい場合、flagsのAll_Corrupted_Data_was_tried_to_recoverフラグは０であり、NOW_recoveringフラグは１である。さらに、num_of_recoveredがentry_countと同一である場合、flagsのAll_Corrupted_Data_was_tried_to_recoverフラグは１であり、NOW_recoveringフラグは０である。
　図６に示すように、Partially Corrupted File Boxにはまた、file_dataの各欠損データに対してエントリが生成され、先頭のエントリから順に、各エントリのbyte_offsetとcorrupted_sizeが欠損情報として記述される。図７に示すように、byte_offsetは、欠損データの開始位置をfile_dataの先頭からのオフセット量で示すオフセット情報である。「version」が１である場合、オフセット情報のビット長は64bitであり、１ではない場合、32bitである。また、corrupted_sizeは、欠損データのサイズを示す情報である。
　なお、修復は、先頭のエントリに対応する欠損データから順に行われる。従って、num_of_recoveredは、最後に修復が行われた欠損データに対応するエントリが先頭から何番目のエントリであるかを示す情報であるともいえる。
　Partially Corrupted File Boxが、図６および図７で説明したように構成されることにより、修復部３５は、修復対象ファイルのflagsに基づいて、修復対象ファイルの修復が未実行であるか、途中であるか、または完了しているかを認識することができる。また、修復部３５は、修復対象ファイルの修復が途中で中断されている場合に、修復対象ファイルのentry_countに基づいて、中断位置から修復を再開することができる。
　（受信装置の処理の説明）
　図８は、図１の受信装置１２のファイル生成処理を説明するフローチャートである。このファイル生成処理は、放送局１１から放送データのファイルが送信されてきたとき、開始される。
　図８のステップＳ１１において、受信装置１２の放送受信部３１は、図示せぬアンテナなどを介して、放送局１１から送信されてくる放送データのファイルを受信し、ファイル生成部３２に供給する。
　ステップＳ１２において、ファイル生成部３２は、放送受信部３１から供給される放送データのファイルに欠損データが存在するかどうかを判定する。
　ステップＳ１２で放送データのファイルに欠損データが存在すると判定された場合、ステップＳ１３において、ファイル生成部３２は、Partial File Storageという手法で、放送データから欠損ありファイルを生成する。
　ステップＳ１４において、設定部３３は、修復情報のデフォルト値を、ファイル生成部３２により生成された欠損ありファイルのPartially Corrupted File Boxに設定する。なお、修復情報のデフォルト値は０である。
　ステップＳ１５において、設定部３３は、修復情報のデフォルト値が設定された欠損ありファイルを記録部３４に供給し、記録させる。そして、処理は終了する。
　一方、ステップＳ１２で放送データのファイルに欠損データが存在しないと判定された場合、ステップＳ１６において、ファイル生成部３２は、放送データから欠損なしファイルを生成する。
　ステップＳ１７において、ファイル生成部３２は、欠損なしファイルを記録部３４に供給し、記録させる。そして、処理は終了する。
　図９は、図１の受信装置１２のファイル修復処理を説明するフローチャートである。このファイル修復処理は、例えば、修復部３５が、記録部３４に記録されている欠損ありファイルのうちの１つを修復対象ファイルとして選択したとき開始される。
　図９のステップＳ３１において、受信装置１２の修復部３５は、記録部３４に記録されている修復対象ファイルのPartial File Container Boxを読み出す。ステップＳ３２において、修復部３５は、ステップＳ３１で読み出されたPartial File Container BoxからPartially Corrupted File Boxを取得する。
　ステップＳ３３において、修復部３５は、ステップＳ３２で取得されたPartially Corrupted File Boxからflagsを取得する。
　ステップＳ３４において、修復部３５は、flagsに基づいて、All_Corrupted_Data_was_tried_to_recoverフラグが１に設定されているかどうか、即ちflagsの下から２ビット目に１が設定されているかどうかを判定する。
　ステップＳ３４でAll_Corrupted_Data_was_tried_to_recoverフラグが１に設定されていると判定された場合、即ち修復対象ファイルの全ての欠損データの修復が少なくとも１度完了している場合、処理は終了する。
　一方、ステップＳ３４で、All_Corrupted_Data_was_tried_to_recoverフラグが１に設定されていないと判定された場合、即ち修復対象ファイルの全ての欠損データの修復がまだ１度も完了していない場合、処理はステップＳ３５に進む。
　ステップＳ３５において、修復部３５は、flagsに基づいて、NOW_recoveringフラグが１に設定されているかどうか、即ちflagsの下から３ビット目に１が設定されているかどうかを判定する。
　ステップＳ３５でNOW_recoveringフラグが１に設定されていると判定された場合、即ち修復対象ファイルの全ての欠損データの修復が途中で中断されている場合、処理はステップＳ３６に進む。
　ステップＳ３６において、修復部３５は、ステップＳ３２で取得されたPartially Corrupted File Boxからnum_of_recoveredを取得し、処理をステップＳ３７に進める。
　一方、ステップＳ３５でNOW_recoveringフラグが１に設定されていないと判定された場合、即ち修復対象ファイルの全ての欠損データの修復がまだ開始されていない場合、修復部３５は、num_of_recoveredが０であると認識する。そして、処理はステップＳ３７に進む。
　なお、図９の例では、ステップＳ３５でNOW_recoveringフラグが１に設定されていないと判定された場合、修復部３５は、num_of_recoveredが０であると認識するようにするが、Partially Corrupted File Boxからnum_of_recoveredとして０を取得するようにしてもよい。
　ステップＳ３７において、修復部３５は、読み出されたPartial File Container BoxからOriginal Source URL Boxを取得する。
　ステップＳ３８において、修復部３５は、修復対象ファイルの欠損データを順に修復する欠損データ修復処理を行う。この欠損データ修復処理の詳細は、後述する図１０を参照して説明する。
　図１０は、図９のステップＳ３８の欠損データ修復処理の詳細を説明するフローチャートである。
　図１０のステップＳ５１において、修復部３５は、カウント値ｉを、取得または認識されたnum_of_recoveredに１を加算した値に設定する。ステップＳ５２において、修復部３５は、カウント値ｉが、Partially Corrupted File Boxに含まれるentry_count以下であるかどうかを判定する。
　ステップＳ５２でカウント値がentry_count以下であると判定された場合、即ち、修復対象ファイルの全ての欠損データの修復がまだ完了していない場合、修復部３５は、Partially Corrupted File Boxの先頭からｉ番目のエントリに対応する欠損データを修復対象データに決定する。
　そして、ステップＳ５３において、修復部３５は、Original Source URL Boxに記述されるURL情報をHTTP受信部３６に供給することにより、HTTPサーバ１３に保持されている修復用ファイルのｉ番目のエントリに対応する放送データを修復用データとして、HTTP受信部３６を介して取得する。ステップＳ５４において、修復部３５は、Partially Corrupted File Boxに記述される先頭からｉ番目のエントリの欠損情報と修復用データとに基づいて、そのエントリに対応する修復対象データの修復を行う。そして、修復部３５は、カウント値ｉを修復済み情報として設定部３３に供給する。
　ステップＳ５５において、修復部３５は、欠損データ修復処理を中止するかどうかを判定する。ステップＳ５５で欠損データ修復処理を中止しないと判定された場合、ステップＳ５６において、修復部３５は、カウント値を１だけインクリメントする。そして、処理はステップＳ５２に戻る。
　一方、ステップＳ５５で欠損データ修復処理を中止すると判定された場合、処理はステップＳ５７に進む。ステップＳ５７において、設定部３３は、記録部３４に記録されている修復対象ファイルのNOW_recoveringフラグを１に設定（更新）し、処理をステップＳ５９に進める。
　また、ステップＳ５２でカウント値がentry_countより大きいと判定された場合、即ち全ての欠損データの修復が完了した場合、処理はステップＳ５８に進む。ステップＳ５８において、設定部３３は、記録部３４に記録されている修復対象ファイルのAll_Corrupted_Data_was_tried_to_recoverフラグを１に設定し、NOW_recoveringフラグを０に設定する。そして、処理はステップＳ５９に進む。
　ステップＳ５９において、設定部３３は、記録部３４に記録されている修復対象ファイルのnum_of_recoveredに、修復部３５から供給される修復済み情報が表すカウント値ｉを設定する。そして、処理は図９のステップＳ３８に戻り、処理は終了する。
　以上のように、受信装置１２は、欠損ありファイルの修復情報を設定するので、欠損ありファイルの修復時に、その欠損ありファイルの修復の状態を容易に認識することができる。これにより、受信装置１２は、途中で修復が中断された欠損ありファイルの修復を再開する場合に修復済みのデータを再度修復したり、修復に失敗したデータに対して何度も修復を行ったりすることなく、中断位置から適切に修復を再開することができる。その結果、ファイルの修復処理の負荷が軽減される。
　これに対して、修復情報が設定されない場合、受信装置は、修復と同時に、entry_countの更新や欠損情報の削除等の処理を行うことにより、修復の再開時に修復の中断時の状態を認識することができる。しかしながら、この処理は煩雑であり、また、処理の結果Partially Corrupted File Boxのサイズが変更されるため、Partially Corrupted File Box以降のデータの書き直し等が必要になる。従って、ファイルの修復処理の負荷が大きい。
　＜第２実施の形態＞
　（Partially Corrupted File Boxのシンタックスとセマンティクスの例）
　本開示を適用した情報処理システムの第２実施の形態は、修復情報、および、修復済み情報の代わりに各欠損データの修復の成功または失敗を表す修復結果情報が修復部３５から設定部３３に供給される点を除いて、第１実施の形態と同一である。従って、以下では、図１の各部を情報処理システムの第２実施の形態の各部として用いて、修復情報および修復結果情報に関する処理についてのみ説明する。
　図１１は、第２実施の形態におけるPartially Corrupted File Boxのシンタックスの例を示す図であり、図１２は、セマンティクスの例を示す図である。
　図１１および図１２のPartially Corrupted File Boxの構成は、flagsがPCFB_BYTES_REMOVEDフラグのみから構成される点、num_of_recoveredが記述されない点、およびエントリごとにrecovered_flagが新たに記述される点が、図６および図７の構成と異なる。即ち、第２実施の形態における修復情報は、flagsとnum_of_recoveredではなく、recovered_flagである。
　各エントリのrecovered_flagは、そのエントリに対応する欠損データの修復が成功した状態、修復が失敗した状態、または修復が行われていない状態を示すフラグであり、修復情報である。recovered_flagは、RecoveredフラグとFailed_to_recoverフラグにより構成される。
　図１２に示すように、Recoveredフラグは、recovered_flagの最下位ビットに値が設定される、修復が成功した状態であるかどうかを示すフラグである。Recoveredフラグは、修復が成功した状態であることを示す場合１であり、修復が成功した状態ではないことを示す場合０である。
　Failed_to_recoverフラグは、recovered_flagの下から２番目のビットに値が設定される、修復が失敗した状態であるかどうかを示すフラグである。Failed_to_recoverフラグは、修復が失敗した状態であることを示す場合１であり、修復が失敗した状態ではないことを示す場合０である。
　従って、RecoveredフラグとFailed_to_recoverフラグが０である場合、修復が行われていない状態を示している。よって、修復情報のデフォルト値は０である。
　Partially Corrupted File Boxが、図１１および図１２で説明したように構成されることにより、修復部３５は、修復対象ファイルの各エントリのrecovered_flagに基づいて、そのエントリに対応する欠損データの修復の実行の有無および成功の有無を認識することができる。
　（受信装置の処理の説明）
　第２実施の形態におけるファイル生成処理は、図８のファイル生成処理と同様であるので、説明は省略する。
　図１３は、第２実施の形態における受信装置１２のファイル修復処理を説明するフローチャートである。
　図１３のステップＳ７１およびＳ７２の処理は、図９のステップＳ３１およびＳ３２の処理と同様であるので、説明は省略する。ステップＳ７３の処理は、図９のステップＳ３７の処理と同様であるので、説明は省略する。
　ステップＳ７４において、受信装置１２の修復部３５は、カウント値ｉを１に設定する。ステップＳ７５において、修復部３５は、ステップＳ７２で取得されたPartially Corrupted File Boxに記述される先頭からｉ番目のエントリのrecovered_flagを取得する。
　ステップＳ７６において、修復部３５は、ステップＳ７５で取得されたrecovered_flagが０であるかどうか、即ちRecoveredフラグおよびFailed_to_recoverフラグが０であるかどうかを判定する。
　ステップＳ７６でrecovered_flagが０であると判定された場合、即ちｉ番目のエントリに対応する欠損データに対してまだ修復が行われていない場合、修復部３５は、ｉ番目のエントリに対応する欠損データを修復対象データに決定する。
　そして、ステップＳ７７において、修復部３５は、Original Source URL Boxに記述されるURL情報をHTTP受信部３６に供給することにより、HTTPサーバ１３に保持されている修復用ファイルのｉ番目のエントリに対応する放送データを修復用データとして、HTTP受信部３６を介して取得する。ステップＳ７８において、修復部３５は、ｉ番目のエントリの欠損情報と修復用データとに基づいて、そのエントリに対応する修復対象データの修復を行う。
　ステップＳ７９において、修復部３５は、ステップＳ７８の修復が成功したかどうかを判定する。例えば、修復部３５は、Original Source URL Boxに記述されるURL情報に対応してHTTPサーバ１３に修復用ファイルが存在せず、ステップＳ７７において修復用ファイルの取得に失敗している場合、修復部３５は、修復が成功していないと判定する。
　ステップＳ７９で修復が成功したと判定された場合、修復部３５は、ｉ番目のエントリに対応する修復対象データの修復の成功を表す修復結果情報を設定部３３に供給する。
　そして、ステップＳ８０において、設定部３３は、記録部３４に記録されている修復対象ファイルのｉ番目のエントリのRecoveredフラグを１に設定し、処理をステップＳ８２に進める。
　一方、ステップＳ７９で修復が成功していないと判定された場合、修復部３５は、ｉ番目のエントリに対応する修復対象データの修復の失敗を表す修復結果情報を設定部３３に供給する。
　そして、ステップＳ８１において、設定部３３は、記録部３４に記録されている修復対象ファイルのｉ番目のエントリのFailed_to_recoverフラグを１に設定し、処理をステップＳ８２に進める。
　また、ステップＳ７６でrecovered_flagが０ではないと判定された場合、即ちｉ番目のエントリに対応する欠損データに対して既に修復が行われている場合、処理はステップＳ８２に進む。
　ステップＳ８２において、修復部３５は、ファイル修復処理を中止するかどうかを判定する。ステップＳ８２でファイル修復処理を中止しないと判定された場合、処理はステップＳ８３に進む。ステップＳ８３において、設定部３３は、カウント値ｉを１だけインクリメントする。
　ステップＳ８４において、設定部３３は、カウント値ｉが、Partially Corrupted File Boxに記述されるentry_count以下であるかどうかを判定する。ステップＳ８４でカウント値ｉがentry_count以下であると判定された場合、処理はステップＳ７５に戻り、以降の処理が繰り返される。
　一方、ステップＳ８２でファイル修復処理を中止すると判定された場合、処理は終了する。また、ステップＳ８４でカウント値ｉがentry_countより大きいと判定された場合、即ち全ての欠損データの修復が行われた場合、処理は終了する。
　以上のように、第２実施の形態では、修復情報が、各欠損データの修復が成功した状態、失敗した状態、または行われていない状態を示す情報である。従って、受信装置１２は、各欠損データの修復の実行の有無だけでなく、その修復の成功の有無も認識することができる。
　＜第３実施の形態＞
　（Partially Corrupted File Boxのシンタックスの例）
　本開示を適用した情報処理システムの第３実施の形態は、第１実施の形態および第２実施の形態を組み合わせたものである。即ち、第３実施の形態では、修復情報が、flags，num_of_recovered、およびrecovered_flagであり、修復済み情報と修復結果情報が修復部３５から設定部３３に供給される。従って、以下では、図１の各部を情報処理システムの第３実施の形態の各部として用いて、修復情報、修復済み情報、および修復結果情報に関する処理についてのみ説明する。
　図１４は、第３実施の形態におけるPartially Corrupted File Boxのシンタックスの例を示す図である。
　図１４のPartially Corrupted File Boxの構成は、エントリごとにrecovered_flagが新たに記述される点が、図６の構成と異なる。
　（受信装置の処理の説明）
　第３実施の形態におけるファイル生成処理は、図８のファイル生成処理と同様であるので、説明は省略する。また、第３実施の形態におけるファイル修復処理は、ステップＳ３８の欠損データ修復処理を除いて図９のファイル修復処理と同様であるので、以下では、欠損データ修復処理についてのみ説明する。
　図１５は、第３実施の形態における受信装置１２の欠損データ修復処理を説明するフローチャートである。
　図１５のステップＳ１００乃至Ｓ１０３の処理は、図１０のステップＳ５１乃至Ｓ５４の処理と同様であり、ステップＳ１０４乃至Ｓ１０６の処理は、図１３のステップＳ７９乃至Ｓ８１の処理と同様である。また、ステップＳ１０７乃至Ｓ１１１の処理は図１０のステップＳ５５乃至Ｓ５９の処理と同様である。
　＜第４実施の形態＞
　（欠損ありファイルの第１の構造例）
　本開示を適用した情報処理システムの第４実施の形態は、修復情報がPartially Corrupted File Boxとは異なる新たなBoxに設定される点を除いて、第３実施の形態と同一である。従って、以下では、図１の各部を情報処理システムの第４実施の形態の各部として用いて、欠損ありファイルの構造についてのみ説明する。
　図１６は、第４実施の形態における欠損ありファイルの第１の構造例を示す図である。
　図１６の欠損ありファイルの構造は、Partially Corrupted File Boxに修復情報が記述されない点、および、欠損ありファイルがPartial File Container Boxと修復情報が配置されるRecovery Status Boxの２つのBoxから構成される点が、図２の構造と異なっている。
　図１６のPartially Corrupted File Boxのシンタックスは、flagsがPCFB_BYTES_REMOVEDフラグのみからなる点、および、num_of_recoveredが配置されない点を除いて、図６のシンタックスと同一であるため、説明は省略する。
　Recovery Status Boxは、Partial File Container Boxと同一の階層のBoxである。
　（欠損ありファイルの第２の構造例）
　図１７は、第４実施の形態における欠損ありファイルの第２の構造例を示す図である。
　図１７の欠損ありファイルの構造は、Recovery Status BoxがPartial File Container Box内に配置される点が、図１６の構造と異なっている。
　以上のように、第４実施の形態では、修復情報がPartially Corrupted File Boxとは異なるBoxに配置されるので、修復情報の設定を容易に行うことができる。
　なお、図示は省略するが、図１６および図１７の欠損ありファイルにおいて、図３の場合と同様に、file_dataにダミーデータが配置されないようにしてもよい。
　（Partial File Container Boxのシンタックスの例）
　図１８は、図１７のPartial File Container Boxのシンタックスの例を示す図である。
　図１８のPartial File Container Boxのシンタックスは、Recovery Status Boxが新たに配置される点を除いて、図４のシンタックスと同一である。
　（Recovery Status Boxのシンタックスの第１の例）
　図１９は、図１６および図１７のRecovery Status Boxのシンタックスの第１の例を示す図である。
　図１９のRecovery Status Boxには、flags,entry_count、およびnum_of_recoveredが記述される。また、Recovery Status Boxには、エントリごとにrecovered_flagが記述される。従って、Recovery Status Boxに記述されるrecovered_flagの数はentry_countである。
　（Recovery Status Boxのシンタックスの第２の例）
　図２０は、図１６および図１７のRecovery Status Boxのシンタックスの第２の例を示す図である。
　図２０のRecovery Status Boxのシンタックスは、entry_countが記述されない点、および、file_dataの欠損データのうちの修復が行われた欠損データのrecovered_flagのみが配置される点が、図１９のシンタックスと異なる。
　図２０のRecovery Status Boxでは、file_dataの欠損データのうちの修復が行われた欠損データのrecovered_flagのみが配置されるので、recovered_flagの数は、entry_countではなく、num_of_recoveredである。従って、全ての欠損データの修復が完了していない場合、図２０のRecovery Status Boxのデータサイズは、recovered_flagの数がentry_countである図１９のRecovery Status Boxのデータサイズに比べて小さくなる。
　また、図２０の場合、recovered_flagのRecoveredフラグとFailed_to_recoverフラグのいずれかが、必ず１に設定される。即ち、recovered_flagは、修復が行われていない状態を示す０にはならない。
　なお、第４実施の形態では、第３実施の形態の修復情報がPartially Corrupted File Boxとは異なる新たなBoxに設定されたが、第１実施の形態または第２実施の形態の修復情報がPartially Corrupted File Boxとは異なる新たなBoxに設定されてもよい。
　＜第５実施の形態＞
　（ファイル生成部の処理の説明）
　本開示を適用した情報処理システムの第５実施の形態は、放送データのファイルがMPEG-DASHに準拠したファイルである場合に、ファイル生成部３２が、そのファイルのうちのMPD（Media Presentation Description）ファイルに、欠損ありファイルを特定する欠損ファイル情報を設定する点と、設定部３３が修復情報をMPDファイルにも設定する点とを除いて、第１実施の形態乃至第４実施の形態の構成と同一である。従って、以下では、図１の各部を情報処理システムの第５実施の形態の各部として用いて、MPDファイルに関する処理についてのみ説明する。
　図２１は、第５実施の形態におけるファイル生成部３２の処理を説明する図である。
　図２１に示すように、放送データのファイルがMPEG-DASHに準拠したファイルである場合、ファイルはセグメント化されており、１つのInitialization Segmentファイル、１以上（図２１の例ではｎ個）のMedia Segmentファイル、および図示せぬMPDファイルにより構成される。なお、以下では、Initialization SegmentファイルとMedia Segmentファイルを特に区別する必要がない場合、それらをまとめてSegmentファイルという。
　ファイル生成部３２は、放送受信部３１から供給されるSegmentファイルに欠損データが存在するかどうかを判定する。
　図２１に示すように、先頭からx番目のMedia Segmentファイル（Media Segment x）に欠損データが存在すると判定された場合、ファイル生成部３２は、そのMedia Segmentファイルの放送データから、欠損ありファイルを生成する。
　なお、図２１の例では、第１実施の形態乃至第３実施の形態と同様に欠損ありファイルが生成されるが、第４実施の形態と同様にRecovery Status Boxを含む欠損ありファイルが生成されるようにしてもよい。
　また、先頭からx番目のMedia Segmentファイル以外のSegmentファイルに欠損データが存在しないと判定された場合、ファイル生成部３２は、そのSegmentファイルをそのまま欠損なしファイルとする。ファイル生成部３２は、生成された欠損ありファイルと欠損なしファイルを記録部３４に供給し、記録させる。
　（MPDファイルの第１の構成例の説明）
　図２２は、欠損ありファイル情報と修復情報が設定されたMPDファイルの第１の構成例を示す図である。
　MPDファイルは、Segmentファイルを管理するファイルであり、MPDファイルには、放送データの符号化情報（Configration情報）、画像のサイズ、音声の言語などの情報が階層化されて、XML形式で記述される。
　図２２のＡに示すように、MPDファイルにおける階層化は、ピリオド（Period）、アダプテーションセット（AdaptationSet）、リプレゼンテーション（Representation）等の要素を用いて行われる。
　MPDファイルでは、自分が管理するSegmentファイルに格納される放送データが所定の時間範囲で分割される。ピリオド要素は、分割された放送データごとに記述される。アダプテーションセット要素は、ピリオド要素に含まれ、そのピリオド要素に対応する放送データのリプレゼンテーション要素をグルーピングする。リプレゼンテーション要素は、放送データの種類（図２２のＡの例では、画像、音声）等によってグルーピングされる。リプレゼンテーション要素は、分割された放送データの取得先のURL情報等を有する。
　ファイル生成部３２が、放送受信部３１から図２２のＡのMPDファイルを取得し、Segmentファイルの少なくとも１つに欠損データが存在する場合、ファイル生成部３２は、図２２のＢに示す<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:2015”>を、図２２のＡのMPDファイルの（１）乃至（４）のいずれかの位置に設定する。
　<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:2015”>は、それを含む要素が含むリプレゼンテーション要素に対応するSegmentファイルの少なくとも１つが欠損ありファイルであることを示すEssentialPropertyである。
　例えば、図２２のＡの（１）または（２）の位置に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:2015”>が設定される場合、それを含む要素が含むリプレゼンテーション要素に対応する、MPDファイルが管理する全てのSegmentファイル(video.mp4,audio.mp4)の少なくとも一方が欠損ありファイルである。また、図２２のＡの（３）または（４）の位置に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:2015”>が設定される場合、それを含む要素が含むリプレゼンテーション要素に対応するSegmentファイル（video.mp4）が欠損ありファイルである。
　また、ファイル生成部３２と設定部３３は、図２２のＢに示す<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を、図２２のＡのＭＰＤファイルの（１）乃至（４）のいずれかの位置に欠損ありファイルごとに設定する。
　具体的には、<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>は、それを含む要素が含むリプレゼンテーション要素に対応するSegmentファイルのうちの欠損ありファイルの修復情報と欠損ファイル情報を示すEssentialPropertyである。
　より詳細には、図２３に示すように、file_nameは、欠損ファイル情報としての欠損ありファイルのファイル名を示す情報である。また、file_recovered_status_flagは、欠損ありファイルの修復情報としてのAll_Corrupted_data_was_tired_to_recoverフラグとNOW_recoveringフラグにより構成される。
　ファイル生成部３２は、取得された図２２のＡのMPDファイルの（１）乃至（４）のいずれかの位置に、各欠損ありファイルの<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を設定する。ファイル生成部３２は、各欠損ありファイルのfile_nameを、<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>のfile_nameとして設定する。
　なお、<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を含むリプレゼンテーション要素に対応するSegmentファイルが１つである場合（図２２の例では（３）または（４）に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>が設定された場合）、欠損ありファイルは一意に決まるため、file_nameは設定されなくてもよい。
　設定部３３は、各欠損ありファイルの<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>のfile_recovered_status_flagに、デフォルト値として０を設定する。また、設定部３３は、修復部３５から供給される修復済み情報に基づいて、記録部３４に記録されている欠損ありファイルに設定された修復情報だけでなく、MPDファイルに設定された修復情報も更新する。
　（MPDファイルの第２の構成例の説明）
　図２４は、欠損ありファイル情報と修復情報が設定されたMPDファイルの第２の構成例を示す図である。
　図２４の例では、ファイル生成部３２は、放送受信部３１から供給されるSegmentファイルのうちの少なくとも１つに欠損データが存在する場合、図２４のＡに示すように、Partial File Storageという手法で、放送受信部３１から供給されるMPDファイルをカプセル化する。
　具体的には、ファイル生成部３２は、放送受信部３１から供給されるMPDファイルをOriginal MPD要素に格納し、そのOriginal MPD要素をEncapsulated MPD要素に格納する。従って、修復部３５は、MPDファイルにEncapsulated MPD要素が存在するかどうかによって、MPDファイルが管理するSegmentファイルの少なくとも１つが欠損ありファイルであるかどうかを認識することができる。
　ファイル生成部３２は、図２４のＡのMPDファイルの（１）の位置に、図２４のＢに示す<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:2015”>を設定する。<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:2015”>は、MPDファイルが管理するSegmentファイルの少なくとも１つが欠損ありファイルであることを示す。
　また、ファイル生成部３２と設定部３３は、図２４のＡのMPDファイルの（１）の位置に、図２４のＢに示す<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を欠損ありファイルごとに設定する。
　具体的には、<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>は、MPDファイルが管理するsegmentファイルのうちの欠損ありファイルの修復情報と欠損ファイル情報を示す。
　ファイル生成部３２は、取得された図２４のＡのMPDファイルの（１）に、各欠損ありファイルの<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を設定する。ファイル生成部３２は、各欠損ありファイルのfile_nameを、<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>のfile_nameとして設定する。
　設定部３３は、各欠損ありファイルの<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>のfile_recovered_status_flagに、デフォルト値として０を設定する。また、設定部３３は、修復部３５から供給される修復済み情報に基づいて、記録部３４に記録されている欠損ありファイルに設定された修復情報だけでなく、MPDファイルに設定された修復情報も更新する。
　以上のように、図２４の例では、MPDファイルがカプセル化されるので、修復に対応していない既存の再生装置は、MPDファイルを理解することができない。従って、このような再生装置において欠損ありファイルが再生されることを防止することができる。
　第５実施の形態では、MPDファイルに欠損ファイル情報と修復情報が設定される。従って、修復部３５は、MPDファイルを取得するだけで、記録部３４に記録されている修復が完了していない欠損ありファイルを認識することができる。従って、修復部３５は、修復が完了した欠損ありファイルを無駄に読み出すことなく、修復が完了していない欠損ありファイルの修復を行うことができる。
　また、記録部３４に記録されている欠損ありファイルを再生する再生装置は、MPDファイルを取得するだけで、修復が完了した欠損ありファイルを認識することができる。従って、再生装置は、修復が完了していない欠損ありファイルを無駄に読み出すことなく、修復が完了した欠損ありファイルを再生することができる。
　＜第６実施の形態＞
　（ファイル生成部の処理の説明）
　本開示を適用した情報処理システムの第６実施の形態は、放送データのファイルがMPEG-DASHに準拠したファイルである場合に、設定部３３が修復情報をCorrupted File Indexファイルに設定する点と、ファイル生成部３２が、MPDファイルに、欠損ファイル情報や修復情報ではなく、Corrupted File Indexファイルを特定するCorrupted File Indexファイル情報を設定する点とを除いて、第５実施の形態と同一である。従って、以下では、図１の各部を情報処理システムの第６実施の形態の各部として用いて、Corrupted File IndexファイルおよびMPDファイルに関する処理についてのみ説明する。
　図２５は、第６実施の形態におけるファイル生成部３２の処理を説明する図である。
　ファイル生成部３２は、第５実施の形態と同様に、放送受信部３１から供給されるSegmentファイルに欠損データが存在するかどうかを判定する。図２５に示すように、先頭からx番目とy番目のMedia Segmentファイル（Media Segment x, Media Segment y）に欠損データが存在すると判定された場合、ファイル生成部３２は、そのMedia Segmentファイルの放送データから、欠損ありファイルを生成する。
　なお、図２５の例では、図１７の構成の欠損ありファイルが生成されるが、第１実施の形態乃至第３実施の形態と同様に修復情報がPartially Corrupted File Boxに設定された欠損ありファイルが生成されるようにしてもよい。また、図１６に示したようにPartial File Container Boxとは異なるRecovery Status Boxに修復情報が設定された欠損ありファイルが生成されるようにしてもよい。
　また、先頭からx番目およびy番目のMedia Segmentファイル以外のSegmentファイルに欠損データが存在しないと判定された場合、ファイル生成部３２は、そのSegmentファイルをそのまま欠損なしファイルとする。ファイル生成部３２は、生成された欠損ありファイルと欠損なしファイルを記録部３４に供給し、記録させる。
　さらに、ファイル生成部３２は、放送データのファイルとは異なる新しいCorrupted File Indexファイルを生成する。設定部３３は、生成されたCorrupted File Indexファイルに、各欠損ありファイルの修復情報をFile Recovery Status Boxとして設定する。
　（File Recovery Status Boxのシンタックスの例）
　図２６は、File Recovery Status Boxのシンタックスの例を示す図である。
　Corrupted File Indexファイルには、File Recovery Status Boxが欠損ありファイルごとに設けられる。図２６に示すように、File Recovery Status Boxには、file_name、file_recovered_status_flag、およびRecovery Status Boxが記述される。
　なお、File Recovery Status Boxには、Recovery Status Boxが配置されなくてもよい。File Recovery Status BoxにRecovery Status Boxが配置される場合には、欠損ありファイルにはRecovery Status Boxが配置されなくてもよい。
　（MPDファイルの構成例の説明）
　図２７は、Corrupted File Indexファイル情報が設定されたMPDファイルの構成例を示す図である。
　ファイル生成部３２が、放送受信部３１から図２７のＡのMPDファイルを取得し、Segmentファイルの少なくとも１つに欠損データが存在する場合、ファイル生成部３２は、MPDファイルに、Corrupted File Indexファイルのファイル名を示す情報をCorrupted File Indexファイル情報として設定する。
　具体的には、ファイル生成部３２は、図２７のＢに示す<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:2015” value=“file_name”>を、図２７のＡの（１）の位置に設定する。
　<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:2015” value=“file_name”>は、MPDファイルが管理するSegmentファイルの少なくとも１つが欠損ありファイルであり、その欠損ありファイルの修復情報が設定されるCorrupted File Indexファイルのファイル名がfile_nameであることを示すEssentialPropertyである。
　なお、第６実施の形態におけるMPDファイルには、第５実施の形態と同様に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>が記述されてもよい。また、第６実施の形態におけるMPDファイルは、第５実施の形態と同様にカプセル化されてもよい。
　＜第７実施の形態＞
　（ファイル生成部の処理の説明）
　本開示を適用した情報処理システムの第７実施の形態は、放送データのファイルがMPEG-DASHに準拠したファイルである場合に、修復情報が設定されるファイルが、Corrupted File Indexファイルではなく、Initialization Segmentファイルである点を除いて、第６実施の形態と同一である。従って、以下では、図１の各部を情報処理システムの第７実施の形態の各部として用いて、Initialization SegmentファイルおよびMPDファイルに関する処理についてのみ説明する。
　図２８は、第７実施の形態におけるファイル生成部３２の処理を説明する図である。
　ファイル生成部３２は、第６実施の形態と同様に、放送受信部３１から供給されるSegmentファイルに欠損データが存在するかどうかを判定する。図２８に示すように、先頭からx番目とy番目のMedia Segmentファイル（Media Segment x, Media Segment y）に欠損データが存在すると判定された場合、ファイル生成部３２は、そのMedia Segmentファイルの放送データから、欠損ありファイルを生成する。
　また、ファイル生成部３２は、Initialization Segmentファイルに欠損データが存在するかどうかによらず、Initialization Segmentファイルから、欠損ありファイルを生成する。設定部３３は、Initialization Segmentファイルから生成された欠損ありファイル（以下、欠損ありInitialization Segmentファイルという）に、全ての欠損ありファイルの修復情報をSegment Corrupted Information Boxとして設定する。ファイル生成部３２は、生成された欠損ありファイルと欠損なしファイルを記録部３４に供給し、記録させる。
　なお、図２８の例では、図１７の構成の欠損ありファイルが生成されるが、第１実施の形態乃至第３実施の形態と同様に修復情報がPartially Corrupted File Boxに設定された欠損ありファイルが生成されるようにしてもよい。また、図１６に示したようにPartial File Container Boxとは異なるRecovery Status Boxに修復情報が設定された欠損ありファイルが生成されるようにしてもよい。
　（欠損ありInitialization Segmentファイルの構成例）
　図２９は、欠損ありInitialization Segmentファイルの構成例を示す図である。
　図２９の欠損ありInitialization Segmentファイルの構成は、Segment Corrupted Information Boxが配置される点を除いて、図１８の欠損ありファイルの構成と同一である。
　（Segment Corrupted Information Boxのシンタックスの例）
　図３０は、図２９のSegment Corrupted Information Boxのシンタックスの例を示す図である。
　図３０に示すように、Segment Corrupted Information Boxは、欠損ありファイルごとにFile Recovery Status Boxが配置される。
　第７実施の形態におけるMPDファイルの構成は、図２７のＡの（１）の位置に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:2015” value=“file_name”>ではなく、<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:initialization:2015”>が設定される点を除いて、図２７の構成と異なる。
　<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:initialization:2015”>は、MPDファイルが管理するSegmentファイルの少なくとも１つが欠損ありファイルであり、その欠損ありファイルの修復情報がInitialization Segmentファイルに設定されていることを示すEssentialPropertyである。
　なお、第７実施の形態におけるMPDファイルには、第５実施の形態と同様に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>が記述されてもよい。また、第７実施の形態におけるMPDファイルは、第５実施の形態と同様にカプセル化されてもよい。
　以上のように、第７実施の形態では、Media Segmentファイルの再生時に、Media Segmentファイルよりも前に再生されるInitialization Segmentファイルに修復情報が設定される。従って、再生装置は、Media Segmentファイルの再生前に、そのMedia Segmentファイルの修復情報を認識することができる。
　＜第８実施の形態＞
　（情報処理システムの第８実施の形態の構成例）
　図３１は、本開示を適用した情報処理システムの第８実施の形態の構成例を示すブロック図である。
　図３１に示す構成のうち、図１の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。
　図３１の情報処理システム５０の構成は、受信装置１２の代わりにキャッシュプロキシ５１とプレーヤ５２が設けられる点が、図１の情報処理システム１０の構成と異なる。情報処理システム５０では、MPEG-DASHに準拠した放送データのファイルをキャッシュプロキシ５１が受信して保存し、プレーヤ５２が、キャッシュプロキシ５１に保存されているファイルを再生する。
　具体的には、情報処理システム５０のキャッシュプロキシ５１は、例えば、家庭用のホームサーバなどであり、受信装置１２とDASHサーバ６１等により構成される。受信装置１２は、放送局１１から送信されてくるMPEG-DASHに準拠した放送データのファイルを受信して記録し、そのファイルの欠損データを修復する。DASHサーバ６１は、受信装置１２の記録部３４に記録されている全ての欠損データの修復が完了している欠損ありファイルと欠損なしファイルを取得し、保存する。
　プレーヤ５２は、DASHクライアント７１等により構成される。DASHクライアント７１（再生部）は、DASHサーバ６１に保存されているMPDファイルを読み出す。DASHクライアント７１は、MPDファイルを参照して、必要なSegmentファイルをDASHサーバ６１から読み出し、そのSegmentファイルに基づいて取得された放送データの再生を行う。
　＜第９実施の形態＞
　（情報処理システムの第９実施の形態の構成例）
　図３２は、本開示を適用した情報処理システムの第９実施の形態の構成例を示すブロック図である。
　図３２に示す構成のうち、図１の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。
　図３２の情報処理システム１００の構成は、キャッシュプロキシ５１の代わりにキャッシュプロキシ１０１が設けられる点、および、プレーヤ５２の代わりにプレーヤ１０２が設けられる点が、図３１の情報処理システム５０の構成と異なる。情報処理システム１００では、プレーヤ１０２で修復が行われる。
　具体的には、情報処理システム１００のキャッシュプロキシ１０１は、例えば、家庭用のホームサーバなどであり、放送受信部３１、ファイル生成部３２、設定部１１１、およびDASHサーバ１１２により構成される。設定部１１１は、図１の設定部３３の処理のうちの、修復情報のデフォルト値を設定する処理を行う。DASHサーバ１１２は、ファイル生成部３２により生成された欠損なしファイルと、少なくとも一方に修復情報のデフォルト値が設定された欠損ありファイルおよびMPDファイルとを記録する。
　プレーヤ１０２は、記録部３４、修復部３５、HTTP受信部３６、DASHクライアント１２１、および設定部１２２により構成される。
　DASHクライアント１２１（再生部）は、DASHサーバ１１２に記録されているMPDファイルを読み出す。DASHクライアント１２１は、MPDファイルを参照して、必要なSegmentファイルをDASHサーバ１１２から読み出し、記録部３４に記録する。DASHクライアント１２１は、記録部３４に記録されている全ての欠損データの修復が行われたSegmentファイルを読み出し、そのSegmentファイルに基づいて放送データを取得し、再生する。
　設定部１２２は、図１の設定部３３の処理のうちの、修復情報を更新する処理を行う。
　＜第１０実施の形態＞
　（本開示を適用したコンピュータの説明）
　上述した受信装置１２の一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
　図３３は、上述した受信装置１２の一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
　コンピュータ２００において、CPU（Central Processing Unit）２０１，ROM（Read Only Memory）２０２，RAM（Random Access Memory）２０３は、バス２０４により相互に接続されている。
　バス２０４には、さらに、入出力インタフェース２０５が接続されている。入出力インタフェース２０５には、入力部２０６、出力部２０７、記憶部２０８、通信部２０９、及びドライブ２１０が接続されている。
　入力部２０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部２０７は、ディスプレイ、スピーカなどよりなる。記憶部２０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部２０９は、ネットワークインタフェースなどよりなる。ドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア２１１を駆動する。
　以上のように構成されるコンピュータ２００では、CPU２０１が、例えば、記憶部２０８に記憶されているプログラムを、入出力インタフェース２０５及びバス２０４を介して、RAM２０３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ２００（CPU２０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア２１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
　コンピュータ２００では、プログラムは、リムーバブルメディア２１１をドライブ２１０に装着することにより、入出力インタフェース２０５を介して、記憶部２０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部２０９で受信し、記憶部２０８にインストールすることができる。その他、プログラムは、ROM２０２や記憶部２０８に、あらかじめインストールしておくことができる。
　なお、コンピュータ２００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
　本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
　また、本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
　例えば、第５実施の形態において、MPDファイルにSegment Corrupted Information Boxと同様の記述が行われてもよい。
　また、本技術は、放送データを受信する装置だけでなく、LTE（Long Term Evolution）やWi-Fiなどに準拠してマルチキャストされるデータを受信する装置（例えば、携帯型端末など）に適用することもできる。
　なお、本開示は、以下のような構成もとることができる。
　（１）
　ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定部と、
　前記設定部により設定された前記修復情報に基づいて、前記欠損データを修復する修復部と
　を備える情報処理装置。
　（２）
　前記設定部は、前記ファイルのデータが配置されるボックスとは異なるボックスに前記修復情報を設定する
　ように構成された
　前記（１）に記載の情報処理装置。
　（３）
　前記設定部は、前記ファイルのデータが配置されるボックスに含まれる、前記欠損データの位置とサイズを表す欠損情報が配置されるボックスとは異なるボックスに前記修復情報を設定する
　ように構成された
　前記（１）に記載の情報処理装置。
　（４）
　前記設定部は、前記ファイルの前記欠損データの位置とサイズを表す欠損情報が配置されるボックスに前記修復情報を設定する
　ように構成された
　前記（１）に記載の情報処理装置。
　（５）
　前記設定部は、前記ファイルを管理する管理ファイルに前記修復情報を設定する
　ように構成された
　前記（１）乃至（４）のいずれかに記載の情報処理装置。
　（６）
　前記管理ファイルはカプセル化される
　ように構成された
　前記（５）に記載の情報処理装置。
　（７）
　前記ファイルを特定する欠損ファイル情報を、前記ファイルを管理する管理ファイルに設定するファイル生成部
　をさらに備える
　前記（１）乃至（４）のいずれかに記載の情報処理装置。
　（８）
　前記管理ファイルは、カプセル化される
　ように構成された
　前記（７）に記載の情報処理装置。
　（９）
　前記設定部は、前記ファイルとは異なるファイルである修復情報ファイルに前記修復情報を設定する
　ように構成された
　前記（１）に記載の情報処理装置。
　（１０）
　前記設定部は、前記修復情報ファイルに前記ファイルを特定する欠損ファイル特定情報を設定する
　ように構成された
　前記（９）に記載の情報処理装置。
　（１１）
　前記修復情報ファイルを特定する情報を、前記ファイルを管理する管理ファイルに設定するファイル生成部
　をさらに備える
　前記（９）または（１０）に記載の情報処理装置。
　（１２）
　前記修復情報ファイルは、Initialization Segmentファイルである
　ように構成された
　前記（９）乃至（１１）のいずれかに記載の情報処理装置。
　（１３）
　前記修復情報は、前記ファイルの全ての前記欠損データの修復の途中であることを示す情報である
　ように構成された
　前記（１）乃至（１２）のいずれかに記載の情報処理装置。
　（１４）
　前記修復情報は、前記ファイルの全ての前記欠損データの修復が完了したことを示す情報である
　ように構成された
　前記（１）乃至（１３）のいずれかに記載の情報処理装置。
　（１５）
　前記修復情報は、前記修復部により前記修復が行われた前記欠損データを示す情報である
　ように構成された
　前記（１）乃至（１４）のいずれかに記載の情報処理装置。
　（１６）
　前記修復情報は、各欠損データの前記修復が成功した状態、前記修復が失敗した状態、または前記修復が行われていない状態を示す情報である
　ように構成された
　前記（１）乃至（１５）のいずれかに記載の情報処理装置。
　（１７）
　前記修復情報は、前記修復部により前記修復が行われた前記欠損データを示す情報と、前記修復が行われた各欠損データの前記修復が成功したか、または、失敗したかを示す情報である
　ように構成された
　前記（１）乃至（１４）のいずれかに記載の情報処理装置。
　（１８）
　情報処理装置が、
　ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定ステップと、
　前記設定ステップの処理により設定された前記修復情報に基づいて、前記欠損データを修復する修復ステップと
　を含む情報処理方法。
　（１９）
　ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生部
　を備える情報処理装置。
　（２０）
　情報処理装置が、
　ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生ステップ
　を含む情報処理方法。
　１２　受信装置,　３２　ファイル生成部,　３３　設定部,　３５　修復部,　７１，１２１　DASHクライアント

Claims (20)

  1. 　ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定部と、
    　前記設定部により設定された前記修復情報に基づいて、前記欠損データを修復する修復部と
    　を備える情報処理装置。
  2. 　前記設定部は、前記ファイルのデータが配置されるボックスとは異なるボックスに前記修復情報を設定する
    　ように構成された
    　請求項１に記載の情報処理装置。
  3. 　前記設定部は、前記ファイルのデータが配置されるボックスに含まれる、前記欠損データの位置とサイズを表す欠損情報が配置されるボックスとは異なるボックスに前記修復情報を設定する
    　ように構成された
    　請求項１に記載の情報処理装置。
  4. 　前記設定部は、前記ファイルの前記欠損データの位置とサイズを表す欠損情報が配置されるボックスに前記修復情報を設定する
    　ように構成された
    　請求項１に記載の情報処理装置。
  5. 　前記設定部は、前記ファイルを管理する管理ファイルに前記修復情報を設定する
    　ように構成された
    　請求項１に記載の情報処理装置。
  6. 　前記管理ファイルは、カプセル化される
    　ように構成された
    　請求項５に記載の情報処理装置。
  7. 　前記ファイルを特定する欠損ファイル情報を、前記ファイルを管理する管理ファイルに設定するファイル生成部
    　をさらに備える
    　請求項１に記載の情報処理装置。
  8. 　前記管理ファイルは、カプセル化される
    　ように構成された
    　請求項７に記載の情報処理装置。
  9. 　前記設定部は、前記ファイルとは異なるファイルである修復情報ファイルに前記修復情報を設定する
    　ように構成された
    　請求項１に記載の情報処理装置。
  10. 　前記設定部は、前記修復情報ファイルに前記ファイルを特定する欠損ファイル特定情報を設定する
    　ように構成された
    　請求項９に記載の情報処理装置。
  11. 　前記修復情報ファイルを特定する情報を、前記ファイルを管理する管理ファイルに設定するファイル生成部
    　をさらに備える
    　請求項９に記載の情報処理装置。
  12. 　前記修復情報ファイルは、Initialization Segmentファイルである
    　ように構成された
    　請求項９に記載の情報処理装置。
  13. 　前記修復情報は、前記ファイルの全ての前記欠損データの修復の途中であることを示す情報である
    　ように構成された
    　請求項１に記載の情報処理装置。
  14. 　前記修復情報は、前記ファイルの全ての前記欠損データの修復が完了したことを示す情報である
    　ように構成された
    　請求項１に記載の情報処理装置。
  15. 　前記修復情報は、前記修復部により前記修復が行われた前記欠損データを示す情報である
    　ように構成された
    　請求項１に記載の情報処理装置。
  16. 　前記修復情報は、各欠損データの前記修復が成功した状態、前記修復が失敗した状態、または前記修復が行われていない状態を示す情報である
    　ように構成された
    　請求項１に記載の情報処理装置。
  17. 　前記修復情報は、前記修復部により前記修復が行われた前記欠損データを示す情報と、前記修復が行われた各欠損データの前記修復が成功したか、または、失敗したかを示す情報である
    　ように構成された
    　請求項１に記載の情報処理装置。
  18. 　情報処理装置が、
    　ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定ステップと、
    　前記設定ステップの処理により設定された前記修復情報に基づいて、前記欠損データを修復する修復ステップと
    　を含む情報処理方法。
  19. 　ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生部
    　を備える情報処理装置。
  20. 　情報処理装置が、
    　ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生ステップ
    　を含む情報処理方法。
PCT/JP2016/078352 2015-10-09 2016-09-27 情報処理装置および情報処理方法 Ceased WO2017061299A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US15/747,964 US20180232287A1 (en) 2015-10-09 2016-09-27 Information processing apparatus and information processing method
EP16853453.5A EP3319327A4 (en) 2015-10-09 2016-09-27 Information processing apparatus and information processing method
JP2017544459A JP6834967B2 (ja) 2015-10-09 2016-09-27 情報処理装置および情報処理方法
CN201680057561.2A CN108141640B (zh) 2015-10-09 2016-09-27 信息处理设备和信息处理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015201344 2015-10-09
JP2015-201344 2015-10-09

Publications (1)

Publication Number Publication Date
WO2017061299A1 true WO2017061299A1 (ja) 2017-04-13

Family

ID=58487498

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/078352 Ceased WO2017061299A1 (ja) 2015-10-09 2016-09-27 情報処理装置および情報処理方法

Country Status (5)

Country Link
US (1) US20180232287A1 (ja)
EP (1) EP3319327A4 (ja)
JP (1) JP6834967B2 (ja)
CN (1) CN108141640B (ja)
WO (1) WO2017061299A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6309639B2 (ja) * 2014-01-13 2018-04-11 エルジー エレクトロニクス インコーポレイティド １つ以上のネットワークを介して放送コンテンツを送信又は受信するための方法及び装置
US20190020734A1 (en) * 2017-07-14 2019-01-17 Comcast Cable Communications, Llc Reduced content manifest size
US11438647B2 (en) 2018-05-11 2022-09-06 Qualcomm Incorporated Signaling missing sections of media data for network streaming in a manifest file
US11290757B2 (en) 2018-09-28 2022-03-29 Comcast Cable Communications, Llc Per-segment parameters for content

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010152425A (ja) * 2008-12-24 2010-07-08 Nippon Hoso Kyokai <Nhk> ファイル送信装置及びファイル受信装置
JP2015530006A (ja) * 2012-11-29 2015-10-08 サムスン エレクトロニクス カンパニー リミテッド 国際標準化機構基盤メディアファイル内のモーションピクチャーエクスパーツグループメディアトランスポートアセットのカプセル化方法及び装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6553518B1 (en) * 1999-03-08 2003-04-22 International Business Machines Corporation Severe error detectors, methods and computer program products that use constellation specific error event thresholds to detect severe error events during demodulation of a signal comprising symbols from a plurality of symbol constellations
US20100135646A1 (en) * 2007-04-04 2010-06-03 Gun Bang Storage/playback method and apparatus for mpeg-2 transport stream based on iso base media file format
US7694165B2 (en) * 2007-05-03 2010-04-06 Microsoft Corporation Automation of bare metal recoveries
JP2012182788A (ja) * 2011-02-10 2012-09-20 Panasonic Corp 記録システム、記録方法およびコンピュータプログラム
US8924355B1 (en) * 2011-03-29 2014-12-30 Emc Corporation Checkpoint restart
KR101890767B1 (ko) * 2011-07-01 2018-09-28 시게이트 테크놀로지 인터내셔날 주소 사상 정보 관리 방법 이를 적용한 저장 장치
WO2013020709A1 (en) * 2011-08-10 2013-02-14 Telefonaktiebolaget L M Ericsson (Publ) Media stream handling
KR101316579B1 (ko) * 2012-01-17 2013-10-18 (주)피타소프트 Ｍｐ4 파일 구성 장치 및 복구 장치, ｍｐ4 파일 구성 방법 및 복구 방법
US20130254611A1 (en) * 2012-03-23 2013-09-26 Qualcomm Incorporated Recovering data in multimedia file segments
WO2014108207A1 (en) * 2013-01-11 2014-07-17 Telefonaktiebolaget L M Ericsson (Publ) Technique for operating client and server devices in a broadcast communication network
US9807452B2 (en) * 2013-10-07 2017-10-31 Samsung Electronics Co., Ltd. Practical delivery of high quality video using dynamic adaptive hypertext transport protocol (HTTP) streaming (DASH) without using HTTP in a broadcast network
WO2016204490A1 (ko) * 2015-06-16 2016-12-22 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010152425A (ja) * 2008-12-24 2010-07-08 Nippon Hoso Kyokai <Nhk> ファイル送信装置及びファイル受信装置
JP2015530006A (ja) * 2012-11-29 2015-10-08 サムスン エレクトロニクス カンパニー リミテッド 国際標準化機構基盤メディアファイル内のモーションピクチャーエクスパーツグループメディアトランスポートアセットのカプセル化方法及び装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3319327A4 *

Also Published As

Publication number Publication date
US20180232287A1 (en) 2018-08-16
JPWO2017061299A1 (ja) 2018-07-26
CN108141640B (zh) 2020-11-03
CN108141640A (zh) 2018-06-08
JP6834967B2 (ja) 2021-02-24
EP3319327A4 (en) 2019-01-02
EP3319327A1 (en) 2018-05-09

Similar Documents

Publication Publication Date Title
JP5266327B2 (ja) 媒体トランスポートストリームにおける触覚効果データの同期化
KR101885852B1 (ko) 컨텐트 전송 및 수신 방법 및 장치
CN103190092B (zh) 用于流数字内容的同步重放的系统和方法
CN103974147A (zh) 一种基于mpeg-dash协议的带有码率切换控制和静态摘要技术的在线视频播控系统
JP6834967B2 (ja) 情報処理装置および情報処理方法
JP2007173987A (ja) マルチメディアデータ送受信システム、及び装置、又はプログラム
BRPI0710236A2 (pt) método e aparelho para a reconstrução de mìdia, produto de programa de computador, aparelho para criar uma representação de mìdia, objeto de dados de ponto de acesso randÈmico, e, representação e documento ou recipiente de mìdia
WO2018014691A1 (zh) 一种媒体数据的获取方法和装置
KR20220165693A (ko) 디지털 방송 서비스 방법 및 장치
CN104735463A (zh) 流媒体传输方法及系统
CN104661083A (zh) 视频播放方法、系统、流媒体播放方法、装置及系统
JP2014017741A (ja) コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体
JP2006074391A (ja) ファイル記録方法および記録装置
US20080240676A1 (en) Method of updating additional data and apparatus for reproducing the same
WO2022075342A1 (ja) 情報処理装置および方法
CN105379281A (zh) 用于使用图形处理器的视频解码的图片参考控制
US20190043535A1 (en) Information processing apparatus, information processing method, and program
WO2023010402A1 (zh) 一种媒体文件播放方法、装置、计算机设备及存储介质
CN114928753A (zh) 一种视频拆分处理方法、系统及装置
US20110110641A1 (en) Method for real-sense broadcasting service using device cooperation, production apparatus and play apparatus for real-sense broadcasting content thereof
JP5263399B2 (ja) コンテンツアップロードシステム、コンテンツアップロード方法、コンテンツ送受信装置
EP1902588A2 (en) File format translation
US20130088946A1 (en) Method for playing back recording medium and recording medium playback device using the same
JP6290073B2 (ja) 収録装置及び収録方法
JP5207268B2 (ja) 再生装置、再生方法及び再生プログラム

Legal Events

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

Ref document number: 16853453

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15747964

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2017544459

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2016853453

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE