https://bugs.kde.org/show_bug.cgi?id=410726
Steve <ulat...@yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ulat...@yahoo.com
--- Comment #1 from Steve <ulat...@yahoo.com> ---
Created attachment 128535
--> https://bugs.kde.org/attachment.cgi?id=128535&action=edit
an archive with 3 files that reproduce the problem
Enclosed is a *very* simple reproduction case. Extract this archive to some
convenient directory, replace all instances of CURRENTDIR with wherever you put
the .mlt and .wav file, and all instances of PROFILEDIR with your kdenlive
profile directory. You can move the customprofile32 file there, although I
don't think it affects anything.
Here are the parameters to mlt that I'm using:
xml:///CURRENTDIR/audio-artifact.mlt properties=WAV -consumer
avformat:audio-artifacts.wav ar=44100
The .mlt file literally plays one clip with a Gain filter and a
fade-in/fade-out. It's very simple.
At the end of the generated audio, there's a little glitch that's visible in
Audacity; it sounds like a "pop" sound. (Sometimes, my attempt to use kdenlive
to make audio for my video is filled with these artifacts, making it unusable.)
I spent most of today single-stepping through mlt in Qt Creator (mostly
consumer_thread() in consumer_avformat.c), inspecting memory, etc. in an
attempt to track down the source of this bug, but the audio being returned from
mlt_frame_get_audio() didn't look like the audio being output to the .wav file,
so I'm not sure how to track this. Hopefully you take this as evidence of a
good-faith effort to find the bug myself, and that someone that knows this code
better takes a look at my reproduction example.
I noticed two odd things that might be related to the bug:
1) filter_get_audio(), in filter_volume.c, sets the _previous_gain property to
the current
value of "gain" at the beginning of any volume change. That seems like it
would have a
non-intuitive effect on fade-in and fade-out, i.e. a 1-frame fade-in would
actually be
a 1-frame mute followed by a 1-frame fade-in, and a 1-frame fade-out would
actually be
1 frame of unaltered audio, followed by a 1-frame fade-out.
Since the artifact commonly happens after the clip's audio is supposed to be
faded out,
this may be related.
2) fps values are represented by floats and doubles. NTSC framerates are
fractional, e.g.
24000/1001 and 30000/1001 are commonly found. ffmpeg internally uses a
struct called
AVRational to avoid problems with fractional framerates.
Please, please, PLEASE look into this! The original forum post is almost 2 1/2
years old, and this artifact is ruining my ability to use kdenlive.
--
You are receiving this mail because:
You are watching all bug changes.
