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
Please reproduce the issue, then compress and attach admlog.txt from %localappdata%\avidemux\ to your reply.
hopefully, this helps
Thank you, things start to go wrong at the line 1659 of the log:
[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?
Actually, the reason for the anomaly is
[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.
Quote from: eumagga0x2a on March 17, 2019, 08:17:37 PM
Thank you, things start to go wrong at the line 1659 of the log:
[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
Quote from: eumagga0x2a on March 17, 2019, 08:24:46 PM
Actually, the reason for the anomaly is
[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?
Did you reindex the stream with 2.7.2 by deleting the corresponding .idx2 file?
Quote from: eumagga0x2a on March 17, 2019, 08:49:49 PM
Did you reindex the stream with 2.7.2 by deleting the corresponding .idx2 file?
I have results remain the same
Thanks, could you please provide a sample ~200 MiB in size of the source video using a binary cutter / file splitter (e.g. HJSplit (http://www.hjsplit.org/)) and a service like WeTransfer, Mega, Dropbox or Google Drive? Of course, only if the video is innocuous enough :-)
Quote from: eumagga0x2a on March 17, 2019, 09:21:19 PM
Thanks, could you please provide a sample ~200 MiB in size of the source video using a binary cutter / file splitter (e.g. HJSplit (http://www.hjsplit.org/)) 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
Thank you very much, I needed just the first chunk.
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.
Please try the 190319 nightly from https://avidemux.org/nightly/vsWin64/