[CinCV TNG] H.264 export broken - users should be aware
sitelve at gmail.com
Thu Oct 22 11:46:07 CEST 2015
If I understand you correctly, you're planning to stay on the 2.8.*
stable-version of ffmpeg. So ?
Currently we have 2.8.1 (stable) and 2.9-dev
And CVE works with 2.8.1 (I compiled yesterday).
How will behave CinCV if the company source.ffmpeg.org will release a new
stable version of the ffmpeg (for example 2.9-stable) ?
Will CinCV to load (automatically during new compilation) a new
version of ffmpeg
2.9-stable or CinCV will work with the old version of ffmpeg 2.8.* ?
Compiling with external ffmpeg is currently is not officially supported.
The option (in ./configure) exist but no works.
Do you plan to introduce this possibility ?
2015-10-22 12:00 GMT+03:00 Einar Rünkaru <einarrunkaru at gmail.com>:
> On 21 October 2015 at 23:16, igor_ubuntu <sitelve at gmail.com> wrote:
>> I suggest options for ./configure
>> -- disable-updating-ffmpeg
>> -- updating-only-stable-ffmpeg
> The current behavior is to check out the last commit from ffmpeg branch
> 2.8 when the directory <cinelerra_root>/ffmpeg does not exist. When the
> directory does exist, configure does not make any attempt to download
> I expect that fixes in released versions are only bugfixes and api does
> not change. User can upgrade ffmpeg when he/she thinks that improves
> something. I think that this situatioin will be quite rare.
> Expert user can download any version of ffmpeg and put it into
> <cinelerra_root>/ffmpeg. This does not conflict with configure.
> <cinelerra_root>/.configure sould be run after changing ffmpeg because it
> attempts to configure the internal ffmpeg. Users should be aware that
> cinelerra with such a custom ffmpeg may not compile - api changes are
> relatively frequent.
> When you configure with external ffmpeg nothing is downloaded.
>> 2015-10-21 23:09 GMT+03:00 Johannes Sixt <j6t at kdbg.org>:
>>> Am 20.10.2015 um 19:44 schrieb Einar Rünkaru:
>>>> On 10/20/2015 07:41 PM, Sérgio Basto wrote:
>>>>> Also if I clone today and you clone tomorrow we
>>>>> may have different results , which is not good for testing .
>>>> Yes, this is a problem. But our goal is not to fix ffmpeg, but
>>>> cinelerra. When we discover a bug in ffmpeg we send patch to them. When
>>>> we don't understand where the problem is, we can agree what commit we
>>> This looks like a candidate for a git submodule: The Cinelerra tree
>>> records a "preferred" ffmpeg commit to check out. But users can always
>>> change the checked-out version to a different one, if the like and know how
>>> to handle the case.
> My goal is to keep cinelerra compatible with multiple versions on ffmpeg.
> So the prefferred commit is overkill.
> Cinelerra mailing list
> Cinelerra at lists.cinelerra-cv.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cinelerra