Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This makes two changes:
First, it respects the frame rate of the input file. There is in general no good way to convert footage that was shot in one framerate into a different one. The problem is worse for some transitions than others, for example 29.97 -> 30 is not a big problem, but 24 -> 30 will result in a choppy video. The first commit here just extracts the frame rate in the source footage and uses that for the output video. If you want to be perfectionists, you could also render the preroll video in a really high frame rate (at the moment it is in 29.97) so that it always converts nicely to the output fps (very high fps to lower fps also works well).
Second, it sets the output audio to 48 kHz. All video stuff always uses 48 kHz, but the current configuration produces videos with 44 kHz. I think the reason is that the preroll video uses 44 kHz and then that is presumably just used for the entire video.
Everything at best lightly tested, so definitely only for next year :)