Thread: [Mlt-devel] Problem with volume effect
Brought to you by:
ddennedy,
lilo_booter
From: j-b-m <j-...@us...> - 2008-11-06 22:40:51
|
Hi. There is a problem with the volume effects (normalize/filter_volume.c) that we use in Kdenlive for audio fades. This effect caches the gain of the last read frame in a value called "previous_gain". The problem is that if you seek through the file, this value is completely wrong. Also, if you save the playlist when in the middle of the effect, it will save that value and use it as a value for the first frames of the effect when you try to play the file in inigo for example. This results in inappropriate volume changes and breaks our audio fades. I do not really understand why that value is cached. I tried to completely remove the usage of this cached value, and everything seems to work fine. So I would like to request that we either: 1- remove all reference to that previous_gain value or 2- also store a previous_pos value that keeps the last frame position so that is we seek the filter can detect that the cached gain should not be used (for example clear it if previous_pos > pos, etc). I can provide a patch for the chosen solution regards jb |
From: j-b-m <j-...@us...> - 2010-08-31 21:15:27
|
Hi! Playing with the volume effect (Kdenlive bug 1785), I discovered a problem, and not sure if it is a bug that can be fixed or a limitation of the MLT framework. When applying 2 volume effects on the same place, only the last effect will be used. It looks like instead of using the sound produced by effect one as input, the second effect uses the original soundtrack, meaning that the first effect is completely bypassed. Video effects do not have this limitation. For example, using the "lines" effect: melt myclip.mpg -attach lines width=80 num=1 -attach lines width=2 num=10 I attach 2 "lines" effects, and both effects can be seen on the resulting clip. However, when adding 2 volume effects: melt a11.mov -attach volume gain=.5 -attach volume gain=1 I would expect to have a final volume of 50%, but instead I get a 100% volume When using: melt a11.mov -attach volume gain=1 -attach volume gain=.5 The result is a 50% audio volume. As explained before, only the last volume effect seems to be effective. Does that seem fixable or is there a reason why MLT cannot do this? regards jb |
From: Dan D. <da...@de...> - 2010-08-31 21:39:13
|
On Tue, Aug 31, 2010 at 2:15 PM, j-b-m <j-...@us...> wrote: > Hi! > > (sending you a private since my message to the list was held because "The > message headers matched a filter rule" ... ) I have not been able to figure out what causes this! I looked over the mailman admin web UI and could not find anything. > Playing with the volume effect (Kdenlive bug 1785), I discovered a problem, and > not sure if it is a bug that can be fixed or a limitation of the MLT framework. > > When applying 2 volume effects on the same place, only the last effect will be > used. It looks like instead of using the sound produced by effect one as input, > the second effect uses the original soundtrack, meaning that the first effect is > completely bypassed. Yes, this will be easy to fix. Basically, there is a 'process' virtual function called for each frame prior to the real processing function. In this pre-processing function, the filter is computing some stuff and simply setting the "volume.___" properties such that multiple instances are overwriting each other. I have a pattern to remedy this. > Video effects do not have this limitation. For example, using the "lines" > effect: Some video filters could suffer from similar problems. We will just address them as they arise. -- +-DRD-+ |
From: Dan D. <da...@de...> - 2008-11-07 05:33:23
|
Thank you for bringing it to my attention, On Thu, Nov 6, 2008 at 2:51 PM, j-b-m <j-...@us...> wrote: > Hi. > > There is a problem with the volume effects (normalize/filter_volume.c) that we > use in Kdenlive for audio fades. > > This effect caches the gain of the last read frame in a value called > "previous_gain". The problem is that if you seek through the file, this value > is completely wrong. Indeed. The earliest use case of this was mostly for sequential processing and not serializing through the westley. > Also, if you save the playlist when in the middle of the effect, it will save > that value and use it as a value for the first frames of the effect when you > try to play the file in inigo for example. This results in inappropriate > volume changes and breaks our audio fades. Yeah, it is simple change to prevent it from serializing - preface it with '_' or '.'. > I do not really understand why that value is cached. I tried to completely > remove the usage of this cached value, and everything seems to work fine. So I > would like to request that we either: > > 1- remove all reference to that previous_gain value The purpose of this property is to create a more smooth volume ramp when you take advantage of animating the gain value using the end property as you are doing. Without it, from one video frame to the next the gain increase would look like a stair-step if you were to draw it as a line graph. > or > > 2- also store a previous_pos value that keeps the last frame position so that > is we seek the filter can detect that the cached gain should not be used (for > example clear it if previous_pos > pos, etc). I believe I properly reproduced it and committed the fix. Please let me know. -- +-DRD-+ |
From: j-b-m <j-...@us...> - 2008-11-07 09:06:42
|
On Friday 07 November 2008 06.33:18 Dan Dennedy wrote: > Yeah, it is simple change to prevent it from serializing - preface it > with '_' or '.'. Ok, had not realized that. > I believe I properly reproduced it and committed the fix. Please let me > know. Seems perfect, thanks. jb |