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

[mean]

The beginning & the end are not obviously different

[Jan Gruuthuse]

Looks like playing in sync here. when you have the audio settings like in the screenshot. Save the audio, you should get an AC3 audio file, drag and drop that in audacity:

File (4.76 MB total) AC3usedFootage
Will be deleted on 6 September, 2016
Download link https://we.tl/09nDBfKWzL

The video as such is damaged at begin due to dd skip 1.2 GB and saving 127 MB after that point
Don't make your observations with avidemux as player !!!!

You should get this after drag and drop into audacity of above ac3 avidemux saved audio, confirming all audio channels are present.

[eumagga0x2a]

On my system, when played in Avidemux with the ac3 track active and set as the first track, the audio meter shows two channels (the very first and the very last) pulsing at the beginning. Starting with the beginning of the concert, only the indicator for the first channel is moving. Is it different on your system?

I use AlsaDefault as audio output device and "No downmixing". I have only stereo speakers, no surround.

[Jan Gruuthuse]

Preferences: [Audio]
Local playback downmixing [No Downmixing] try Pro Logic or Pro Logic II here
AudioDevice: Pulse AudioS

Pro Logic:

[eumagga0x2a]

Looks like playing in sync here.

Are you sure? The video plays sort of at a half speed on my system with your (and my) sample, audio plays at the right speed, no matter which track.

when you have the audio settings like in the screenshot.

The screenshot is from Audacity, how is it related? I don't doubt that the audio contains 6 channels, but Avidemux plays just the first one past the layout switch.

The video as such is damaged at begin due to dd skip 1.2 GB and saving 127 MB after that point

This should not matter at all. TS streams may start and end at any point. A player should be able to find the first usable key frame and ignore the damaged part prior to that. Avidemux seems to accomplish this just fine.

Don't make your observations with avidemux as player !!!!

I don't agree. Avidemux is not a dedicated video player, sure, but the wrong framerate in this case could be avoidable. At least ffplay, which is also not a real dedicated video player (yet), gets it right. Avidemux should be basically usable as a player to decide on cut points and AV offset (and it is in most cases).

reacting audio meters
1 1st moves
2 not reacting
3 3rd moveds
4 not reacting
5 not reacting
6 not reacting

At which position of the stream? Still, it definitely doesn't match my experience at any position. Starting with the jingle at 16.413 only the first one moves.

PS: Yes, downmixing helps, and masks the place where the channel layout switches.

[Jan Gruuthuse]

Me bad, was stereo track and sound is really muffled (center track perhaps?)
with prologic or prologicII it should be beter.

You could be having issues with Dual Core and 720p and decoding AC3?
I'm on 4 core intel (core I7), video decoding with GTX 960 vdpau?

try muxing with avidemux into mkv put on USB stick and play that on flatscreen tv, if it plays media or from Blue-ray or DVD player or sat receiver.
If that plays fine on one of those devices, your hitting a bottleneck somewhere on the computer

ProLogicII:

[Jan Gruuthuse]

Jingle in prologic see the increased peek.
Try playing with zoom 1:4 (numeric keypad)

[Jan Gruuthuse]

AlsaDefault Or PulseAudioS doe not make any difference.

Local playback downmixing with either Stereo, Pro Logic or Pro Logic II

If you look at the audacity screen shot (that is the full length of that audio track) you don't see a switch occurring.
1st & 2nd = left and right.
3rd track = center
4th track = subwoofer
5th track = surround
6th track = surround

[mean]

The other option is that the PMT mapping is changing
i.e. it starts with audio track PID=400
and later on  it is mapped to PID=403

Avidemux can't find PID=400 so no more audio

[Jan Gruuthuse]

this pops up while playing ac3UsedFootage with only ac3 track selected:

Code Select Expand

[AudioStream] Warning skew in dts =-226011,
[AudioStream] Warning skew lastDts=00:00:00,493
[AudioStream] Warning skew newDts=00:00:00,267 
[rewind]  [AudioBridge] Going to time 00:00:00,493
  [goToTime]   go to time 0,49 secs
  [goToTime]  => seg 0, rel time 0,49 secs
  [resetAfterSeek]   flushing after seek 
No accelerated IMDCT transform found
[AudioStream] Warning skew in dts =-225345,
[AudioStream] Warning skew lastDts=00:00:00,493
[AudioStream] Warning skew newDts=00:00:00,267 
[AUDMAudioFilter_Bridge]  [Bridge] Starting with time 00:00:00,493 , shift 0 ms
  [AUDMAudioFilter_Bridge]  [Bridge] Ending with time 00:00:00,493, sample 0
  [rewind]  [AudioBridge] Going to time 00:00:00,493
  [goToTime]   go to time 0,49 secs
  [goToTime]  => seg 0, rel time 0,49 secs
  [resetAfterSeek]   flushing after seek 
No accelerated IMDCT transform found
[AudioStream] Warning skew in dts =-225345,
[AudioStream] Warning skew lastDts=00:00:00,493
[AudioStream] Warning skew newDts=00:00:00,267 
[rewind]  [AudioBridge] Going to time 00:00:00,493
  [goToTime]   go to time 0,49 secs
  [goToTime]  => seg 0, rel time 0,49 secs
  [resetAfterSeek]   flushing after seek 
No accelerated IMDCT transform found
[AudioStream] Warning skew in dts =-225345,
[AudioStream] Warning skew lastDts=00:00:00,493
[AudioStream] Warning skew newDts=00:00:00,267 
[getPCMPacket]  [Composer::getPCMPacket] Track 2,24efa60 : drift 225345, computed :00:00:00,493  [getPCMPacket]   got 00:00:00,267
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =267
[getPCMPacket]  [Composer::getPCMPacket] Track 2,24efa60 : drift 193345, computed :00:00:00,493  [getPCMPacket]   got 00:00:00,299
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =299
[getPCMPacket]  [Composer::getPCMPacket] Track 2,24efa60 : drift 161345, computed :00:00:00,493  [getPCMPacket]   got 00:00:00,331
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =331
[getPCMPacket]  [Composer::getPCMPacket] Track 2,24efa60 : drift 129345, computed :00:00:00,493  [getPCMPacket]   got 00:00:00,363
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =363
[getPCMPacket]  [Composer::getPCMPacket] Track 2,24efa60 : drift 97345, computed :00:00:00,493  [getPCMPacket]   got 00:00:00,395
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =395
[getPCMPacket]  [Composer::getPCMPacket] Track 2,24efa60 : drift 65345, computed :00:00:00,493  [getPCMPacket]   got 00:00:00,427
[Composer::getPCMPacket] Track 2:24efa60 : Dropping packet 493 last =427
[getPCMPacket]  [Composer::getPCMPacket] Track 2,24efa60 : drift -62655, computed :00:00:00,493  [getPCMPacket]   got 00:00:00,555
DeviceStopped -> DeviceStopped
[localInit]  Pulse, initiliazing channel=2 samplerate=48000
  [localInit]  [PulseSimple] open ok
DeviceStopped -> DeviceStarted
[stop]  [audioDevice]Stopping device... DeviceStarted -> DeviceStop_Requested
[AudioDeviceThreaded] Entering loop
DeviceStop_Requested -> DeviceStop_Granted
[AudioDeviceThreaded] Exiting loop
[PulseAudio] Stopped
DeviceStop_Granted -> DeviceStopped
DeviceStopped -> DeviceStopped
[localInit]  Pulse, initiliazing channel=2 samplerate=48000
  [localInit]  [PulseSimple] open ok
DeviceStopped -> DeviceStarted
[Playback] Latency : 50 ms
[AudioDeviceThreaded] Entering loop
[Playback] Latency is now 0

[eumagga0x2a]

Thank you, but it is not a performance issue at all. My rather outdated hardware is still capable of playing 1080p h264 videos with Avidemux' Lavcodec decoder without a hitch, even better with VDPAU, though the architectural peculiarities of Avidemux limit the benefits of VDPAU compared with mplayer consuming below 5% CPU when playing 1080p h264 videos thanks to VDPAU decoding.

By the way, remuxing your sample TS file with ffmpeg using

Code Select Expand

ffmpeg -i AC3UsedFootage.ts -map 0:1 -map 0:6 -c copy AC3UsedFootage-remuxed-with-ffmpeg.mkv

doesn't make C3UsedFootage-remuxed-with-ffmpeg.mkv correctly playable in Avidemux, the video is still much slower than audio.

The questions are:

1) What was arte HD doing wrong in my sample which made Avidemux think the ac3 track didn't continue past channel layout switch?

2) What makes Avidemux choose a wrong video framerate with both sample videos?

Jingle in prologic see the increased peek.

The point where the channel layout switches is actually audible even with downmixing, but the behaviour without downmixing is just... surprising (even if this is a bug, it is not really an issue).

AlsaDefault Or PulseAudioS doe not make any difference.

The volume slider in Avidemux doesn't work with PulseAudio Simple (this is an API limitation).

The other option is that the PMT mapping is changing
i.e. it starts with audio track PID=400
and later on  it is mapped to PID=403

Avidemux can't find PID=400 so no more audio

Thank you, actually there is a big discontinuity in video timestamps(?) in the stream at the place where Avidemux drops the ac3 audio track according to ffplay:

Code Select Expand

76505.02 A-V:  0.058 fd= 104 aq=   48KB vq= 3321KB sq=    0B f=0/0

2 frames later:

Code Select Expand

95446.68 A-V:18941.638 fd=  81 aq=   48KB vq= 3263KB sq=    0B f=0/0

3 frames later back to normal:

Code Select Expand

76505.61 A-V:  0.503 fd=  81 aq=   48KB vq= 3225KB sq=    0B f=0/0

This looks really like a crazy thing arte HD was doing.

[eumagga0x2a]

The other option is that the PMT mapping is changing
i.e. it starts with audio track PID=400
and later on  it is mapped to PID=403

Avidemux can't find PID=400 so no more audio

I apologize for my ignorance if I misunderstand the role of PMT, but while I'm unable to identify the mapping exactly at the crucial location in the stream, ffplay shows the very same program (10302) and stream (0x13fc) IDs for the beginning of the sample and a fragment cut with

Code Select Expand

tail -c 100M testcase-ac3-framerate-issue.ts > fragment.ts

which starts just after the problematic spot.

[mean]

The info is in the idx2 file
language=fra
Track2.pid=13fc
Track2.codec=8192
Track2.fq=48000

I'll have to look deeper.
It could be a temporary switch to another pid & back
Avidemux tries for a given length to find the pid it wants, after that it fails

It is possible, since seeking after 1mn works well

You can try changing the value in  dmxTsPacket.cpp

That's the one :

Code Select Expand


#define MAX_SKIPPED_PACKET 150*100 // 150*180*100=~ 2.2 MBytes

you can try to put a 20 times larger value

[eumagga0x2a]

Thank you, increasing MAX_SKIPPED_PACKET from 150*100 to 150*100*20 doesn't help with a dropped ac3 track.

I wonder whether

Code Select Expand

Audio bf:04037640 Pes:13f8:04032578:0:2590175582 Pes:13f9:04032634:0:2590175582 Pes:13fc:0401fe40:0:2590168975 Pes:13fd:04034e98:0:2590176482
Video at:0401b124:001e Pts:2590274305:2590270705  DF:017341:0:0 PF:002f97:14400:1800 BF:0004c3:7200:3600 BF:0019e4:1800:-1 BF:001cc9:3600:-1 BF:000357:5400:-1 BF:0005ec:9000:10800 BF:000224:10800:12600 BF:0006b3:12600:14400 PF:000e58:28800:16200 BF:0166c8:21600:18000 BF:0002c2:16200:-1 BF:000327:18000:-1 BF:000248:19800:-1 BF:000352:23400:25200 BF:00023b:25200:27000 BF:017f34:27000:28800 PF:001873:43200:30600 BF:000e0f:36000:32400 BF:000308:30600:-1 BF:00029e:32400:-1 BF:00026d:34200:-1 BF:01f2c6:37800:39600 BF:00056c:39600:41400 BF:0002b2:41400:43200
Audio bf:040b77e4 Pes:13f8:040b3d24:0:2590210142 Pes:13f9:040b3de0:0:2590210142 Pes:13fc:0409a708:0:2590203535 Pes:13fd:040b7d08:0:2590211042
Video at:040b3398:001e Pts:2590331905:2590315705  DF:003c02:0:0 BF:000836:-7200:1800 BF:00055d:-12600:-1 BF:019f74:-10800:-1 BF:000274:-9000:-1 BF:000338:-5400:9000 BF:0000d3:-3600:10800 BF:0188d5:-1800:12600 PF:0003a1:14400:14400 BF:0001b3:7200:16200 BF:0000a3:1800:-1 BF:0004b0:3600:-1 BF:000060:5400:-1 BF:0004f2:9000:23400 BF:00004a:10800:25200 BF:000552:12600:27000 PF:0000f4:28800:28800 BF:0007a0:21600:30600 BF:000040:16200:-1 BF:018df0:18000:-1 BF:000040:19800:-1 BF:000551:23400:37800 BF:000042:25200:39600 BF:000602:27000:41400 PF:000aff:41400:43200 BF:014526:36000:45000 BF:000043:30600:-1 BF:00054b:32400:-1 BF:000043:34200:-1 BF:00058a:37800:52200 BF:000087:39600:54000 PF:0171b1:43200:55800
Audio bf:0416af4c Pes:13f8:04154a64:0:2590261982 Pes:13f9:04154b20:0:2590261982 Pes:13fc:041522bc:0:2590261135 Pes:13fd:04157d10:0:2590262882
Video at:0416aba0:001e Pts:2590376905:2590373305  DF:00017c:0:0
Audio bf:0416bb0c Pes:13f8:04154a64:0:2590261982 Pes:13f9:04154b20:0:2590261982 Pes:13fc:041522bc:0:2590261135 Pes:13fd:04157d10:0:2590262882
Video at:0416af4c:001e Pts:2590378705:2590375105  DF:000952:0:0
Audio bf:04173c4c Pes:13f8:04174ea8:0:2590270622 Pes:13f9:04174f64:0:2590270622 Pes:13fc:0417c1f4:0:2590272655 Pes:13fd:04178210:0:2590271522
Video at:0416bb0c:001e Pts:2590380505:2590376905  DF:006f5b:0:0 PF:0098c3:5400:1800 BF:0008f8:1800:3600 BF:0006e4:3600:5400 PF:01147e:9000:7200 BF:001876:7200:9000 PF:00f001:12600:10800 BF:001b0a:10800:12600 PF:0108ac:16200:14400 BF:001f3b:14400:16200 PF:014991:19800:18000 BF:00246b:18000:19800 PF:01b54c:34200:21600 BF:00cc2d:27000:23400 BF:005100:21600:-1 BF:003e4c:23400:-1 BF:001f2e:25200:-1 BF:002784:28800:30600 BF:00283c:30600:32400 BF:001abc:32400:34200 PF:016f7d:45000:36000 BF:009dfc:39600:37800 BF:001cac:36000:-1 BF:001e53:37800:-1 BF:0019be:41400:43200 BF:0017a2:43200:45000
Audio bf:0428cb68 Pes:13f8:0427cf84:0:2590331102 Pes:13f9:0427d040:0:2590331102 Pes:13fc:04279290:0:2590330255 Pes:13fd:04281258:0:2590332002
Video at:0424e9cc:001e Pts:2590438105:2590423705  DF:036618:0:0 BF:008d06:-5400:1800 BF:002370:-10800:-1 BF:00277d:-9000:-1 BF:001c60:-7200:-1 BF:001a8d:-3600:9000 BF:001823:-1800:10800 PF:013312:14400:12600 BF:0094e7:7200:14400 BF:0013db:1800:-1 BF:002238:3600:-1 BF:002170:5400:-1 BF:001ae8:9000:21600 BF:002310:10800:23400 BF:001dae:12600:25200 PF:014296:28800:27000 BF:0099a3:21600:28800 BF:00172c:16200:-1 BF:0023b3:18000:-1 BF:0021e4:19800:-1 BF:001ab0:23400:36000 BF:002207:25200:37800 BF:001c4b:27000:39600 PF:015ba1:43200:41400 BF:009b71:36000:43200 BF:00178b:30600:-1 BF:0023a0:32400:-1 BF:0022b2:34200:-1 BF:001aaa:37800:50400 BF:0022d3:39600:52200 BF:001d5a:41400:54000

starting at line 220 of the corresponding idx2 file describes the problematic spot. Still, Pes:13fc appears at every line prefixed with Audio in the [Data] section.

Meanwhile I've found more problematic streams, all recorded from arte HD over DVB-S2 in recent years, and they all showed an already mentioned timestamp jump (audio, not video) in the ac3 track when frame-stepping in mplayer (mplayer has a better console output as ffplay for this purpose), two examples:

Code Select Expand


A:76504.6 V:76504.6 A-V:  0.000 ct: -1.074   0/  0  1%  0%  1.8% 0 0
A:76504.6 V:76504.6 A-V:  0.000 ct: -1.074   0/  0  1%  0%  1.8% 0 0
A:95446.3 V:76504.7 A-V:18941.617 ct: -1.072   0/  0  1%  0%  1.9% 0 0
A:95446.3 V:76504.7 A-V:18941.615 ct: -1.070   0/  0  1%  0%  1.9% 0 0
A:95446.3 V:76504.7 A-V:18941.613 ct: -1.068   0/  0  1%  0%  1.9% 0 0
A:95446.3 V:76504.7 A-V:18941.609 ct: -1.066   0/  0  1%  0%  1.8% 0 0
A:95446.4 V:76504.7 A-V:18941.609 ct: -1.064   0/  0  1%  0%  1.8% 0 0
A:95446.4 V:76504.8 A-V:18941.607 ct: -1.062   0/  0  1%  0%  1.8% 0 0
A:76505.2 V:76504.8 A-V:  0.424 ct: -1.060   0/  0  1%  0%  1.9% 0 0
A:76505.2 V:76504.8 A-V:  0.422 ct: -1.058   0/  0  1%  0%  1.9% 0 0


and

Code Select Expand

A:13283.2 V:13283.2 A-V:  0.000 ct: -0.960   0/  0  1%  0%  2.2% 0 0
A:13283.2 V:13283.2 A-V:  0.000 ct: -0.960   0/  0  1%  0%  2.2% 0 0
A:95446.3 V:13283.3 A-V:82163.008 ct: -0.958   0/  0  1%  0%  2.3% 0 0
A:95446.3 V:13283.3 A-V:82163.008 ct: -0.956   0/  0  1%  0%  2.3% 0 0
A:95446.3 V:13283.3 A-V:82163.000 ct: -0.954   0/  0  1%  0%  2.3% 0 0
A:95446.3 V:13283.3 A-V:82163.000 ct: -0.952   0/  0  1%  0%  2.3% 0 0
A:95446.3 V:13283.3 A-V:82163.000 ct: -0.950   0/  0  1%  0%  2.3% 0 0
A:95446.4 V:13283.4 A-V:82163.000 ct: -0.948   0/  0  1%  0%  2.3% 0 0
A:13283.8 V:13283.4 A-V:  0.422 ct: -0.946   0/  0  1%  0%  2.3% 0 0
A:13283.8 V:13283.4 A-V:  0.420 ct: -0.944   0/  0  1%  0%  2.3% 0 0


There are in all cases 6 frames in the ac3 track with wildly wrong audio timestamps. The values of these timestamps are identical across different recordings. Such places in the TS stream derail Avidemux when saving in copy mode to another container like mkv while ffmpeg happens to swallow this irregularity.

Now for the slow playback issue: I experimented with a 3sat HD stream and it seems that Avidemux needs at least 5 minutes of video duration to keep AV sync reliably. Samples shorter than approx. 280 seconds  (~360 MiB of stream) start to behave funny.

[mean]

It starts as 5.1 then switches to stereo at 50s