avidemux 2.7.6 cannot handle long .ts files

Started by lvm, July 17, 2020, 03:10:56 PM

Previous topic - Next topic

lvm

I have a problem similar to this one https://avidemux.org/smif/index.php/topic,19110.0.html - avidemux can see only the first part of long .ts file, but in my case it is 2.7.6 for linux-64, it stops at about 2h:25m and the last offset in idx2 file it creates is always just shy of 0x280000000 e.g.

Audio bf:27ffbb744 Pes:1fe:27ff92104:0:3338339574 Pes:1ff:27ff91e04:0:3338339574
Video at:27ffa4d04:0013 Pts:3338412835:3338394835  DT:013885:0:0 PB:005eea:1800:1800 BT:004b4f:-10800:3600 BB:003f0e:-9000:5400 BT:004224:-7200:7200 BB:005379:-5400:9000 BT:002ccc:-3600:10800 BB:00384a:-1800:12600 PT:01e618:14400:14400 PB:011b43:16200:16200 BT:002f15:3600:18000 BB:001f25:5400:19800 BT:00a539:7200:21600 BB:00a0d5:9000:23400 BT:008009:10800:25200 BB:006edb:12600:27000 PT:009d77:28800:28800 PB:007058:30600:30600 BT:00505f:18000:32400 BB:005182:19800:34200 BT:003c55:21600:36000 BB:0036c9:23400:37800 BT:001aab:25200:39600 BB:00294d:27000:41400 PT:0094ec:43200:43200 PB:007941:45000:45000 BT:001e2d:32400:46800 BB:002ab9:34200:48600 BT:00381c:36000:50400 BB:0036c4:37800:52200 BT:003ca7:39600:54000 BB:0033a5:41400:55800 PT:00a7ef:57600:57600 PB:006756:59400:59400 BT:002efc:46800:61200 BB:0028ee:48600:63000 BT:00394d:50400:64800 BB:002f3a:52200:66600 BT:002d63:54000:68400 BB:001eb3:55800:70200 PT:00741e:72000:72000 PB:006b06:73800:73800 BT:002659:61200:75600 BB:001cdf:63000:77400 BT:00476d:64800:79200 BB:003cce:66600:81000 BT:003bcb:68400:82800 BB:003d45:70200:84600 PT:00ca9d:86400:86400 PB:009d35:88200:88200 BT:003a46:75600:90000 BB:003168:77400:91800
[End]


Smaller files from the same source are handled ok.


=====================================================
Video
=====================================================
Codec 4CC:      H264
Image Size:      1920 x 1080
Aspect Ratio:      1:1 (1:1)
Frame Rate:      50.000 fps
Total Duration:      02:23:23.291

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

=====================================================
Audio (2 active tracks)
=====================================================
Codec:         MP2
Channels:      Stereo
Bitrate:      24000 Bps / 192 kbps
Frequency:      48000 Hz
Total Duration:      02:23:21.696


eumagga0x2a

Please rename the .idx2 file, start Avidemux, load the .ts file, close Avidemux, then compress (zip, 7z) and attach admlog.txt from %localappdata%\avidemux\ to your reply.

(I have no difficulty to load a > 16 GiB MPEG-TS stream over 2h:40m in duration)

lvm

Attached. I am having problems with files only from one source, and they are weird: some players cannot determine video length properly but at least they can play the full file.


eumagga0x2a

#3
A debug build, nice. Updating to the latest git master won't harm. I didn't think that you are on Linux (actually, you wrote it :-o), this makes things much simpler.

Could you please provide a ~100 MiB long sample from about the area where we lose sync?

dd if=input.ts of=output.ts bs=1M skip=10200 count=100

Please use WeTransfer (no email address and not registration required!), Mega, Dropbox, Google Drive or an equivalent service.

lvm

#4
Here it is https://0x0.st/ivOY.ts

Actually I am not building it myself but getting from this ppa: https://launchpad.net/~ubuntuhandbook1/+archive/ubuntu/avidemux

eumagga0x2a

Thank you, not only Avidemux but also ffplay and mpv all see only ~38 seconds worth of video in the sample, so something happens starting from ~ the last 55 MiB of the stream. I'll try to identify the reason a bit later, we are at least not alone here.

eumagga0x2a

Quote from: lvm on July 17, 2020, 04:43:00 PM
Actually I am not building it myself but getting from this ppa: https://launchpad.net/~ubuntuhandbook1/+archive/ubuntu/avidemux

The maintainer of that PPA indeed ships debug builds as release builds.

eumagga0x2a

At the low level the stream is OK but the PES payload for the PID doesn't make sense (bitstream not aligned at byte boundaries??) starting from the point where indexing stops.