Many render profiles are broken because of "unsupported audio codec" pcm_s16le.
System: Opensuse 12.1
kdenlive 0.8.2.1 from packman repo
libmlt++3 0.7.6 from packman repo
libmlt4 0.7.6 from packman repo
libavcodec52 0.7.11 from packman repo
libavcodec53 0.10 from packman repo
libavformat52 0.7.11
libavformat53 0.10
ffmpeg -codecs shows that pcm_s16le definitely *is* present.
Am I doing something wrong?
Thanks in advance.
Partially solved - I didn't look carefully enough at the output of ffmpeg -codecs, it appears that my ffmpeg setup only supports decoding and not encoding. I guess I have to figure out why this is the case.
David
OK, this is weird.
"ffmpeg -codecs" shows decode support but no encode support for pcm_s16le, but if I run the following command from the command line:
ffmpeg -i input_file.MTS -vcodec dnxhd -b 220000k -acodec pcm_s16le -r 29.97 output_file.mov
it works with no errors and generates an output file with pcm audio (verified with mplayer)
I'm not sure why this is happening, but for some reason ffmpeg seems confused about which codecs it supports. Is it possible to force kdenlive to render with pcm_s16le even though ffmpeg might be reporting that it is not supported?
Thanks..
I have the same problem, one of the profile says: unsupported audio codec pcm_s16le, but I know I had no such problems before. Maybe this?
http://www.kdenlive.org/mantis/view.php?id=2526
I will downgrade ffmpeg and I will check again.
After verifying this problem with the git versions of kdenlive/MLT/FFmpeg on both OpenSuse and Mint, I filed that bug report. I don't know for sure, but I'm guessing there might be some change in the way ffmpeg reports what codecs are present and kdenlive/MLT hasn't adapted to that. Just a guess...
A patch fixing the problem in MLT is ready, so this issue should be fixed soon.
Thanks for fixing it so quickly! I re-compiled and it's working now.
Hi everybody,
I still experience this issue with the new 0.9, using the packages from sunab stable repository on Ubuntu 12.04 64bit; no problems with the version compiled from source...
I also still experience this issue. I'm using kdenlive 0.9.2 and kubuntu 12.04. But not only trouble in pcm_s16le codec. Also error unsupported audio codec apperas almost to all of available profiles. It writes that there are no libxvid, libx264 video and pcm_s16le, libmp3lame audio codecs. Please fix it, because I can't encode files to any of most popular formats, except MPEG-2
Same thing here, now more codecs (libxvid, libx264, libmp3lame) doesn't work in 0.9.2 version from Sunab repos and Ubuntu 12.04. I would report a bug, but is not really clear to me where the problem comes from, seeing that kdenlive compiled from source doesn't present any issue. Probably the codecs shipped with Ubuntu are causing the issue, as they did almost in every version of Kdenlive I used before.
This considered, and to avoid similar problems with all the other distros, wouldn't be possible for you developers to include the codecs into the program (sorry for the technically poor language, hope you get the general sense), in order to have a binary version that always works?
Yeah me too on 32bit sunab builds I can't use x264 but can use mpeg2. Have the audio codec pcm_S16 error as well. On 64bit builds x264 is available but every codec crashes rendering. Total mess. Build script 64bit builds also crash rendering. All on 12.04 Ubuntu.
@ _PunK_
@ albe
have you installed livbavcodec-extra-53 packages? it isn't installed by default in Ubuntu (ans debian derivatives), it allows encoding in mp3 h.264 ...
then after installing it run the configuration wizard in kdenlive settings menu, and check for libmp3lame,libxvid4,libx264 among others in video codecs column.
@sunab
I am sure I installed libavcodec-extra-53 along with the 0.9 version, but it wasn't there anymore... maybe I'm getting old :) anyway, now I can use libmp3lame,libxvid4,libx264 but still can't use pcm_s16le.
Except for this little issue, the repository is great! Thank you!
Hi, albe
I looked at the pcm_s16le problem. I experience the same issue, and I've seen the same problem Drosky pointed out. libavcodec-extra-53 only exposes a decoding capability but it can encode too.
So it is related to ffmpeg version shipped with ubuntu (0.8.1). As a workaround you can edit manually the kdenliverc file in your home directory (in a hidden folder)
.kde/share/config/kdenliverc
At the end of the file there is a section called [unmanaged], add pcm_s16le to the audiocodecs line. The launch kdenlive, and will no more complain about pcm_16le. Same trick applies to other misreported codecs.
Important note : if you launch the config wizard (in kdenlive settings menu) it will erase your changes to the file.
Hi, sunab
That solved the problem, thank you.
So it was a problem with ffmpeg... do you think it would be technically possible to provide an integrated version of it with(in) Kdenlive in the future releases (I know it doesn't depends on you, just asking your opinion) as VLC and Mplayer do (I think...) ?
This would avoid this kind of problem that probably arise in other distros as well...
Sorry for the misspelling , post edited.
As for including ffmpeg, better said "libav" (now in debian and ubuntu), doesn't seem to be a good solution and it is against debian packaging philosophy. Vlc and mplayer depend on libav* packages, they don't embed special versions of it. Check it by yourself :
- vlc precise package
- mplayer precise package
Embeding libraries like this leads to a lot of duplication. A better way is getting this fixed upstream and wait for updates. This is first reason why I maintain kdenlive ppas. I it a modest contribution in bug tracking. More people can easely find bugs and report them.
This needs confirmation but is really seems that libav 0.8.1 is reporting wrong encoders list. Someone has ho fill a bug report ;)
Thank you for the explanation.
If things really go bad, I'll recompile from source.
Not sure if could make any difference or be of any use, but what about an 'alternative' version of the libav packages (or wathever else is nedeed to avoid problems) installed in /opt, or something like that?
In my opinion compiling from source is only needded in specifinc use cases. Packages exist for a good reason ;)
If things "goes bad" feel free to ask the forum. Kdenlive 0.9.x series are really a good one! There are bugs, no matter, let's fix them.
libav in /opt is a half baked solution (in my opinion). The better way would be writing a patch to address the issue and sending it to upstream and to ubuntu libav package maintainer. Welcome on board ;)
The .kde/share/config/kdenliverc edit method works for me too.
@ Sunab
Thank you!
Yes, let's squash the bugs! I would really like to be able to write a patch, for now I'll just keep on reporting issues here on the forum, while trying to figure out how to properly report a bug.
@sunab
Thank-you so much - the .kde/share/config/kdenliverc file was not including libmp3lame for me, but manually including it makes it work beautifully. There defintely seems to be someting wrong with how the encoders are being reported...
Thanks once again!
@sunab
Thanks for the tip.
Including the pcm_16le codec in the kdenliverc enabled many profiles that were disabled before. However, there's no sound when rendering in AVI - just noise. Rendering in MP4 works very nicely though.
Kdenlive 0.9.3 - KDE 4.8.5 - Kubuntu 12.04
I still have this problem.
At first I did find this issue in mantis marked as fixed: http://www.kdenlive.org/mantis/view.php?id=2526
As recommended there I had someone helping me to change to this git version (I am new to linux).
When this was installed the problem was still there. So we did change kdenliverc and it worked.
But with this new version I had some major crashes so I switched back to Version 0.9.2.
kdenliverc still has pcm_s16le written in it but it does not work...
Any ideas?
Thanks in advance!
I am using Fedora 17 and the file .kde/share/config/kdenliverc doesn't seem to exist on my computer. Nor did a search of the entire hard drive find anything.
What can I do to fix that?
"At first I did find this issue in mantis marked as fixed: http://www.kdenlive.org/mantis/view.php?id=2526"
Looking at that mantis report it seems to me that it is fixed by a fix in mlt not in kdenlive.
So when it says "Fixed in Version Recent git => 0.9 " I am thinking it is meaning fixed in ver 0.9 or higher of the melt / mlt video frame work.
My melt is 0.8.2
$>melt -version
$ melt 0.8.2
And I find that I need to do the kdenliverc edit to fix this issue with kdenlive 0.9.2 and melt 0.8.2
Upgraded to Kdenlive 0.9.3 and melt 0.8.6 from http://ppa.launchpad.net/sunab/kdenlive-svn/ubuntu precise main
And I find that I still need to do the kdenliverc edit to fix this issue with kdenlive 0.9.3 and melt 0.8.6
But I have not got to melt > 0.9 yet !
But on the other hand I guess I can't get to 0.9 of melt because Wed, 14 Nov 2012 ver 0.8.6 was released. So 0.8.6 would be the most recent I guess.
So I have to conclude that the mantis bug being closed is bogus. Might see what can be done to reopen it.
Just wanted to add, that I'm having the same problem here.
I was about to either reopen the issue #2526 (http://www.kdenlive.org/mantis/view.php?id=2526), but then maybe it's something else causing pcm_s16le to not show up now?
Anything we could do/help to track this problem down with the above mentioned versions?
I did find a workaround. Instead of using the rendering option of kdenlive you could use "melt" in the command line.
This is the command that I use:
melt input.kdenlive -consumer avformat:output.avi vcodec=ffv1 acodec=pcm_s16le
But this is a workaround - and I really would prefer the bug to be fixed.
I've just found several closed reports on mantis and a new, recent one (~15 jan 2013): http://www.kdenlive.org/mantis/view.php?id=2943
Seems like this issue ain't fixed :(
Has anyone managed to export with pcm_s16le with the current version (0.9.4) yet?
Anything we could do to help tracing it down?
Just wondering, how does kdenlive (or MLT, I'm not sure which) determine what audio codecs are avaiable? Does it use something akin to "ffmpeg -codecs". If I know how it is trying to determine the available audio codecs, maybe it will help debug the problem. ffmpeg -codecs shows that pcm_s16le is present. Right now I can't render to my required formats and it worked on Opensuse 11.4, also with packages from Packman repository.
Thanks,
David