I thought I was seeing some jumping in the exported video and checked the frame rate of my exported video using Windows 10 properties.
The export setting framerate was 29.970030 which matched the video on the playlist -
The framerate on the exported file as reported under Property/Details on Windows 10 was 30.06 -
Using ShotCut 21.03.21 the exported file was 29.97 as expected -
Subjectively, it appeared that the video from version 21.03.21 was smoother with less hesitation.
Not being an expert on things like this, I’m curious as to what I’m overlooking.
If you bring the exported file back into Shotcut and check its Properties, does it say 30.06 or 29.970030? Wanting to rule out if Windows Properties is seeing something different than Shotcut Properties.
These are great suggestions and I really appreciate the help. It turns out that framerate 30.06 was rounded by Windows. The actual framerate reported by ShotCut is 30.057152.
No, nothing unusual. I edited a 2 minute package with version 21.03.21 and decided after it was finished to upgrade to 21.09.20 and make sure it would create the same video. The file size and data rate where slightly different. When I went to Properties Details I saw that the frame rate of version 21.09.20 had gone to 30.009512 (from 29.970030) even though nothing else (apparently) had changed.
Sometimes Shotcut doesn’t properly detect variable frame rate files, and this might be one of these times. There is a free software I use to see all details of a file. It’s called MediaInfo.
Here is an example of what it shows, from the same file I have shown above in Shotcut.
Thank you for recommending MediaInfo. Very interesting! MediaInfo reports that the frame rate of both the source and exported video file is constant and at the exact rate that ShotCut is set for. So, Windows says it’s slightly high, ShotCut agrees when the exported file is put back into the playlist, and MediaInfo says everything is OK. I’m going to add vsync=cfr as Austin suggests and maybe everything will agree. Wouldn’t that be nice?
I’m using vsync=cfr with version 21.09.20 and the anomaly hasn’t changed. Hudson555x recommended Mediainfo and to my surprise, it reports 29.970 fps as expected. That same video re-entered into ShotCut shows a slightly faster framerate. (as shown) This is well above my knowledge level to justify the difference.
All I know is that ShotCut version 21.03.21 produces files where the framerate reads as expected on both products.
Thanks again for your help. I would be interesting if this can be reproduced. The test is run on Windows 10 with a single 11 second clip in the playlist to be exported. Version 21.09.20
I reproduce this as a bug in the integration of the FFmpeg libraries after updating the code to fix compile failures against their latest code where they have removed most deprecated things.
“vsync” does not work because that is a ffmpeg command line option and not an API AVOption, and Shotcut needs to use the library and not the command line tool.
As a workaround I found that if I change the format to matroska then the problem goes away. It seems that anything based on mov or mp4 suffers this problem. For example, also ProRes and DNxHR, and besides Matroska also that works is WebM (based on Matroska) or things in AVI like MJPEG or MPEG-2 program stream.
I’m seeing this warning in FFmpeg documentation now:
Note: the old undocumented way of specifying per-stream AVOptions by prepending v/a/s to the options name is now obsolete and will be removed soon.
To me, this suggests that ab and acodec and vcodec would start to break where ffmpeg is invoked for reversing or converting source videos. I’m also worried vprofile=dnxhr_hq would no longer be available in the Advanced > Other tab. I tried to replace it with profile:v:0=dnxhr_hq but got this error:
[dnxhd @ 0x7f4cb400f4c0] video parameters incompatible with DNxHD. Valid DNxHD profiles:
Do you happen to know which version of FFmpeg the transition takes place? I assume Shotcut is still building against 4.2 based on build-shotcut.sh.
MLT is not affected by this because it uses the prefix to select the corresponding muxer or codec and then removes the prefix before applying the AVOption.
profile:v:0
MLT does not use the ffmpeg command line stream selector syntax.
This problem is fixed for the next version or nightly build.
The problem is that we are stuck on a slightly older version of FFmpeg for compatibility reasons (v4.2) and the mp4/mov muxer in that version was not completely ready for the removal of the deprecated bits. The current code worked on FFmpeg v4.4 and git master branches but not v4.2. I had to add a little compatibility shim in the MLT code. I also recently purchased a used, old machine that has the same CPU as someone who was adversely affected by our previous attempts to upgrade FFmpeg - so that I can try to work through that compatibility issue.
