https://bugs.kde.org/show_bug.cgi?id=411260
farid changed:
What|Removed |Added
Resolution|--- |UPSTREAM
CC|
https://bugs.kde.org/show_bug.cgi?id=411260
--- Comment #9 from Jonathan Gilbert ---
MLT master now has a fix for this issue, so as long as it has another release
before the next Kdenlive release, and Kdenlive updates to take that release,
this bug should be resolved. :-)
--
You are receiving t
https://bugs.kde.org/show_bug.cgi?id=411260
--- Comment #8 from Jonathan Gilbert ---
I actually have a further update. It seems this is more properly a bug in MLT,
because the XML standard says that attribute order should not be a semantic
difference -- that's why Qt 5 feels it is okay to start u
https://bugs.kde.org/show_bug.cgi?id=411260
Vincent PINON changed:
What|Removed |Added
CC||vpi...@kde.org
--- Comment #7 from Vincent PINO
https://bugs.kde.org/show_bug.cgi?id=411260
emohr changed:
What|Removed |Added
Ever confirmed|0 |1
Status|REPORTED|CONFI
https://bugs.kde.org/show_bug.cgi?id=411260
--- Comment #5 from Jonathan Gilbert ---
I did a bit more research. Kdenlive is using the Qt `QDomDocument` type to
represent an XML DOM in-memory while building the MLT script. It turns out that
between Qt 4 and Qt 5, this DOM representation got rework
https://bugs.kde.org/show_bug.cgi?id=411260
--- Comment #4 from Jonathan Gilbert ---
Alright, I have feedback from the MLT side. This appears to be a bug on the
Kdenlive side after all. When it generates the tag in the MLT
script, the parameters get reordered apparently randomly (maybe they're p
https://bugs.kde.org/show_bug.cgi?id=411260
--- Comment #3 from Jonathan Gilbert ---
With further experimentation, I have determined that the preset files in
question are sourced directly from the MLT release and aren't part of the
Kdenlive codebase. As such, I believe I need to take this issue u
https://bugs.kde.org/show_bug.cgi?id=411260
--- Comment #2 from Jonathan Gilbert ---
I have just done a follow-up test. It appears that if "f=mp4" is entirely
removed from the presets file (no 'f' option value specified), then a value
specified in the render format definition is in fact respected
https://bugs.kde.org/show_bug.cgi?id=411260
--- Comment #1 from Jonathan Gilbert ---
I have been reviewing the background of this report and tried to reproduce a
previous Kdenlive version producing an MKV file as I remembered. From fresh
installations of 17.12 and 18.12.2, I saw the same behaviou
https://bugs.kde.org/show_bug.cgi?id=411260
Jonathan Gilbert changed:
What|Removed |Added
Platform|Other |MS Windows
OS|Linux
11 matches
Mail list logo
