Some while ago, with the (then) newest avidemux 2.6.4 for MacOS X 10.8.4, I could edit an mp4 file also on P- or even B-frames, mostly just simply for cutting the beginning of a video. When saving the result I got a warning message about not using keyframes for the edit, but the saved file was ok and usable.
Since about early August, including the latest build r8897, I can still do this type of edit, and when saving I get the same warning message, but when I now click Ok, then I get a crash-message from Avidemux and the edit is lost:
"Crash
Assert failed: flags & AVI_KEY_FRAME
file
/users/fx/hudson/workspace/2.6_mac/avidemux/qt4/common/ADM_editor/src/ADM_segment.cpp, line 517"
Can anybody help? Or is a bugfix planned?
Very little knowledge of mac over here, cannot be of much assistance
Quote from: mean on September 06, 2013, 08:11:23 AM
Very little knowledge of mac over here, cannot be of much assistance
IMHO somebody doing the Mac-Relasing should be able to get around that bug without too much effort.
It can't be overly complicated, because before August this crash in this situation didn't happen, and possibly it is just sort of a software-internal safety-exit. Apparently it's no OS-level crash, but an emergency exit by Avidemux itself.
And it's a pity because Avidemux is a really valuable tool in the limited MacOS world.
Probably fixed in nightly
http://avidemux.org/nightly/osx/Avidemux2.6_r8932.dmg
Quote from: mean on September 22, 2013, 02:18:29 PM
Probably fixed in nightly
http://avidemux.org/nightly/osx/Avidemux2.6_r8932.dmg
Yes, the crash is fixed. Thank you.
But just for information: when cutting the start of an mp4 on a B frame, as I just did for testing, then I got a delay of the video relative to the audio of app. 1..2 seconds.
If you dont cut at all, do you have the delay ?
or cut on intra ?
Quote from: mean on September 22, 2013, 03:21:32 PM
If you dont cut at all, do you have the delay ?
No, the uncut version of the mp4 has perfect audio synchronisation
Sorry, I'm a layman
Quote from: mean on September 22, 2013, 03:31:08 PM
or cut on intra ?
What do you mean with that?
cut on keyframe
Quote from: mean on September 22, 2013, 06:26:26 PM
cut on keyframe
Ups, of course, sorry for my sillyness...
I tried it, and much to my surprise, when cutting on an intraframe, I get the same video delay of 2.5 seconds with my 30 min mp4.
I ran some tests. First with a second mp4 also coded in the same way with Handbrake (profile: Apple TV3). Both cutting at a B frame and cutting at an I frame did not distort the original audio-video-synchronization.
Then I looked again at the initial mp4 that after any way of cutting led to the reported 2500 ms video delay. MediaInfo gave me the information for both audio tracks: video delay 2500 ms!
So here is my speculative conclusion: although the audio and video synchronization of the uncut original mp4 was perfect, some of the software in the workflow that generated it (mainly Handbrake nightly builds) had - for whatever reason - introduced this video-delay-information into the containers information tables.
And Avidemux apparently felt obliged to output an mp4 with the video delay reduced to 0, by finally "implementing" the video delay of 2500 ms, thus innocently distorting the audio-video-sync.
I cannot blame Avidemux for that. And I have learned to better use MediaInfo in the future, before doing any Avidemux cuts.
Might be that avidemux ignores the side information giving the delay
When you playback the file in avidemux, is the delay already there ?
Quote from: mean on September 25, 2013, 11:46:47 AM
When you playback the file in avidemux, is the delay already there ?
Yes, playing the original uncut mp4 back in Avidemux has the video already delayed by 2500 ms.
To avoid any misunderstandings, I try to make a table: "Uncut" means the original mp4 as I got it from Handbrake, "Cut" means the mp4v2 file output by Avidemux after cutting some part of the beginning either at a B frame or at an I frame.
mp4 file version: Uncut Cut
Audible video playback
delay in VLC, ms none 2500
Video delay in MediaInfo, 2500 47
same for both audio tracks
Audible video playback
delay in Avidemux, ms 2500 2500
|
I hope this sheds some light onto what happens.
i would be interested in having a small sample file with side information saying the delay is 2500 ms
so that it is taken into account by avidemux
Quote from: mean on September 25, 2013, 03:37:37 PM
i would be interested in having a small sample file with side information saying the delay is 2500 ms
so that it is taken into account by avidemux
The original mp4 is 400 MByte, the cut file as well, and unfortunately I cannot make them smaller, because this means cutting und thus influencing their characteristics.
Therefore I have uploaded both the original file (https://dl.dropboxusercontent.com/u/90792628/Maus.mp4) and the cut file (https://dl.dropboxusercontent.com/u/90792628/Maus-cut-at-I-frame.mp4) onto my dropbox account, so you can play with them. I'll leave them at least some days there, so you don't need to hurry. From now (posting time) you need to wait another 2 hours (until app. 7pm GMT), until the upload is complete.
A hint: there is not much into-the-face talking in the video. The easiest way to visually check for audio-sync/desync is at the very end of both videos, within the last 20 seconds. It's easy to see that the guy keeps talking for 2500 ms, although audio has already finished.
The 2nd file looks ok, but the first one is 404
Quote from: mean on September 25, 2013, 07:03:21 PM
The 2nd file looks ok, but the first one is 404
Probably you tried too early. Now it works, please try again.
got it thanks
Just to let you know
There is indeed an information that is ignored
It basically says "drop the 2.5 first second of video"
Quote from: mean on September 29, 2013, 12:44:19 PM
There is indeed an information that is ignored
It basically says "drop the 2.5 first second of video"
So am I right in assuming, that you want to say, that some of the preceding software (most probably Handbrake, or the after the satellite recorder the TS editor TSDoctor) has generated some of the contents in the mp4 container information in a wrong way?
And VLC plays it "right" either by chance or for the wrong reasons?
That would be basically my assumption, and of course one can live with that. One only would need to be careful to check mp4 parameters before editing with Avidemux.
The file is okay
It's just that it uses a complicated sync method that is ignored by some software (including avidemux)
I'll add support for that
Quote from: mean on September 29, 2013, 03:58:06 PM
The file is okay
It's just that it uses a complicated sync method that is ignored by some software (including avidemux)
Ok.
QuoteI'll add support for that
So when you eventually have done that, it would be nice to give a word here in this thread, for avoiding the relatec Avidemux checking afterwards.
Try that one :
http://avidemux.org/nightly/osx/Avidemux2.6_r8944.dmg
It does not handle all cases but should work for yours
Quote from: mean on September 30, 2013, 06:27:54 AM
Try that one :
http://avidemux.org/nightly/osx/Avidemux2.6_r8944.dmg
It does not handle all cases but should work for yours
Thank you, and Good Luck also in the future with your fine software!
EDIT:
If I may voice a wish: would it be desirable and possible, to change the default "Output Format" from the present "AVI" to "mp4V2"? I had already many errors after I forgot to change this every time I start Avidemux.
I'm aware that the AVI user fraction would like the present default to stay, but I guess the Avidemux environment is more mp4 than AVI. Of course perfect would be an option in "Settings", but this may be too much work.