Doesn't trim selection

[LordMaster316]

when I trim a file in the 2.7 - 64 version it renders large amounts outside of the selection. 6 minute trim turns into 40+ after rendering

[eumagga0x2a]

Please reproduce the issue, then compress and attach admlog.txt from %localappdata%\avidemux\ to your reply.

[LordMaster316]

hopefully, this helps

[eumagga0x2a]

Thank you, things start to go wrong at the line 1659 of the log:

Code Select Expand

[ADM_videoStreamCopy::ADM_videoStreamCopy] 19:13:27-748 PTS/DTS delta=2271430737 us

We detect a delay of almost 38 minutes between the decode (DTS) and the presentation (PTS) timestamps in the video – this is why the saved duration is vastly different from the expected one. Was the index file (the loaded .mp4 file is not a MP4 but a MPEG TS) generated with 2.7.2 or with an older Avidemux version?

[eumagga0x2a]

Actually, the reason for the anomaly is

Code Select Expand

[tsHeader::getVideoDuration] 19:11:59-527 Found maxDts =00:00:00,000, 966332 frames from the end

DTS are unset in the stream (apart from the default DTS = 0 for the first frame), so all checks based on the assumption that we can do anything meaningful based on DTS produce unexpected results.

[LordMaster316]

Thank you, things start to go wrong at the line 1659 of the log:

Code Select Expand

[ADM_videoStreamCopy::ADM_videoStreamCopy] 19:13:27-748 PTS/DTS delta=2271430737 us

We detect a delay of almost 38 minutes between the decode (DTS) and the presentation (PTS) timestamps in the video – this is why the saved duration is vastly different from the expected one. Was the index file (the loaded .mp4 file is not a MP4 but a MPEG TS) generated with 2.7.2 or with an older Avidemux version?

Yes, it first started to occur with 2.6. Although the issue is fairly recent, 2-3 months recent

Actually, the reason for the anomaly is

Code Select Expand

[tsHeader::getVideoDuration] 19:11:59-527 Found maxDts =00:00:00,000, 966332 frames from the end

DTS are unset in the stream (apart from the default DTS = 0 for the first frame), so all checks based on the assumption that we can do anything meaningful based on DTS produce unexpected results.

How should we proceed?

[eumagga0x2a]

Did you reindex the stream with 2.7.2 by deleting the corresponding .idx2 file?

[LordMaster316]

Did you reindex the stream with 2.7.2 by deleting the corresponding .idx2 file?

I have results remain the same

[eumagga0x2a]

Thanks, could you please provide a sample ~200 MiB in size of the source video using a binary cutter / file splitter (e.g. HJSplit) and a service like WeTransfer, Mega, Dropbox or Google Drive? Of course, only if the video is innocuous enough :-)

[LordMaster316]

Thanks, could you please provide a sample ~200 MiB in size of the source video using a binary cutter / file splitter (e.g. HJSplit) and a service like WeTransfer, Mega, Dropbox or Google Drive? Of course, only if the video is innocuous enough :-)

The source file is 6GB+ so I couldn't sync every file, but hopefully, what's there will help.

https://www.dropbox.com/sh/1mlopj0s6g7hxmw/AAC4KxnjvEEz3UuLz3EXNVw-a?dl=0

[eumagga0x2a]

Thank you very much, I needed just the first chunk.

[eumagga0x2a]

I pushed a patch to the ffmpeg4x branch tailored for the specific brokenness (dts missing AND time increment wrong) and codec features (H.264 without B-frames) of the sample. Future nightlies should handle this source video fine. A more generic solution likely to follow.

[eumagga0x2a]

Please try the 190319 nightly from https://avidemux.org/nightly/vsWin64/