Old post removed.
Problem is copy/paste leading to a crash
Just by way of summarising the old post:
Avidemux crashes when using the fast forward/reverse keys when processing HD complex video streams.
This is observed mostly by users that run the program on the windows OS.
From a windows user perspective, the crash is a forced exit by way of an access violation.
The developer attributes a latency issue as the probable cause for this crash.
When using the linux OS, the copy/past function also triggers a crash due to this latency issue.
The copy/paste crash is also confirmed on the windows OS.
One thought:
Avidemux for windows in the repositories, is a crosscompiled product.
Natively compiling the source with MinGW, or another Toolchain, might produce tighter binaries and so benefit this issue.
A separate thread has been started to try and create a native avidemux build environment (not just for this issue, but inspired by it!).
Don't know if this is related or not?
While saving edited video, a 'free()' / pointer error showed up n terminal window, followed by avidemux 2.6.8 unexpected shut down. One of these could possible help:
1) Deleting the config2 (avidemux 2.6.8 settings file)
2) Rebuilding avidemux after kernel update (linux) (or a possible big windows update)
Or combination of the 2 that solved the issue.
Sorry have no log or documentation of these events.
As for now, I just notice these are not occurring, for now.
If not related at all, just let me know, I edit this posting.
The underlying issue that causes this crash seems to be mentioned in the recent patch section discussions about HEVC encoding.
The response from Mean:
What i've seen is some corner cases errors in the timing computation
That ends up requesting a frame at a time that does not exist => assert => crash
I am just curious if Windows OS is less able to deal with access violations than Linux OS.
Hi everyone
Developers or helper users still working on that problem?
If yes then: How is going the forward/backward problem resolution? good results? I wonder yes.
There is any beta that I could test for Windows about this?, in the Avidemux sourceforge there is always the same v2.6.8 stable version... it is planning to update a the sourceforge pckages for endusers?
There is something that I could do about the backward/forward problem for you?
Thanks for read
Unless Mean tell you otherwise!
AFAIK nobody is working to specifically resolve this mostly windows issue.
It has been implied on a few occasions that this is a "corner case" issue.
Meaning an issue that presents only when you operationally push the program/hardware to extremes.
To maybe get a better idea of the where, how and why, look at building a debug version and run it through a native debugger.
Use the nightlies for the latest beta releases, as the sourceforce versions are merely milestone installer snapshots of these nighlies.
Pick latest from win32 or win64: http://www.avidemux.org/nightly/
Thankyou guys.
I totally dissapoint about the reason/decission:
QuoteMeaning an issue that presents only when you operationally push the program/hardware to extremes.
I could understand whether an investigation or a fix will be discarded in case of "
an issue that presents only when you operationally push the program/hardware to extremes",
but in my oppinion is not like that, it is AviDemux who is causing the hardware to extrem then crash, is not the hardware itself just for doing a simple and basic backward/forward operation :(
I wonder that it can be re-considered in the future to try solve this, thanks for all your work done in this, everyone.
Avidemux: Reporting bugs (http://www.avidemux.org/admWiki/doku.php?id=general:bugtracker)
GNU Debugger for Windows (gdb) (http://www.equation.com/servlet/equation.cmd?fa=gdb)
merry xmas
@ Jan, I didn't know about that gdb port. Interesting!
@ pitoloko, only the concept of FFW is simple.
Program Extreme = non linear resolving of HD fancy coded AVC frames very quickly.
OS Level = Differences in exception handling.
Hardware Level = Processing Capability.
Corner Case = Dependent on all of the above.
To think of it as just a coding bug is over simplifying the issue.
But like you I hope to see a fix - maybe the code can somehow be tweaked, maybe a new OS is better behaved, maybe PC processing power will overcome, maybe its a simple bug fix, or maybe the machine code produced is just not efficient enough ? ? ? ? ?