View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006382 | MMW v4 | Properties/Auto-Tools | public | 2010-06-20 15:35 | 2011-11-14 21:50 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.2 | ||||
| Target Version | 4.1 | Fixed in Version | 4.0 | ||
| Summary | 0006382: Tagging of large MP4 files takes too long | ||||
| Description | I found that tagging of large MP4 file (e.g. > 200 MB video file) takes 30 seconds on my system. This is because the workflow seems to be this: 1. The whole file "Filepath.MP4" is copied to "Filepath.mp4.XXXXXX" 2. Then copy "Filepath.mp4.XXXXXX" is tagged 3. The original "Filepath.MP4" is replaced by the copy "Filepath.mp4.XXXXXX" Question is: Is it really neccessary to create the copy, isn't it possible to tag the original directly like in case of the other filetypes? | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1425 | ||||
| related to | 0001449 | resolved | MMW v4 | AAC (m4p, m4a, mp4) Tagging support (failed scans / crash on scan) | |
| related to | 0005487 | resolved | jiri | MMW v4 | Multiple LIST INFO Chunks in WAV files are not cleared during Tag save |
| related to | 0007251 | closed | michal | MMW v4 | Tagging and playing of very large MP4 files does not work. |
| related to | 0007626 | closed | michal | MMW v4 | Tagging QuickTime files (MOV) |
| related to | 0008309 | assigned | michal | MMW v4 | Add 'Optimize for Streaming' to Advanced tagging functions |
| related to | 0008310 | closed | michal | AAC / Video codec plugin | Optimize MP4 muxer, so it will generate files optimized for streaming |
| related to | 0008466 | closed | michal | MMW v4 | Some m4a files make no sound on iPod/iPhone (regression) |
|
|
It is probably possible, but it leads to complete rework of the file saving algorithm. The AAC plugin now reads the atoms from the source file and creates new file from them. New algorithm should analyze the file and try to write metadata to the free space in the header or to the end of the file (and make free space from existing metadata, if there is not enough space in the header). |
|
|
Note that iTunes has the same issue and even worse, because they don't tag on background and therefore iTunes freezes completely in such a case. |
|
|
Just a suggestion. Something Similar is done with FLAC and with WAVE. I remember I had similar issues with them Maybe we could optimize routine to be more efficient (WAVE have JUNK Chunk for allowing appending LISTINFO Chunk on the end of file, ...) |
|
|
peke: yes, this is what I've meant. I use similar algorithm for AVI tagging. We need to change the whole saving algorithm. |
|
|
If we decide to do something about it then we should ensure that it will not cause any problems with regard to readability by the others applications! |
|
|
Ludek: sure, we talk about standard atoms and structure of course, MP4 has standard atom for free space too, it is all about smarter saving algorithm. |
|
|
Do not forget that we need to take in consideration Network Tagging which is currently performance bottleneck. |
|
|
Michal: You are completely right see 0005487 |
|
|
As discussed with Michal over IM, the best suggested approach is: 1. To rewrite the mp4 plug-in, due to old complex and inefficient code. 2a. Try to write MOOV to the beginning of tagged file. 2b. Always keep a reserve in the newly written MOOV, so that further updates are fast. 3. In case there isn't any space available at the beginning of file, we either: 3a. Write MOOV to the beginning anyway, relocate the rest of file - for smaller files, like < 10MB? 3b. Write MOOV to the end of file for larger files. 4. Since MOOV should be at the beginning of file for streaming purposes, we could add an entry to Advanced tagging functions - 'Optimize for Streaming' that would move MOOV to the beginning regardless of file size. 5. Our MP4 muxer currently writes MOOV to the end of file. We should try to fix this, so that user doesn't have to use 4. for streaming fix. It seems that the best approach would be to keep a reserve for MOOV (needs to be estimated) and update it when A/V data are written. In case the reserve was underestimated, the file would have to be relocated after conversion. |
|
|
1-3b fixed in build 1425. New f_MP4.dll plugin introduced, it will handle all tagging/parsing functionality of MP4-like files instead of f_AAC.dll. |
|
|
Resolving. The rest is tracked as 0008309 and 0008310. |
|
|
Verified 1459 |
