Strange File Handling

[Cormy1]

I'm not sure how to describe this so here's the video file: https://we.tl/t-PcpMHeMy7H
It plays fine in MPC-BE/VLC/MPC-HC
But Avidemux seems to struggle greatly with this file, playback is messed.

[eumagga0x2a]

Apart from the video stream using full color range instead of the usual MPEG one (which means that Avidemux decodes it at least on Linux in software instead of via VDPAU in hardware) and mpv complaining about keyframe flag set for frames which are not keyframes, a current Avidemux build for Linux doesn't exhibit any difficulty handling this sample. I'll retest on Windows later.

Did you experience problems with this sample with the latest build for Windows from Aug. 30?

[Urik]

But Avidemux seems to struggle greatly with this file, playback is messed.

Try OpenGL (1) , (2). It plays fine on it for me (OpenGL is my usual setting with Avidemux + Nvidia config).
Your file plays fine for me with these settings; however, with DXVA display, playhead / interface is freezing up. Software playback works fine with the file too. I use latest August 30th nightly (non vs)

Apart from the video stream using full color range instead of the usual MPEG one

(offtopic / unrelated to avidemux)

That's interesting. I even went and tested myself.

I don't know why, but now my OBS also records (or tags) files as full range. To be clear, these are OBS recordings using Nvidia (nvenc) encoder, just like OP's file.
I have similar but older OBS files from a couple months back and they were limited

Code Select Expand

Color range                : Limited
Color primaries            : BT.709
Transfer characteristics    : BT.709
Matrix coefficients        : BT.470 System B/G

The new files are

Code Select Expand

Color range                : Full
Color primaries            : BT.709
Transfer characteristics    : BT.709
Matrix coefficients        : BT.709

I don't use OBS that often (I primarily use Nvidia Shadowplay instead), so don't know what happened there... Didn't update it since then, the version still the same as it's been, settings are the same.
Maybe the drivers changed, though I don't remember updating them within the timeframe.

I've long experience with Nvidia Shadowplay, and it itself records files with BT.601 colors / BT.470 matrix. Always did. Weird, I know. No current HD equipment/software I know of records with that space (and not supposed to). I always thought it's just how Nvidia's Shadowplay / Experience software is programmed, and they never cared to fix it.

In a recent development, something's been updated within Youtube, and now it can't interpret those Shadowplay files properly anymore and processed videos get gamma shifted down (become darker). Rewrapping stream copy doesn't help, only re-encode. People been having problem with it for over a month now.

[eumagga0x2a]

Avidemux exhibits zero issues handling this sample on my Windows 10 installation with DXVA2 enabled both for decoding and display (Intel). No freezes, smooth playback using hardware decoder.

I'll try on Windows 7 with Nvidia later.

[eumagga0x2a]

It looks like using an external renderer like DXVA2 on Windows results in a different window refresh strategy by Qt which in turn looks like a jerky, irregular advancing of the navigation slider during playback when frame rate of the video is that high (60 fps). With an internal renderer (Qt, QtGl), the window is refreshed each frame, which increases load but looks good.

It might be interesting to compare with a VC++ Avidemux build as they use a much older Qt version.

The handling of the file and the playback as such is absolutely fine on Windows 7 with an Nvidia graphics card, with hardware accelerated decoding and display working despite full color range.

So said, the only real issue is on Linux with VDPAU (and maybe with other HW accel. interfaces not yet tested), but we probably can't do anything about it.

[Cormy1]

I don't know why, but now my OBS also records (or tags) files as full range. To be clear, these are OBS recordings using Nvidia (nvenc) encoder, just like OP's file.

This is exactly right. I had no reason to record in 60fps, I just kind of left it like that, but this is an OBS recording of a Netflix video being played in Mozilla Firefox 60.9ESR (64bit)

I had been on build 200813
DXVA2 was being used, Win8.1 (far behind on updates, my Windows Update is very broken)

However if there's really nothing wrong, I guess I'm just being thrown off by Avidemux's playback speed again. Since the video was captured at 60fps, despite the source likely being in 30 or even 24fps, and Avidemux will only play it back at 30fps, I get huge timing desyncs when it comes to the audio, which makes it impossible to edit well.
And as you say, the slider appeared jerky but I assume that's just a visual glitch while function is still fine...? Using OpenGL/QT solves that problem.

But generally speaking, I feel like I'm always having more lag in current versions of Avidemux when I play/stop my recordings.
It just feels less responsive.

Would it be better to send an Application Log? It seems you've figured it out this time but it would probably be faster just to send you a log right?

[eumagga0x2a]

I had been on build 200813

200903 is the latest one for now.

However if there's really nothing wrong, I guess I'm just being thrown off by Avidemux's playback speed again. Since the video was captured at 60fps, despite the source likely being in 30 or even 24fps, and Avidemux will only play it back at 30fps, I get huge timing desyncs when it comes to the audio, which makes it impossible to edit well.
And as you say, the slider appeared jerky but I assume that's just a visual glitch while function is still fine...?

Exactly, my 8 years old hardware, which was middle class at best in terms of performance back then, can play this sample in real time even without DXVA2 with ease. Enabling DXVA2 reduces the CPU load significantly, however.

Using OpenGL/QT solves that problem.

For me, OpenGL improves the looks, but worsens the performance. I suspect that something is wrong with graphics drivers on your system.

But generally speaking, I feel like I'm always having more lag in current versions of Avidemux when I play/stop my recordings.
It just feels less responsive.

A comparison between VC++ and MinGW builds would be interesting here (I don't observe any negative changes with my private builds). What I do see, is Avidemux window often being not refreshed on stopping playback (buttons seem to remain disabled unless I move mouse over the window). I wonder whether this should be attributed to changes in recent Qt versions. Official MinGW builds use 5.15.0, official VC++ builds a much older 5.12.0.

Would it be better to send an Application Log? It seems you've figured it out this time but it would probably be faster just to send you a log right?

Sure, please do.

[Cormy1]

Stop/Pause is slow to respond
It's just annoying more than anything.

[eumagga0x2a]

I see, indeed, it takes sometimes a few seconds(!) for keypresses or mouse clicks to register by Qt and to be passed to the application if CPU load is very high. Maybe GUI is running on the same thread as decoding and display?

The actual process of stopping playback may take up to a half of a second, but usually completes within 200 ms. This is not extremely fast but IMHO tolerable.

[eumagga0x2a]

I've got to test on Linux/Intel and GUI goes often completely unresponsive (navigation slider and time indication not advancing, it is impossible to stop playback) when playing a video with fps exactly matching the display refresh rate (60 fps in this case). Higher fps values are fine, as are lower. Color range doesn't matter.

Thank you for raising the topic, even if I don't see an easy solution ATM.