Usually my Handbraked mp4-files can be edited without problems. Today though I had the same bug both wit the April version of Avidemux and with the one from yesterday:
After cutting the front 20 seconds from a "normal" mp4 file (with output format mp4v2), the length acc. to MediaInfo was nearly tripled. Trying to play it with VLC resulted in the first hours playing without video, only sound.
I have attached the MediaInfos and kept the original mp4, and I can supply additional information or do test, if wished.
a small file where it happens would help
Maybe you could handbrake ~1 mn of the same source ?
Quote from: mean on May 04, 2015, 06:09:02 PM
a small file where it happens would help
Maybe you could handbrake ~1 mn of the same source ?
I just did cut the original mkv (using Avidemux), handbraked the result, and then did a front-cut with Avidemux again. Unfortunately the bug did not happen.
I will continue to try producing a useful result.
Do you know by chance, whether Handbrake has a (reasonably simple) option, to convert only the first 2 minutes or so?
I found a way to limit the handbrake output to a specific amount of seconds, but unfortunately with such shortened output the problem of the subsequent Avidemux editing did also not occur...
The only thing which I can tell to be different from my "normal" operations is the following: My handbraked mkv had a subtitle track, which I did let Handbrake burn in.
I will try the original length mkv be handbraked without the burn-in option, and I will report what happened then.
QuoteDo you know by chance, whether Handbrake has a (reasonably simple) option, to convert only the first 2 minutes or so?
handbrake: found no way to set duration.
record from source with limited duration 1 min, 2 min, ... (Set Top Box)
find similar content with the required duration (youtube, ... ) browser download extension
did run into possible mkv issue, either:
- audio track source/conversion. Can't recall exactly what it was (mono, aac (Faac vs Lav), ...)
- If more then one possibility in avidemux preferences for Display & HW Accel, switch back to lower performing option. see if that issue is gone then
not on MacOSX, but ubuntu, could still be related
Could be the sub are mixing up with the audio tracks
Quote from: mean on May 05, 2015, 07:01:20 AM
Could be the sub are mixing up with the audio tracks
I was suspicious of a correlation as well, because usually I don't Handbrake burned-in subtitles into the mp4 (which I subsequently edited with Avidemux). But my tests revealed, that this was a pure coincidence. FWIW, I describe the latest workflow again:
I took a 1080p mpv consisting of a video, an audio, and a subtitle track. This file I converted with the latest Handbrake into an mp4, using the iTunes compatible preset,
ignoring the subtitle track.
The resulting mp4 has a video and 2 audio tracks, and it plays well with VLC, with Quicktime, and with MPlayer OS X Extended.
But when I edit this mp4 with Avidemux, cutting only the front 20 seconds, and using mp4v2 as output format, then the file is corrupted, with a video length of 6 hours, as shown in my first post.
I made an additional observation: although the mp4 has 2 GB, it is opened by Avidemux within only app. 3 seconds, and can be edited immediately. Usually reading in takes a minute or so. But when I save the file after the edit, then for more than a minute the "saving" progress bar was empty, showing nothing, before then starting to display progress for another one or two minutes.
Please tell me, if I can do anything in addition.
Quote from: Jan Gruuthuse on May 05, 2015, 06:59:57 AM
handbrake: found no way to set duration.
FWIW: the Handbrake nightlies allow to specify, which chapters are to be converted, and it is also possible, instead to specify a number of seconds.
remove the .idx2 file with the same name as your video. This should allow avidemux 2.6.8 to re-index the the file (just in case).
thnx for chapter tip.
It smells like bad timestamp decoding
A sample would really help
Quote from: mean on May 05, 2015, 10:51:35 AM
It smells like bad timestamp decoding
A sample would really help
Yes, but anything shortened up to now did not produce the bug. I've ran out of ideas...
Quote from: Jan Gruuthuse on May 05, 2015, 10:50:35 AM
remove the .idx2 file with the same name as your video. This should allow avidemux 2.6.8 to re-index the the file (just in case).
Can you explain that technically, i.e. what I have to do?
In the folder where you have the concerned videofile, you should have a similar named file with the extension .idx2, delete this one then reload that video in avidemux. This should create a new index file.
handbrake rev5474 (about handbrake) I don't find the iTunes compatible set. Have only iPod, iPhone & iPod touch, iPad, AppleTV, AppleTV 2, AppleTV 3.
Quote from: Jan Gruuthuse on May 05, 2015, 12:51:22 PM
In the folder where you have the concerned videofile, you should have a similar named file with the extension .idx2, delete this one then reload that video in avidemux. This should create a new index file.
Unfortunately I don't find such a file, even not when I look for invisible or system files.
But that's no longer a problem, because in 20 minutes or so I will present a downloadable repeatable version of the problem, which hopefully can be debugged
Quotehandbrake rev5474 (about handbrake) I don't find the iTunes compatible set. Have only iPod, iPhone & iPod touch, iPad, AppleTV, AppleTV 2, AppleTV 3.
E.g. all AppleTV presets generate iTunes compatible format. This means, that they have an AAC audio as the preferred (or "active") audio, plus a second AC3 audio stream.
BTW: I'm using the latest version 7156 of the nightlies, which I strongly recommend. I can not remember to ever have stumbled upon a bug with the nightlies.
Quote from: mean on May 05, 2015, 10:51:35 AM
It smells like bad timestamp decoding
A sample would really help
Heureka!
I could produce an mp4 with Handbrake, using the lowest-most quality settings, resulting in a 680 MB file, which still produces the bug:
https://www.dropbox.com/s/ozuo8h0wsaiikri/_Test-Black-Rain-bad-for-Avidemux.mp4?dl=0 (https://www.dropbox.com/s/ozuo8h0wsaiikri/_Test-Black-Rain-bad-for-Avidemux.mp4?dl=0)
You need only to load this file in Avidemux, edit/cut the first 20 seconds, and then save it from Avidemus with output set to mp4v2. The resulting/saved mp4 will have a (MediaInfo-) length of 6 hours, and when played with VLC or such, will not show video for the first hour or so.
when cutting @ 0:00:19.019, and save the movie: black screen and indication film has 6 hour duration when playing saved video.
attached terminal output:
even worse when saving this to mkv
[FF] Saving
[saveLoop] avg fps=24390
[initUI] Muxer, creating UI, video duration is 02:04:59,076
[getPacket] PTS<DTS : PTS=0 ms , DTS=18446744073709467ms
[refresh] XV:refresh
[adm_lavLogCallback] [lavc] pts (0) < dts (18446744073709468) in stream 0
[FF]Error writing video packet
[saveLoop] [FF] Wrote 0 frames, nb audio streams 2
[saveLoop] [FF] Found 0 missing PTS / 0 total frames
[close] [Mkv] Closing
[~DIA_encodingQt4] Destroying encoding qt4
[~DIA_encodingBase] DiaEncodingBase: Destroying
terminal output lavcodec to mkv
weird is when you cut @ next keyframe 0:00:22.897 (3 seconds in between) all is back to normal.
Quote from: Jan Gruuthuse on May 05, 2015, 02:41:58 PM
weird is when you cut @ next keyframe 0:00:22.897 (3 seconds in between) all is back to normal.
Yes, I can confirm this also for my high quality version. I didn't notice it before.
Just noticed something else the keyframes selected by avidemu vary in time: 1st, 2nd, 3rd, ... sequential order
0:00:00.083
0:00:02.419
0:00:12.429
0:00:19.019
0:00:22.897
0:00:27.777
0:00.32.365
no idea if this expected or not.
thanks for the sample, i'll look into it
It is indeed a bad timestamp computation, fixing it...
Quote from: mean on May 06, 2015, 07:40:13 AM
It is indeed a bad timestamp computation, fixing it...
Good to hear... Please let us know, by posting here, when you have uploaded the fix.
Should be ready in ~ 30 mn
Quote from: mean on May 06, 2015, 11:55:48 AM
Should be ready in ~ 30 mn
Works perfect. Thank you.
same here, works fine, thnx