Hello SolveigMM-team,
I hope this forum is still active, because of the large amount of spam that accumulated during the last days...
But well, here is my question/problem description:
- tried with Video Splitter v3.6.1306.21(?) and v3.7.1309.19-BETA
- input file:
* video: MPEG-4 Visual - Simple Profile @ L4a (VFR but no B-frames and stuff)
* audio: AAC-LC with CBR
- selected fragment: just the first 2 minutes, cut at an I-frame (or K-frame)
- VideoSplitter settings: "GOP Accuracy", "Smart Mode", "Obey Sample Times" or
"Ignore Trimming Errors" - all that does not matter
- using "Batch Manager", "Save Current Fragment" or "Trim" gives same result
When you trim an MP4 video, the position of the samples/chunks in the output file's MDAT atom is different every time you save. The files are okay, they play just fine, as the STBL (sub-)atoms do reflect those changes. As I can imagine, the position of the audio samples, even combining them into new chunks, might be subject to some kind of optimization, but I could not imagine any reason why this would lead to a different output for the very same input.
I discovered this while comparing two output files in a hex-editor to detect what changed (on a binary level) when adding 1 frame at the end of the fragment to be saved. Expecting only some additional KBytes at the end of the file, I was very surprised to find many differences everywhere in the file!
While trying to dig deeper into that, I saw no such behaviour in AviDemux v2.65-r8900; the MP4v2 muxer only changes the timestamps in the header-atoms (MVHD, TKHD, MDHD), the rest is the same no matter how often you save the fragment.
When you want to reproduce this (just use any "*.mp4"-video, eg. one recorded with your smartphone) you might get the following result:
- two output files are almost identical, only one or two audio samples are slightly offset,
- there appear to be massive changes, ie. many audio samples are at completely different places,
- the files really are identical.
There seems to be one certain constellation which appears to surface more often than any other, so if you save the fragment 10x, you can obtain 3-6 identical files, while the others are all different to some extent.
The same or at least something similar is true for AVI-file trimming (MPEG-4 Visual ASP@L5, MP3), as the output might be almost identical or have many differences in the "LIST movi"-chunk. Okay, this might be due to the massive amount of JUNK-chunks inserted by your AVI muxer (as they could be filled with random data), but that only leads to another problem. The 119sec long test-output-file of VideoSplitter (16546 kB) is about 3MB(!) larger than that of AviDemux v2.65-r8900 (13550 kB), both obviously being OpenDML-compliant. As I do not want to cut *.AVI atm, this is not my main concern, it's just a remark.
It took me several days to investigate but now I quit, I give up! At least I learned something about MP4-atoms and AVI-chunks, but actually I just wanted to split/cut some recordings. I wish I hadn't checked the output files with my HexEditor ;-). Hopefully, you can help me with that issue, because I really liked your clean and easy interface.
That (writing "interface") reminds me of another small feature I'd love to see added:
Since I use keyboard shortcuts whenever possible, I missed one to select a single marker and cycle through them in order to delete them individually. I felt like it should be (Shift-)Ctrl-Tab, although you used this one for activating the slider. It would be sufficient to add the possibility to use these shortcuts, they don't need to be set by default.
Thanks for reading all of this... *g*
