Bug 436832

Summary: Fade in/out not working on rendered output
Product: [Applications] kdenlive Reporter: Herr Irrtum <die-nmi>
Component: TranslationAssignee: Vincent PINON <vpinon>
Status: RESOLVED WAITINGFORINFO    
Severity: normal CC: julius.kuenzel
Priority: NOR    
Version First Reported In: 21.04.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Herr Irrtum 2021-05-09 17:48:03 UTC
SUMMARY
Fade in/out not working on rendered output

STEPS TO REPRODUCE
1. In the timeline stack two clips above each other (Use tracks V1 and V2)
2. Drag the left upper edge of clip in V2 a bit to the right to create a fade in
3. Drag the right upper edge of clip in V2 a bit to the left to create a fade out

OBSERVED RESULT

In the rendering result: As long as fading goes on, the clip beneath (v2) is not shown, just black. That's not the case in the realtime project monitor where V1 can be seen though. The moment the fade in the upper video is down to zero, the lower clip in V1 is abruptly 100% visible.

EXPECTED RESULT

The rendering result should be the same as what's shown in the project monitor: When fading the clip in v2, the content from v1 should start shimmering 
through instead of just showing a black nothing.


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
KDE Plasma Version: 5.21.5
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
MLT: 6.26.1

ADDITIONAL INFORMATION

Tested with 
  * Kdenlive 21.07.70 from git 
  * AND Kdenlive 21.4.0  (official arch package)
  
Both show the bug. 

The bug does not occur on 
  * Kdenlive 20.12.3
  
Tested on AMD ZEN Hardware with free MESA AMD graphics stack and Intel Hardware
with propriatary Nvidia graphics stack.
Comment 1 Julius Künzel 2021-05-10 19:01:13 UTC
Thanks for your report! What was your output format (render output like *.mp4, *.mkv)? Does choosing an other format solve this? Can you also please try to play the test project with the melt command line player and see if it happens there too? (See https://www.mltframework.org/docs/melt/ for more information on melt)
Comment 2 Herr Irrtum 2021-05-11 18:22:58 UTC
Thanks Julius for your quick comment.
Output formats I've tried: 
  * MP4/H264/AAC (my standard choice)
  * Webm (also run in the known low bit rate output problem here)

Melt test result soon.
Comment 3 Herr Irrtum 2021-05-11 18:47:53 UTC
When preparing my melt test I started from scratch with two images. 
The bug does not occur when fading images! 
So. Important to reproduce this bug: *You have to use video clips.*

Melt did produce exactly the same wrong result.

Here's the output for what it's worth.

```
$ LC_ALL=C melt bugreport.mlt

mlt_repository_init: failed to dlopen /usr/lib/mlt-7/libmltsdl.so
  (/usr/lib/mlt-7/libmltsdl.so: undefined symbol: XGetWindowAttributes)
mlt_repository_init: failed to dlopen /usr/lib/mlt-7/libmltrtaudio.so
  (librtaudio.so.6: cannot open shared object file: No such file or directory)
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|1=-10| |2= -5| |3= -2| |4= -1| |5=  0| |6=  1| |7=  2| |8=  5| |9= 10|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
+---------------------------------------------------------------------+
|               H = back 1 minute,  L = forward 1 minute              |
|                 h = previous frame,  l = next frame                 |
|           g = start of clip, j = next clip, k = previous clip       |
|                0 = restart, q = quit, space = play                  |
+---------------------------------------------------------------------+
[mp4 @ 0x7f850c200f40] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
[mp4 @ 0x7f850c200f40] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
[mp4 @ 0x7f850c200f40] Timestamps are unset in a packet for stream 1. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 0x7f850c200f40] Encoder did not produce proper pts, making some up.
Current Position:        937
```
Comment 4 Vincent PINON 2021-05-11 19:19:37 UTC
your latest log shows mlt-7, but Kdenlive 21.04 is not updated and targets mlt-6 (which should be co-installable?). We do have a MLT7 branch for Kdenlive, but it misses features that have been ported to new API.
But this is not the problem here as melt fails alone.
And your initial report show mlt libraries 6.26.1...
Comment 5 Herr Irrtum 2021-05-11 19:32:55 UTC
Solved!
I am sorry for having wasted your valuable time! Won't happen again!

(In reply to Vincent PINON from comment #4)
> your latest log shows mlt-7, but Kdenlive 21.04 is not updated and targets
> mlt-6 (which should be co-installable?). We do have a MLT7 branch for
> Kdenlive, but it misses features that have been ported to new API.

Ah! Thanks Vincent. This is an Arch Linux issue.

```
melt --version
melt 7.0.0
Copyright (C) 2002-2021 Meltytech, LLC
```

But kdenlive still reports Melt 6 in it's about dialog.
Arch has a separate melt package (which happens to be v.7) and for some reason I had installed it. There is also a "mlt6" package - and it's melt6 binary renders my example just fine!

So Vincenct was on point here. Again sorry. And thanks for helping anyway!