"2.7.5 r191130_win32" crash on drag-drop: bug or not?

[hiro]

Hi,

"avidemux_2.7.5 r191130_win32.exe (Nov 30 2019 7:18 AM)" quick test:

Bug or not? Sorry: I have no ADM log, neither a video sample to submit / been testing at a friend's & ran short of time.*

Anyway, that nightly crashed repeatedly, on Win. XP 32, when dropping an FFmpeg remuxed .mp4 vid onto it (perfectly functional, tested OK using "VLC, PotPlayer" + other ADM versions) — though accepting ADM 2.7.4 recoded vids...

* Back home: ADM 2.7.5 on Win. 10 64: no crash on similar but not on same exact vids.


.

[eumagga0x2a]

It is impossible to assess the issue with the information available. Can you get hold of the file which triggered the crashes?

* Back home: ADM 2.7.5 on Win. 10 64: no crash on similar but not on same exact vids.

At the moment, the latest official VC++ nightly is from Dec 21 2:43 PM, it is also a "2.7.5". I mean, 2.7.5 as version info alone is not very specific.

The general rule is always to test with the latest build and if it fails in some way to compare the results with the last release to check whether the problem was introduced by recent code changes.

[hiro]

Thanks for the answer. No, can't be retrieved / I called the friends but the (heavy) file had already been recoded — on Win. 10 —, + deleted.

Well, never mind, I guess, as I was not able to reproduce the issue on my Win. XP PC. We'll just wait for the next 32-bit release — and TRY to avoid testing in a rush!..

[eumagga0x2a]

No, can't be retrieved / I called the friends but the (heavy) file had already been recoded — on Win. 10 —, + deleted.

That's a pity. Just preserving the admlog.txt from the crash might have given a clue about the nature of the problem.

We'll just wait for the next 32-bit release

Waiting for a release is the best recipe for keeping the bugs safe.

https://avidemux.org/nightly/win32/

The last nightly is from yesterday, Dec 23 2019. Please help to squish bugs and keep testing nightlies.

(Nevertheless, it would make a lot of sense to ditch Windows XP and move to 64 bits hardware and software.)

[hiro]

While testing "avidemux_2.7.5 r191223_win32" / no problem so far:


About ditching Win. XP, + BTW "As of Sept. 2019, 1.54% of Windows PCs run Windows XP. (Google)",

well, of course — except for (amateur but) "mass reencoding", as friends + I can't always afford buying additional PCs;

in that case, we often let 2 to 4 of those antediluvian "boxes" grind overnight (or worse) [ though I haven't calculated "electricity bill vs. purchasing new / faster equipment" costs, "yet"?.. ].

[eumagga0x2a]

While testing "avidemux_2.7.5 r191223_win32" / no problem so far:

While running on Windows XP? It should be easily possible to crash it by enabling DXVA2 video output and loading any video :-D

[hiro]

There must be some kind of "bug~in~your~crash~test~advice"...

See? I finally found one!:

so, here we go: (on Win. XP SP2) after activating DXVA2 and trying to drop several types of vids. onto this new ADM, not only they display perfectly, moreover, they (also) happen to PLAY... like a breeze.

[eumagga0x2a]

Did you restart Avidemux after enabling DXVA2? (Did you enable also hw accelerated decoding?)

I'd be curious to see admlog.txt from such a session.

[hiro]

Yes, I did restart Avidemux after setting it to "DXVA2" – several times (several tests).

"hw accelerated decoding"? Do you mean "Video display: DXVA2 (best)"? If so, yes.

+ "HW Accel": tried about every option...

See attached screenshot(s) – and "admlog.txt".

[eumagga0x2a]

Thank you, indeed, dxva2.dll is not found and thus checks which I suspected might crash Avidemux skipped = no crash.

Code Select Expand

[indexify] 14:36:28-796 Build Track index, track timescale: 24000
[indexify] 14:36:28-796 Histogram map has 3 elements.
Frame duration 1000 count: 240
Frame duration 1001 count: 241
Frame duration 1002 count: 239
[indexify] 14:36:28-796 Checking whether we need to fix jitter from rounding errors...
[indexify] 14:36:28-796 Yes, enforcing CFR, frame duration 1001 ticks.
[indexify] 14:36:28-796 Video index done.
[indexify] 14:36:28-796 Setting video timebase to 1001 / 24000

Glad to see this. We correctly identify timestamp jitter caused by an earlier Avidemux version and fix it. When saved in copy mode or re-encoded, the resulting video will have a constant frame rate again.

[hiro]

Yep, I sure am a "CFR (oldschool?) aficionado" in all cases!

I've read about "VFR benefits" – which never convinced me, knowing the trouble I went thru, due to ("smart"phones) "VFR" vids...

... that I'd rather keep away from when possible / or convert at once! But that was a few years ago, OK.

__________

Now, about:

"Cannot load dxva2.dll
This binary has no DXVA2 support ("what~a~shame!")
DXVA2 not available",

I mean... should I "worry"? I might not know "what I'm missing", but I guess I won't fuss, as everything's working fine (so~far).

[eumagga0x2a]

Yep, I sure am a "CFR (oldschool?) aficionado" in all cases!

This has nothing to do with personal preferences, just with correcting my own errors. I made changes in Avidemux code which solved the problem of frequent failures to save a video due to timestamp collisions but at the same time exposed an older bug which resulted in incorrect rounding of timestamps. Now both the old bug as well as my error are fixed (effective especially for mp4 as source and as target format) by disentangling frame rate (fps) from time base which is an assumption that all timestamps in the video can be represented as a multiple of "number of clock ticks" divided by "clock frequency" (number of clock ticks per second), in this case 1001/24000.

By passing this fraction all the way down to muxer, Avidemux ensures now that the saved file will get the same (or a compatible) time base and also retain the CFR property of the source.

I've read about "VFR benefits" – which never convinced me, knowing the trouble I went thru, due to ("smart"phones) "VFR" vids...

Again, this is not about benefits or drawbacks. As you noticed, most (all?) smartphones (Android ones much more than iPhones, but iPhones as well) record variable frame rate mp4 videos. Our task is to preserve original timestamps (actually, the durations of each frame, so that a different start offset doesn't hurt) as good as possible which is essential for A/V sync, not to falsify them by forcing a fake CFR.

Now, about:

"Cannot load dxva2.dll
This binary has no DXVA2 support ("what~a~shame!")
DXVA2 not available",

I mean... should I "worry"?

No, not at all. DirectX hardware accelerated video decoding was introduced only in later Windows versions (Vista?).