Seeking with a certain video file freezes PC

[Bearbear]

After 20 secs or so of seeking with a particular video file, avidemux gets slower and slower until it or my PC hangs, forcing me to reboot. Could it be some kind of memory leak?

I've also tried using Virtualdub2 to edit and I can seek fine within that program without it crashing, however it won't let me use a direct copy of the audio to export, which could mean there's a problem with the audio perhaps?

Here's a small sample of the problematic video in question that I've managed to cut using LosslessCut (a ffmpeg GUI), the only program I've found that can do it so far:

https://we.tl/t-AYPGamXHXe 3MB (link expires in 7 days but can reupload if needed)

admlog: You cannot view this attachment.

[Bearbear]

Short video of the crash https://streamable.com/4637w4

All I'm doing here is clicking and dragging the seeker on the seek bar left and right, the seeker gets less and less responsive until it crashes

Here's the MediaInfo on the file https://paste.ee/p/xn7Od

[eumagga0x2a]

The bug is that Avidemux tries to load a file with a video track exceeding max supported size which is 4096 px width or height. It should have refused to open it.

As the last line of defence, fixed in editor by [editor] Reject video with width or height exceeding maximum supported, but it is worth being caught already at the stage of demuxer.

Thank you very much for your report.

[Bearbear]

I've edited files that exceed frame dimensions greater than 4096px before, and as a test right now, I've opened a file that is 6144px X 3072px and can seek through it fine without it hard crashing my PC. So the issue isn't with resolution, I'm almost positive it's something to do with the file itself or how it's encoded.

Did you take a look at the video sample I uploaded?

In fact, I'd actually prefer it if you didn't implement your last code change to reject videos that exceed the max supported since I often downscale large videos.

[eumagga0x2a]

I've edited files that exceed frame dimensions greater than 4096px before

This should never happen, lack of bounds checking is a horrible bug which you thankfully reported.

Did you take a look at the video sample I uploaded?

Allocation of hardware surfaces, needed for hardware-accelerated decoding of the video stream, fails at this resolution.

In fact, I'd actually prefer it if you didn't implement your last code change to reject videos that exceed the max supported since I often downscale large videos.

No way :-) A lot of things like fixed-size buffer allocation which rely on dimensions being within bounds may fail in an unpredictable way, cause memory corruption and system crashes (no idea whether this could be easily expoited for nefarious purposes). Upper bounds may be increased after all parts of the chain have been checked for being able to deal with larger sizes.

[Bearbear]

From further testing, it is indeed DXVA2 hardware-accelerated decoding that is causing that hard crash. Turning off that option enables me to freely seek the problematic files without crashing.

I have noticed that it's only certain files that causes this, a 6144 x 3072 px file (MediaInfo) with HW accel on doesn't crash when seeking, however a different 5760 x 2880 px (MediaInfo) file crashes. So it's the combination of when the Video Decoder says it's using Lavcodec DXVA2 and DXVA2 HW accel is enabled, is when it crashes.

No way :-)

I guess I'll have to keep this current version of Avidemux installed then since I often have to downscale.

[eumagga0x2a]

You can always compile your personal Avidemux build with the value of MAXIMUM_SIZE at https://github.com/mean00/avidemux2/blob/master/avidemux_core/ADM_core/include/ADM_inttype.h#L19 set to whatever suits your needs best (or I can provide a private MinGW build). It is just something which would not be okay to conciously distribute.

The file which you say doesn't crash is a HEVC encoded video. All the others are H.264.

The screenshot indicates that the software decoder (Lavcodec) with DirectX hardware-accelerated video output ("DXVA2") are active.

I'm currently working on unrelated issues / features. Will look into our options here when I have time.

[Bearbear]

So the issue is H.264 files with a resolution greater than 4096px and using HW accel decoding, which makes sense since the H.264 spec technically shouldn't support it, but H.265 does (max of 8192 × 4320 px).

You can always compile your personal Avidemux build with the value of MAXIMUM_SIZE at https://github.com/mean00/avidemux2/blob/master/avidemux_core/ADM_core/include/ADM_inttype.h#L19 set to whatever suits your needs best (or I can provide a private MinGW build). It is just something which would not be okay to conciously distribute.

I don't have the means to compile nor know where to even begin, but your offer is hugely generous and I'm very appreciative of that. I'm OK with just sticking with the current build, I've not run into any other bugs that I know of and I can just disable HW accel decoding whenever the need arises.

If all else fails, I'll come and politely ask for a private build.

Thanks for the help!

[eumagga0x2a]

I would like to apologize for my nonsense about surface allocation failing. To the contrary, it succeeds, but creation of the decoder indeed fails.

So the issue is H.264 files with a resolution greater than 4096px and using HW accel decoding, which makes sense since the H.264 spec technically shouldn't support it, but H.265 does (max of 8192 × 4320 px).

I may be easily wrong here, but the latest H.264 spec from June 2019 says that the maximum size of a frame in macroblocks for the highest possible level 6.2 is 139264 which is enough for 8192x4320 px = 138240 macroblocks (but of course not for 8192x8192). It might be rather a limitation of a particular hardware to meet a specific cost target or a limitation within the graphics driver.

We should probably define limits not presumpting a square picture, but this would make problems in video filters where we can't have dynamic limits.

You can always compile your personal Avidemux build with the value of MAXIMUM_SIZE at https://github.com/mean00/avidemux2/blob/master/avidemux_core/ADM_core/include/ADM_inttype.h#L19 set to whatever suits your needs best

I don't have the means to compile nor know where to even begin

It is actually quite easy if you have some experience with Linux, see https://github.com/mean00/avidemux2/blob/master/cross-compiling.txt

[eumagga0x2a]

You might want to try the latest nightly, it has the maximum width and height bumped to 8192 (will be probably reverted later) with some safeguards added, including the one which probes DXVA2 size limits prior to asking it to decode a frame.

[Bearbear]

You might want to try the latest nightly, it has the maximum width and height bumped to 8192 (will be probably reverted later) with some safeguards added, including the one which probes DXVA2 size limits prior to asking it to decode a frame.

Sorry I've taken so long to reply, I never got any notification but thank you for the update, I really appreciate it.