[kdenlive] [Bug 466232] Subtitles are drawn from wrong source when rendering projects in batch mode
https://bugs.kde.org/show_bug.cgi?id=466232 --- Comment #1 from Terry Hancock --- I did find a work-around: Since the MLT files have only the one reference to the SRT file source, it's possible to simply replace the temporary file listed with the correct sidecar SRT file from the projects directory, using a text editor. Once corrected, the batch runner will generate the videos with the correct subtitles, regardless of what project is open in Kdenlive. It's a bit of a hassle, but much better than running the jobs one-by-one. This sidecar SRT files exists after the first save of the project file after the subtitles have been added, so presumably some kind of hook could be used to update the script generate on what SRT file to reference, when the project is saved. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 466232] Subtitles are drawn from wrong source when rendering projects in batch mode
https://bugs.kde.org/show_bug.cgi?id=466232 Terry Hancock changed: What|Removed |Added CC||digita...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 466232] New: Subtitles are drawn from wrong source when rendering projects in batch mode
https://bugs.kde.org/show_bug.cgi?id=466232 Bug ID: 466232 Summary: Subtitles are drawn from wrong source when rendering projects in batch mode Classification: Applications Product: kdenlive Version: 22.12.2 Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: digita...@gmail.com Target Milestone: --- SUMMARY The SRT subtitling feature renders correct subtitles in the editor when viewing the project. However, if one uses the "generate script" feature in the rendering panel to create rendering jobs, and then attempts to queue these for later batch processing, they do not retrieve the subtitles from the correct source. The rendering process should pull them from the appropriate SRT sidecar file for each project to be rendered. Instead, what happens, is that the SRT file is pulled from the CURRENTLY-OPEN Kdenlive project in the editor. STEPS TO REPRODUCE 1. Create a video project in Kdenlive. 2. Create subtitles. 3. Open rendering panel 4. Generate MLT script to render the project 5. Save 6. Repeat steps 1-5 for a 2nd project 7. Queue the two scripts for rendering and render (note that the 2nd project is open in the editor at this point) OBSERVED RESULT Both rendered videos will use the subtitles from the 2ND project (so the 1ST project's subtitles will be wrong). Alternatively, if a new/empty Kdenlive project session is used to queue the batch rendering jobs, the files will have NO subtitles. If an unrelated project with SRT subtitles is open in the editor used to queue the jobs, that project's subtitles will appear in the rendered output. Etc. EXPECTED RESULT Each project should be rendered with the subtitles belonging to that project (which can be found in the .kdenlive.srt sidecar file stored beside each of them on the filesystem). SOFTWARE/OS VERSIONS Ubuntu Studio 20.04. Originally discovered in Kdenlive 20.12. Same behavior verified in 22.12.2 AppImage package. ADDITIONAL INFORMATION Examining the actual MLT scripts with an editor, the only SRT file reference I could find is to a temporary file (i.e. /tmp/.srt ). There's no reference to the correct sidecar file, although it is present beside the Kdenlive project file. I feel like this violates an encapsulation principle, in that I expect batched MLT jobs to be self-sufficient, not relying on information from the currently-open Kdenlive project. This seems to be true for other features, and the batch rendering feature seems to be useless without this expectation. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 414367] Edge Crop doesn't work on a track
https://bugs.kde.org/show_bug.cgi?id=414367 Terry Hancock changed: What|Removed |Added CC||digita...@gmail.com --- Comment #2 from Terry Hancock --- In the 19.12.3 version from the Ubuntu 20.04 distribution, this bug was resolved -- Edge Crop did work for me on tracks. In the 20.12.3 version for Ubuntu 20.04 from the PPA, it is broken (again?) -- Edge Crop does not work on tracks. Edge Crop does work on bin or timeline clips. The Transform effect did still work on tracks, so it's specific to Edge Crop. I ran into this after upgrading to the PPA, on an existing document, and then experimented with deleting and adding the effect to the bin clip, timeline clip, and track. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 417249] New: Kdenlive cannot render from command line
https://bugs.kde.org/show_bug.cgi?id=417249 Bug ID: 417249 Summary: Kdenlive cannot render from command line Product: kdenlive Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: digita...@gmail.com Target Milestone: --- SUMMARY Kdenlive LACKS any way to render from command line STEPS TO REPRODUCE 1. Open a terminal on a computer with Kdenlive fully installed 2. Type $ kdenlive my_kdenlive_edit.kdenlive --render (that's about the simplest interface I can imagine, anyway) OBSERVED RESULT Kdenlive opens the edit up in the GUI and waits for interaction. EXPECTED RESULT It should render the project file to the video file described in the project file, using the video settings profile from the project file, and all of the other default settings that would apply, and then exit. SOFTWARE/OS VERSIONS It appears to still be true in 19.12.x, based on current forum questions, but I have only actually tested it in 17.12.3 on Ubuntu Studio. ADDITIONAL INFORMATION I am of course aware of some workarounds for this problem. It's possible to render with MLT directly. Or to use the 'kdenlive_render' helper tool -- but both require lots of command line parameters requiring inside knowledge of the installation and project settings, which of course, kdenlive has access to. I had even considered using GUI automation tools to run this. But it really seems like this is an essential basic feature. Consider this conversation from your forum, which illustrates the complexity of workarounds for this: 'rendering from command line a kdenlive script' https://forum.kde.org/viewtopic.php?f=265=164334 Surely it would be fairly simple to implement this? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 395810] Allow replacement of selected clips on the timeline
https://bugs.kde.org/show_bug.cgi?id=395810 Terry Hancock changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||digita...@gmail.com --- Comment #1 from Terry Hancock --- This would be also be EXTREMELY USEFUL for animation and VFX workflow. I am aware of Kdenlive internal "proxy" system, but this ignores an important other reason for using proxies: sometimes the reason is that the final version of the shot is not yet available. Routinely, we create GL previz versions of shots, which can then be used for editing. But replacing these shots with the final renders (or even updated GL renders) requires a laborious process of re-cutting the new shot to match the old, which is just stupidly wasteful, from a workflow perspective. It should be possible to simply drop in the replacement shot and update the clips that refer to it. Clearly some error handling would have to deal with cases where the clip doesn't match the specs of the original clip, but most of the time, it will in this case. In fact, we do have a trick, which is to actually load a SYMLINK to the shot, then update the symlink at the file-system level to the corrected shot. Kdenlive doesn't know about this, though, and it doesn't update thumbnails or other things it technically ought to do. But I'll think you'll agree this is an ugly workaround! -- You are receiving this mail because: You are watching all bug changes.
