Hi, no matter what version I use since 2.6.12 every second edit crashes avidemux. If I set the cut points and then hit delete it crashes. If I don't hit delete and move the cursor outside the cut points it's ok. That is a work around, but I often forget and hit delete. The program crashes and I have to wait until I can restart it. It loads the old job and works fine after that.
These are programs I record from tv and edit out the commercials before I watch them. So I edit out the part before the program starts and it's when I edit the first commercial segment that it always crashes.
Any help would be appreciated.
You should upgrade 2.6.12 to latest 2.7 http://www.avidemux.org/nightly/win64/ (2017/08/26)
At start of video got to 1st cut (end of commercial) mark [ B] then [Ctrl][X] (cut). All content from begin to [ B] is now gone.
Select editing points only with up or down keyboard arrow. See if that helps.
Thanks for the reply. I have upgraded to the lastest hoping that would fix it, but it doesn't. I tried using only key frames and it still does it. I should add I get a seek error before it crashes.
I have attached the error message in case it helps.
Delete the .idx2 files for related videos.
Try not to use such deep paths, if your on windows?
Is your source DVB-T recording? Does it only happens to this video recording? or same videos (same source)
Clean your temp files (windows/cache) check you do have enough room to edit the video ( approx 2.5 x the video size)
All I can think of, I'm not on windows.
Ctrl+X executes "Cut" which is "Copy to clipboard" and "Delete" in one step.
The only relevant thing is whether the current position is between the markers or outside. If it is the former, Avidemux tries to seek to the time of the A marker. If video decoding fails at this moment, things can go very wrong. Please reproduce this crash and, without restarting Avidemux, compress admlog.txt from the %localappdata%\avidemux folder and attach it to your reply.
Please check also whether you have video decoding via DXVA2 enabled. If yes, disable it.
I used my laptop as a test and it worked. I am still attaching the admlog as I'd like to get this fixed on my desktop. Let me know if uninstalling all the instances of avidemux is a place to start.
Did it work on your laptop with the very same video?
Anyway, I can reproduce the issue by manipulating ADM_Composer::goToTimeVideo in a way that makes both calls to ADM_Composer::seektoTime fail. This results in _currentSegment getting out of sync with _currentPts, ultimately leading to an assert failing in ADM_Composer::samePicture.
No, it fails with the newer video's on my laptop. At first I used an older one as a test. When I tried a newer one it also fails. I use Hauppauge capture and Hauppauge hd pvr to record the video's. I can try running them through Handbrake to see if they still fail after.
Could you please provide a sample?
I've pushed a patch (https://github.com/mean00/avidemux2/commit/3f4bfa2e22b05707ec373f8a62ffc802eb320e28) which should make Avidemux more robust against this crash.
Thanks. :) How do I get the patch? a nightly build or something?
Either you cross-build (https://github.com/mean00/avidemux2/blob/master/cross-compiling.txt) yourself or wait for an official nightly to happen.
A sample would be nice nevertheless.
I'm on slow and metered internet, but I'll see how small a sample I can provide.
I tried uploading a larger sample, but I think there is a size restriction here. I am attaching a zipped video that is as poor quality as I can record. Plus it's only 3 seconds long, but long enough to reproduce the error.
I can't reproduce the issue with this sample. You should have used a service like WeTransfer and post a link to the file.
Interesting. I recreated the problem with this file before I replied.
Here is a 10 second file. I also made sure it failed on the second edit. https://we.tl/KTfsSxybak
I'm sorry, but I can't reproduce with the second sample too. Please specify exact steps (position of markers, playback position etc.).
Maybe I should note that I'm on macOS, using a fresh local build from the git master. I'll retest later with a similar local win64 build. Usually this should not matter when not using hw accelerated decoding (which is strongly platform-dependent).
I mark in at the beginning of the file. up arrow to the first out point. set point, hit delete. Up arrow to the second in point. set in point. Up arrow to the second out point. Set out point, hit delete. seek error, click ok then crash.
<edit> BTW I only up arrow once. It's just a test so I don't care about position.
Thank you, with these steps I can finally reproduce the seek error (Avidemux doesn crash due to patch, it rewinds to the beginning of the video instead).
Please test if omitting the Step 1 (setting "in" marker at the first frame) allows to avoid the seek error (and crash without a patched build) at the second deletion. Start straight with the "go to the next keyframe" command.
Ya, that stops the error from happening.
BTW, I often get a seek error cutting the very end of the file, but it doesn't cause a crash.
Instead of deleting the start and the end, you should better just save the in-between.
Pardon my ignorance, but how does one save just the middle?
Chose the codec you wish or leave video in copy mode, set marker A where you would like the video to start, set marker B where it should end. Now save the video (Ctrl+S) and you're done.
Thanks! lol, I just stumbled on to that.
BTW, the seek error with the steps you've given me is reproducible with almost all videos I tried. Thank you, will investigate deeper.
Thank YOU! I love this software!
It seems the fatal seek error was related to the way how we clean up the gap between the zero point and the first frame after delete if the marker A was at the first frame: The start time of the first video segment was not set to zero, leaving us with an improper segment layout.
The patch (https://github.com/mean00/avidemux2/commit/bca395b22c4b295487118032c439759477c18790) doesn't prevent seek errors after delete completely, so the previous patch is still needed.
Is this logic possible?
When copy mode
- if no keyframe on (selected) [ A] or begin of video
-- set 1st upcoming keyframe if begin of video
-- set 1st previous keyframe if set [ A], if none, set 1st upcoming keyframe
If no copy mode, this is no issue, my understanding.
This has nothing to do with transcoding vs. copy mode. When deleting a chunk of video, we have a function which performs cleanup: removes empty (zero-duration) segments. This function also deletes very short segments with a non-zero duration but no video frames from the start of a reference video to its first frame. This is all fine, except if this tiny segment is the first one. It got purged, but the linear start time of the following segment was not adjusted afterwards.
This way we got a video with a non-zero linear start time. In the subsequent delete action, this start time got finally adjusted to zero, but not the duration of following segments, resulting in segments boundaries being shifted to the left and thus not matching video frames they had been at anymore. This broke seeking which in turn could lead to a crash in samePicture().
The solution was to swap the order of purging empty segments and recalculating their start points: now instead of "adjust first, then purge" we purge first, then adjust.
Obviously, this results in a comparably harmless seek error in the first delete action if the marker A was at the first frame with a non-zero PTS. The error could only be avoided by seeking to zero instead of to A, never deleting the first empty segment or adjusting the start time in reference and duration of the second segment.