Force constant FPS for rendered videos #493
Conversation
|
Great if it works and don't break anything (else this needs to be an option). Will check later tonight. |
|
It doesn't break anything as far as I've seen but the rendered videos have an "extra" length, for instance:
I don't know if we are rendering an extra frame and that was the original problem or what... |
|
Now it works perfectly: both FPS, time and total frames count match with the scene settings. HandBrake, kdenlive and ffprobe validate the expected result of video, please, try other ones if you want and let me know if they reconfirm it. 😊 |
|
I tried before your newest commit, and there was no difference between a project rendered in RC1 or this PR. |
|
My project:
A basic social media video that lasts for 20 sec. RCPR (prior to last commit)DIFF: --- demo1.txt 2025-03-30 14:01:12.000000000 +0200
+++ demo2.txt 2025-03-30 14:13:19.000000000 +0200
@@ -1,5 +1,5 @@
General
-Complete name : Desktop/demo1.mp4
+Complete name : Desktop/demo2.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)PR (last commit)DIFF: --- demo2.txt 2025-03-30 14:13:19.000000000 +0200
+++ demo3.txt 2025-03-30 14:22:45.000000000 +0200
@@ -1,11 +1,11 @@
General
-Complete name : Desktop/demo2.mp4
+Complete name : Desktop/demo3.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
-File size : 22.5 MiB
-Duration : 20 s 0 ms
-Overall bit rate : 9 431 kb/s
+File size : 22.2 MiB
+Duration : 19 s 967 ms
+Overall bit rate : 9 320 kb/s
Frame rate : 30.000 FPS
Writing application : Lavf58.29.100
@@ -19,7 +19,7 @@
Format settings, Reference frames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
-Duration : 20 s 0 ms
+Duration : 19 s 967 ms
Bit rate : 9 000 kb/s
Width : 1 080 pixels
Height : 1 080 pixels
@@ -31,7 +31,7 @@
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.257
-Stream size : 22.5 MiB (100%)
+Stream size : 22.2 MiB (100%)
Writing library : x264 core 155
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=12 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=12 / rc=abr / mbtree=1 / bitrate=9000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Codec configuration box : avcC |
|
btw, none of the files I rendered are accepted by kdenlive 24.12. |
|
Ok, let me test it again later, I'm away from computer now... could you try a simple example that could share so that I test it here as well? I did 2 different tests at different settings and they both worked... |
|
I'm back here, I did a simple test file with your settings and they both are different, the one using this PR works perfectly in kdenlive 24.12.0, the one compiled with RC1 doesn't... My tests were done with "MP4 Video" profile, no audio rendered. Did you rendered audio in yours? |
|
I tried myself the "MP4 Video + Audio" profile and it also works. |
|
Another question, what video info checker are you using? |
The "MP4 Video" profile. I'm using ffmpeg 4.2.10 (I use the same SDK used to build releases).
I used This was done on my macbook (macOS12). I can test on Linux later today. |
|
OK, I don't know what ffmpeg I'm using but I guess is the one embed with Friction... I'll test now using mediainfo but it's strange your videos have no effect with the new changes... |
|
I tried using Being that said, could you try my sample video (one of some, I don't think it's necessary to send you all of them):
This is my output as an example: The important information is the first The video exported with this PR has If you use this PR with just the first commit you will see that the If you load the videos in HandBrake you will also see more or less the same information. Finally in kdenlive 24.12.0, if you open a project, set the project FPS to 30 (go to I'm going to test this on another computer and OS just in case, please, let me know your results if you are able to test them as I told you. |
|
Just tested on Windows (d6a9ff66) (https://github.com/friction2d/friction/actions/runs/14155877500) and my video rendered from Friction is not accepted by kdenlive, still complains about VFR. I also don't like that Handbrake says source is 30.1 fps.
The video (from Friction) is now missing 1 sec: untitled.mp4 |
|
Umm, and what about the videos I shared with you? |
Handbrake says everything (even the file that works in kdenlive) is peak or variable framerate, I don't trust it. This is a mess 😄 |
|
So, do you agree the videos rendered by Friction have something weird? I've tried too on a Windows computer and I confirm your results, it doesn't behave the same as on my macbook Pro were I coded and built the PR... My guess now would be that "the problem" could be an external component that is built in Friction but not compiled and that is behaving differently on macOS, Windows/Linux, do you agree? could it be FFMPEG? different versions or something like that? BTW, what I tried with this PR was to force the rendered video to include the real information from the video that was rendered:
I started all these strategy by checking that if I remuxed a video coming out from Friction RC1, I used Then the So maybe the next logical step is find out why the videos rendered with this PR are not behaving the same (probably because this "forced remux" is not working or not even being performed...) Any idea? |
That's because your are using a different build/version of ffmpeg on your Mac. On my macbook it works as on Windows. I use the same components on all platforms. I'm all for fixing this, but I need some kind of documentation that say how things should be. Not random apps that says random things 😄 (and builds of ffmpeg that behave differently) |
OK
How could I sync them all?
We will then have to dive into FFMPEG, video codecs, etc... but I agree that what I did was experiment and somehow guess what was happening, not really checking that it was wrong and how it should be. |
|
So, the issue seems to be ffmpeg version, if I upgrade ffmpeg to 4.4.5 then your PR actually does something. ffprobe is ok and kdenlive accepts the file. Only This is on my macbook. |
Well, that's great, a step forward... I checked my ffmpeg version and is 4.4.4
Funny, I checked if only one was needed and end up thinking both were needed, but there is a chance I didn't test all options and I was wrong.
And what version are we running on Friction packages? as you said it would make sense to sync to the version used on the packages so that this kind of errors doesn't happen. Knowing this version number would help us finding the problem and maybe proposing a solution that works no matter what ffmpeg version we are using, right? Another option would be to upgrade the packages to ffmpeg 4.4.5 but I don't know if that would break something more... |
|
It seems there is a big leap from ffmpeg 4.2 to >4.4 regarding the subject (copied from ChatGPT): FPS-Related Changes Between FFmpeg 4.2 and 4.4Between FFmpeg 4.2 and 4.4, there were significant improvements regarding the handling of framerate (FPS) information, both when reading and writing video headers. This mainly affects how FFmpeg detects, preserves, and reports CFR (Constant Frame Rate) vs VFR (Variable Frame Rate) content. Notable FPS & Header Related Improvements in FFmpeg 4.41. Better CFR vs VFR Detection
2. Header Preservation when Remuxing
3. New Warning Messages
4. Improved
|
| Feature | FFmpeg 4.2 | FFmpeg 4.4 |
|---|---|---|
| CFR vs VFR detection | Basic and sometimes inaccurate | More accurate and robust |
| FPS in headers | Often forced to CFR | Better preservation of actual FPS (CFR or VFR) |
| Remuxing behavior | Could flatten VFR into CFR accidentally | Keeps true timestamps much better |
ffprobe output |
Could give misleading r_frame_rate |
Clear separation of r_frame_rate vs avg_frame_rate |
We use ffmpeg 4.2. There is a reason for this, 4.4 randomly stalls during end of render, so I decided to downgrade (don't remember when, think it was in 0.9.6 or 0.9.5). I also checked the commits in 4.4 vs 4.2 and I didn't find anything related to this issue in the encoder/muxer. Moving from ffmpeg 4.2 to 4.4 this late in the release process is a no-go from me. Only option would be to patch ffmpeg, but I don't know where the problem is (we only need to "fix" movenc, the rest is not important). |
Will check the commits in ffmpeg, at least I have something to look for 😄 |
I guessed it, if not you would have updated it... Have you ever tried with even more modern versions? they are in 7.x now.
Indeed! this is not an important bug, I mean, we can live without this, it can be studied and tested for v1.1..
If it's something easy/fast for you then go ahead, if not, let it go for v1.1, doesn't it? |
7.x removed deprecated functions, Friction will not build. For now I think it would be best to find the fix for mp4/mov in ffmpeg 4.4 and backport it, then focus on moving to ffmpeg 4.4 in Friction v1.1. After that we could look into fixing the deprecated stuff and move on to a newer version of ffmpeg if needed. Also note that ffmpeg supports their releases for a long time, so going beyond 4.4 is not a big priority unless it fixes something in Friction. |
|
In the meanwhile, I'm going to try to find a fix for Friction rendered videos that is compatible with ffmpeg 4.2... |
|
Proposed a new PR that looks to work fine: #598 |
It's a pretty simple fix but I think it solves the problem as not just kdenlive but HandBrake and ffprobe are reading Friction rendered video with not a rounded and exact/constant FPS as the one set at your scene.
I'm not expert in this field so I used chatGPT to help me so, please, have a look at it if this is a nice solution o not as it works for kdenlive, HandBrake and ffprobe but I don't know if somehow we could be breaking the videos....
ChatGPT says this about the proposed fix: