News:

--

Main Menu

Video Ouput fps not following source.

Started by midasthegod, May 07, 2023, 10:38:31 PM

Previous topic - Next topic

midasthegod

I am currently editing a large mp4 file (2.4GB) and when I encode the video with HEVC and mp4 muxer (the same also happens with MPEG H.264 and probably others aswell), the output has only about 14fps. The source file is about 24fps. With the link below you can download a sample.mp4 (source) and a sample_edit.mp4 (output) file. Any idea why this is happening? I am new to avidemux so I might be missing some settings. What I have noticed is that when I playback the source file in avidemux after importing it, it's already choppy.
Any help would be greatly appreciated.

Files: https://drive.switch.ch/index.php/s/N8G8087eY8NJVqy

I'm using avidemux 2.8.1 on Windows x64.

eumagga0x2a

PTS in the source file are broken (in particular, they are set equal to DTS despite the video stream containing B-frames). Avidemux would check files with a H.264 video stream for broken PTS, but not when the video stream is HEVC.

It doesn't look like one can trigger PTS check in Avidemux for this file by other means than by enabling it generally for all HEVC videos in a future nightly build at line 795 of avidemux/common/ADM_editor/src/ADM_edit.cpp file.

midasthegod

Quote from: eumagga0x2a on May 08, 2023, 09:41:21 PMPTS in the source file are broken (in particular, they are set equal to DTS despite the video stream containing B-frames). Avidemux would check files with a H.264 video stream for broken PTS, but not when the video stream is HEVC.

It doesn't look like one can trigger PTS check in Avidemux for this file by other means than by enabling it generally for all HEVC videos in a future nightly build at line 795 of avidemux/common/ADM_editor/src/ADM_edit.cpp file.

First of all thanks for your fast response!

So there's no way I can fix this? Did I understand this correctly?

jimmy

Don't know if this will help you, but, I took your sample and

1) remuxed it in mkvtoolnix, using the force duration fps option to 24000/1001p
2) then encoded that remuxed sample in avidemux with HEVC default settings in mp4

The result was good, duration was 1 ms shorter, frame count was 1 less.
Hopefully, on a full length video, this method might work.

midasthegod

Quote from: jimmy on May 09, 2023, 03:43:57 AMDon't know if this will help you, but, I took your sample and

1) remuxed it in mkvtoolnix, using the force duration fps option to 24000/1001p
2) then encoded that remuxed sample in avidemux with HEVC default settings in mp4

The result was good, duration was 1 ms shorter, frame count was 1 less.
Hopefully, on a full length video, this method might work.

Thanks jimmy, appreciate your effort. I think this solved it for me, thanks a bunch! What does the force duration fps 24000/1001p parameter really mean?

eumagga0x2a

That's pretty amazing that mkvtoolnix seems to be able to figure out the correct display order of frames. The source mp4 file lacks the ctts atom which is used to store the delta between pts and dts in units of the track timescale.

eumagga0x2a

Quote from: midasthegod on May 09, 2023, 08:20:32 PMWhat does the force duration fps 24000/1001p parameter really mean?

"Default duration" field in Matroska container tells a video player for how long a frame should be displayed before the player shows the next one. It is used only if a frame lacks timing information. In my testing, there is no need to specify default duration manually when remuxing the source mp4 file to MKV using mkvtoolnix. The latter just does the right thing in this case and sets all necessary timestamps (Matroska doesn't store DTS, but it requires PTS to be set) automatically.