Wrongly halved framerate, ac3 audio unusable after a channel number switch

[eumagga0x2a]

This turns out to be a QT "gtk" theme issue with the current value for ADM_LARGE_SCALE in Q_qui2.cpp:47. Halving the value is already sufficient to avoid the problem on my system, further reduction provides a security margin. Alternatively, forcing another QT theme e.g. via

Code Select Expand

export QT_STYLE_OVERRIDE=breeze

or

Code Select Expand

export QT_STYLE_OVERRIDE=fusion

in the console prior to running avidemux3_qt5 helps as well. This said, it could be possible to reproduce the issue on KDE when launching Avidemux with

Code Select Expand

QT_STYLE_OVERRIDE=gtk avidemux3_qt5

Oddly enough, setting refreshCapEnabled to true and refreshCapValue to any value in the allowed range seems to have no effect at all.

[Jan Gruuthuse]

@Jan:

Could you please test if the slow video / progressive desync issue with short videos  (from 2 to 4 minutes long) and maximized Avidemux window in foreground is reproducible with Unity?

I'll test later on Xfce.

(Now imagining a mplayer-style warning: "Your system is too slow to render this navigation slider!"  )

You could be on to something. I never noticed the issue: I never use avidemux as player. Just editing.
To understand clearly:
In avidemux playing any video (screensize / codec) after playing 5 minutes audio is delayed: AC3 only?
Display:
- VDPAU
- X11
- OpenGL
- Libva

with avidemux using full Full screen? 4K display 3840 x 2160 here.

[Jan Gruuthuse]

Last minute countdown counter becomes redish
all tracks should at least play 5 minutes
1st track AC3 5.1
2nd track AC3 stereo
3rd track MP3 stereo
4th track MP2 stereo

Files (85.5 MB total) Avidemux5MinuteSyncTest.mkv
Will be deleted on 9 September, 2016

[eumagga0x2a]

Thank you very much for your testing.

You could be on to something.

Not really as the nature of the issue has been identified already. The problem is related to the Qt theme in use quite like http://avidemux.org/smif/index.php/topic,16742.msg75823.html. The workaround (or a solution, depends on your point of view) is to reduce the value for https://github.com/mean00/avidemux2/blob/master/avidemux/qt4/ADM_userInterfaces/ADM_gui/Q_gui2.cpp#L47. It was already lowered once to avoid Avidemux being rendered completely unusable by the "adwaita-qt" Qt theme.

I never noticed the issue: I never use avidemux as player. Just editing.

Me too (simply looking at the system load caused by Avidemux is enough to abstain from using it purely as a video player), but footages of classical music performances are often poorly synchronised and Avidemux usually provides an easy way to counteract this pre-existing A-V offset. I use Avidemux as player to identify the proper value for the audio delay. For this purpose Avidemux may not introduce its own A-V desync, obviously

To understand clearly:
In avidemux playing any video (screensize / codec)

Yes...

after playing 5 minutes

No, it starts to desync immediately, but the effect must accumulate a bit to become clear (usually 10 seconds are enough depending on the footage). The video must be short to make steps the position slider has to accomplish reflecting the playback status bigger.

audio is delayed

No, video gets delayed.

AC3 only?

No, the audio codec similar to the video codec doesn't matter at all.

Display:
- VDPAU
- X11
- OpenGL
- Libva

Doesn't matter, but the video driver (nvidia|nouveau|intel|radeon|amdgpu) may play a role (though unlikely).

with avidemux using full Full screen? 4K display 3840 x 2160 here.

Bigger Avidemux window makes a longer navigation toolbar makes bigger steps for the slider makes it easier to reproduce the issue.

[Jan Gruuthuse]

tested with commit f4272d2
- X11
- XVideo
- VDPAU
- OpenGL
no video had any noticeable delay when testing with AC3 5.1 or AC3 Stereo during the 5 minute playback on fullscreen with ubuntu 14.04.5 lts amd64 on somewhat aged system:
Hardware:

Processor: Intel Core i7-3770K @ 3.90GHz (8 Cores), Motherboard: ASRock Z77 Extreme3, Chipset: Intel Xeon E3-1200 v2/3rd, Memory: 32768MB, Disk: 2 x 1000GB Western Digital WD1002FAEX-0 + 2 x 4001GB Western Digital WD4003FZEX-0, Graphics: ASUS NVIDIA GeForce GTX 960 2048MB (1417/3600MHz), Audio: Intel 7 /C210, Network: Realtek RTL8111/8168/8411

Software:

OS: Ubuntu 14.04, Kernel: 3.19.0-68-generic (x86_64), Desktop: Unity 7.2.6, Display Server: X Server 1.15.1, Display Driver: NVIDIA 352.99, OpenGL: 4.3.0, Compiler: GCC 4.8.4 + CUDA 7.5, File-System: ext4, Screen Resolution: 4920x2160

[eumagga0x2a]

no video had any noticeable delay when testing with AC3 5.1 or AC3 Stereo during the 5 minute playback on fullscreen with ubuntu 14.04.5

Was it a Qt4 build then? I referred only to Qt5 builds in this topic and didn't test with Qt4 builds at all, so I don't know whether you might expect to see the issue there.

On the other hand, 5 minutes duration is too long to make the issue appear even on my system which is 25% as powerful as yours at best. You could try if a shorter video (no need to generate a new sample, just delete temporarily a section of the video in Avidemux) of max. 2 minutes duration would allow to reproduce the problem, but I guess your hardware is just too ridiculously fast

(fixed some grammar)

[Jan Gruuthuse]

Was it a Qt4 build then? I referred only to Qt5 builds in this topic and didn't test with Qt4 builds at all, so I don't know whether you might expect to see the issue there.

1st time QT5 is mentioned in this thread 

Will do some test on QT5 tomorrow ...

[eumagga0x2a]

1st time QT5 is mentioned in this thread 

Why should it? Qt5 is the default. It is Qt4 which should be specifically outlined. I still expect both behave the same in this case when using the same Qt "gtk" style.

Anyway, the workaround for those with modest hardware is cheap and straightforward and I am unable to contribute to a more efficient slider implementation.

[Jan Gruuthuse]

On our YouTube channel Avidemux Demo you can find Audio Sync Delay Test 10 seconds amongst some more durations 20,30 seconds, 1,2,3,4 and 5 minutes.

[eumagga0x2a]

Thanks, are these countdown videos with AV perfectly in sync really screencasts? It would have been helpful to see at least parts of Avidemux GUI too, especially the navigation toolbar.

(The issue affects only playback, not saving.)

[Jan Gruuthuse]

Done test with sync delay video. And could not notice a delay on ubuntu 16.04.1 amd64 unity desktop with QT5

Thanks, are these countdown videos with AV perfectly in sync really screencasts? It would have been helpful to see at least parts of Avidemux GUI too, especially the navigation toolbar.

(The issue affects only playback, not saving.)

No the videos are not a desktop recording of avidemux playing the test video. If I under stood your question correctly.
I will try to make such a desktop recording, but my system is most likely not powerful enough doing so at 25 fps in full 4K screen. I did run in recording issues before.

[eumagga0x2a]

Done test with sync delay video. And could not notice a delay on ubuntu 16.04.1 amd64 unity desktop with QT5

Thank you, then your system is fast enough to cope with the high graphical load caused by the navigation slider with the QT5 "gtk" theme.

Thanks, are these countdown videos with AV perfectly in sync really screencasts? It would have been helpful to see at least parts of Avidemux GUI too, especially the navigation toolbar.

(The issue affects only playback, not saving.)

No the videos are not a desktop recording of avidemux playing the test video. If I under stood your question correctly.

I see that you expected a progressive desync while in playback mode (if it happens) to be present also in the results of Avidemux remuxing or reencoding the source video. No, the issue affects only the playback, never saving. Comparing saved videos was useless. In case you could reproduce the issue despite having such a beast of a PC, just filming the screen with a camera while Avidemux plays a sample would deliver a proof, if you would want to deliver a perfect proof (which I don't actually need).

I will try to make such a desktop recording, but my system is most likely not powerful enough doing so at 25 fps in full 4K screen. I did run in recording issues before.

I really think it was sufficient that you looked at the screen and reported what you saw, if I managed to explain you the issue clear enough, of course.

[Jan Gruuthuse]

Anyway the desktop recordings went OK (previous recording issue seems solved)
Test 4K: X11, XVideo, OpenGL, VDPAU, VDPAU Hardware-accelerated, LibVA and LibVA Hardware-accelerated.

Avidemux v2.6.13 (160904_ 09b745b6d9b) File: Audio Sync Delay Test 30 seconds

On our YouTube channel: Avidemux Demo the videos of the tests:
X11
XVideo
OpenGL
VDPAU
VDPAU Hardware-accelerated
LibVA
LibVA Hardware-accelerated

Hardware:
Processor: Intel Core i7-3770K @ 3.90GHz (8 Cores), Motherboard: ASRock Z77 Extreme3, Chipset: Intel Xeon E3-1200 v2/3rd, Memory: 32768MB, Disk: 2 x 1000GB Western Digital WD1002FAEX-0 + 2 x 4001GB Western Digital WD4003FZEX-0, Graphics: ASUS NVIDIA GeForce GTX 960 2048MB (1012/3600MHz), Audio: Realtek ALC892, Network: Realtek RTL8111/8168/8411

Software:
OS: Ubuntu 16.04, Kernel: 4.4.0-36-generic (x86_64), Desktop: Unity 7.4.0, Display Server: X Server 1.18.3, Display Driver: NVIDIA 361.42, Compiler: GCC 5.4.0 20160609 + CUDA 7.5, File-System: ext4, Screen Resolution: 4920x2160

ps.:

Comparing saved videos was useless

those video files are for testing purpose, the test is done in videos in this post.

[eumagga0x2a]

It is not the "gtk" Qt theme in the recording (it is probably the "fusion" one), the issue doesn't affect fusion and breeze. You should see a different appearance of Qt widgets if you launch Avidemux with

Code Select Expand

export QT_STYLE_OVERRIDE=gtk
avidemux3_qt5

Again, video output drivers and decoders don't matter alltogether, you burden yourself with a lot of work which is unrelated to the topic.

[eumagga0x2a]

I'm really sorry for not having tested with one of your AV sync test YouTube videos earlier, but I can't reproduce the issue already with the very first one I tried: https://www.youtube.com/watch?v=8aGeizQcaoA. The most probable reason is 25 fps in the YouTube sample vs. 50 fps in the arte HD one.