Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002586KdenliveMLTpublic2012-04-19 13:232012-05-05 21:33
Assigned To 
PlatformAMD Athlon(tm) 64 X2 Dual Core POSRemix_OS (Puredyne/Ubuntu var.)OS Version12.03
Product Version0.8.2.1 
Target VersionFixed in Version 
Summary0002586: Audio sometimes stutters at start of playback
DescriptionI have some clips made by a camera with video capabilities by a friend of mine. They are in the format:

640x480 MjPEG
1 ch. 11024 kHZ 8-bit PCM audio

My processor can EASILY play this back in any video player I have in Linux. (I didn't realize the audio was so lo-fi.) I have a fairly standard script to pipe ALSA to Jack, and all the other output systems supported by KDEnlive also work. The first time I play an audio clip, it plays normally. Simply moving the cursor before the clip and playing it a second time causes the first fraction of a second to repeat, and presumably the audio to be slightly out of sync for the remainder of the clip. It happens every time I try to play a clip for the second time or more. For me, right now, proxy clips do not work; but I do not think I should have to use proxy clips and reencode my entire video just for the sound to work right. This might be crucial, when someone is trying to align a clip with a sound, and the sound isn't obvious from the waveform. Other than that, I really haven't pushed it enough to get other glitches yet.

As a practical matter, this is not of much annoyance to me. I believe this has already been mentioned in this thread:

http://kdenlive.org/forum/clip-stutters-playback [^]

and it claims there is already a bug report about it; but the closest one I found was a case where somebody was asking a lot of the CPU, and it wouldn't quit stuttering once it had caught back up. I can play these videos back without a hitch in ALSA or Jack in other media players. While the thread at the above link mentions that proxy clip generation also fails, and I have double checked that I have found two posts that list all the libraries required to make proxy clips, they still don't work. I haven't filed a bug on this yet, as it is sure to get fixed sometime; but for me, the majority case is to not have to use them.

I think if KDEnlive audio is stuttering at the beginning of clips which play right in most players, and CPU bandwidth doesn't begin to be an issue, I think KDEnlive is doing something wrong. This is happening in all audio subsystems for me, and yet it isn't codec bandwidth, since the first time plays right. If it plays right the first time, just make it do that again, if someone who knows how kindly would. =)
Steps To Reproduce1) play a clip with audio, in my case 640x480 MjPEG, 1 ch. 11024 kHZ 8-bit PCM audio
2) play it again
TagsNo tags attached.
Build/Install MethodDistribution package
Attached Files

- Relationships

-  Notes
CodeLurker (reporter)
2012-05-05 21:33

I've done more more testing on this issue. Its severity should now be higher than minor. I had assumed that this audio problem was reflected in playback only, not in the final product, due to a posting making that claim. This is not the case. More testing reveals garbage in the audio that sounds like bad compression artifacts that is present in the final audio, whether using mp2, libmp3lame, or flac. In order to get libmp3lame to work in ffmpeg, I had to install "libavcodec-extra-52", which wanted to create dependency hell, and uninstall a whole bunch of things. I resisted for some time, but finally bit the bullet. It uninstalled KDEnlive, Bombono, and a bunch of other stuff. I then reinstalled them, and wonder of wonders, Synaptic didn't try to uninstall libavcodec-extra-52. That also allowed me to create proxy clips to test how well they solve this problem. The artifacts decreased, but they did not disappear. I can confirm that even proxy clips do not solve KDEnlive's audio rendering problems - at least on my system. These artifacts sometimes seem to still be there when replaying a clip, but may change when I choose "Reload Clip". They are best observed in material that is intermittently loud punctuated by periods of silence. Sometimes, upon loading a project, they don't seem to be there, or aren't there much, but seem to show up later after further editing. These artifacts might be unreleated to the stuttering thing, as the stuttering at the beginning of clips doesn't seem to show up in the final result. I would not be against someone wanting to split this into two bugs: stuttering at the beginning of clips that does not show up in the final product, and bad mp3-sounding artificts that do, but it might be better to keep them together, as they might be related - so I have reported it this way.

- Issue History
Date Modified Username Field Change
2012-04-19 13:23 CodeLurker New Issue
2012-05-05 21:33 CodeLurker Note Added: 0008009

Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker