CN113555040B - Write method of moov container in multimedia file and computer readable storage medium - Google Patents
Write method of moov container in multimedia file and computer readable storage medium Download PDFInfo
- Publication number
- CN113555040B CN113555040B CN202111102924.9A CN202111102924A CN113555040B CN 113555040 B CN113555040 B CN 113555040B CN 202111102924 A CN202111102924 A CN 202111102924A CN 113555040 B CN113555040 B CN 113555040B
- Authority
- CN
- China
- Prior art keywords
- container
- moov
- size
- variable sub
- multimedia file
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
- G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a method for writing in a moov container in a multimedia file and a corresponding computer readable storage medium.
Description
Technical Field
The invention relates to the technical field of audio and video file editing, in particular to a method for writing a moov container in a multimedia file and a computer readable storage medium.
Background
According to the ISO/IEC 14496-12 standard, the media description and the media data in the mp4 file format are separate and the organization of the media data is also relatively free and does not have to be arranged in chronological order. All data in the mp4 file is packaged in containers (boxes), and the mp4 file is composed of several containers, each container having a type and a length, and if another container is contained in the container, such a container is called a container (container box).
An mp4 file with an ftyp type container as a marker for mp4 format and containing some information about the file; there is also and only one moov type container, metadata (metadata) information of media data is stored in the moov type container, the moov type container contains file index information and belongs to a container, the structure of the moov container contains containers such as stts, stsz, stsc, stco, co64, stss, etc., and the sizes of the containers may become larger as the recording duration increases; and an mdat-type container for storing media data of the mp4 file, the mdat-type container may be plural or none, and when the media data all refer to other files, the structure of the media data is described by metadata.
When data in the moov type container is missing or abnormal, it may be that the mp4 file will not be readable. In the prior art, a general method is that when an mp4 file is written in a storage carrier (a built-in storage module or an external storage), an mdat container is written first, an moov container is stored in a memory first, and after recording is finished, the entire moov container is written at the end of the file. As an improvement of the above scheme, before writing in the mdat container, a part of space is reserved for the moov container, and the moov container is periodically and completely rewritten, however, as the recording duration increases, the size of a part of container related to the audio/video frame information will increase, and in the moov overall writing process, the storage location offset of these sub-containers will change, so that once the rewriting process is abnormal, it will easily cause that the content of a part of sub-containers is not written with new content after being covered, which results in file damage, and meanwhile, as the file index is frequently updated, performance is degraded, if the rewriting time interval is increased, the damage probability is only reduced, which still cannot ensure safety, and increasing the rewriting time also easily causes that part of data is lost and cannot be read when an abnormality occurs.
Some schemes are to create another temporary file while recording an mp4 file, write audio and video data into the temporary file in sequence, once an abnormality occurs, restore an index through the temporary file, and this scheme can repair the abnormality through the temporary file, and is not a standard, so that it is easy to cause dependence on a specific device during repair, for example, a flash disk is inserted into a corresponding device for recording, and after the abnormality occurs, the file cannot be played if the flash disk is pulled out and inserted into another device for playing before the device is repaired.
Similarly, according to the QTFF protocol of apple inc, the above problems are also present with mov files that employ a similar file structure.
Disclosure of Invention
In view of the above, based on the problems in the prior art, the present invention provides a method for writing an moov container in a multimedia file, which solves the risk that the multimedia file cannot be read due to a moov container write anomaly by allocating a reserved space for each sub-container in the moov container and updating the sub-containers according to sub-container storage position offsets.
In order to solve the above problem, the present invention provides a method for writing a moov container in a multimedia file, for writing the moov container in a storage carrier, the method comprising the steps of:
estimating the size of reserved space of all containers in the moov container and the size of reserved space of the moov container according to the protocol specification of the multimedia file format;
sequentially acquiring the storage position offset of each container according to the storage position offset of the moov container, the storage sequence of each container in the moov container and the size of the reserved space of each container;
and respectively writing corresponding contents in the moov container and each container contained in the moov container according to the storage position offset of the moov container and the storage position offset of each container.
The moov container structure comprises a container and a non-container, the reserved space of the container is equal to the reserved space of all the containers contained in the container and the storage space required by a fixed field in the container, and the fixed field is related to the type of the container.
Dividing a non-container in the moov container structure into a quantitative sub-container and a variable sub-container, wherein the size of an effective space of the quantitative sub-container is unchanged in the whole multimedia file recording process; the effective space of the variable sub-container changes along with the number of the items written in the variable sub-container, and a fixed field for storing the total number of the items written in the variable sub-container is arranged in the variable sub-container; the effective space refers to a space actually occupied by the valid data written in the container.
Wherein, for a variable sub-container, estimating the size of the reserved space of the variable sub-container comprises the following steps:
acquiring an estimated value of the total number of items which can be written in the variable sub-container when the recording of the multimedia file is finished according to the content of the items to be written in the variable sub-container and the preset recording duration of the multimedia file;
and obtaining the size of the reserved space of the variable sub-container according to the estimated value of the total number of the items, the size of the storage space required by a single item in the variable sub-container and the size of the storage space required by the internal fixed field of the variable sub-container.
Further, the size of the reserved space of the variable sub-container further includes a preset margin, the preset margin is used for preventing entry errors, and the preset margin is set according to the size of a storage space required by a single entry in the corresponding variable sub-container.
Further, according to the protocol specification of the multimedia file format, the item content written in some variable sub-containers is configured in advance, so that the number of items written in the corresponding variable sub-containers in the whole multimedia file recording process is kept unchanged.
And the size of the reserved space of the fixed quantum container is the size of the storage space required by the fixed field in the fixed quantum container.
Writing corresponding contents in the moov container and each container thereof, wherein the method comprises the following steps:
at the initial updating moment, sequentially writing the contents which are stored in the corresponding fixed fields in the storage carrier according to the moov containers and the storage position offset of each container; for the variable container, the existing items at the current moment need to be written, and the item number of the last item is recorded;
at each subsequent updating moment, updating the value of the fixed field in each container in the moov container; for the variable sub-container, after determining the entry number of the initial entry at the current updating time according to the entry number recorded at the last updating time, writing the entries with the corresponding number, and recording the entry number of the last entry; and if the number of the entries of the variable sub-container at the current updating time is the same as the number of the entries at the last updating time, not writing.
Wherein the multimedia file is an mp4 file or an mov file.
Correspondingly, the invention also discloses a computer readable storage medium, which stores a computer program, and the program realizes the writing method of the moov container in the multimedia file when being executed.
Compared with the prior art, the invention has the following advantages:
according to the method for writing the moov container in the multimedia file, the container size defined by mp4 and the moov standard can be set according to the protocol specification, and the storage position offset of the container belonging to the same container and at the same level is the sum of the storage position offset of the previous container and the size of the previous container, and the storage position offset of each container is sequentially obtained and recorded according to the estimated size of the reserved space of each container; when the reserved space size of each variable sub-container is estimated, determining the maximum storage space required by the variable sub-container when the recording of the multimedia file is finished according to the item content written in by each variable sub-container, ensuring that the storage position offset of each container does not change in the whole recording process of the multimedia file, and solving the risk that mp4 and mov multimedia files cannot be read due to abnormal writing in the moov container; further, in order to reduce the difference between the size of the moov container reserved space and the size of the effective space, according to the protocol specification, the entry content written in some variable sub-containers is pre-configured, so that the total number of entries written in the variable sub-containers in the whole multimedia file recording process is a fixed value, and the estimated value of the total number of entries which can be written in the variable sub-containers at the end of the recording of the multimedia file is not required to be obtained according to the recording duration of the multimedia file; in the writing process, the updating speed of the moov container is further optimized by updating the content of part of the sub-containers, so that the updating frequency can be increased, and the data volume lost when an exception occurs is reduced.
Drawings
FIG. 1 is a flow chart of a moov container writing method in a multimedia file according to the present invention;
FIG. 2 is a schematic structural diagram of an moov container of an mp4 file in the embodiment of the invention;
fig. 3 is a schematic diagram of the contents of the mdhd container of fig. 2;
FIG. 4 is a schematic diagram of the contents of a portion of the stts container of the video track of FIG. 2;
FIG. 5 is a schematic diagram of the contents of a portion of the stts container of the audio track of FIG. 2;
FIG. 6 is a schematic diagram of the contents of a portion of the stsz container of the video track of FIG. 2;
FIG. 7 is a schematic diagram of a portion of the content contained in the stsc container for the video track of FIG. 2;
FIG. 8 is a schematic illustration of the content contained in the video track co64 container of FIG. 2;
FIG. 9 is a schematic diagram of the contents of a portion of the video track stss container of FIG. 2;
fig. 10 is a schematic diagram of the initial update timing of the partial contents contained in the stsz container in fig. 6;
fig. 11 is a schematic diagram showing a certain update timing of a part of the content contained in the stsz container in fig. 10.
Detailed Description
The present invention will be further described with reference to the following examples.
For convenience of description, the reserved space is defined as a storage space pre-allocated to the container, and the effective space is a space actually occupied by the effective data written in the container. And defining a quantitative sub-container and a variable sub-container according to whether the effective space of the non-container changes in the whole multimedia file recording process, namely whether the effective space of the non-container changes along with the recording duration of the multimedia file, wherein the effective space of the quantitative sub-container remains unchanged in the whole multimedia file recording process, the effective space of the variable sub-container changes along with the change of the number of the items written in the variable sub-container in the whole moov container writing process, and a fixed field for storing the total number of the items written in the variable sub-container is arranged in the variable sub-container.
As shown in fig. 1, the moov container writing method in a multimedia file of the present invention is used for writing a moov container in a storage carrier, and includes the following steps:
(1) estimating the size of reserved space of all containers in the moov container and the size of reserved space of the moov container according to the protocol specification of the multimedia file format;
(2) sequentially acquiring the storage position offset of each container according to the storage position offset of the moov container, the storage sequence of each container in the moov container and the size of the reserved space of each container;
(3) and respectively writing corresponding contents in the moov container and each container contained in the moov container according to the storage position offset of the moov container and the storage position offset of each container.
The moov container writing method is suitable for mp4 files or moov files, the structural frameworks of the moov containers of the two files are similar, and only mp4 files are taken as an example in the invention for detailed description.
This embodiment describes a moov container writing method by taking a container structure of a certain mp4 file as an example, as shown in fig. 2, there is only one ftyp container in the mp4 file, the container can only be contained in the file layer, and is placed at the very beginning of the file, and is used for indicating related information of mp4 file application, in fig. 2, the size of the ftyp container is 28 bytes, and the storage location offset is 0x 0; the content of the free container can be ignored, and the box is deleted without any influence on the playing.
According to mp4, the mov standard defines that the storage location offset of a container belonging to the same hierarchy of the same container is the sum of the storage location offset of the previous container plus the storage space of the previous container. Thus, for the moov container in the present embodiment, the storage location offset thereof can be derived by the sum of the fyp container size and the free container size, and the storage location offset thereof is 0x24 as shown in fig. 1.
The scheme of the present invention mainly relates to a moov container (Movie Box), and according to a standard protocol specification (ISO/IEC 14496 series standard) of mp4 file format, the moov container shown in fig. 2 does not include all sub-containers specified in the protocol, and this embodiment is merely a representative example for convenience of explaining a writing method of the moov container of the present invention. As shown in fig. 2, the moov vessel in the embodiment of the present invention includes an mvhd vessel (Movie Header Box) and two trak vessels (Track Box), as well as a Meta vessel (Meta Box) and an udta vessel (User Data Box). Wherein, the mvhd container is generally used as a first sub-container of the moov container, is a necessary sub-container, and includes a fixed field which does not change the container size, the container type, the container version, the time scale, the time length and the like or does not influence the overall size of the container, and is a quantitative sub-container; meta containers include some descriptive content, the container being a non-essential container; the udta container contains user information and data about the container it contains, which is a non-essential container. the trak container contains information related to one track (track), and also belongs to a container, namely an essential container, and a fixed quantum container and a variable quantum container are contained in the container.
How to estimate the size of the reserved space of all the containers in the moov container and the size of the reserved space of the moov container according to the protocol specification of the multimedia file format will be described below.
The reserved space of the container is equal to the reserved space of all containers directly contained in the container and the storage space required by a fixed field (a variable defined in a corresponding class) in the container, the fixed field is stored in the head position of the corresponding container, the fixed field and the required storage space are related to the container type of the container, and the reserved space is defined in the ISO/IEC 14496-12 protocol.
The following Box class specified in the ISO/IEC 14496-12 protocol defines two variables of size and boxtype, the storage spaces corresponding to the two variables are fixed, the container is the base class of all boxes in mp4, and then the fixed fields of the base class are used for storing the container size and the container type. The moov container and trak, edts, mdia, minf, dinf and stbl in the structure of the moov container are extension classes of the Box class, and for such container, the size of the storage space required by the internal fixed field of the container is the storage space of the container size (corresponding to variable size, 32 bits and 4 bytes) and the storage space of the container type (corresponding to variable type, 32 bits and 4 bytes).
aligned(8) class Box (unsigned int(32) boxtype,
optional unsigned int(8)[16] extended_type) {
unsigned int(32) size;
unsigned int(32) type = boxtype;
if (size==1) {
unsigned int(64) largesize;
} else if (size==0) {
// box extends to end of file
}
if (boxtype==‘uuid’) {
unsigned int(8)[16] usertype = extended_type;
}
}
Taking the first trak container in fig. 2 as an example, the reserved space size of the container is the sum (92 +36+ 1741112) of the reserved space sizes of all the containers tkhd, edts, mdia contained in the container plus 8 bytes, which is 1741248 bytes.
In the moov container structure, there are container containers such as dref, stsd, and the like, which are extension classes of the FullBox, such as definitions of the FullBox class specified in the following ISO/IEC 14496-12 protocol, where all definitions of the Box class are inherited, and two variables, namely version information version and flag information flag, are added to the Box class, and the corresponding sizes of these variables are fixed. Therefore, the fixed field of such container is used for storing the size of the container (32 bits, 4 bytes) and the type of the container (32 bits, 4 bytes), the version information (corresponding to the variable version, 8 bits, 1 byte) and the flag information (corresponding to the variable flags, 24 bits, 3 bytes), and the size of the storage space required by the fixed field is also fixed and is 12 bytes.
aligned(8) class FullBox(unsigned int(32) boxtype, unsigned int(8) v, bit(24) f)
extends Box(boxtype) {
unsigned int(8) version = v;
bit(24) flags = f;
}
Taking the dref container in fig. 2 as an example, the dref container is defined in the following ISO/IEC 14496-12 protocol, the dref container is extended on the basis of a FullBox, the variable entry _ count is further added, the size of the variable to be stored is also specified (32 bits, 4 bytes), and therefore the space size of the fixed field in such a container is 16 bytes. So dref container headspace size is the headspace size (12 bytes) of its inner container url container (DataEntryBox class) plus 16 bytes, with a headspace size of 28 bytes.
aligned(8) class DataReferenceBox
extends FullBox(‘dref’, version = 0, 0) {
unsigned int(32) entry_count;
for (i=1; i <= entry_count; i++) {
DataEntryBox(entry_version, entry_flags) data_entry;
}
}
For a non-container, it is divided into a quantitative sub-container and a variable sub-container in the present invention, and for the quantitative sub-container, the estimation of the reserved space size is different from that of the container only in that the container includes other containers, but the non-container does not include other containers, and thus, the reserved space size of the quantitative sub-container is the storage space size required by its internal fixed field.
In fig. 2, mvhd container directly contained in moov container, tkhd container directly contained in trak container, elst and hdlr containers directly contained in edts container, vmhd and hdlr containers directly contained in minf container, url container directly contained in dref container, and stsd container directly contained in stbl container are all quantitative child containers.
Taking the mdhd container in fig. 2 and fig. 3 as an example, the mdhd container in the ISO/IEC 14496-12 protocol is defined as follows, the fixed field of the container is extended on the basis of the FullBox (12 bytes), and the variables of creation _ time, modification _ time, duration, language, and pre _ defined are added, and when version = =0, the size of the storage space required by these variables is 20 bytes, and then the size of the reserved space of the mdhd can be obtained as 32 bytes.
aligned(8) class MediaHeaderBox extends FullBox(‘mdhd’, version, 0) {
if (version==1) {
unsigned int(64) creation_time;
unsigned int(64) modification_time;
unsigned int(32) timescale;
unsigned int(64) duration;
} else { // version==0
unsigned int(32) creation_time;
unsigned int(32) modification_time;
unsigned int(32) timescale;
unsigned int(32) duration;
}
bit(1) pad = 0;
unsigned int(5)[3] language; // ISO-639-2/T language code
unsigned int(16) pre_defined = 0;
}
For the variable sub-container, in the whole moov container writing process, the effective space changes with the number of entries written therein, and a fixed field for storing the total number of entries written therein is arranged in the variable sub-container. According to the protocol, when the multimedia file is written in, the storage position offset of each container is not stored in the storage carrier, when the multimedia file is read, the storage position offset of each container is sequentially acquired according to the initial position offset 0x0 and the size of the storage space of each container, when the content of the variable quantum container is read, the content of the fixed field is read according to the storage position offset, and then the content of the entry is read according to the number of the entry in the fixed field.
For convenience of explaining the scheme of the invention, in the embodiment, the mp4 file includes audio and video information, a first trak records video track information, a second trak records audio track information, and an stbl container contains information about all time and position information of samples in the trak, coding and decoding of the samples, and the like; the stbl container includes a stsd container (Sample Description Box), a stts container (Time To Sample Box), a stsz container (Sample Size Box), a stsc container (Sample To Chunk Box), a co64 container (Chunk Offset Box), a stss container (Sync Sample Box), and the like. The stbl container comprises a quantitative sub-container and a variable sub-container, the stsd container comprises the coding type and the coding initialization information, the effective space size of the container is kept unchanged in the whole multimedia file recording process, the stsd container is a container, and all the containers directly contained in the stsd container are quantitative sub-containers.
The calculation of the size of the reserved space of the stts container, the stsz container and the co64 container, which belong to the FullBox class, will be described in detail below. According to the standard, the standard is that,the content recorded in these containers is related to the number of frames and the size of the available space may increase as the length of the recording time increases. For sub-containers such as stts container, stsz container, and co64 container, the reserved space size SiThe calculation formula of (2) is as follows:
Si=Si_const+Ni_frame*Si_frame（1）
wherein the subscript i is used to identify the container type, Si_constThe size of the storage space required for a fixed field in the container identified by i, Si_frameRepresenting the storage space required for a single entry in i-identified container for recording frame information, Ni_frameAn estimate representing the total number of entries in the container identified by i when the mp4 file completed recording, i.e., a frame number estimate. The size of the memory required for the fixed field and the size of the memory required for a single entry may be determined according to a standard.
Frame number estimation Ni_frameThe calculation formula of (2) is as follows:
Ni_frame=[Trec*Fframe]（2）
wherein, TrecRepresenting the duration of the recording, which value is determined according to the user's choice, FframeIs the frame rate.]Indicating rounding.
In this embodiment, the average frame rate is preset to F for the video tracksframe=24000/1001fps, for an audio track, the frame rate is Fframe=44100/1024 (audio sample rate per second 44100, 1024 samples per frame), recording duration Trec=1h, then N is the video track in this embodimenti_frame=86313, for audio track, Ni_frame=155039。
Taking fig. 4 as an example, the duration of each sample (sample) is stored in the stts container, the stts container adds a variable (entry _ count field, 32 bits, 4 bytes) to the foundation (12 bytes) of the FullBox, that is, the number of entries and each entry record, each entry is used to record frame information, as shown in fig. 4, if the sampling durations of different frames are not consistent, each entry needs to be updated, and the content includes the number of samples included in the video frame corresponding to the entryAnd a sample duration, e.g., the sample number sample _ count of entry 0 is 1, and the sample duration sample _ duration is 1025 units; the sample number sample _ count of entry 1 is 1, the sample duration sample _ duration is 977 units, and the sample number sample _ count of entry 2 is 3, and the sample duration sample _ duration is 1001 units. For this case, the reserved space of the stts container is the storage space size S required for the fixed fieldi_constWith the sum of the storage space required for all entries, as defined by the stts container in the ISO/IEC 14496-12 protocol below, the size S of the storage space required for the fixed field when subscript i identifies the stts containeri_constFor 16 bytes, corresponding to a size S per framei_frameThe frame rate is preset for 8 bytes (4 bytes, 32 bits for each of sample _ count and sample _ delta), and in this embodiment, the reserved space size S of the stts container calculated by the video track according to the formula (1) is set in advanceiAs shown in fig. 3, is 690520 bytes.
aligned(8) class TimeToSampleBox
extends FullBox(’stts’, version = 0, 0) {
unsigned int(32) entry_count;
int i;
for (i=0; i < entry_count; i++) {
unsigned int(32) sample_count;
unsigned int(32) sample_delta;
}
}
If the sampling time of each sample in the track is consistent, only one entry needs to be recorded to read the mp4 file normally, for comparison, taking a second track as shown in fig. 5 as an example, the track records an audio track, the number of entries in the stts container does not change with the recording time, so the size of the stts container is fixed, and the reserved space is equal to the size of the storage space required by the fixed fields such as the number of entries (S)i_const) The sum of 16 bytes and the size of a fixed number of entries (one entry) is 8 bytes, and the reserved space is equal to the effective space.
The sampling duration can be set to be a fixed value according to the needs of an actual scene, in short, if the sampling duration is not fixed in advance, the stts container is a variable sub-container, and if the sampling duration is fixed in advance, the size of an effective space of the stts container in the whole multimedia recording process is not changed, which is a special case of the variable sub-container. The embodiment of the invention can reduce the size of the reserved space and reduce the difference between the reserved space and the effective space by pre-configuring the information related to the item content of the stts container.
As shown in fig. 6, the size of each sample, sample _ size, and the number of all samples in the media, sample _ count, are defined in the stsz container, and sample _ size in the legend is 0, which indicates that in the embodiment of the present invention, the size of the mp4 file sample is not fixed, and the size of each sample needs to be written, and the data of sample _ count only needs to be updated with specific values, and does not affect the size of the stsz container. Obviously, the effective space of the stsz container will increase as the sample entry increases, but the new entry will not overwrite the next container because enough space is reserved. As defined below for stsz containers in the ISO/IEC 14496-12 protocol, when subscript i identifies a stsz container, Si_constFor the total size of the fixed field (12 bytes), sample size field (4 bytes) and sample count field (4 bytes) in the FullBox, 20 bytes, each frame corresponds to the size Si_frameIs 4 bytes, Ni_frameObtained as described above, then for a video track, the size of the reserved space of the stsz container calculated according to equation (1) is 345272 bytes as shown in the first trak in fig. 1; for an audio track, the calculation according to equation (1) is 620176 bytes as shown in the second trak in fig. 1.
aligned(8) class SampleSizeBox extends FullBox(‘stsz’, version = 0, 0) {
unsigned int(32) sample_size;
unsigned int(32) sample_count;
if (sample_size==0) {
for (i=1; i <= sample_count; i++) {
unsigned int(32) entry_size;
}
}
}
The mapping relationship between samples and chunk is described in the stsc container, the chunk may include one or more samples stored continuously, when the chunk includes multiple samples, the correspondence between the chunk and the samples is not fixed, and since the number of entries of the chunk cannot be directly estimated, if the maximum number of entries to be written in the stsc container is estimated according to the maximum frame number, as defined in the stsc container in the following ISO/IEC 14496-12 protocol, the size of the storage space required by the fixed field in the stsc container is 12 bytes corresponding to fubollx and 4 bytes (corresponding to entry _ count variable) added thereto, which total 16 bytes, while each entry in the stsc requires 12 bytes for storage, which inevitably results in that the size of the reserved space of the stsc is much larger than the size of the effective space of the stsc at the end of file recording, resulting in space waste and an excessively large moov container. In this embodiment, in order to simplify the processing, it is preset that one chunk only includes one sample, and then only one entry information needs to be stored in the stsc, so that the multimedia file can be correctly read, as shown in fig. 7, the size of the reserved space is 28 bytes.
aligned(8) class SampleToChunkBox
extends FullBox(‘stsc’, version = 0, 0) {
unsigned int(32) entry_count;
for (i=1; i <= entry_count; i++) {
unsigned int(32) first_chunk;
unsigned int(32) samples_per_chunk;
unsigned int(32) sample_description_index;
}
}
The locations of chunk in the media stream are described in co64 containers, stco containers, again as defined in the ISO/IEC 14496-12 protocol (not shown below), with the only difference being that co64 containers correspond to 64 bit lengths and stco containers correspond to 32 bit lengths. Since in the embodiment, the stsc is optimizedThe content stored in the item is a separate chunk for each sample, so that the items stored in the co64 container have a one-to-one correspondence with the samples, and when subscript i identifies the co64 container, S isi_constFor 16 bytes (12 bytes for the FullBox and 4 bytes for the fixed field entry count added in the corresponding class), each frame corresponds to a size Si_frameWhich is 8 bytes. For a video track, the reserved space size of the co64 container calculated according to equation (1) is 690520 bytes as shown in fig. 8. For an audio track, the calculation according to equation (1) is 1240328 bytes as shown in the second trak container in fig. 1.
The key frames in the media container are described in the sts container, which are independently codec frames, for video coding it is necessary to store the sequence number of the key frame in the box, while for audio each sample can be analogized to the key frame. The reserved space calculation formula of the stts container is as follows:
S=Sconst+Kframe*Sframe（3）
wherein S isconstSum of the size of the storage space required for the fixed fields in the container, the storage space required for recording a single entry of key frame information, KframeRepresenting the estimated number of key frames.
For the stss container, the definition of the stss container in ISO/IEC 14496-12 protocol (not shown below) is also followed, since it is also an extension of the FullBox class, SconstThe size of the memory required for the fixed field entry _ count (32 bits, 4 bytes) plus the 12 bytes, i.e., 16 bytes, required for the FullBox fixed field memory, the size S of the memory required for the record entry for each key frameframe4 bytes, the estimated number of key frames KframeThe frame rate (or frame interval) of the key frame may be calculated according to the frame rate of the key frame, and the frame rate of the key frame is generally set to be the number of key frames in a unit duration through a preset configuration, or a key frame is taken from a fixed number of frames at an interval, in this embodiment, a key frame is taken at one second, and the recording duration T is calculated according to the recording duration Trec14416 bytes are obtained when the number of bytes is 3600s, and in this embodiment, in order to prevent errors from occurring in the encoder, the actual number of bytes is actually reducedThe number of key frames is larger than calculated, so that the margin is set (one is added as margin in this example) according to the size of the storage space required by a single entry, such as 14420 bytes as shown in fig. 9.
In this embodiment, the allowance is set only based on the stss container, and for other variable sub-containers, the allowance may be set as needed during implementation. In short, as an embodiment, the size of the reserved space of the variable sub-container may further include a preset margin, where the preset margin is used to prevent an entry error, and the preset margin is set according to the size of the storage space required by the single entry corresponding to the corresponding variable sub-container.
In summary, the logic for calculating the size of the reserved space of the variable sub-container in the above formula (1) and formula (3) is consistent, that is:
acquiring an estimated value of the total number of items which can be written in the corresponding variable sub-container when the recording of the multimedia file is finished according to the content of the items to be written in the variable sub-container and the preset recording duration of the multimedia file;
and acquiring the size of the reserved space of the corresponding variable sub-container according to the estimated value of the total number of the items, the size of the storage space required by the single item in the corresponding variable sub-container and the size of the storage space required by the fixed field.
For some variable sub-containers, such as stts container and stsc container, which can reduce the size of the reserved space by pre-configuring the storage contents of their entries, as a special case of the variable sub-containers, the difference from the above general variable sub-containers is only that the total number of entries written by the corresponding variable sub-container in the whole multimedia file recording process is fixed and does not need to be obtained according to the recording time length of the multimedia file.
The reserved space size of all the sub containers in the moov container and the reserved space size of the moov container can be estimated in the above manner, and how to sequentially obtain the storage position offset of each container according to the storage position offset of the moov container, the storage order of each container in the moov container and the reserved space size of each container will be further described in combination with the above description about the fixed field. In the whole writing process, the storage position offset of each container is recorded in the memory.
As shown in fig. 2, the storage location offset of the moov container is 0x24, and since the moov container is an extension class of the Box class, the storage location offset of the first container mvhd container directly contained in the moov container is 0x2c, which is the storage location offset of the moov container (0 x 24) plus the fixed field size (8 bytes) of the head of the moov container.
For the containers directly contained in the moov container, taking the trak container as an example, the storage location offset is obtained by adding the storage location offset (0 x2 c) of the mvhd container located at the same level to the storage space (108 bytes) of the mvhd container, i.e., 0x 98.
Taking the tkhd container directly contained in the trak container as an example, its storage location offset is the storage location offset of the trak container (0 x 98) plus the storage space required by the trak container fixed field (8 bytes), i.e., (0 xa 0). Taking the edts container directly contained in the trak container as an example, the storage offset is obtained by adding the storage offset (0 xa 0) of the tkhd container located at the same level to the storage space (92 bytes) of the tkhd container, i.e. 0 xfc.
In short, the storage location offset of the container belonging to the same level of the same container is the sum of the storage location offset of the previous container plus the storage space of the previous container, and the storage location offset of the first container in the container is the storage location offset of the container plus the storage space required by the fixed field corresponding to the container.
Compared with the prior art, taking the stts container in the first track in fig. 2 as an example, the container is a variable sub-container, if the moov container is updated integrally according to the prior art, the storage space required by the stts container becomes large with the increase of the recording time, which inevitably causes storage position shifts of the stsz container, the stsc container, the co64 container, and the stss container, and if an exception occurs when the moov container is not completely written, it is easy to cause that the next containers cannot be found correctly, and thus the mp4 file cannot be played.
The method of the invention sequentially obtains the storage position offset of each container according to the storage position offset of the moov container, the storage sequence of each container in the moov container and the size of the reserved space of each container, and records the storage position offset of each container in the memory. Due to the fact that appropriate storage spaces are reserved for the sub-containers in advance, the offset of the storage spaces of the containers in the embodiment of the invention can be kept constant in the whole write-in process of the moov container, even if abnormality occurs in the write-in process of the moov container, the sub-containers cannot be found, and the situation that the content written in one sub-container is covered by other sub-containers cannot occur.
How to write corresponding contents in the moov container and each container contained therein according to the storage position offset of the moov container and the storage position offset of each container will be described below.
As a container content update mode, the writing process includes the following steps:
at the initial updating time, sequentially writing the content to be stored in the fixed field in each container according to the moov container and the storage position offset of each container, wherein the content of the fixed field is related to the type of the container and is described in detail above; for the variable container, the existing entries at the current moment need to be written;
at each subsequent updating moment, updating the value of the fixed field in each container in the moov container; for the variable sub-container, the entries already existing at the current time are also updated.
As another container content updating method, in order to reduce the updating content, only partial entries are updated for a variable quantum container, and the method comprises the following steps:
at the initial updating time, sequentially writing the content to be stored in the fixed field in each container according to the moov container and the storage position offset of each container, wherein the content of the fixed field is related to the type of the container and is described in detail above; for the variable container, the existing items at the current moment need to be written, and the item number of the last item is recorded;
at each subsequent updating moment, updating the value of the fixed field in each container in the moov container; for the variable sub-container, after determining the entry number of the initial entry at the current updating time according to the entry number recorded at the last updating time, writing the entries with the corresponding number, and recording the entry number of the last entry; if the number of entries of the variable sub-container at the current update time is the same as the number of entries at the last update time, i.e., the special case of the variable sub-container described above, no writing is required.
The updating of the value of the fixed field in each container may be performed entirely or only partially according to the change of the value of the fixed field.
Specifically, taking the variable sub-container stsz container as an example, as shown in fig. 6, 10, and 11, at the initial update time, the contents of the fixed field are written according to the storage location offset (0 xa8bd 8) of the stsz variable sub-container, for example, 92 entries already exist at the current time, and the entry number of the last entry is recorded as 91;
at an update time immediately after that, the value of the internal fixed field is updated, and compared with fig. 10 and 11, the content of the sample _ count field changes (corresponding to the storage location offset 0xa8be 8), from 92 (hexadecimal 5C) to 154 (hexadecimal 9A); after determining the entry number 92 of the starting entry at the current update time according to the entry number 91 recorded at the last update time, writing a certain number of entries, such as 62, and recording the entry number 153 of the last entry (compare fig. 10 and 11, the effective space size of stsz changes); this completes the content writing at each subsequent update timing.
Of course, as another entry updating method of a variable quantum container, a fixed number of entries may be written periodically, for example, only 90 entries are written each time, and once 90 new entries are accumulated in the memory, the corresponding entries are written into the storage carrier.
As an embodiment, the present invention further provides a computer storage medium, in which a program is stored, where such a computer storage medium may be embedded in an mp4 recording device, and a physical button provided by the mp4 recording device may cooperate with a display or a touch screen display, a web interface, etc. for a user to preset a recording duration and some information related to a frame, such as a frame rate, a frame rate of a key frame, an encoding format, a sampling duration, etc., before recording an mp4 file, and when the processor executes the program stored in the computer storage medium, the recording of the mp4 file may be implemented.
Although the preferred embodiments of the present invention have been described in detail, the present invention is not limited to the details of the embodiments, and various equivalent modifications can be made within the technical spirit of the present invention, and the scope of the present invention is also within the scope of the present invention.
Claims (7)
1. A method for writing a moov container in a multimedia file, for writing the moov container in a storage carrier, the method comprising the steps of:
estimating the size of reserved space of all containers in the moov container and the size of reserved space of the moov container according to the protocol specification of the multimedia file format;
sequentially acquiring the storage position offset of each container according to the storage position offset of the moov container, the storage sequence of each container in the moov container and the size of the reserved space of each container;
writing corresponding contents in the moov container and each container contained in the moov container according to the storage position offset of the moov container and the storage position offset of each container;
wherein, the moov container structure comprises a container and a non-container, the reserved space of the container is equal to the reserved space of all the containers contained in the container and the storage space required by a fixed field in the container, and the fixed field is related to the type of the container; dividing a non-container in the moov container structure into a quantitative sub-container and a variable sub-container, wherein the size of an effective space of the quantitative sub-container is unchanged in the whole multimedia file recording process; the effective space of the variable sub-container changes along with the number of the items written in the variable sub-container, and a fixed field for storing the total number of the items written in the variable sub-container is arranged in the variable sub-container; the effective space refers to the space actually occupied by the written effective data in the container;
wherein, for a variable sub-container, estimating the size of the reserved space of the variable sub-container comprises the following steps:
acquiring an estimated value of the total number of items which can be written in the variable sub-container when the recording of the multimedia file is finished according to the content of the items to be written in the variable sub-container and the preset recording duration of the multimedia file;
and obtaining the size of the reserved space of the variable sub-container according to the estimated value of the total number of the items, the size of the storage space required by a single item in the variable sub-container and the size of the storage space required by the internal fixed field of the variable sub-container.
2. The method of claim 1, wherein the size of the reserved space of the variable sub-container further comprises a preset margin, the preset margin is used for preventing entry errors, and the preset margin is set according to the size of a storage space required by a single entry in the corresponding variable sub-container.
3. The method for writing the moov container in the multimedia file according to claim 1, wherein the entry content written by some variable sub-containers is configured in advance according to the protocol specification of the multimedia file format, so that the number of entries written by the corresponding variable sub-containers in the whole multimedia file recording process is kept unchanged.
4. The method for writing to an moov container in a multimedia file according to claim 1, wherein the reserved space size of the fixed sub-container is a storage space size required by a fixed field therein.
5. The method for writing the moov container in the multimedia file according to claim 1, wherein corresponding contents are written in the moov container and each container thereof, comprising the steps of:
at the initial updating moment, sequentially writing the contents which are stored in the corresponding fixed fields in the storage carrier according to the moov containers and the storage position offset of each container; for the variable sub-container, the existing items at the current moment need to be written, and the item number of the last item is recorded;
at each subsequent updating moment, updating the value of the fixed field in each container in the moov container; for the variable sub-container, after determining the entry number of the initial entry at the current updating time according to the entry number recorded at the last updating time, writing the entries with the corresponding number, and recording the entry number of the last entry; and if the number of the entries of the variable sub-container at the current updating time is the same as the number of the entries at the last updating time, not writing.
6. The method for writing to an moov container in a multimedia file according to claim 1, wherein the multimedia file is an mp4 file or an mov file.
7. A computer-readable storage medium storing a computer program, characterized in that the program, when executed, implements the method of writing an moov container in a multimedia file according to any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111102924.9A CN113555040B (en) | 2021-09-18 | 2021-09-18 | Write method of moov container in multimedia file and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111102924.9A CN113555040B (en) | 2021-09-18 | 2021-09-18 | Write method of moov container in multimedia file and computer readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113555040A CN113555040A (en) | 2021-10-26 |
| CN113555040B true CN113555040B (en) | 2021-12-14 |
Family
ID=78106419
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111102924.9A Active CN113555040B (en) | 2021-09-18 | 2021-09-18 | Write method of moov container in multimedia file and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113555040B (en) |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100876494B1 (en) * | 2007-04-18 | 2008-12-31 | 한국정보통신대학교 산학협력단 | Integrated file format structure composed of multi video and metadata, and multi video management system based on the same |
| CN102646433B (en) * | 2012-04-17 | 2014-10-15 | 北京华夏电通科技股份有限公司 | Method, device and system for generating stream media real-time record file of digital court |
| CN105872484B (en) * | 2016-06-04 | 2017-07-21 | 武汉诚迈科技有限公司 | A kind of abnormal guard method of monitoring video |
-
2021
- 2021-09-18 CN CN202111102924.9A patent/CN113555040B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN113555040A (en) | 2021-10-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108093299B (en) | Method for repairing damaged MP4 file and storage medium | |
| CN101661787B (en) | Data recording method | |
| US20080256431A1 (en) | Apparatus and Method for Generating a Data File or for Reading a Data File | |
| CN1643605B (en) | Data recording method, data recording device, data recording medium, data reproduction method, and data reproduction device | |
| CN111063376B (en) | Method, terminal equipment and storage medium for audio and video synchronization in MP4 repairing | |
| US20120158802A1 (en) | Mp4 container file formats and methods of processing mp4 container files | |
| CN110740391B (en) | Method for repairing MP4 damaged file | |
| CN101351845B (en) | Recording device, recording method, recording program, imaging device, imaging method, and imaging program | |
| JP2007012112A (en) | Data recording device and method thereof, program, and recording medium | |
| CN108322808B (en) | Video recording processing method and device, computer device and storage medium | |
| CN101542623A (en) | Reproducing apparatus, reproducing method, and program | |
| CN114007112B (en) | Method for repairing mdat box data errors in MP4 video file | |
| KR20000068577A (en) | Data recording/reproducing device, file managing method, file informaion generating method, file managing method, management information generating device, management information analyzing device, and medium | |
| JP2002529884A (en) | Signal processing on information files to obtain characteristic point information sequences | |
| JP5164183B2 (en) | Data recording method, data set extraction method, data file, data structure, and medium for storing the data | |
| JP7391963B2 (en) | Apparatus and method for signaling information in container file format | |
| US8868429B2 (en) | Method and device for storing audio data | |
| CN100440352C (en) | Power failure recovery method | |
| CN113555040B (en) | Write method of moov container in multimedia file and computer readable storage medium | |
| CN105653385B (en) | A kind of vehicle-mounted kinescope method | |
| TWI555406B (en) | Storage method and processing device and video recording system thereof | |
| RU2416830C2 (en) | Recording medium, method of recording data and device for recording data | |
| CN112732180B (en) | Information processing method, processing device, electronic equipment and storage medium | |
| CN112929686A (en) | Method and device for playing back recorded video in real time on line | |
| KR20000016370A (en) | Record playing apparatus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |