August 12, 2020, 11:14:08 pm

News:

--


Doesn't trim selection

Started by LordMaster316, March 17, 2019, 04:17:23 pm

Previous topic - Next topic

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


eumagga0x2a

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?

eumagga0x2a

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.

LordMaster316

March 17, 2019, 08:35:12 pm #5 Last Edit: March 17, 2019, 08:36:57 pm by LordMaster316
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?

eumagga0x2a

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

LordMaster316

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

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

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) 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