AAC audio - short sections without any sound

[teoburger]

Hi all,

I have transport stream file recorded from DVB-T. I would like to edit it in Avidemux, but I have problem with AAC audio. If I open this file in Avidemux there is short 1 second section without any sound every about 10-20 minutes. I have tried it on Fedora Linux (Avidemux 2.6) and Windows 10 (Avidemux 2.6) - the result is the same and on the same time. By the way, I have tried to play this file in VLC media player on Linux and Windows and the audio is OK. So it must be problem in Avidemux.

File info:

=====================================================
Video
=====================================================
Codec 4CC:      H265
Image Size:      960 x 540
Aspect Ratio:      1:1 (1:1)
Frame Rate:      50.000 fps
Total Duration:      02:47:57.782

=====================================================
Extra Video Properties
=====================================================
ExtraDataSize:      00

=====================================================
Audio (1 active track(s))
=====================================================
Codec:         AAC
Channels:      Stereo
Bitrate:      16000 Bps / 128 kbps
Frequency:      48000 Hz
Total Duration:      02:47:56.608

Do you have any suggestions?

Best regards

Teoburger.

[eumagga0x2a]

I have tried it on Fedora Linux (Avidemux 2.6)

I assume this is a typo, Avidemux 2.6.x is unsupported legacy software. Only the version 2.7.8 and the current git master is supported.

File info:

Code Select Expand

=====================================================
Video
=====================================================
Codec 4CC:      H265
Image Size:    960 x 540

Is this really a file captured from a DVB-T (DVB-T2) broadcast? I never heard of broadcasts using HEVC at such a low resolution.

Anyway, could you please provide a sample, long enough to be able to reproduce the issue? Please use tools like head to copy the beginning of the file without any modifications of the stream to a new file.

[teoburger]

Hi eumagga0x2a,

I am very sorry. The version is a typo - I mean 2.7.6. Yes, the video file is really captured from DVB-T2 by myself with AB CryptoBox 702T (https://www.abcomeu.com/ab-cryptobox-702t-2).
Ffmpeg -i shows:
Program 520
    Metadata:
      service_name    : NOVA CINEMA | T2
      service_provider: CESKE RADIOKOMUNIKACE
    Stream #0:1[0xfb5]: Video: hevc (Main) ([36][0][0][0] / 0x0024), yuv420p(tv), 960x540 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc
    Stream #0:2[0xfb6](cze): Audio: aac_latm (LC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
    Stream #0:3[0xfbe](cze): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006), 492x250
    Stream #0:4[0xfbf]: Unknown: none ([5][0][0][0] / 0x0005)
    Stream #0:5[0x1f40]: Unknown: none ([12][0][0][0] / 0x000C)

From ffmpeg info, I noticed that origin audio is aac_latm. I have tried to do this: ffmpeg -i input.ts -c:s copy -c:v copy -c:a aac output.ts.
After this I did not noticed any sections without sound in new output.ts. So the problem have to be in aac_latm.

I have also tried to only pass file through ffmpeg without modifications and problem with sound persists:
ffmpeg -i input.ts -c:s copy -c:v copy -c:a aac output.ts

Best regards

Teoburger.

[eumagga0x2a]

The version is a typo - I mean 2.7.6

Please test whether the problem persists with 2.7.8 and if it does, please provide a piece of the original stream, not remuxed with ffmpeg or modified by any other software.

[teoburger]

Hi eumagga0x2a,

yes the problem persist in 2.7.8 - on both Windows 10 and Fedora 33. I can provide you piece of the original stream, but I have to cut it in ffmpeg - of course without remuxing. But I would like to share this piece only to you (via PM) for testing purpouses. I don't want to share it publicly. Is it ok for you?

Best regards

Teoburger.

[eumagga0x2a]

but I have to cut it in ffmpeg

No, this outright defies the purpose, please use a proper tool (head or dd on Fedora) to cut the file without any interpretation / modification of the content.

But I would like to share this piece only to you (via PM) for testing purpouses. I don't want to share it publicly. Is it ok for you?

Yes, sure, as long as the footage is innocuous enough.

[teoburger]

Hi eumagga0x2a,

the movie recorded from DVB-T2 is some Disney tale. I found the sound gap at the beginning in the 9th second. So I made the sample with this command:

dd if=sample.ts of=short_sample.ts count=10000

I send you the link to Google drive and you can try it yourself. Then you can share your opinion in this topic.

You can see that there is no sound gap in VLC player. But you can hear the sound gap in Avidemux. After you save ts file from Avidemux, you can hear the gap also in VLC player. This gap is really short but some gaps are 1 second long. All my recordings from DVB-T2 have this kind of sound gaps.

Best regards

Teoburger.

[eumagga0x2a]

Thank you for the sample. At the first glance, it looks like the LATM AAC audio stream is using features we don't support:

Code Select Expand

[readStreamMuxConfig] 17:48:31-892  LATM: only supports subframe=1, subprogram=1
 [getPacket] 17:48:31-892  Error demuxing LATM frame, 40 attempts remaining.
[Composer::getPCMPacket] Track 0, 0x279dd80 : drift -277333, computed : 00:00:09,834 got 00:00:10,112
[Composer::getPCMPacket] Track 0, 0x279dd80 : drift -192000, computed : 00:00:09,920 got 00:00:10,112
[Composer::getPCMPacket] Track 0, 0x279dd80 : drift -106667, computed : 00:00:10,005 got 00:00:10,112
[Composer::getPCMPacket] Track 0, 0x279dd80 : drift -42667, computed : 00:00:10,368 got 00:00:10,410
Avidemux, unable to demux such packets, skips them, which results in brief gaps.

I'll try to inspect the sample deeper ASAP.

[eumagga0x2a]

By the way, I remember having encountered a sample with the same issue, also from Česko. That time I was unsure whether the stream was simply broken in that particular sample as nobody complained about drop-outs. Of course, never experienced this with DVB-T2 samples from elsewhere and thus thought this would be a random fluke :-/

[teoburger]

Hi eumagga0x2a,

it seems it is not a fluke. The gaps are really in all my recordings. As I wrote before ffmpeg can save aac_latm to aac without problem and than I can edit it in Avidemux. So I have some workaround. But if this "bug" will be fixed in some future release I will be very happy.

I will wait for your reply.

Best regards

Teoburger.

[eumagga0x2a]

If you remux with ffmpeg to mkv, the issue will persist as ffmpeg doesn't remove LATM envelope. The problem is limited support for some LATM features in Avidemux.

PS: "-c:a aac" on ffmpeg command line re-encodes audio, it doesn't losslessly extract the LATM-encapsulated AAC stream like Avidemux does (but fails with some LATM features).

[teoburger]

My workaround is this - it converts aac_latm to aac:

ffmpeg -i input.ts -c:v copy -c:a aac output.ts

[eumagga0x2a]

My late edit explained that this ffmpeg command line re-encodes the audio track (probably with some very low default bitrate and corresponding poor quality).

[eumagga0x2a]

Some background: AAC codec needs so-called extradata (decoder configuration) in order to know how to interpret the bitstream. A raw AAC stream doesn't provide any place for extradata, this short binary blob needs to be supplied from elsewhere. In MPEG-TS, decoder configuration needs to be readily available whenever a player jumps into the stream to start playback, so that AAC audio tracks absolutely need a sort of a lightweight container to repeatedly include extradata along with raw compressed audio packets. This is the purpose of ADTS and LATM containers, with the latter broadly used in digital broadcasts.

[eumagga0x2a]

Should be fixed now, please try the latest git master.

The problem was not related to unsupported features. The calculation of LATM frame size was slightly wrong and Avidemux landed 2 bytes short of the start of the next LATM frame. With your sample, this was enough to encounter an sequence of 11 bits exactly matching the syncword. As a result, the calculated size of the next LATM frame was completely bogus and rendered a big chunk of demuxed data invalid.

Thank you again for your report and the sample.