Version of Kdenlive where bug is still present: 19.11.80 (it's not present in versions list for reporting, so I chosen "git-master" as the closest). The bug appeared as early as 19.04.2 at least. To reproduce (100% repeatability): - Open "Project" -> "Render" menu. - Select "MP4 - the dominant format" format (doubtfully that is mandatory step). - Press "Create new profile" button. - Enter any Profile name (let's say "test"), in "Parameters" field change "acodec" parameter value to something mistaken, let's say "acodec = bbc". - Press OK. - Newly created format will be shown in the list with a star but without red highlighting due to erroneous parameters. Upon some actions later (for example, upon changing project profile and saving the project), the format will be reevaluated, so "Rendering" window finally will have the format marked as erroneous by red highlighting. Actually, there are two bugs which implicitly report the same problem: 384148 and 411261. I would not like to create duplication, but considering how titles of both are formulated, I believe the essence of the problem will continue to be slipped away until explicitly titled bug report would appear.
Maybe there are two bugs here. In my bug report, kdenlive complains that "f=mkv" is an unsupported video format -- but editing and resaving the profile clears the error, and I know that "f=mkv" is indeed supported and valid because I can then do a render and the resulting file is an MKV file. I can reproduce the problem you're seeing, though, with "acodec=bbc", and that error is also cleared by editing and resaving the profile. Interestingly, I can still render a clip with acodec set to an invalid value -- it just results in a file with no audio stream. So, bug 1 is that saving a profile clears errors on it and doesn't do validation. Bug 2 (pertinent to my work) is that it thinks "f=mkv" is invalid when it isn't really. The validation isn't correct. But, it is correct when it thinks "acodec=bbc" is invalid.
I've just poked at the source code to see what's up, and I note the following: * All of the code involved is found inside src/dialogs/renderwidget.cpp. * The validation is done by RenderWidget::refreshView, based on ambient supportedFormats, acodecsList and vcodecsList. * There is a probable bug in that if acodec fails validation, then it sets the item background to red, and this line is missing for when f and vcodec fail validation. * The ambient list of supported codecs/formats is populated in RenderWidget::checkCodecs by asking the MLT consumer: consumer->get_data("vcodec"), consumer->get_data("acodec"), consumer->get_data("f"). Therefore, if "mkv" isn't in the supported list, it's possibly an MLT bug, MLT isn't reporting a format it actually supports. I took a peek at the MLT codebase but I can't see any way to quickly identify how consumer->get_data("f") gets its values. * The validation should probably be done within RenderWidget::parseProfiles, as all of the different methods that involve changes to the profile list funnel down to this.
I have an update from the MLT team. MLT is passing the format value to/from FFmpeg under the hood. When you ask MLT what "f" values it supports, it asks FFmpeg, and from what I've been told, FFmpeg doesn't include "mkv" in the list. It _does_ include "matroska" in the list. So, it's actually correct for Kdenlive to report in the UI that "mkv" isn't a supported format. I have been using it _anyway_, not realizing this, because the bug you describe here allows me to bypass that validation. It just so happens that if you ignore FFmpeg and say "mkv" _anyway_ then it, well, does the right thing and still produces a Matroska file. I will update my bug report correspondingly and close it.
Hi, thanks for your report! Is this report still valid/relevant? Recently there have been some fixes for the parameter handling that are in master/nightly (not sure if they made it to 21.04…)
I just checked in the latest nightly build (21.07.70-3ea8bbc), the bug is still reproducible exactly by the steps in initial bug report.