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

[eumagga0x2a]

Thank you. It turns out to be that deleting just about 4 GOPs around the offending spot allows Avidemux to generate a mkv with full uninterrupted ac3 track despite # of channels switch.

[eumagga0x2a]

Actually both claims in the subject "Wrongly halved framerate, ac3 audio unusable after a channel number switch" of this topic proved to by bloody wrong. The halving of FPS has nothing to do with slow video playback and AV async and channel # switch has probably nothing to do with cut off ac3 track 

Adjusting the subject for this post.

[mean]

The other probblem is that it switches, the audio goes back in time causing an error
That could be fixed i think

[mean]

Should be ok now

[eumagga0x2a]

Confirming that the issue of the ac3 track being cut off due to timestamp jump is fixed by [audioCore] try to ignore packets that are out of range Dts wise. Merci mille fois !

Do you think it could be worth your effort if you look into video playback speed in Avidemux / async with relatively short TS streams as well?

Sorry for the mess I've made out of this topic mixing unrelated issues together.

[mean]

Could be :
* CPU maxxed out
* Audio clock drifting

[eumagga0x2a]

Thank you, top shows each core between 30% and 40% idle when playing the testcase (by the way, Xorg causes even higher CPU load as the avidemux3_qt5 process when playing a 720p video in Avidemux), so CPU is probably not an issue. Audio is played at correct pace. The problem emerges only with sufficiently short streams, in my testing below 400 MiB in size and 5 minutes in duration. Avidemux plays the original, uncut version of the very same stream with video in sync when the total length of the stream is higher.

[mean]

If it resyncs after you seek, the audio clock drifting could be it
The sync is done on video, it is assumed the audio is correct

If the error is small, you'd need to wait a while for it to accumlate

Or it could be a bug

[eumagga0x2a]

If it resyncs after you seek, the audio clock drifting could be it

Yes, it definitely resyncs on seek, then drifts quickly apart when playing, with video running approx. 10% slower than the audio (but it again depends somewhat on the length of the sample, shorter samples resulting in slower video) in the case of the sample provided by Jan in http://avidemux.org/smif/index.php/topic,17079.msg76631.html#msg76631.

Or it could be a bug

I wouldn't doubt it 

[mean]

It's not obviously desync'ed for me

[eumagga0x2a]

Something strange is going on. Just discovered that...

• If I let Avidemux play the sample offscreen on another virtual desktop, there is no desync when I return back to it, but it develops quickly when Avidemux plays on the current virtual desktop and the video is rendered to the screen.
• If I let Avidemux play in foreground on the current virtual desktop but hide the navigation toolbar, there is no desync too.

The way the position slider gets rendered must induce some bad interactions with gnome-shell, compositing, Xorg etc. This explains also why short samples exhibit the problem while long do not: the jerky slider trembles with higher amplitude if a sample has less frames. In a long sample the updates for the slider happen not so often.

tl;dr:
The "slow motion" problem with short samples seems to be a performance issue related to the way the position of the slider in the navigation toolbar is updated and how the slider is rendered.

[mean]

Could be
I'm using KDE, and i did not spot any issue

Qt & Gnome/unity do not always play nicely together

[eumagga0x2a]

Sure, but it looks like refactoring of the slider code could bring a substantial benefit for the performance (maybe it would be better to continue in http://avidemux.org/smif/index.php/topic,17060.0.html).

[Jan Gruuthuse]

- avidemux uses minimal 2 threads, you can't set it lower in preferences. 2 core cpu without HT hits the bottleneck if the OS is trying to do something.
- moving slider involves big data transfer: 720p video on average 6.2 GB for 1 hour of recording.
performance decreases by older hardware
- Sata I = up to 150MB/s / II = up to 300MB/s / III up to 600MB/s
- Hard disk = Mechanical drive usually top out no faster than 180MB/s at the very fastest
   5,400 RPM HDD  75 MB/s
   7,200 RPM HDD 100 MB/s
  10,000 RPM HDD 140 MB/s- USB 2.0 in practice you'll never get above 40MB/s
- USB 2.0 in practice you'll never get above 40MB/s
  USB 2.0 flash drives: 33MB/s reads and 15MB/s writes out of most USB 2.0 flash drives.
- available memory
- ...

used sources:
Difference between SATA I, SATA II and SATA III
Adam Savage's tested

[eumagga0x2a]

I'm using KDE, and i did not spot any issue

I can't reproduce the issue on Plasma either, despite Xorg load being very high when playing even a very small video in Avidemux 

With gnome-shell, a bigger size of Avidemux window (making the navigation toolbar longer) makes the issue much worse, while video resolution and size of the video surface almost doesn't matter.

The issue is completely unrelated to disk I/O as short, low resolution videos using computationally cheap codecs like Xvid only a couple of megabytes in size are sufficient to trigger the issue on a moderately powerful desktop PC running GNOME with gnome-shell.

@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!"  )