[Kdenlive-devel] profiles.xml in svn is outdated
Dan Dennedy
dan at dennedy.org
Fri Nov 20 19:58:30 UTC 2009
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-+
More information about the Kdenlive
mailing list