9:38 p.m.
Hi all,
sorry it took so long, but I didn't have enough free time to do it
faster.
Anyway, long story short:
The plan is to push FFmpeg 0.8.2 and latest x264 stable git to
devel/F-16 branch. There are 34 packages which depend on these two.
Out of those, only 2 (two!) had build failures which I wasn't able
to fix quickly, namely ffmpeg2dirac and lightspark.
ffmpeg2dirac needs more porting to FFmpeg 0.8 API than I was able to
do quickly and lightspark's build fails with some obscure llvm error.
So I think we're in pretty good shape to move forward.
I'll post my patches in this thread so that the respective maintainers
can look at them and hopefully push them upstream. Note that most
packages simply need a version bump and a rebuild.
Here is the full status:
audacious-plugins-freeworld - already fixed in devel (3.0.2)
dvbcut - patch
dvdstyler - fixed in 1.9.0+
ffmpeg2dirac - 0.2.0 available, still needs porting to FFmpeg 0.8 API
ffmpegthumbnailer - fixed in 2.0.7
gpac - patch
gstreamer-ffmpeg - fixed in 0.10.12
guvcview - fixed in 1.5.0
k3b-extras-freeworld - patch (also, update to 2.0.2)
kdemultimedia-extras-freeworld - builds with no issues
kino - patch; builds, but needs porting to v4l2
libdlna - patch
lightspark - 0.4.8.1 and 0.5.0 don't build due to llvm bug(?)
mlt - builds with no issues
motion - patch
mpd - fixed in 0.16.3 (current stable), maybe add more deps
picard-freeworld - already fixed in devel (0.15.1)
qmmp-plugins-freeworld - needs update to at least 0.5.1
transcode - patch
ushare-freeworld - patch
vlc - patch
wxsvg - fixed in 1.1.1
xine-lib-extras-freeworld - patch
xmms2-freeworld - patch
Ordering issues:
vlc before k3b-extras
wxsvg before dvdstyler
libdlna before ushare-freeworld
libquicktime before mlt
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:44 p.m.
New subject: [PATCH] dvbcut: port to FFmpeg-0.8 API
Patch attached.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:45 p.m.
New subject: [PATCH] ffmpeg2dirac: port to FFmpeg-0.8 API (incomplete)
This patch is incomplete, but can be used as a starting point.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:29 p.m.
New subject: [PATCH] ffmpeg2dirac: port to FFmpeg-0.8 API (incomplete)
And now a complete patch that makes ffmpeg2dirac build.
However, it disables some code in ffmpeg2dirac.cpp:
@@ -2924,7 +2955,9 @@ int main (int argc, char **argv){
formatParams->time_base.den = convert->framerate.num;
formatParams->time_base.num = convert->framerate.den;
}
+#if FF_API_PARAMETERS_CODEC_ID
formatParams->video_codec_id = av_guess_image2_codec(inputfile_name);
+#endif
}
if (av_open_input_file(&convert->context, inputfile_name, input_fmt, 0,
formatParams) >= 0){
if (av_find_stream_info (convert->context) >= 0){
I haven't been able to find out what's the new API equivalent of that,
but I suspect setting video_codec_id might be unnecessary. Please highlight
that upstream, however.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10 p.m.
New subject: [PATCH] gpac: port to FFmpeg-0.8 API
This is a modified version of the patch already present in the package.
I can separate the actual API porting to a separate patch if you want.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:01 p.m.
New subject: [PATCH] k3b-extras-freeworld: port to FFmpeg-0.8 API
Attached.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:04 p.m.
New subject: [PATCH] kino: port to FFmpeg-0.8 API
Apart from this patch, kino needs to be ported to v4l2 API as well,
as the v4l1 API is already gone from F16+ kernels. One can make it
build (as I did) by using the backwards-compatibility header from
libv4l (libv4l1-videodev.h), but haven't tested if the built binary
actually works.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
11:06 p.m.
New subject: [PATCH] kino: port to FFmpeg-0.8 API
Dominik 'Rathann' Mierzejewski wrote:
Apart from this patch, kino needs to be ported to v4l2 API as well,
as the v4l1 API is already gone from F16+ kernels. One can make it
build (as I did) by using the backwards-compatibility header from
libv4l (libv4l1-videodev.h), but haven't tested if the built binary
actually works.
Apps should be using libv4l rather than v4l2 directly. (Otherwise, they
won't work with many webcams out there, because v4l2 doesn't decode weird
formats in the kernel.)
Using the v4l1 compat header from libv4l is good enough until upstream gets
native libv4l support. Please post the patch you used.
Kevin Kofler
7:28 a.m.
New subject: [PATCH] kino: port to FFmpeg-0.8 API
Hi,
On 09/05/2011 01:06 AM, Kevin Kofler wrote:
Dominik 'Rathann' Mierzejewski wrote:
> Apart from this patch, kino needs to be ported to v4l2 API as well,
> as the v4l1 API is already gone from F16+ kernels. One can make it
> build (as I did) by using the backwards-compatibility header from
> libv4l (libv4l1-videodev.h), but haven't tested if the built binary
> actually works.
Apps should be using libv4l rather than v4l2 directly. (Otherwise, they
won't work with many webcams out there, because v4l2 doesn't decode weird
formats in the kernel.)
Using the v4l1 compat header from libv4l is good enough until upstream gets
native libv4l support. Please post the patch you used.
The compat header will just make things compile, it replaces linux/videodev.h,
but does not do anything magic to make the app actually work with v4l2
devices all of a sudden, iow the app will still try to talk the v4l1 API to
any /dev/video nodes.
To use the v4l1 compat layer libv4l comes with, you need to:
1) #include <libv4l1.h>
2) replace open("/dev/video0", ...) with v4l1_open("/dev/video0",
...)
3) replace ioctl(video_fd, ...) with v4l1_ioctl(video_fd, ...)
4) idem for read / mmap / munmap (on a ptr coming from v4l1_mmap) & close
5) Add -lv4l1 to LD_FLAGS
Or start the binary with LD_PRELOAD=/usr/lib/libv4l/v4l1_compat.so, but the
above is highly preferred. The LD_PRELOAD shim is really only there for
proprietary software (yes skype I'm looking at you).
This will make libv4l1 translate the v4l1 calls to v4l2 calls, and then
pass them through libv4l2, so that you also get the often needed format
conversion.
Regards,
Hans
1:57 p.m.
New subject: [PATCH] kino: port to FFmpeg-0.8 API
Hans de Goede wrote:
The compat header will just make things compile, it replaces
linux/videodev.h, but does not do anything magic to make the app actually
work with v4l2 devices all of a sudden, iow the app will still try to talk
the v4l1 API to any /dev/video nodes.
Oh, I didn't notice that he was talking about using only the videodev.h
replacement.
To use the v4l1 compat layer libv4l comes with, you need to:
1) #include <libv4l1.h>
2) replace open("/dev/video0", ...) with v4l1_open("/dev/video0",
...)
3) replace ioctl(video_fd, ...) with v4l1_ioctl(video_fd, ...)
4) idem for read / mmap / munmap (on a ptr coming from v4l1_mmap) & close
5) Add -lv4l1 to LD_FLAGS
Thanks for this clarification.
Kevin Kofler
5:41 p.m.
New subject: [PATCH] kino: port to FFmpeg-0.8 API
I hope no one takes my question the wrong way, but...
How many people still use Kino? The last website updated appears to be
May 2010 and the last release September 2009.
I tried it out but when I found out that it doesn't handle HD video
(even my digital camera does 720p clips) I gave up and that's when I
found and packaged Openshot.
Between Kdenlive & Openshot I think it's pretty well covered. If
someone needs more advanced video editing perhaps LiVES or Cinelerra
could be packaged?
Richard
12:04 a.m.
New subject: [PATCH] kino: port to FFmpeg-0.8 API
On Monday, 05 September 2011 at 19:41, Richard Shaw wrote:
I hope no one takes my question the wrong way, but...
How many people still use Kino? The last website updated appears to be
May 2010 and the last release September 2009.
I tried it out but when I found out that it doesn't handle HD video
(even my digital camera does 720p clips) I gave up and that's when I
found and packaged Openshot.
Hence my suggestion to retire kino starting with F-16.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:05 p.m.
New subject: [PATCH] libdlna: port to FFmpeg-0.8 API
Attached.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:06 p.m.
New subject: [PATCH] motion: port to FFmpeg-0.8 API
Attached.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
noon
New subject: [PATCH] motion: port to FFmpeg-0.8 API
Thanks, I contacted upstream to integrate the modification.
On Sep 4, 2011, at 12:06 AM, Dominik 'Rathann' Mierzejewski wrote:
Attached.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
<motion-ffmpeg.patch>
10:07 p.m.
New subject: [PATCH] transcode: port to FFmpeg-0.8 API
Attached.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:12 p.m.
New subject: [PATCH] ushare-freeworld: port to new libupnp API and fix missing includes
Two patches, actually, and none of them is FFmpeg-related.
The libupnp patch comes from OpenWRT:
https://dev.openwrt.org/raw-attachment/ticket/8296/101-ushare-upnp-build-...
and the other one just adds missing #include statements which generate
implicit function declaration warnings.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:14 p.m.
New subject: [PATCH] vlc: port to FFmpeg-0.8 API
Attached.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:16 p.m.
New subject: [PATCH] xine-lib-extras-freeworld: port to FFmpeg-0.8 API
Attached.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:17 p.m.
New subject: [PATCH] xmms2-freeworld: port to FFmpeg-0.8 API
Attached.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:32 a.m.
On 04/09/11 07:38, Dominik 'Rathann' Mierzejewski wrote:
The plan is to push FFmpeg 0.8.2 and latest x264 stable git to
devel/F-16 branch. There are 34 packages which depend on these two.
Out of those, only 2 (two!) had build failures which I wasn't able
to fix quickly, namely ffmpeg2dirac and lightspark.
ffmpeg2dirac needs more porting to FFmpeg 0.8 API than I was able to
do quickly and lightspark's build fails with some obscure llvm error.
For packagers who are "consumers" of ffmpeg, what will the process be ?
1. Dom commits ffmpeg and builds for -testing
2. once it appears (Dominik could announce), other "consumer" packagers
grab Dominik's patches for their own packages, and build locally.
3. if successful, send patch upstream
4. commit patch, and request build
5. else request help on the list if necessary.
Am I understanding this correctly ?
7:41 a.m.
Hi David,
On Sunday, 04 September 2011 at 07:32, David Timms wrote:
On 04/09/11 07:38, Dominik 'Rathann' Mierzejewski wrote:
>The plan is to push FFmpeg 0.8.2 and latest x264 stable git to
>devel/F-16 branch. There are 34 packages which depend on these two.
>Out of those, only 2 (two!) had build failures which I wasn't able
>to fix quickly, namely ffmpeg2dirac and lightspark.
>ffmpeg2dirac needs more porting to FFmpeg 0.8 API than I was able to
>do quickly and lightspark's build fails with some obscure llvm error.
For packagers who are "consumers" of ffmpeg, what will the process be ?
1. Dom commits ffmpeg and builds for -testing
We don't have "testing" for devel branch, do we? Anyway, the builds
are done.
2. once it appears (Dominik could announce), other
"consumer"
packagers grab Dominik's patches for their own packages, and build
locally.
3. if successful, send patch upstream
Well, I did all my builds in mock against offcial repos and my local
repo with the new ffmpeg and x264. But of course you're welcome to
verify that I haven't missed anything. Also, the patches I prepared
are quite minimal and may not be appropriate for direct inclusion
upstream.
4. commit patch, and request build
5. else request help on the list if necessary.
Am I understanding this correctly ?
Yes. That's the plan, more or less.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
11:30 a.m.
On 04/09/11 17:41, Dominik 'Rathann' Mierzejewski wrote:
We don't have "testing" for devel branch, do we?
Anyway, the builds
are done.
They don't appear in yum --enablerepo=* list ffmpeg (I see:
ffmpeg.x86_64 0.7.1-1.fc16 rpmfusion-free-rawhide )
Do we need to wait until it's pushed to rawhide, so that our build will
pick up the updated ffmpeg ?
11:58 a.m.
2011/9/5 David Timms <dtimms(a)iinet.net.au>:
They don't appear in yum --enablerepo=* list ffmpeg (I see:
ffmpeg.x86_64 0.7.1-1.fc16 rpmfusion-free-rawhide )
Do we need to wait until it's pushed to rawhide, so that our build will pick
up the updated ffmpeg ?
ffmpeg 0.8.2-1.fc16 is in the "rpmfusion-free-needsign-rawhide"
repository available on the builders, it seems.
(Can be seen in root.log from recent builds.)
- Thomas
12:32 p.m.
On Monday 05 of September 2011 13:58:02 Thomas Moschny wrote:
2011/9/5 David Timms <dtimms(a)iinet.net.au>:
> They don't appear in yum --enablerepo=* list ffmpeg (I see:
> ffmpeg.x86_64 0.7.1-1.fc16 rpmfusion-free-rawhide )
> Do we need to wait until it's pushed to rawhide, so that our
> build will pick up the updated ffmpeg ?
ffmpeg 0.8.2-1.fc16 is in the
"rpmfusion-free-needsign-rawhide" repository available on the
builders, it seems.
(Can be seen in root.log from recent builds.)
so ... if I take the qmmp-plugins-freeweorld spec in devel,
increment the release and do make tag, make build, it will be
rebuilt with the new ffmpeg already and that is all I need to do?
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
2:11 p.m.
Hi,
On 09/05/2011 02:32 PM, Karel Volný wrote:
On Monday 05 of September 2011 13:58:02 Thomas Moschny wrote:
> 2011/9/5 David Timms<dtimms(a)iinet.net.au>:
>> They don't appear in yum --enablerepo=* list ffmpeg (I see:
>> ffmpeg.x86_64 0.7.1-1.fc16 rpmfusion-free-rawhide )
>> Do we need to wait until it's pushed to rawhide, so that our
>> build will pick up the updated ffmpeg ?
>
> ffmpeg 0.8.2-1.fc16 is in the
> "rpmfusion-free-needsign-rawhide" repository available on the
> builders, it seems.
> (Can be seen in root.log from recent builds.)
so ... if I take the qmmp-plugins-freeweorld spec in devel,
increment the release and do make tag, make build, it will be
rebuilt with the new ffmpeg already and that is all I need to do?
Yes, although ideally, you would download the new ffmpeg + x264 from
here:
http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion...
As well as anything which you've installed which uses them. and upgrade to them
(removing anything that needs them which has not been rebuild yet, which is a
pain).
Then do a local rebuild, test it, and then do the increment the release and do
make tag, make build thingy. If you want to go for really perfect, you then
download the build result and replace your local built rpm with it, and
test again.
Regards,
Hans
2:51 p.m.
On Monday 05 of September 2011 16:11:56 Hans de Goede wrote:
Hi,
On 09/05/2011 02:32 PM, Karel Volný wrote:
> On Monday 05 of September 2011 13:58:02 Thomas Moschny wrote:
>> 2011/9/5 David Timms<dtimms(a)iinet.net.au>:
>>> They don't appear in yum --enablerepo=* list ffmpeg (I
>>> see: ffmpeg.x86_64 0.7.1-1.fc16 rpmfusion-free-rawhide
>>> ) Do we need to wait until it's pushed to rawhide, so
>>> that our build will pick up the updated ffmpeg ?
>>
>> ffmpeg 0.8.2-1.fc16 is in the
>> "rpmfusion-free-needsign-rawhide" repository available on
>> the builders, it seems.
>> (Can be seen in root.log from recent builds.)
>
> so ... if I take the qmmp-plugins-freeweorld spec in devel,
> increment the release and do make tag, make build, it will
> be rebuilt with the new ffmpeg already and that is all I
> need to do?
Yes, although ideally, you would download the new ffmpeg +
x264 from here:
http://buildsys.rpmfusion.org/plague-results/fedora-developmen
t-rpmfusion_free/
As well as anything which you've installed which uses them.
and upgrade to them (removing anything that needs them which
has not been rebuild yet, which is a pain).
we used to call it a royal PITA ... I wonder how had I managed
not to break my system with all that --nodeps rpm magic :-)
Then do a local rebuild, test it, and then do the increment
the release and do make tag, make build thingy. If you want
to go for really perfect, you then download the build result
and replace your local built rpm with it, and test again.
thanks, done
http://buildsys.rpmfusion.org/plague-results/fedora-development-
rpmfusion_free/qmmp-plugins-freeworld/0.5.1-2.fc16/
- if someone wants to test too ...
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
8:35 a.m.
Hi,
Thanks for working on this!
On 09/03/2011 11:38 PM, Dominik 'Rathann' Mierzejewski wrote:
Hi all,
sorry it took so long, but I didn't have enough free time to do it
faster.
Anyway, long story short:
The plan is to push FFmpeg 0.8.2 and latest x264 stable git to
devel/F-16 branch. There are 34 packages which depend on these two.
Out of those, only 2 (two!) had build failures which I wasn't able
to fix quickly, namely ffmpeg2dirac and lightspark.
ffmpeg2dirac needs more porting to FFmpeg 0.8 API than I was able to
do quickly and lightspark's build fails with some obscure llvm error.
So I think we're in pretty good shape to move forward.
I'll post my patches in this thread so that the respective maintainers
can look at them and hopefully push them upstream. Note that most
packages simply need a version bump and a rebuild.
I've taken the liberty to do a bump and rebuild for libquicktime
(as I need this for gstreamer-ffmpeg testing, because that testing
needs gstreamer-plugins-bad -> mjpegtools -> libquicktime).
I'll also take care of rebuilding:
gstreamer-ffmpeg (including rebase to 0.10.12)
gstreamer-plugins-ugly
audacious-plugins-freeworld
Regards,
Hans
4:57 p.m.
New subject: [PATCH] xbmc: port to FFmpeg-0.8 API
Hi,
it seems that I forgot about xbmc. However, I have now managed to port
it to the new FFmpeg API and it builds fine. I'm not sure the patch
is 100% correct, but upstream should be able to improve upon it.
By the way, how is the unbundling effort coming along?
I can still see a ton of bundled libraries:
liba52
libdts
libdvdnav
flac
nofrendo
libsidplay/utils, resid
snesapu
StSoundLibrary
ASAP
timidity
vgmstream
libvorbis
libogg
unrar
cmyth
cximage
libupnp
libopendaap (modified)
apetaglib
libexif
libhts
libid3tag
libscrobbler
squish
sqlite
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:05 p.m.
New subject: [PATCH] xbmc: port to FFmpeg-0.8 API
On Fri, Sep 9, 2011 at 11:57 AM, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
Hi,
it seems that I forgot about xbmc. However, I have now managed to port
it to the new FFmpeg API and it builds fine. I'm not sure the patch
is 100% correct, but upstream should be able to improve upon it.
By the way, how is the unbundling effort coming along?
I've un-bundled everything I'm capable of doing for avidemux...
http://rpmfusion.org/BundledLibraries
Thanks,
Richard
5:20 p.m.
New subject: Unbundling effort
On Friday, 09 September 2011 at 19:05, Richard Shaw wrote:
On Fri, Sep 9, 2011 at 11:57 AM, Dominik 'Rathann'
Mierzejewski
<dominik(a)greysector.net> wrote:
> Hi,
> it seems that I forgot about xbmc. However, I have now managed to port
> it to the new FFmpeg API and it builds fine. I'm not sure the patch
> is 100% correct, but upstream should be able to improve upon it.
>
> By the way, how is the unbundling effort coming along?
I've un-bundled everything I'm capable of doing for avidemux...
http://rpmfusion.org/BundledLibraries
Good work, your effort is appreciated. I may be able to help with
FFmpeg unbundling, assuming I can find some spare time.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:29 p.m.
New subject: Unbundling effort
On Fri, Sep 9, 2011 at 12:20 PM, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
On Friday, 09 September 2011 at 19:05, Richard Shaw wrote:
> On Fri, Sep 9, 2011 at 11:57 AM, Dominik 'Rathann' Mierzejewski
> <dominik(a)greysector.net> wrote:
> > Hi,
> > it seems that I forgot about xbmc. However, I have now managed to port
> > it to the new FFmpeg API and it builds fine. I'm not sure the patch
> > is 100% correct, but upstream should be able to improve upon it.
> >
> > By the way, how is the unbundling effort coming along?
>
> I've un-bundled everything I'm capable of doing for avidemux...
>
> http://rpmfusion.org/BundledLibraries
Good work, your effort is appreciated. I may be able to help with
FFmpeg unbundling, assuming I can find some spare time.
The only part of the above URL that's sort of a lie is that I had to
re-enable the built-in spider monkey (js) for Fedora releases 15+
because avidemux 2.5x is not compatible with the fedora provided
version. Hopefully that will be fixed for avidemux 2.6+.
I'd like the help but I'm not sure how easy it will be. I noticed that
the version of ffmpeg they use is heavily patched during the build
process.
Thanks,
Richard
6:13 p.m.
New subject: [PATCH] xbmc: port to FFmpeg-0.8 API
Hi,
it seems that I forgot about xbmc. However, I have now managed to port
it to the new FFmpeg API and it builds fine. I'm not sure the patch
is 100% correct, but upstream should be able to improve upon it.
Thanks for the patch. I'm not sure if it will apply to the latest
upstream git (pre-"Eden", which is the next release) as they have done a
lot of internal reorganization of the code.
By the way, how is the unbundling effort coming along?
One of upstream's stated goals is to unbundle a lot of the libraries,
see "restructuring" here:
http://xbmc.org/theuni/2011/02/21/whats-going-on/
I haven't followed git too closely recently but I think they have
have been progressing along those lines, so it's probably not
worth spending too much effort on Dharma (10.x). I'll try to start
porting a stable version of Eden (11.x) to rawhide.
I can still see a ton of bundled libraries:
A lot of those libraries actually are either no longer used or we
compile against the system version. For example, we compile against
system libogg and libvorbis and sqlite3 (you can see they system
libraries if you run "rpm -q --requires xbmc").
It may be that the code isn't removed from the tarball I remove most
of them but if there are specific libraries which are still in the
tarball that we don't use or compile against, let me know which and
I can add them to my tarball cleaning script:
http://fedorapeople.org/gitweb?p=alexlan/public_git/xbmc-rpm.git;a=blob;f...
For liba52 and libdts we don't compile them at all IIRC and I strip
out the bundled code in the tarball cleaning script:
for i in liba52 libmpeg2 libdts
do
rm -r xbmc/cores/dvdplayer/Codecs/$i
done
There are also a few that have the same name as an existing system
library, but are actually different code entirely. libexif, I think
is one of those, see: http://trac.xbmc.org/ticket/8331.
Others would be very difficult to extract without impacting other
platforms, cximage, for example, although somebody did try to port
to ImageMagick: http://trac.xbmc.org/ticket/8992
Some of these might be closer to resolution in the Eden/11.x branch.
Alex
liba52
libdts
libdvdnav
flac
nofrendo
libsidplay/utils, resid
snesapu
StSoundLibrary
ASAP
timidity
vgmstream
libvorbis
libogg
unrar
cmyth
cximage
libupnp
libopendaap (modified)
apetaglib
libexif
libhts
libid3tag
libscrobbler
squish
sqlite
11:46 p.m.
New subject: [PATCH] xbmc: port to FFmpeg-0.8 API
Dominik 'Rathann' Mierzejewski wrote:
I can still see a ton of bundled libraries:
[snip]
unrar
This library is non-Free and has no business being in something which claims
to be Free Software at all, bundled or not!
Kevin Kofler
10:35 a.m.
New subject: [PATCH] xbmc: port to FFmpeg-0.8 API
On Fri, 9 Sep 2011 18:57:21 +0200, D'M (Dominik) wrote:
By the way, how is the unbundling effort coming along?
I can still see a ton of bundled libraries:
libsidplay/utils, resid
Probably libsidplay2 (which requires resid), because temporarily it has
not been trivial to use it or package it correctly. libsidplay1 has always
been available as a simple system library, and there has been plenty of
opportunity to merge any needed modifications into it. It's kind of legacy.
Meanwhile, with libsidplayfp there's some new activity, including attempts
at adding thread-safety:
sidplay2 fork with resid-fp
http://sourceforge.net/projects/sidplay-residfp/
| libsidplayfp is a fork of LIBSIDPLAY2, a C64 music player library which
| integrates the reSID SID chip emulation into a cycle-based emulator
| environment, started with primary purpose to improve emulation of the
| C64 system and the SID chips.
This still cannot be included in Fedora due to requiring the included
Commodore "Kernal" and Basic ROM images.
--
Fedora release 16 (Verne) - Linux 3.1.0-0.rc4.git0.0.fc16.x86_64
loadavg: 0.00 0.03 0.07
4822
days inactive
4829
days old
rpmfusion-developers@lists.rpmfusion.org
35 comments
10 participants
participants (10)
-
Agnes Jones -
Alex Lancaster -
Dominik 'Rathann' Mierzejewski -
Hans de Goede -
Karel Volný -
Kevin Kofler -
Michael Schwendt -
Richard Shaw -
Steven Moix -
Thomas Moschny