[kdenlive] [Bug 476716] Kdenlive Fails to Generate Proxy Clip from Stabilized Clip
https://bugs.kde.org/show_bug.cgi?id=476716 BoffinBrain changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #8 from BoffinBrain --- (In reply to Jean-Baptiste Mardelle from comment #6) > Looks like you are working with an interlaced project profile, is that > correct? That's even more puzzling. It definitely isn't, and neither are the source files. Here's the project settings: > Frame size: 1920 x 1080 (16:9) > Frame rate: 50 fps > Pixel aspect ratio: 1 > Color space: ITU-R 709 > Interlaced: no Here is the MediaInfo data for one example clip in my project: > General > Format: MPEG-4 > Format profile: Base Media > Codec ID : isom (isom/iso2/mp41) > File size : 22.8 MiB > Duration : 12 s 563 ms > Overall bit rate : 15.2 Mb/s > Writing application : Lavf59.16.100 > Video > ID: 1 > Format: HEVC > Format/Info : High Efficiency Video Coding > Format profile: Main@L4.1@Main > Codec ID : hev1 > Codec ID/Info : High Efficiency Video Coding > Duration : 12 s 563 ms > Bit rate : 15.1 Mb/s > Width : 1 920 pixels > Height: 1 080 pixels > Display aspect ratio : 16:9 > Frame rate mode : Constant > Frame rate: 59.940 (6/1001) FPS > Color space : YUV > Chroma subsampling: 4:2:0 (Type 0) > Bit depth : 8 bits > Scan type : Progressive > Bits/(Pixel*Frame): 0.121 > Stream size : 22.5 MiB (99%) > Writing library : x265 3.5+36-9b59d4554:[Windows][GCC 11.2.0][64 > bit] 8bit+10bit+12bit > Encoding settings : (snipped for brevity) > Language : English > Color range : Full > Color primaries : BT.709 > Transfer characteristics : BT.470 System M > Matrix coefficients : BT.601 > Codec configuration box : hvcC > Audio > ID: 2 > Format: AAC LC > Format/Info : Advanced Audio Codec Low Complexity > Codec ID : mp4a-40-2 > Duration : 12 s 513 ms > Source duration : 12 s 534 ms > Source_Duration_LastFrame : -10 ms > Bit rate mode : Constant > Bit rate : 128 kb/s > Channel(s): 2 channels > Channel layout: L R > Sampling rate : 48.0 kHz > Frame rate: 46.875 FPS (1024 SPF) > Compression mode : Lossy > Stream size : 196 KiB (1%) > Source stream size: 196 KiB (1%) > Language : English > Default : Yes > Alternate group : 1 Here's the result of attempting to proxy with x264: > [libx264 @ 01fdc88392c0] height not divisible by 4 (1440x810) > Current Frame: 1, percentage: 0 > [swscaler @ 01fdccf33080] deprecated pixel format used, make sure you did > set range correctly > (repeated 8 times for 8 frames) Here's the result of attempting to proxy with NVENC H264/H265: > Current Frame: 1, percentage: 0 > [swscaler @ 01a3f7e62700] deprecated pixel format used, make sure you did > set range correctly > [swscaler @ 01a38ac97e00] deprecated pixel format used, make sure you did > set range correctly > [swscaler @ 01a38ac8ae00] deprecated pixel format used, make sure you did > set range correctly > [swscaler @ 01a38aca4dc0] deprecated pixel format used, make sure you did > set range correctly > [h264_nvenc @ 01a3f7991e80] Interlaced encoding is not supported. > Supported level: 0 > [h264_nvenc @ 01a3f7991e80] No capable devices found Proxying with MJPEG, MJPEG2 and ProRes works without any issue. Again, this only happens when proxying a stabilized .mlt clip. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476716] Kdenlive Fails to Generate Proxy Clip from Stabilized Clip
https://bugs.kde.org/show_bug.cgi?id=476716 BoffinBrain changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #5 from BoffinBrain --- I guess I'll just move the status to Reported for now, since I've provided all the info I can, and am willing to do further testing if anyone gets back to me on the issue. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476716] Kdenlive Fails to Generate Proxy Clip from Stabilized Clip
https://bugs.kde.org/show_bug.cgi?id=476716 --- Comment #3 from BoffinBrain --- I have some more diagnostic info that may help. The issue occurs when using regular x264, NVENC-x264 and NVENC-x265. The issue does NOT occur when using MJPEG (proxy clips generate successfully). This is a fine workaround for now, but doesn't explain why these encoders fail on MLTs when they work fine with the original clips. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476716] Kdenlive Fails to Generate Proxy Clip from Stabilized Clip
https://bugs.kde.org/show_bug.cgi?id=476716 --- Comment #2 from BoffinBrain --- (In reply to emohr from comment #1) > I tried with an 1080p50 clip, following your steps and it creates the proxy > clips. Maybe convert your clip to a user friendly format (right click on the > clip -> transcode to edit friendly format) and try again. While this technically works, it adds a bunch of extra steps to the workflow and the edit-friendly files are 100x the size of the original video. I'd really like to fix the root cause of the problem. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476716] New: Kdenlive Fails to Generate Proxy Clip from Stabilized Clip
https://bugs.kde.org/show_bug.cgi?id=476716 Bug ID: 476716 Summary: Kdenlive Fails to Generate Proxy Clip from Stabilized Clip Classification: Applications Product: kdenlive Version: 22.08.2 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: bugs@boffinbrain.com Target Milestone: --- SUMMARY When stabilizing a video clip, the resulting clip doesn't have a proxy and attempting to generate one creates errors. STEPS TO REPRODUCE 1. Enable proxy clips for your project. 2. Add a clip to the project bin. 3. Apply the Stabilize clip job. OBSERVED RESULT The stabilized video clip is added to the bin, but an error message shows beneath: "Failed to create proxy clip." The 'Show log' button presents the following info: Current Frame: 1, percentage: 0 [swscaler @ 01b31ecea100] deprecated pixel format used, make sure you did set range correctly [swscaler @ 01b32d2ec380] deprecated pixel format used, make sure you did set range correctly [swscaler @ 01b331e11a40] deprecated pixel format used, make sure you did set range correctly [swscaler @ 01b331fea040] deprecated pixel format used, make sure you did set range correctly [h264_nvenc @ 01b31a321800] Interlaced encoding is not supported. Supported level: 0 [h264_nvenc @ 01b31a321800] No capable devices found Right-clicking the clip and choosing Proxy Clip results in the same error. EXPECTED RESULT The stabilized clip should have a proxy. SOFTWARE/OS VERSIONS Windows 10 KDE Frameworks Version 5.110.0 MLT Version 7.21.0 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476659] Rendering a Reversed Clip is Extremely Slow
https://bugs.kde.org/show_bug.cgi?id=476659 --- Comment #2 from BoffinBrain --- > Can you code this? I wish I could, but that's way too low-level for me. I would imagine one possible way would be to use some extra memory to cache all the frames decoded between one I-frame and the next one to eliminate repeated seeking and processing of the same frames. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476660] New: Clicking on Menu Divider Closes the Menu
https://bugs.kde.org/show_bug.cgi?id=476660 Bug ID: 476660 Summary: Clicking on Menu Divider Closes the Menu Classification: Applications Product: kdenlive Version: 22.08.2 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: bugs@boffinbrain.com Target Milestone: --- SUMMARY When clicking a dividing line between groups of menu items (such as when barely missing a click on the menu item you want) the menu closes. This is unusual behaviour for a UI. Typically the user would expect it to stay open so they can try again. I don't know if this is specific to Kdenlive or an general issue with Qt/KDE on Windows. STEPS TO REPRODUCE 1. Click to open any menu (File, Edit, etc.) 2. Click on a dividing line that separates groups of menu items. OBSERVED RESULT The menu closes. EXPECTED RESULT The menu should stay open. SOFTWARE/OS VERSIONS Tested on Kdenlive 22.08.2 Windows 10 KDE Frameworks Version 5.110.0 Qt Version 5.15.10 (built against 5.15.10) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476659] New: Rendering a Reversed Clip is Extremely Slow
https://bugs.kde.org/show_bug.cgi?id=476659 Bug ID: 476659 Summary: Rendering a Reversed Clip is Extremely Slow Classification: Applications Product: kdenlive Version: 22.08.2 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: bugs@boffinbrain.com Target Milestone: --- SUMMARY When rendering a video that has a reversed clip, the reversed portion of the video takes an extremely long time. I understand that most codecs are designed under the assumption that videos are played in a forward direction and thus i-frames depend on the preceding frames, thus a lot of seeking is necessary if frames are requested in reverse order. However, in my testing I found that rendering regular video could be around 30fps while the reversed section would be approximately 0.5fps. Surely there are some optimizations we can make to this process, and perhaps they can be applied to within the editor too for faster playback. STEPS TO REPRODUCE 1. Add a clip to the timeline (recommended at least 5 seconds long) that's an MP4 video or similar. 2. Make a copy of it, place it after the first clip and reverse the clip. 3. Start rendering the project. OBSERVED RESULT Rendering the first half of the video is fast, while the second half is *extremely* slow. EXPECTED RESULT Speed for rendering the second half should ideally be within the same order of magnitude as the first half. SOFTWARE/OS VERSIONS Tested on Kdenlive 22.08.1 and 22.08.2 Windows 10 KDE Frameworks Version 5.110.0 Qt Version 5.15.10 (built against 5.15.10) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 465068] New: Typo in Contrast Adaptive Sharpen Filter - "Strenght"
https://bugs.kde.org/show_bug.cgi?id=465068 Bug ID: 465068 Summary: Typo in Contrast Adaptive Sharpen Filter - "Strenght" Classification: Applications Product: kdenlive Version: 22.12.1 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: Translation Assignee: j...@kdenlive.org Reporter: bugs@boffinbrain.com Target Milestone: --- Created attachment 155815 --> https://bugs.kde.org/attachment.cgi?id=155815=edit Screenshot of the filter options SUMMARY There's a small typo in the Contrast Adaptive Sharpen filter's parameter slider. 'Strength' is misspelled as 'Strenght' :) Screenshot is attached. SOFTWARE/OS VERSIONS Windows: 10 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 443614] Time Remapping panel has an unlabelled mystery button
https://bugs.kde.org/show_bug.cgi?id=443614 BoffinBrain changed: What|Removed |Added Platform|Other |Microsoft Windows OS|Other |Microsoft Windows --- Comment #2 from BoffinBrain --- Thank you too for maintaining the project. :) Yes, I forgot to add the platform to this one. Specifically it's Windows 10. Style and theme are default, and Breeze icons are on. I've just installed and tried 21.08.2, but there's still no icon on the button. I even uninstalled and reinstalled fresh, and made a new project just to be sure. I also tried the standalone version. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 443614] New: Time Remapping panel has an unlabelled mystery button
https://bugs.kde.org/show_bug.cgi?id=443614 Bug ID: 443614 Summary: Time Remapping panel has an unlabelled mystery button Product: kdenlive Version: 21.08.1 Platform: Other OS: Other Status: REPORTED Severity: minor Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: bugs@boffinbrain.com Target Milestone: --- Created attachment 142346 --> https://bugs.kde.org/attachment.cgi?id=142346=edit Time remapping blank button SUMMARY The Time Remapping panel has a square button in the bottom right with no label or tooltip. When pressed, it appears to simply disable time remapping on the clip without updating the checkbox state on the context menu. There appear to be a few other ways to cause desync or contradictions between the apparent state of time remapping (when looking at the flag on the clip context menu) versus the Time Remapping panel itself being enabled/disabled. See also: bug #443613. STEPS TO REPRODUCE 1. Enable time remap on a clip and open the Time Remapping panel. 2. Click the unlabelled button in the screenshot. OBSERVED RESULT Time remap panel is disabled but context menu erroneously indicates that it's still enabled. EXPECTED RESULT 1. Button should have a label/icon (perhaps the trash can icon?) and a tooltip, or be removed entirely. 2. Time remap checkbox state and panel state should stay in sync. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 443613] New: Time Remap is Unavailable when a clip's speed is not 100%
https://bugs.kde.org/show_bug.cgi?id=443613 Bug ID: 443613 Summary: Time Remap is Unavailable when a clip's speed is not 100% Product: kdenlive Version: 21.08.1 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: bugs@boffinbrain.com Target Milestone: --- Created attachment 142345 --> https://bugs.kde.org/attachment.cgi?id=142345=edit Screenshot of a clip that appears to have time remapping enabled SUMMARY When a clip has had its speed changed, Time Remapping can be enabled, but the Time Remapping panel will remain disabled which can cause major confusion. I encountered this when trying to use the new feature on an existing project. Additionally, If time remapping is in effect and the clip speed is changed, then the remap flag is still on and the panel is still enabled, until the clip is deselected. STEPS TO REPRODUCE 1. Add a clip to the timeline and set its speed to 120%. 2. Enable Time Remap from the clips's context menu. 3. Open the Time Remapping panel OBSERVED RESULT The panel is disabled. EXPECTED RESULT 1. The panel should be usable and the clip's speed is reset to 100%, OR 2. An error is shown stating that Clip Speed and Time Remap cannot be used at the same time, OR 3. Time Remap menu option is disabled, preventing step 2 (less desirable since it may not be clear why it's disabled). ADDITIONAL INFORMATION What should happen if we attempt to reset the clip speed to 100% and there is not enough space in the timeline? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 443611] New: Change Speed: Minimum Speed Error is unclear and doesn't show under some circumstances
https://bugs.kde.org/show_bug.cgi?id=443611 Bug ID: 443611 Summary: Change Speed: Minimum Speed Error is unclear and doesn't show under some circumstances Product: kdenlive Version: 21.08.1 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: bugs@boffinbrain.com Target Milestone: --- Created attachment 142344 --> https://bugs.kde.org/attachment.cgi?id=142344=edit Change Speed dialog with minimum speed error SUMMARY When a clip has another clip immediately after it and you open the Change Speed dialog, the Down button on the spinner is disabled and entering a new number lower than the current value automatically reverts it to the old value, but doesn't show an error. When sliding the slider down, you get the warning that the "Minimum speed is X" but it doesn't explain why. Ideally this error should show up after typing a number manually too, and it should state the reason why the speed cannot be reduced i.e. adjacent clip is in the way. While I was first learning to use Kdenlive I came across this issue multiple times and had to find out the cause of the problem by trial and error. Hopefully this change will make things easier for others. See also: bug #378104 STEPS TO REPRODUCE 1. Add a clip to the timeline and set its speed to 120%. 2. Add a second clip immediately after it. 3. Open up the Change Speed dialog of the first clip. 4. Type "100" into the speed box and press Tab. OBSERVED RESULT The speed gets changed back to 120% and no error is shown. EXPECTED RESULT The error should be shown AND the error message should explain that the minimum speed is X because of an adjacent clip in the timeline. ADDITIONAL INFO If you type "100" and press Enter instead, the dialog gets closed but nothing happens, which is also confusing because the user never gets to see the error. I'm not entirely sure how this should be handled. Perhaps keep the dialog open (disable the OK button). -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 442221] Smooth speed change with Time Remapping
https://bugs.kde.org/show_bug.cgi?id=442221 BoffinBrain changed: What|Removed |Added CC||bugs@boffinbrain.com -- You are receiving this mail because: You are watching all bug changes.
