AviDemux 2.7.5 x64 does not recognize audio of the first 2 seconds of this .ts

[doquan0]

On Windows 8.1 x64, I open this .ts video with AviDemux. I press 'Play' button and notice AviDemux miss audio of the first 2 seconds (PotPlayer and VLCPlayer play this .ts video normally). Exporting to .mkv (lossless, Video & Audio Output: Copy) also has this problem.

I tested this .ts video with these AviDemux versions (I delete the index file .ts.idx2 before each test)
- Stable 2.7.5 x64
- Nightly 2.7.5 VC++ 64bits 200611
- Nightly 2.7.5 r200611 win64
- Nightly r200611 win64Qt5

Link to download my .ts video
- Name: TestVideo_password_123.zip (size: 287MB)
- Password to unzip: 123
https://drive.google.com/file/d/11TiMabp9hu2urmzNJjaR-gSbnZsU-3dE/view?usp=sharing

Thanks

[eumagga0x2a]

Thank you for the sample, there are multiple issues starting with a very strange time base 1/96000 for the video codec which Avidemux naively translates as 48000 fps, subsequently discarded by the editor and replaced with 25 fps as fallback.

Just curious, do you know by chance what application (well, the stream is encoded by x264, but x264 is usually invoked by another application) is responsible for this video? I'm sort of baffled by this time base.

Avidemux indeed misses a portion of the audio, you can rectify it for this particular sample by replacing the line 26 in the .idx2 file by

Code Select Expand

Audio bf:0000678c Pes:100:00011074:0:394800

I'll look into it, but probably too late for 2.7.6.

[eumagga0x2a]

Regarding audio, it is clear what happens here: we find the first SPS NAL unit, then continue reading the file until the end of the GOP looking for a SEI picture timing message which whould allow to unmistakably detect interlacing or lack thereof. As there is no such SEI message in the first GOP, we give up and seek back to the start of SPS to start indexing. However, the info about the position and timing of audio packets is not reset on rewind, so the first index entry for audio points to audio at the end of the first GOP, approx. 3 seconds after the first frame.

Unfortunately, there is no simple remedy as info about audio packets is extracted as they arrive, and there is no audio at the moment we write the first audio entry in this sample.

Now I understand why the first audio entry in the index was being discarded until I removed that code two years ago.

[doquan0]

Just curious, do you know by chance what application (well, the stream is encoded by x264, but x264 is usually invoked by another application) is responsible for this video? I'm sort of baffled by this time base.

Hi eumagga0x2a

This .ts video is the first part of an episode of a TV show downloaded by a program called N_m3u8DL-CLI SimpleG (https://github.com/nilaoda/N_m3u8DL-CLI).

I use N_m3u8DL-CLI SimpleG v2.6.3 and update its FFmpeg static v4.2.3 x64 before downloading this episode.

I frequently use Avidemux to merge all parts of an episode video to Avidemux_Merge_Video.ts. Then I compare to N_m3u8DL_Merge_Video.mp4 (which is created automatically by N_m3u8DL).

Other episodes are merged correctly by Avidemux, only this part of this episode has problem in audio with Avidemux. N_m3u8DL-CLI merges this episode correctly.

[eumagga0x2a]

Thank you, from a very cursory look at the code it seems like the downloader is not responsible for the strange codec time base. Thus the source of this anomaly remains unknown.

The audio issue should be fixed by [demuxers/MpegTS] Make sure we have valid packet stats for the first audio index entry, only files with H.264 and HEVC video for now.

Thank you for your report.