On Fri, Nov 20, 2009 at 1:15 AM, Peter Soetens <peter.soetens at gmail.com> wrote: > On Fri, Nov 20, 2009 at 01:19, Dan Dennedy <dan at dennedy.org> wrote: >> On Thu, Nov 19, 2009 at 6:00 AM, Peter Soetens <peter.soetens at gmail.com> >> wrote: >>> svn rev 4136 >>> >>> The export/profiles.xml file still uses acodec=aac, while the code in >>> src/renderer.cpp assumes that it uses acodec=libfaac. Just replace case >>> sensitive 'aac' with 'libfaac' in profiles.xml and it's fixed. >> >> We discussed this on the list already. I added the code in >> renderer.cpp when profiles.xml still read acodec=libfaac. Then, >> someone changed profiles.xml to acodec=aac - maybe because they had >> not updated to receive my code. In our discussion, I concluded that >> soon aac will be the norm and libfaac a welcome distant memory. What >> exactly needs "fixing?" That we need to continue to support both >> instead of just aac? > > For some time at least. My ffmpeg version (Ubuntu karmic, > SVN-r19352-4:0.5+svn20090706-2ubuntu2) requires libfaac (it's actually > libavformat that needs it).
I do not disagree. > If this is a particular old version, maybe the code in renderer.cpp > can be changed such that it does aac->libfaac if it detects the > libfaac in the params list. So just the other way around. I had read > on forums that libfaac was the new standard instead of aac, so I actually, that is backwards. FFmpeg team noticed libfaac code contains inconsistent licensing and can now only be enabled in a non-redistributable build configuration. Besides the faac implementation sucks big time. So, they accelerated adoption of the AAC encoder implementation from a Summer of Code project and included it in early July. I do not yet know about the quality of that implementation. > assumed profiles.xml needed changing. Yes, I agree the recent change from libfaac->aac should be reverted. >> >>> Also, it's quite annoying that you need to restart kdenlive after >>> running the Config Wizard in order to pickup the changes of installed >>> codecs. (same for picking up new profiles.xml ?) >> >> new profiles.xml? You mean you want kdenlive to automatically detect >> and load changes made to profiles.xml by another app? > > Maybe that's not the right workflow anyway. But when I add a format in > the transcode tab of the configure dialog, it does not show up in > Renderer. So it was the only way for me to play with adjusting codec Transcode preset is not the same as the Render profile. That's why you did not see it. :-) > parameters. I also don't like the in-row editing of the ffmpeg > parameters in transcode tab, I loose overview. I'd rather have a > multi-line dialog popup that can show the complete command line in one > glance. > >> >>> I was also hit by the sound issue on Ubuntu Karmic which is broken badly >>> (kdenlive freezes during playback) when the wrong deb packages are >>> installed. I finally settled with libsdl1.2debian-all. Also dv recording >>> seems to be broken. It can connect (the cam goes into play/paused') but >>> a next command just stops the cam. The display only shows >>> 'Initialising...' >> >> I will test it. > > Kino's dv grabbing works perfectly btw. I some versions of FFmpeg this year had some bad datastream probe heuristics for raw DV. I am wondering if our dvgrab | ffplay, which is what occurs under the covers, is failing due to this. >> >>> There's also a bug in the scroll bar of the Render widget (test it with >>> scrolling through the H.264 profiles) >> >> I think this is a Qt issue - most noticeable when you enable the info >> panel. Does that sound correct? If you turn off the info panel by >> clicking the i button does it scroll as you expect? > > No. It does not make a difference. You can remove the info tab and > shrink the size of the dialog, then you'll have the same effect again. -- +-DRD-+
