AviDeMux only handles first 3h of a 16h TS file

[beta-tester]

hello,

i am using AviDeMux 2.7.4 (and AviDeMux 2.7.5 nightly) on windows 10. i recently recorded a big 16 hour chunk of TS file with my TV card.
now i wanted to split that 16 hour TS file into small separate video files of 90 minutes chunks.
but after AviDeMux created the indexfile i only can see and handle the very first 00:00:00.000 to 02:49:32.891 part of the total 16:04:55 of the TS file.
the VLC player is able to play back the whole 16:04:55 of the TS file without problems.
but AviDeMux only see the first 02:49:32 part.

that is what AviDeMux gives as properties:

Code Select Expand

=====================================================
Video
=====================================================
Codec 4CC: H264
Auflösung: 1280 x 720
Seitenverhältnis: 1:1 (1:1)
Bildrate: 50.000 fps
Gesamtdauer: 02:49:32,891

=====================================================
Zusätzliche Video-Eigenschaften
=====================================================
ExtraData-Länge: 00

=====================================================
Audio (4 active track(s))
=====================================================
Codec: MP2
Kanäle: Stereo
Bitrate: 32000 Bps / 256 kbps
Abtastrate: 48000 Hz
Gesamtdauer: 02:49:31,941


the 16:04:55 TS file has a file size of 48,7 GB (52.395.066.080 Bytes).
AviDeMux created an index file of 73,2 MB (76.758.523 Bytes).

any idea, how i can handle the whole TS file with AviDeMux?

[eumagga0x2a]

Please move, rename or delete the idx2 file, then start the latest available Avidemux nightly, load the TS file so that Avidemux regenerates the index, close Avidemux, then compress (zip or 7z) and attach the admlog.txt file from %localappdata%\avidemux\ to your reply and provide the created idx2 file (it would be probably too large for an attachment even when compressed) via WeTransfer, Mega, Dropbox, Google Drive or an equivalent service to allow to assess the problem.

It could be a timestamp reset in the stream (which is not handled by Avidemux for MPEG-TS) or something completely different. The two files might give a hint.

[beta-tester]

here is the log file that AviDeMux created while opening and indexing that TS file:
see attachment

PS.: i used different versions of AviDeMux 2.7.5 nightly (win64 QT, win64, vc win64, win32) none of them could handle the whole TS file.

[eumagga0x2a]

Thank you, will look at it in a moment.

By the way, is the report https://sourceforge.net/p/avidemux/bugs/98/ yours? I don't have a SourceForge account and I'm not going to create one, but reports there are read, of course, just no action can be taken upon them if an inquiry is necessary.

PS.: i used different versions of AviDeMux 2.7.5 nightly (win64 QT, win64, vc win64, win32) none of them could handle the whole TS file.

Sure, the MpegTS demuxer code is the same.

[beta-tester]

yes, thats my report...

here the link to the uploaded 7z'ipped index file:
http://www.filedropper.com/diverse202001011355tsidx2
i couldnt find another file hoste without registration.

[beta-tester]

from the indexing dialog of ADM i could see that the last number of processed frames was aroud 2891700 frames.
calculating with 50fps content of the TS file that looks like the whole 16 houres.
so i think the index file should contain the complete 16 hours as well (hopefully)

[eumagga0x2a]

Thank you, got the file. NB: WeTransfer requires neither registration nor an email address (and doesn't ask users to solve captcha).

Already the log provides some hints:

Code Select Expand

[tsDemux] Found 2894693 video frames

At 50 fps this means ~ 16 hours of video, which matches the expectations.

Code Select Expand

[addReferenceVideo] 08:32:44-036 min increment 00:00:00,020 = 20000 us for frame 1
[addReferenceVideo] 08:32:44-036 max increment 339:53:08,480 = 18446744025987712772 us for frame 2386055

Looks very much like timestamp reset (so that the code which doesn't expect decode timestamps going back results in unsigned values wrapping around) close to the end. The duration we get is the duration of the part of the stream after the presumable timestamp reset.

[eumagga0x2a]

It is a bit more complicated. The duration is the last presentation timestamp - the first presentation timestamp, with timestamp reset at offset 39436043720 Bytes (~36,73 GiB).

If you have a Linux system or a tool equivalent to head or dd at hand, you could just copy the first 36,72 GiB of the stream which Avidemux should handle without problems. The same applies to the tail of the file from the offset 39436043720 on, it is just the boundary which is currently not handled.

[beta-tester]

do you think the issue is fixable, maybe by changing the datatype of that offset/index?

[eumagga0x2a]

It would be great if you could provide a small part of the original stream containing the timestamp reset as a sample, e.g. by using

Code Select Expand

dd if=diverse_20200101_1355.ts of=mpegts-tsreset.ts bs=1M skip=37500 count=200

The file "mpegts-tsreset.ts", 200 MiB in size, would contain the boundary.

[beta-tester]

If you have a Linux system or a tool equivalent to head or dd at hand, you could just copy the first 36,72 GiB of the stream which Avidemux should handle without problems. The same applies to the tail of the file from the offset 39436043720 on, it is just the boundary which is currently not handled.

yes, that is a good idea to split the TS file in chunks that ADM can handle.
can i split TS files to any size or is there a alignments i have to respect?

[eumagga0x2a]

do you think the issue is fixable, maybe by changing the datatype of that offset/index?

The issue might be fixable in the code of the MpegTS demuxer (probably not in time for 2.7.6, but who knows). It could be partially worked around as described above by splitting the input file.

If you have a Linux system or a tool equivalent to head or dd at hand, you could just copy the first 36,72 GiB of the stream which Avidemux should handle without problems. The same applies to the tail of the file from the offset 39436043720 on, it is just the boundary which is currently not handled.

can i split TS files to any size or is there a alignments i have to respect?

Any size, just the first GOP after the cut will be probably lost.

[eumagga0x2a]

I don't think splitting input file using Linux on command line is a viable approach for the majority of users, so finding a code fix would be preferable by far. Only possible when a sample is available

[eumagga0x2a]

Thank you very much, got the file with the reset happening at offset ~ 109 MiB. The problem is that Avidemux happens to load it just fine. Need to understand why it works here, will look into it a bit later.

[beta-tester]

i now splitted the huge TS file in three overlapping smaller ones that ADM can handle.
so i do not loose anything.
thank you for the hint with splitting the file as workaround.