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.
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
Audio (1 active track(s))
Bitrate: 16000 Bps / 128 kbps
Frequency: 48000 Hz
Total Duration: 02:47:56.608
Do you have any suggestions?
Quote from: teoburger on March 13, 2021, 03:27:39 PMI 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.
Quote from: teoburger on March 13, 2021, 03:27:39 PMFile info:
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.
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:
service_name : NOVA CINEMA | T2
service_provider: CESKE RADIOKOMUNIKACE
Stream #0:1[0xfb5]: Video: hevc (Main) ( / 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) ( / 0x0011), 48000 Hz, stereo, fltp
Stream #0:3[0xfbe](cze): Subtitle: dvb_teletext ( / 0x0006), 492x250
Stream #0:4[0xfbf]: Unknown: none ( / 0x0005)
Stream #0:5[0x1f40]: Unknown: none ( / 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
Quote from: teoburger on March 17, 2021, 06:08:39 PMThe 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.
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?
Quote from: teoburger on March 24, 2021, 05:25:20 PMbut I have to cut it in ffmpeg
No, this outright defies the purpose, please use a proper tool (head
on Fedora) to cut the file without any interpretation / modification of the content.
Quote from: teoburger on March 24, 2021, 05:25:20 PMBut 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.
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.
Thank you for the sample. At the first glance, it looks like the LATM AAC audio stream is using features we don't support:
[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.
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 :-/
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.
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).
My workaround is this - it converts aac_latm to aac:
ffmpeg -i input.ts -c:v copy -c:a aac output.ts
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).
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.
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.
great news. I am very happy that you found the cause of the problem. Thank you very much. Now, I am very busy at work so I am not sure if I find some time to compile Avidemux from source. Could I ask you when this fix will be available in the official release?
I have tried Avidemux_2.7.9 VC++ 64bits 210326.exe (nightly build) and I can say that bug is fixed. I have tried it on two recordings and the sound is ok.
Thank you very much!
Thank you for the feedback.
just for info. I built rpm packages from https://github.com/mean00/avidemux2. So I can inform you that in Fedora 33 the sound is ok too.
Best regards and thank you again for quick response and fix.
Quote from: teoburger on March 28, 2021, 07:04:10 AMSo I can inform you that in Fedora 33 the sound is ok too.
Thanks, indeed, it should as the fix has been developed on Fedora 33 :-)
If you used CPack to create RPMs as invoked by createRpmFromSourceFedora.bash, then it is nice to hear that it still works (I never tested it after it was written; RPM Fusion provides a proper Avidemux package for Fedora, so reusing their spec file would be the straightforward way to generate packages).
Quote from: eumagga0x2a on March 28, 2021, 03:03:17 PMIf you used CPack to create RPMs as invoked by createRpmFromSourceFedora.bash, then it is nice to hear that it still works (I never tested it after it was written; RPM Fusion provides a proper Avidemux package for Fedora, so reusing their spec file would be the straightforward way to generate packages).
Yes, I used bash createRpmFromSourceFedora.bash --no-install
. It generated seven rpm packages. I installed them and - it works :-).