1:51 p.m.
2012/6/24 Julian Sikorski <belegdol(a)gmail.com>:
W dniu 24.06.2012 14:15, Nicolas Chauvet pisze:
> 2012/6/24 Sérgio Basto <sergio(a)serjux.com>:
>> On Qui, 2012-06-21 at 23:40 +0100, Sérgio Basto wrote:
>>> More seriously, have we any order to do that ? , for me seems:
>>>
>> I forgot at least gpac so updating the list :
>>
>> 1st - build gpac
>> 2nd - build x264 with bootstrap
>> 3rd - build ffmpeg-0.11
>> 4th - build x264 without bootstrap
>>>
>> After that everything that depends on x264 or ffmpeg-0.11 or gpac.
>
> There is no reason for gpac to be before x264 with bootstrap since
> bootstrap means build x264 with minimal dependency (so without gpac
> and ffmpeg).
>
> Here is the plan
> 1st - build x264 with bootstrap
> 2nd - build ffmpeg-0.11
> 3rd - gpac
> 4th - x264 can be built without bootsrap
>
> but it's also possible to build x264 at the very end.
>
> Now the idea is to build vlc not that far so phonon application can
> have their backend installed at build time.
>
> Nicolas (kwizart)
>
I have posted a patch for vlc not so long ago, so a rebuild should not
be a problem once ffmpeg is in place.
Thx, but the fix existed back to March and
was fetched from the
upstream vlc repository.
At least, can you verify to have mplayer in sync with devel and F-17 ?
After the FFmpeg/x264 bootstrap is done, I will handle libquicktime
vlc and mjpegtools and leave others maintainers the oppotunity to
submit their rebuilt until tommorrow. (Then I will submit a rebuilt
job from the remaining FFmpeg/x264 dependencies).
Depending on how the rebuilt went , I will push package out then or
later this week.
Nicolas (kwizart)
2:22 p.m.
New subject: FFmepg rebuild Schedule ?
Hi,
Just a quick note, while doing a local build of all
deps to work on my ffmpeg dependent packages, I
noticed the following in x264's config.log file:
checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
Failed commandline was:
--------------------------------------------------
gcc conftest.c -m64 -Wall -I. -I$(SRCPATH) -O2 -g -pipe -Wall -Wp,-D_FORTIFY_S
conftest.c: In function 'main':
conftest.c:2:24: error: ignoring return value of 'malloc', declared with attrib
cc1: all warnings being treated as errors
--------------------------------------------------
Failed program was:
--------------------------------------------------
#include <gpac/isomedia.h>
int main () { gf_malloc(1); gf_free(NULL); return 0; }
--------------------------------------------------
I think we should fix this ...
Regards,
Hans
3:41 p.m.
New subject: FFmepg rebuild Schedule ?
On Dom, 2012-06-24 at 16:22 +0200, Hans de Goede wrote:
Hi,
Just a quick note, while doing a local build of all
deps to work on my ffmpeg dependent packages, I
noticed the following in x264's config.log file:
checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
Failed commandline was:
--------------------------------------------------
gcc conftest.c -m64 -Wall -I. -I$(SRCPATH) -O2 -g -pipe -Wall -Wp,-D_FORTIFY_S
conftest.c: In function 'main':
conftest.c:2:24: error: ignoring return value of 'malloc', declared with attrib
cc1: all warnings being treated as errors
--------------------------------------------------
Failed program was:
--------------------------------------------------
#include <gpac/isomedia.h>
int main () { gf_malloc(1); gf_free(NULL); return 0; }
--------------------------------------------------
I think we should fix this ...
checking for gpac/isomedia.h... yes
checking for gf_isom_set_pixel_aspect_ratio(0,0,0,0,0); in
gpac/isomedia.h... yes
checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
not have gf_malloc and gf_free , is problematic ?
what you suggest to fix ?
x264 builds without problem
Thanks,
--
Sérgio M. B.
7:50 a.m.
New subject: FFmepg rebuild Schedule ?
Hi,
On 06/24/2012 05:41 PM, Sérgio Basto wrote:
On Dom, 2012-06-24 at 16:22 +0200, Hans de Goede wrote:
> Hi,
>
> Just a quick note, while doing a local build of all
> deps to work on my ffmpeg dependent packages, I
> noticed the following in x264's config.log file:
>
> checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
> Failed commandline was:
> --------------------------------------------------
> gcc conftest.c -m64 -Wall -I. -I$(SRCPATH) -O2 -g -pipe -Wall -Wp,-D_FORTIFY_S
> conftest.c: In function 'main':
> conftest.c:2:24: error: ignoring return value of 'malloc', declared with
attrib
> cc1: all warnings being treated as errors
> --------------------------------------------------
> Failed program was:
> --------------------------------------------------
> #include <gpac/isomedia.h>
> int main () { gf_malloc(1); gf_free(NULL); return 0; }
> --------------------------------------------------
>
> I think we should fix this ...
checking for gpac/isomedia.h... yes
checking for gf_isom_set_pixel_aspect_ratio(0,0,0,0,0); in
gpac/isomedia.h... yes
checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
not have gf_malloc and gf_free , is problematic ?
No, x264 thinking it does not have them, while they are actually available is
problematic (I don't know if it is causing any real issues, but it is wrong).
Look at the error closely:
> conftest.c: In function 'main':
> conftest.c:2:24: error: ignoring return value of 'malloc', declared with
attrib
> cc1: all warnings being treated as errors
So the problem is that -Wall -Werror somehow is in the CFLAGS when the tests run,
causing the test to fail (where it should succeed)
what you suggest to fix ?
Fix the test code, changing it to something like:
void *p; p = gf_malloc(1); gf_free(p);
Regards,
Hans
5:01 p.m.
New subject: FFmepg rebuild Schedule ?
On Seg, 2012-06-25 at 09:50 +0200, Hans de Goede wrote:
Hi,
On 06/24/2012 05:41 PM, Sérgio Basto wrote:
> On Dom, 2012-06-24 at 16:22 +0200, Hans de Goede wrote:
>> Hi,
>>
>> Just a quick note, while doing a local build of all
>> deps to work on my ffmpeg dependent packages, I
>> noticed the following in x264's config.log file:
>>
>> checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
>> Failed commandline was:
>> --------------------------------------------------
>> gcc conftest.c -m64 -Wall -I. -I$(SRCPATH) -O2 -g -pipe -Wall -Wp,-D_FORTIFY_S
>> conftest.c: In function 'main':
>> conftest.c:2:24: error: ignoring return value of 'malloc', declared with
attrib
>> cc1: all warnings being treated as errors
>> --------------------------------------------------
>> Failed program was:
>> --------------------------------------------------
>> #include <gpac/isomedia.h>
>> int main () { gf_malloc(1); gf_free(NULL); return 0; }
>> --------------------------------------------------
>>
>> I think we should fix this ...
>
> checking for gpac/isomedia.h... yes
> checking for gf_isom_set_pixel_aspect_ratio(0,0,0,0,0); in
> gpac/isomedia.h... yes
> checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
>
> not have gf_malloc and gf_free , is problematic ?
No, x264 thinking it does not have them, while they are actually available is
problematic (I don't know if it is causing any real issues, but it is wrong).
Look at the error closely:
>> conftest.c: In function 'main':
>> conftest.c:2:24: error: ignoring return value of 'malloc', declared
with attrib
>> cc1: all warnings being treated as errors
So the problem is that -Wall -Werror somehow is in the CFLAGS when the tests run,
causing the test to fail (where it should succeed)
> what you suggest to fix ?
Fix the test code, changing it to something like:
void *p; p = gf_malloc(1); gf_free(p);
Hi, many thanks , I will review x264 ASAP , which means tonight or
tomorrow.
Best regards,
--
Sérgio M. B.
9:58 p.m.
New subject: FFmepg rebuild Schedule ?
Hi,
On Seg, 2012-06-25 at 09:50 +0200, Hans de Goede wrote:
Hi,
On 06/24/2012 05:41 PM, Sérgio Basto wrote:
> On Dom, 2012-06-24 at 16:22 +0200, Hans de Goede wrote:
>> Hi,
>>
>> Just a quick note, while doing a local build of all
>> deps to work on my ffmpeg dependent packages, I
>> noticed the following in x264's config.log file:
>>
>> checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
>> Failed commandline was:
>> --------------------------------------------------
>> gcc conftest.c -m64 -Wall -I. -I$(SRCPATH) -O2 -g -pipe -Wall -Wp,-D_FORTIFY_S
>> conftest.c: In function 'main':
>> conftest.c:2:24: error: ignoring return value of 'malloc', declared with
attrib
>> cc1: all warnings being treated as errors
>> --------------------------------------------------
>> Failed program was:
>> --------------------------------------------------
>> #include <gpac/isomedia.h>
>> int main () { gf_malloc(1); gf_free(NULL); return 0; }
>> --------------------------------------------------
>>
>> I think we should fix this ...
>
> checking for gpac/isomedia.h... yes
> checking for gf_isom_set_pixel_aspect_ratio(0,0,0,0,0); in
> gpac/isomedia.h... yes
> checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
>
> not have gf_malloc and gf_free , is problematic ?
No, x264 thinking it does not have them, while they are actually available is
problematic (I don't know if it is causing any real issues, but it is wrong).
Look at the error closely:
>> conftest.c: In function 'main':
>> conftest.c:2:24: error: ignoring return value of 'malloc', declared
with attrib
>> cc1: all warnings being treated as errors
So the problem is that -Wall -Werror somehow is in the CFLAGS when the tests run,
causing the test to fail (where it should succeed)
The problem is really: -Wp,-D_FORTIFY_SOURCE=2 with -Werror from
configure
> what you suggest to fix ?
Fix the test code, changing it to something like:
void *p; p = gf_malloc(1); gf_free(p);
I add this patch
http://cvs.rpmfusion.org/viewvc/rpms/x264/devel/x264-gf_malloc.patch?revi...
I will send it to x264-devel mailing list .
Thanks for point it and feel free to point more .
BTW, this detection problem is not new at all ,
x264-0.0.0-0.29.20110227.fc15 already had the same issue.
Thanks,
--
Sérgio M. B.
5:28 p.m.
New subject: FFmepg rebuild Schedule ?
W dniu 24.06.2012 15:51, Nicolas Chauvet pisze:
2012/6/24 Julian Sikorski <belegdol(a)gmail.com>:
> W dniu 24.06.2012 14:15, Nicolas Chauvet pisze:
>> 2012/6/24 Sérgio Basto <sergio(a)serjux.com>:
>>> On Qui, 2012-06-21 at 23:40 +0100, Sérgio Basto wrote:
>>>> More seriously, have we any order to do that ? , for me seems:
>>>>
>>> I forgot at least gpac so updating the list :
>>>
>>> 1st - build gpac
>>> 2nd - build x264 with bootstrap
>>> 3rd - build ffmpeg-0.11
>>> 4th - build x264 without bootstrap
>>>>
>>> After that everything that depends on x264 or ffmpeg-0.11 or gpac.
>>
>> There is no reason for gpac to be before x264 with bootstrap since
>> bootstrap means build x264 with minimal dependency (so without gpac
>> and ffmpeg).
>>
>> Here is the plan
>> 1st - build x264 with bootstrap
>> 2nd - build ffmpeg-0.11
>> 3rd - gpac
>> 4th - x264 can be built without bootsrap
>>
>> but it's also possible to build x264 at the very end.
>>
>> Now the idea is to build vlc not that far so phonon application can
>> have their backend installed at build time.
>>
>> Nicolas (kwizart)
>>
> I have posted a patch for vlc not so long ago, so a rebuild should not
> be a problem once ffmpeg is in place.
Thx, but the fix existed back to March and was fetched from the
upstream vlc repository.
At least, can you verify to have mplayer in sync with devel and F-17 ?
mplayer is in sync, I have submitted a build
After the FFmpeg/x264 bootstrap is done, I will handle libquicktime
vlc and mjpegtools and leave others maintainers the oppotunity to
submit their rebuilt until tommorrow. (Then I will submit a rebuilt
job from the remaining FFmpeg/x264 dependencies).
Depending on how the rebuilt went , I will push package out then or
later this week.
Nicolas (kwizart)
Regards,
Julian
8:04 a.m.
New subject: FFmepg rebuild Schedule ?
Hi,
I've done a local rebuild of the ffmpeg stack to prepare and test my packages
for the ffmpeg bump.
audacious-plugins-freeworld is committed and ready to build as soon as the
new ffmpeg is in place
gstreamer-ffmpeg is a problem, as upstream is using/supporting only libav and not
ffmpeg, and the 2 seem to have grown apart quite a bit API wise with the last ffmpeg
release. I've been looking at patching gstreamer-ffmpeg to build with ffmpeg rather
then libav, but the 2 really have grown too far apart, requiring too many changes,
which will surely introduce a lot of bugs.
Some examples of the issues are:
-ffmpeg no longer has URLProtocol and av_register_protocol publicly available, they
are still used internally so I've hacked around this, but this hack will require some
changes to our ffmpeg packages, to make the interfaces public again.
-AVCodec no longer has a palettectrl member, instead the palette now is passed as
data[1] to image read/write functions. Supporting this model requires major surgery
to gstreamer-ffmpeg
So we've 4 options:
1) Try to patch gstreamer-ffmpeg to build with new ffmpeg, tried and failed
2) Build gstreamer-ffmpeg with an old ffmpeg-compat. May work for now, but seems like
a dead end in the long run, as I'm sure we don't want to have an ffmpeg-compat
stick around for ever, and having one stick around for ever would seem like a bad
idea from a security pov.
3) Build gstreamer-ffmpeg with its bundled libav copy, this is actually the advised
way to ship gstreamer-ffmpeg by upstream.
4) Package libav in such a way that it is parallel installable to ffmpeg, use a system
libav with gstreamer-ffmpeg
For now I believe that 3. is the best solution, if we get more packages which only work
with libav and not with with ffmpeg we can move to 4. Alternatively if upstream libav
starts making similar API changes as ffmpeg, and gstreamer-ffmpeg moves to the new
API's we could try 1. again.
Regards,
Hans
9:15 a.m.
New subject: FFmepg rebuild Schedule ?
2012/6/25 Hans de Goede <j.w.r.degoede(a)gmail.com>:
Hi,
..
gstreamer-ffmpeg is a problem, as upstream is using/supporting only
libav
I'm not sure to understand on which version you have based you analyse on
?
gst-ffmpeg latest version is 0.11.2 back to march, which is 'around
the same date' of the latest API change from ffmpeg development
version.
Instead we have gstreamer 0.10 infrastrucuture from fedora.
I don't know the development status of gstreamer 0.11, but if the
stable version will not be due to Fedora 18 GA, then we might use
ffmpeg-compat for easier transition. (or to backport changes from
gst-ffmpeg-0.11.2 if it has support for recent ffmpeg).
ffmpeg, and the 2 seem to have grown apart quite a bit API wise with
the
last ffmpeg
release. I've been looking at patching gstreamer-ffmpeg to build with ffmpeg
rather
then libav, but the 2 really have grown too far apart, requiring too many
changes,
which will surely introduce a lot of bugs.
vlc upstream advertised compatibility
with both ffmpeg and libav. But
they came back to provide binaries built with ffmpeg.
At the time of the switch, their analyze was that ffmpeg was a better
upstream, specially as they re-integrate security fixes and features
from libav whereas libav doesn't.
I would like to avoid any topic that would revisit the previous
decision to stay with FFmpeg in RPM Fusion. I might have been
suspicious at the time of the fork, I saw the line have changes from
ffmpeg.org perspective and improved. But I have no doubt that is was
the correct decision.
So we've 4 options:
1) Try to patch gstreamer-ffmpeg to build with new ffmpeg, tried and
failed
This failure is suspicious to me, vlc upstream can be built with
either libav of ffmpeg and binaries are nowadays provided with ffmpeg,
which is more
2) Build gstreamer-ffmpeg with an old ffmpeg-compat. May work for
now, but
seems like
a dead end in the long run, as I'm sure we don't want to have an
ffmpeg-compat
ffmpeg-compat (0.6x branch) is still maintained security wise. This
is
what will be done for EL-6 since this version will match the gstreamer
components there. I can be used as a transition state.
Also it could be investigated to move to branch 0.7 for ffmpeg-compat
which is advertised as using the same "oldabi" from ffmpeg-0.6.
3) Build gstreamer-ffmpeg with its bundled libav copy, this is
actually the
advised
way to ship gstreamer-ffmpeg by upstream.
It can hardly be done, we will miss the
benefit of sse2 in i686 by
default and others CPU related optimization.
(not even talking about ARM case here). That will be a duplicate
maintenance effort anyway. (as usually with internal built).
4) Package libav in such a way that it is parallel installable to
ffmpeg,
use a system
Last I've checked, it couldn't be done without forging a
non-existant
ABI as ffmpeg/libav are mutually exclusive system wide.
Nicolas (kwizart)
9:41 a.m.
New subject: FFmepg rebuild Schedule ?
Hi,
On 06/25/2012 11:15 AM, Nicolas Chauvet wrote:
2012/6/25 Hans de Goede <j.w.r.degoede(a)gmail.com>:
> Hi,
..
> gstreamer-ffmpeg is a problem, as upstream is using/supporting only libav
I'm not sure to understand on which version you have based you analyse on ?
gst-ffmpeg latest version is 0.11.2 back to march, which is 'around
the same date' of the latest API change from ffmpeg development
version.
Instead we have gstreamer 0.10 infrastrucuture from fedora.
Right, note that gstreamer-0.11 are non stable API / ABI preview releases
of what will become gstreamer-1.0, iow they are not really suitable for
packaging.
I don't know the development status of gstreamer 0.11, but if
the
stable version will not be due to Fedora 18 GA, then we might use
ffmpeg-compat for easier transition. (or to backport changes from
gst-ffmpeg-0.11.2 if it has support for recent ffmpeg).
gst-ffmpeg-0.11.x also does not support ffmpeg-0.11
> ffmpeg, and the 2 seem to have grown apart quite a bit API wise
with the
> last ffmpeg
> release. I've been looking at patching gstreamer-ffmpeg to build with ffmpeg
> rather
> then libav, but the 2 really have grown too far apart, requiring too many
> changes,
> which will surely introduce a lot of bugs.
vlc upstream advertised compatibility with both ffmpeg and libav. But
they came back to provide binaries built with ffmpeg.
At the time of the switch, their analyze was that ffmpeg was a better
upstream, specially as they re-integrate security fixes and features
from libav whereas libav doesn't.
I would like to avoid any topic that would revisit the previous
decision to stay with FFmpeg in RPM Fusion. I might have been
suspicious at the time of the fork, I saw the line have changes from
ffmpeg.org perspective and improved. But I have no doubt that is was
the correct decision.
I'm not advocating re-evaluating that decision, I'm just saying that for
gstreamer-ffmpeg it is not working out well atm, so we need to come up
with solution for the gstreamer-ffmpeg case, this can be a gstreamer-ffmpeg
specific solution.
> So we've 4 options:
> 1) Try to patch gstreamer-ffmpeg to build with new ffmpeg, tried and failed
This failure is suspicious to me, vlc upstream can be built with
either libav of ffmpeg and binaries are nowadays provided with ffmpeg,
which is more
This is a choice made by upstream, vlc has chosen to support both, gst-ffmpeg
upstream has chosen to support only libav.
> 2) Build gstreamer-ffmpeg with an old ffmpeg-compat. May work for
now, but
> seems like
> a dead end in the long run, as I'm sure we don't want to have an
> ffmpeg-compat
ffmpeg-compat (0.6x branch) is still maintained security wise. This is
what will be done for EL-6 since this version will match the gstreamer
components there. I can be used as a transition state.
Also it could be investigated to move to branch 0.7 for ffmpeg-compat
which is advertised as using the same "oldabi" from ffmpeg-0.6.
Hmm, 0.7 is too old. gstt-ffmpeg needs 0.10, which brings us to the problem
that 0.10 and 0.11 are not parallel installable since some of the libs change
soname but not all of them. We could try packaging only libavcodec,
libavdevice and libavformat of 0.10 in a compat package, while using the others
from 0.11
May I point out that an upstream doing binary incompatible non parallel
installable releases is not making things any easier for us ?
> 3) Build gstreamer-ffmpeg with its bundled libav copy, this is
actually the
> advised
> way to ship gstreamer-ffmpeg by upstream.
It can hardly be done, we will miss the benefit of sse2 in i686 by
default and others CPU related optimization.
(not even talking about ARM case here). That will be a duplicate
maintenance effort anyway. (as usually with internal built).
I don't see how using an internal copy would result in not using cpu
optimization:
[hans@shalem ~]$ rpm -ql ffmpeg-libs
ffmpeg-libs-0.11.1-1.fc18.x86_64
/usr/lib64/libavcodec.so.54
/usr/lib64/libavcodec.so.54.23.100
/usr/lib64/libavdevice.so.54
/usr/lib64/libavdevice.so.54.0.100
/usr/lib64/libavfilter.so.2
/usr/lib64/libavfilter.so.2.77.100
/usr/lib64/libavformat.so.54
/usr/lib64/libavformat.so.54.6.100
/usr/lib64/libavutil.so.51
/usr/lib64/libavutil.so.51.54.100
/usr/lib64/libpostproc.so.52
/usr/lib64/libpostproc.so.52.0.100
/usr/lib64/libswresample.so.0
/usr/lib64/libswresample.so.0.15.100
/usr/lib64/libswscale.so.2
/usr/lib64/libswscale.so.2.1.100
So we don't have multiple compiles, but runtime cpu detection in one
binary, which will still work fine if the lib is statically linked into
the gstreamer plugin.
As for the maintenance burden, gst-ffmpeg ships with a bundled copy, and
this is the *preferred* way to build it. Upstream takes care of updating
the bundled libav copy on a timely basis. Doing things this way is actually
less maintenance work, since I can stop worrying about compatibility with
the system ffmpeg-libs (which is not guaranteed) and I will no longer need
to write patches to fix gstreamer-ffmpeg building and running with a
different set of ffmpeg-libs then it was written for!
> 4) Package libav in such a way that it is parallel installable to
ffmpeg,
> use a system
Last I've checked, it couldn't be done without forging a non-existant
ABI as ffmpeg/libav are mutually exclusive system wide.
Right, so we would need to install it into a different library dir, use
rpath tricks, and pray that no apps ever uses both gstreamer and directly
links to ffmpeg, not a nice prospect I agree.
So given all of the above, and seeing how 1, 2 and 4 are somewhere between
very hard to do and impossible, I'm even more convinced now that 3. is the right
option.
Regards,
Hans
12:13 p.m.
New subject: FFmepg rebuild Schedule ?
2012/6/25 Hans de Goede <j.w.r.degoede(a)gmail.com>:
Hi,
Right, note that gstreamer-0.11 are non stable API / ABI preview releases
of what will become gstreamer-1.0, iow they are not really suitable for
packaging.
gst-ffmpeg-0.11.x also does not support ffmpeg-0.11
This situation sucks. gst-ffmpeg developers are working on the
unstable 0.11.x code with an *also* unstable Libav API (iow there's no
Libav release incorporating its API changes yet). They expect that we
ship for now gst-ffmpeg 0.10 stable series, which is guaranteed to
work with Libav-0.8 series (which is compatible with FFmpeg up to 0.10
series).
Can't we stick with ffmpeg 0.10.x in F17 and (try to) push 0.11 only
for F18? At some time hopefully Libav-0.9 will be released and FFmpeg
will catch up with the new (final) API in FFmpeg 0.12 or so...
Marcos
12:20 p.m.
New subject: FFmepg rebuild Schedule ?
Hi,
On 06/25/2012 02:13 PM, Marcos Felipe Rasia de Mello wrote:
2012/6/25 Hans de Goede <j.w.r.degoede(a)gmail.com>:
> Hi,
>
>
> Right, note that gstreamer-0.11 are non stable API / ABI preview releases
> of what will become gstreamer-1.0, iow they are not really suitable for
> packaging.
>
>
>
> gst-ffmpeg-0.11.x also does not support ffmpeg-0.11
>
This situation sucks. gst-ffmpeg developers are working on the
unstable 0.11.x code with an *also* unstable Libav API
No they are not, if you are not or poorly informed on a topic please
don't just don't reply rather then spreading non-sense / fud.
If you look here:
http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/log
You can clearly see that the latest update of the libav git submodule is:
"libav: Update to 0.8.3 release"
So they are sticking purely to stable libav releases / API. Yes they are
not supporting the latest ffmpeg stable release / API. This is their
choice and they have every right to choose for libav.
Note that in this case it is ffmpeg which is complicating things by making
non parallel installable ABI breaking stable releases. If they would simply
bump the soname of all the sub-libs of ffmpeg in one go, this problem
would not be as big as it is.
Regards,
Hans
12:31 p.m.
New subject: FFmepg rebuild Schedule ?
2012/6/25 Hans de Goede <j.w.r.degoede(a)gmail.com>:
Hi,
No they are not, if you are not or poorly informed on a topic please
don't just don't reply rather then spreading non-sense / fud.
Agreed.
If you look here:
http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/log
You can clearly see that the latest update of the libav git submodule is:
"libav: Update to 0.8.3 release"
So they are sticking purely to stable libav releases / API. Yes they are
not supporting the latest ffmpeg stable release / API. This is their
choice and they have every right to choose for libav.
Note that in this case it is ffmpeg which is complicating things by making
non parallel installable ABI breaking stable releases. If they would simply
bump the soname of all the sub-libs of ffmpeg in one go, this problem
would not be as big as it is.
I presupposed that they were working with an incompatible Libav
because FFmpeg's merge-all-changes-and-keep-compatible-with-libav
policy they had up to 0.10. Why FFmpeg is doing this now?
Thanks for the info and sorry for the noise.
Marcos
11:38 p.m.
New subject: FFmepg rebuild Schedule ?
Hans de Goede wrote:
Hmm, 0.7 is too old. gstt-ffmpeg needs 0.10,
0.6/0.7 is also way too old from a feature point of view.
Seeing some packages (e.g. transcode) switch to ffmpeg-compat because they
don't build with the latest FFmpeg actually worries me, they're actually
being downgraded to an ancient FFmpeg, with fewer, less powerful and more
buggy codecs. I think that is a very bad solution.
>> 4) Package libav in such a way that it is parallel
installable to
>> ffmpeg, use a system
> Last I've checked, it couldn't be done without forging a non-existant
> ABI as ffmpeg/libav are mutually exclusive system wide.
Right, so we would need to install it into a different library dir, use
rpath tricks, and pray that no apps ever uses both gstreamer and directly
links to ffmpeg, not a nice prospect I agree.
Using both GStreamer and FFmpeg directly is not going to work either if you
use the bundled libav, unless it gets built as a static library with ONLY
hidden symbols (-fvisibility=hidden and the export macros disabled
entirely). If it gets built with exported symbols enabled, it will be
exporting some of the same symbols, so there WILL be symbol conflicts.
Kevin Kofler
10:15 p.m.
New subject: FFmpeg rebuild Schedule ?
On Dom, 2012-06-24 at 15:51 +0200, Nicolas Chauvet wrote:
>> Here is the plan
>> 1st - build x264 with bootstrap
>> 2nd - build ffmpeg-0.11
>> 3rd - gpac
>> 4th - x264 can be built without bootstrap
>>
>> but it's also possible to build x264 at the very end.
I'd like know better about this subject. x264-libs unbootstrap will do
the same effect of x264-libs with bootstrap ?
My thinking is, if x264-libs unbootstrap will do the same or better, we
should compile it sooner (4th place), to get optimal results .
>> Now the idea is to build vlc not that far so phonon
application can
>> have their backend installed at build time.
After the FFmpeg/x264 bootstrap is done, I will handle libquicktime
vlc and mjpegtools and leave others maintainers the opportunity to
submit their rebuilt until tomorrow. (Then I will submit a rebuilt
job from the remaining FFmpeg/x264 dependencies).
Depending on how the rebuilt went , I will push package out then or
later this week.
I think, FFmpeg/x264 bootstrap is done.
I checked mjpegtools and no problems found, can I commit and build
it ?
Thanks,
--
Sérgio M. B.
4534
days inactive
4535
days old
rpmfusion-developers@lists.rpmfusion.org
14 comments
6 participants
participants (6)
-
Hans de Goede -
Julian Sikorski -
Kevin Kofler -
Marcos Felipe Rasia de Mello -
Nicolas Chauvet -
Sérgio Basto