Bug 387092 - Proxy clips interfere with rendering
Summary: Proxy clips interfere with rendering
Status: RESOLVED WORKSFORME
Alias: None
Product: kdenlive
Classification: Applications
Component: Video Display & Export (show other bugs)
Version: 18.04.1
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-19 01:22 UTC by accounts
Modified: 2021-03-30 04:33 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Original File proxied - clip properties (39.06 KB, image/png)
2018-10-24 08:18 UTC, Stephan Bolten
Details
Copied file proxied - clip properties (41.08 KB, image/png)
2018-10-24 08:20 UTC, Stephan Bolten
Details

Note You need to log in before you can comment on or make changes to this bug.
Description accounts 2017-11-19 01:22:23 UTC
When I have a project with proxy clips activated, and I render this project, certain clips are rendered as black.

When I deactivate proxy clips for the project, the project renders as expected.

Reproducible: Always

Steps to Reproduce:
1. Make a project
2. Enable proxy clips for one or multiple videos
3. Place a video in the timeline
4. Render
Comment 1 farid 2017-11-28 16:47:27 UTC
i cannot reproduce this. try using the latest version of kdenlive and see.
Comment 2 Stephan Bolten 2018-08-14 07:31:47 UTC
I have the exact same issue. If proxies are enabled some clips render black. If proxies are disabled (project or clip level) the render result is ok.

Always reproducible with one file, clean project. If needed I could provide the file.

kdenlive 18.04.01
MLT 6.6.0
OS Ubuntu 18.04


Current workaround: Before rendering switch off global proxy under project settings.

Regards,
Comment 3 Stephan Bolten 2018-08-14 08:06:22 UTC
Another finding:

Before proxying the file the clip properties show:
- Audio codec: AAC
- Video codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10

After proxying the file the clip properties show:
- Audio codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
- Video codec: AAC

Also bitrate, frequency is mixed up. If render process takes these values into consideration it is obvious that the result is black.

This odd behavior does not apply to clips where proxy + render is working properly.
Comment 4 emohr 2018-08-14 11:02:16 UTC
Interesting. Keep the Kdenlive project file before and after that happen. Keep all the footage. Notice exactly the step you have done which lead to this strange behavior.

Kdenlive 18.08 with MLT 6.10.0 will be released in the coming next days. After Kdenlive 18.08 is out try again. And post the result.
Comment 5 Stephan Bolten 2018-08-15 09:11:20 UTC
Out of curiosity I "installed" 18.08 AppImage on Ubuntu.
Using the footage in question I do now have a white screen if I place it in the project monitor.

Seems to be related to the footage I have.
Comment 6 emohr 2018-08-20 17:54:26 UTC
You have installed the refactoring branch.

The actual 18.08.0 AppImage version is here: https://files.kde.org/kdenlive/release/kdenlive-18.08.0-x86_64.AppImage.mirrorlist

Try end post the result.
Comment 7 Stephan Bolten 2018-08-20 19:18:50 UTC
Tried - unfortunately same result - proxy enabled - very fast rendering but black result. Proxies disabled - all ok.
Comment 8 Stephan Bolten 2018-08-20 19:28:36 UTC
(In reply to fritzibaby from comment #6)
> You have installed the refactoring branch.
> 
> The actual 18.08.0 AppImage version is here:
> https://files.kde.org/kdenlive/release/kdenlive-18.08.0-x86_64.AppImage.
> mirrorlist
> 
> Try end post the result.

Are you sure that this is 18.08? Looks like 18.04 - i.e. no automatic audio split when pulling a clip on the timeline.
Comment 9 emohr 2018-08-20 20:16:01 UTC
Yes. You have probably tested with 18.08 beta 18 (refactoring branch). Don’t test with this version as there are still some bugs. The refactoring update will come in December.

The 18.08.0 is just a small update of the existing code with mainly:
-	Fix custom lift/gamma/gain displaying wrong UI BUG: 364127
-	Require MLT 6.10 (to avoid the incompatible 6.8)
Comment 10 Jean-Baptiste Mardelle 2018-09-03 05:43:15 UTC
If the proxy clip is all black, it probably means the transcoding failed and the clip was converted to audio only. If you want us to investigate, please attach the project file here, and a short sample of the video clip could help too. You can extract 3 seconds from your clip with this command

ffmpeg -i yourclip.mp4 -c copy -t 3 cut.mp4
Comment 11 Stephan Bolten 2018-10-24 07:59:52 UTC
Extracting the 3secs from the file as suggested will change the source clip in a way that it will render successfully with PROXY=ON. 

On top: Using ffmpeg to duplicate the complete clip (ffmpeg -i yourclip.mp4 -c copy cut.mp4) results in an exact copy which (with PROXY=ON) renders successfully.

So it has to do with the clip coming directly from the camera (actually DJI GO App using DJI Gimbal on Android).

I will try to upload the original file (~150MB) but this might fail due to the size.

Regards, Stephan
Comment 12 Stephan Bolten 2018-10-24 08:17:43 UTC
Again only difference in the two files (original and copied) I can see is through "Clip Properties" when clips are proxied (as mentioned in comment 3 already).

Will attach two screenshots:
1) original file proxied - clip properties
2) copied file proxied - clip properties

Seems like I always have this issue with files from the DJI Go App with audio. Clips from the same app without Audio do not have this issue)

Regards,

Stephan
Comment 13 Stephan Bolten 2018-10-24 08:18:53 UTC
Created attachment 115866 [details]
Original File proxied - clip properties
Comment 14 Stephan Bolten 2018-10-24 08:20:26 UTC
Created attachment 115867 [details]
Copied file proxied - clip properties

copied the whole file with 
ffmpeg -i orig.mp4 -c copy target.mp4
Comment 15 emohr 2018-10-25 16:12:00 UTC
The properties of the original file proxied looks “weird”. Do you have another camera/cell phone to test?
Comment 16 emohr 2021-02-28 16:48:56 UTC
This bug is outdated, all the timeline code was rewritten to avoid exactly this kind of issue.

As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved.
Comment 17 Bug Janitor Service 2021-03-15 04:33:36 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 18 Bug Janitor Service 2021-03-30 04:33:40 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!