Re: ffmpeg 3.2.10 update
Hi, On 27/01/18 12:09, Salvatore Bonaccorso wrote: > On Sat, Jan 27, 2018 at 10:19:19AM +, James Cowgill wrote: >> On 26/01/18 17:53, Moritz Mühlenhoff wrote: >>> On Fri, Jan 26, 2018 at 05:13:54PM +, James Cowgill wrote: I've pushed ffmpeg 3.2.10 here: https://salsa.debian.org/multimedia-team/ffmpeg/tree/debian/stretch Since I've not been doing these updates before, what is the correct procedure. Do I just upload it to security-master, or should I contact the security team first? >>> >>> For ffmpeg (since it's following the 3.2.x series) uploading to >>> security-master is fine (unless some update happens to provide >>> changes in debian/ beyond the changelog, then please send us a >>> debdiff). >> >> I've uploaded it and attached the debdiff. There are some minor >> modifications to debian/ outside the changelog, but I don't think >> they'll be controversial. > > Something whent wrong, presumably the upload interupted? > > The upload is missing the orig.tar.xz: > > [...] > Jan 27 10:20:39 processing /ffmpeg_3.2.10-1~deb9u1_source.changes > Jan 27 10:20:39 ffmpeg_3.2.10.orig.tar.xz doesn't exist (ignored for now) > Jan 27 10:25:39 processing /ffmpeg_3.2.10-1~deb9u1_source.changes > Jan 27 10:25:39 ffmpeg_3.2.10.orig.tar.xz doesn't exist (ignored for now) > [...] > > You should be able to just push ffmpeg_3.2.10.orig.tar.xz in the next > few hours, and the upload beeing processed. Yeah I tried to do a manual upload because I was on a crap internet connection and screwed it up, but I see everything is sorted now. Thanks! James signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg 3.2.10 update
Hi James, On Sat, Jan 27, 2018 at 10:19:19AM +, James Cowgill wrote: > Hi, > > On 26/01/18 17:53, Moritz Mühlenhoff wrote: > > On Fri, Jan 26, 2018 at 05:13:54PM +, James Cowgill wrote: > >> Hi, > >> > >> I've pushed ffmpeg 3.2.10 here: > >> https://salsa.debian.org/multimedia-team/ffmpeg/tree/debian/stretch > >> > >> Since I've not been doing these updates before, what is the correct > >> procedure. Do I just upload it to security-master, or should I contact > >> the security team first? > > > > For ffmpeg (since it's following the 3.2.x series) uploading to > > security-master is fine (unless some update happens to provide > > changes in debian/ beyond the changelog, then please send us a > > debdiff). > > I've uploaded it and attached the debdiff. There are some minor > modifications to debian/ outside the changelog, but I don't think > they'll be controversial. Something whent wrong, presumably the upload interupted? The upload is missing the orig.tar.xz: [...] Jan 27 10:20:39 processing /ffmpeg_3.2.10-1~deb9u1_source.changes Jan 27 10:20:39 ffmpeg_3.2.10.orig.tar.xz doesn't exist (ignored for now) Jan 27 10:25:39 processing /ffmpeg_3.2.10-1~deb9u1_source.changes Jan 27 10:25:39 ffmpeg_3.2.10.orig.tar.xz doesn't exist (ignored for now) [...] You should be able to just push ffmpeg_3.2.10.orig.tar.xz in the next few hours, and the upload beeing processed. Regards, Salvatore ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg 3.2.10 update
On Fri, Jan 26, 2018 at 05:13:54PM +, James Cowgill wrote: > Hi, > > I've pushed ffmpeg 3.2.10 here: > https://salsa.debian.org/multimedia-team/ffmpeg/tree/debian/stretch > > Since I've not been doing these updates before, what is the correct > procedure. Do I just upload it to security-master, or should I contact > the security team first? For ffmpeg (since it's following the 3.2.x series) uploading to security-master is fine (unless some update happens to provide changes in debian/ beyond the changelog, then please send us a debdiff). Cheers, Moritz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg 3.2.10 update
Hi, On 26/01/18 17:53, Moritz Mühlenhoff wrote: > On Fri, Jan 26, 2018 at 05:13:54PM +, James Cowgill wrote: >> Hi, >> >> I've pushed ffmpeg 3.2.10 here: >> https://salsa.debian.org/multimedia-team/ffmpeg/tree/debian/stretch >> >> Since I've not been doing these updates before, what is the correct >> procedure. Do I just upload it to security-master, or should I contact >> the security team first? > > For ffmpeg (since it's following the 3.2.x series) uploading to > security-master is fine (unless some update happens to provide > changes in debian/ beyond the changelog, then please send us a > debdiff). I've uploaded it and attached the debdiff. There are some minor modifications to debian/ outside the changelog, but I don't think they'll be controversial. d/gbp.conf - changed the git packaging branch names to dep14 style. d/patches - dropped patch added in 3.2.9 but has now been applied upstream. Thanks, James diff -Nru ffmpeg-3.2.9/Changelog ffmpeg-3.2.10/Changelog --- ffmpeg-3.2.9/Changelog 2017-10-26 21:48:27.0 +0100 +++ ffmpeg-3.2.10/Changelog 2018-01-13 02:33:15.0 + @@ -1,6 +1,77 @@ Entries are sorted chronologically from oldest to youngest within each release, releases are sorted from youngest to oldest. +version 3.2.10: +- avcodec/utils: Avoid hardcoding duplicated types in sizeof() +- avcodec/arm/sbrdsp_neon: Use a free register instead of putting 2 things in one +- avformat/libssh: check the user provided a password before trying to use it +- avcodec/h264addpx_template: Fixes integer overflows +- avcodec/dirac_dwt: Fix overflows in COMPOSE_HAARiH0/COMPOSE_HAARiL0 +- avcodec/diracdec: Fix integer overflow with quant +- avcodec/opus_parser: Check payload_len in parse_opus_ts_header() +- avcodec/jpeg2000dsp: Fix integer overflows in ict_int() +- avcodec/h264_slice: Do not attempt to render into frames already output +- avcodec/dnxhddec: Check dc vlc +- x264: Support version 153 +- avcodec/exr: Check buf_size more completely +- avcodec/flacdec: Fix overflow in multiplication in decode_subframe_fixed() +- avcodec/hevcdsp_template: Fix Invalid shifts in put_hevc_qpel_bi_w_h() and put_hevc_qpel_bi_w_w() +- avcodec/flacdec: avoid undefined shift +- avcodec/hevcdsp_template.c: Fix undefined shift in FUNC(dequant) +- avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0() and COMPOSE_DD137iL0() +- avcodec/hevc_cabac: Fix integer overflow in ff_hevc_cu_qp_delta_abs() +- tests/audiomatch: Add missing return code at the end of main() +- avcodec/hevc_sei: Fix integer overflows in decode_nal_sei_message() +- avcodec/hevcdsp_template: Fix undefined shift in put_hevc_qpel_bi_w_hv() +- libavfilter/af_dcshift.c: Fixed repeated spelling error +- avfilter/formats: fix wrong function name in error message +- avcodec/amrwbdec: Fix division by 0 in voice_factor() +- avcodec/diracdsp: Fix integer overflow in PUT_SIGNED_RECT_CLAMPED() +- avcodec/dirac_dwt: Fix integer overflows in COMPOSE_DAUB97* +- avcodec/vorbis: Fix another 1 << 31 > int32_t::max() with 1u. +- Don't manipulate duration when it's AV_NOPTS_VALUE. +- avcodec/vorbis: 1 << 31 > int32_t::max(), so use 1u << 31 instead. +- avformat/utils: Prevent undefined shift with wrap_bits > 64. +- avcodec/j2kenc: Fix out of array access in encode_cblk() +- avcodec/hevcdsp_template: Fix undefined shift in put_hevc_epel_bi_w_h() +- avcodec/mlpdsp: Fix signed integer overflow, 2nd try +- avcodec/kgv1dec: Check that there is enough input for maximum RLE compression +- avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi* +- avcodec/mpeg4videodec: Check also for negative versions in the validity check +- Close ogg stream upon error when using AV_EF_EXPLODE. +- Fix undefined shift on assumed 8-bit input. +- Use ff_thread_once for fixed, float table init. +- avformat/mov: Propagate errors in mov_switch_root. +- avcodec/hevcdsp_template: Fix invalid shift in put_hevc_epel_bi_w_v() +- avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output() +- avcodec/zmbv: Check that the buffer is large enough for mvec +- avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD137iL0() +- avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb() +- avcodec/snowdec: Check for remaining bitstream in decode_blocks() +- avcodec/snowdec: Check intra block dc differences. +- avformat/mov: Check size of STSC allocation +- avcodec/vc2enc: Clear coef_buf on allocation +- avcodec/h264dec: Fix potential array overread +- avcodec/x86/mpegvideodsp: Fix signedness bug in need_emu +- avcodec/aacpsdsp_template: Fix integer overflows in ps_decorrelate_c() +- avcodec/aacdec_fixed: Fix undefined shift +- avcodec/mdct_*: Fix integer overflow in addition in RESCALE() +- avcodec/snowdec: Fix integer overflow in header parsing +- avcodec/cngdec: Fix integer clipping +- avcodec/sbrdsp_fixed: Fix integer overflow in shift in sbr_hf_g_filt_c() +- avcodec/aacsbr_fixed: Fix division by zero in sbr_gain_calc() +- avutil/softfloat: Add FLOAT_MI
Processed: Re: ffmpeg: CVE-2017-17555
Processing control commands: > reassign -1 src:aubio 0.4.5-1 Bug #884232 [src:ffmpeg] ffmpeg: CVE-2017-17555 Bug reassigned from package 'src:ffmpeg' to 'src:aubio'. No longer marked as found in versions ffmpeg/7:3.4.1-1 and ffmpeg/7:3.4-4. Ignoring request to alter fixed versions of bug #884232 to the same values previously set Bug #884232 [src:aubio] ffmpeg: CVE-2017-17555 Marked as found in versions aubio/0.4.5-1. -- 884232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884232 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg & fdk aac
Aha! Found it! https://anonscm.debian.org/git/pkg-multimedia/ffmpeg.git/commit/?h=jessie&id=cc62001e2fcad3ec0a95f6bf20d7a7c7ac892a9c It looks like the built-in AAC encoder is now preferred, with the upstream 3.0 release. Thanks. Rob On Thu, Jan 19, 2017 at 10:04 AM Rob Ekl wrote: > Thanks for your reply. With the previous version of ffmpeg that I was > using, I had set up my scripts to use libfdk_aac, described on that page as > "the highest-quality AAC encoder available with ffmpeg". I have never > used the VisualOn AAC encoding library. > > Is there a reason why the FDK encoder is no longer included? > > Rob > > > On Thu, Jan 19, 2017 at 9:59 AM Bálint Réczey > wrote: > > Hi Rob, > > 2017-01-19 15:04 GMT+01:00 Rob Ekl : > > Hi. I just upgraded to ffmpeg-7:3.2.2-1~bpo8+1 on jessie, and the FDK AAC > > encoder seems to be missing. Do I need to do something to see it? Can it > be > > added? > > > > $ ffmpeg -encoders | grep -i aac > > ffmpeg version 3.2.2-1~bpo8+1 Copyright (c) 2000-2016 the FFmpeg > developers > > built with gcc 4.9.2 (Debian 4.9.2-10) > > Please use the embedded encoder. > > https://trac.ffmpeg.org/wiki/Encode/AAC : > ... > libvo_aacenc > > VisualOn AAC encoding library. Support for this library has been > removed. Use the native FFmpeg encoder instead: it provides better > quality and supports more than 2 channels. > ... > > Cheers, > Balint > > ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg & fdk aac
Thanks for your reply. With the previous version of ffmpeg that I was using, I had set up my scripts to use libfdk_aac, described on that page as "the highest-quality AAC encoder available with ffmpeg". I have never used the VisualOn AAC encoding library. Is there a reason why the FDK encoder is no longer included? Rob On Thu, Jan 19, 2017 at 9:59 AM Bálint Réczey wrote: > Hi Rob, > > 2017-01-19 15:04 GMT+01:00 Rob Ekl : > > Hi. I just upgraded to ffmpeg-7:3.2.2-1~bpo8+1 on jessie, and the FDK AAC > > encoder seems to be missing. Do I need to do something to see it? Can it > be > > added? > > > > $ ffmpeg -encoders | grep -i aac > > ffmpeg version 3.2.2-1~bpo8+1 Copyright (c) 2000-2016 the FFmpeg > developers > > built with gcc 4.9.2 (Debian 4.9.2-10) > > Please use the embedded encoder. > > https://trac.ffmpeg.org/wiki/Encode/AAC : > ... > libvo_aacenc > > VisualOn AAC encoding library. Support for this library has been > removed. Use the native FFmpeg encoder instead: it provides better > quality and supports more than 2 channels. > ... > > Cheers, > Balint > ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg & fdk aac
Hi Rob, 2017-01-19 15:04 GMT+01:00 Rob Ekl : > Hi. I just upgraded to ffmpeg-7:3.2.2-1~bpo8+1 on jessie, and the FDK AAC > encoder seems to be missing. Do I need to do something to see it? Can it be > added? > > $ ffmpeg -encoders | grep -i aac > ffmpeg version 3.2.2-1~bpo8+1 Copyright (c) 2000-2016 the FFmpeg developers > built with gcc 4.9.2 (Debian 4.9.2-10) Please use the embedded encoder. https://trac.ffmpeg.org/wiki/Encode/AAC : ... libvo_aacenc VisualOn AAC encoding library. Support for this library has been removed. Use the native FFmpeg encoder instead: it provides better quality and supports more than 2 channels. ... Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: ffmpeg: VP9 seek broken in ffplay
Processing control commands: > reassign -1 libvpx 1.5.0-2 Bug #815673 [ffmpeg] ffmpeg: VP9 seek broken in ffplay Bug reassigned from package 'ffmpeg' to 'libvpx'. No longer marked as found in versions ffmpeg/7:2.8.6-1. Ignoring request to alter fixed versions of bug #815673 to the same values previously set Bug #815673 [libvpx] ffmpeg: VP9 seek broken in ffplay There is no source info for the package 'libvpx' at version '1.5.0-2' with architecture '' Unable to make a source version for version '1.5.0-2' Marked as found in versions 1.5.0-2. > forwarded -1 https://chromium-review.googlesource.com/#/c/329320/ Bug #815673 [libvpx] ffmpeg: VP9 seek broken in ffplay Set Bug forwarded-to-address to 'https://chromium-review.googlesource.com/#/c/329320/'. > tags -1 upstream Bug #815673 [libvpx] ffmpeg: VP9 seek broken in ffplay Added tag(s) upstream. -- 815673: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815673 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#702762: Fwd: Re: [FFmpeg-devel] patch for x32 for libpostproc
There seems to be at least some activity here. Maybe we can update the Debian libpostproc package to Michael's new branch. Derek, just to clarify since you worked on the branch the package is currently based on: What are your thoughts on this? Are you interested in continuing this effort? What would you recommend to use for the Debian package? Is it useful to have libpostproc in Debian? (see also the backlog of this bug). Please advise. Thanks On Fri, Sep 05, 2014 at 08:18:57AM +0200, Reimar Döffinger wrote: > On 05.09.2014, at 03:46, Reinhard Tartler wrote: > > On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer wrote: > >>> At the end of the day, I need a source tarball that contains > >>> maintained sources of a stand-alone libpostproc. I don't care too much > >>> how it is created, as long as it doesn't result in code-duplication > >>> with existing sources in Debian. > >> > >> would it work if libpostproc could be build and installed > >> standalone from ffmpeg git / ffmpeg release tarballs? > > > > That would be exactly the code-duplication I referred to in the text > > you've quoted. > > Combined with a release script doing rm of libav*? > I think the problem is that libpostproc just isn't a viable stand-alone program, mostly due to complete lack of stand-alone testability not to mention test infrastructure. > Keeping the separate git up-to-date certainly is an option but involves extra effort (though a lot less than making libpostproc testable stand-alone). > I don't see a good way to split the libraries into separate repositories that does not involve either at least maintaining configure in each or seriously harming bisecting/regression testing. > Release scripts that generate multiple tarballs seems more realistic than splitting the repository, in case that sounds like helpful to anyone... Heres a proof of concept updated libpostproc https://github.com/michaelni/FFmpeg/tree/separated_libpostproc this is simply a clone of ffmpeg with everything unneeded droped and the build system from the libpostproc repository it builds successfully but is completely untested beyond that It seems the old buildsystem lacks HAVE_MMX*_INLINE support, this would need to be added, as well as updating README and all that as well as testing also the differences in aboves repo could possibly be used to construct a script to create a split out libpostproc for debian if thats whats wanted. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
Le duodi 22 fructidor, an CCXXII, Reinhard Tartler a écrit :
> May I ask out of curiosity, what in FFmpeg actually uses libpostproc
> other than than libavfilter/vf_pp.c? You said that you prefer to
> maintain libpostproc inside FFmpeg because that way you can apply the
> FFmpeg test system on it. I wonder what automated tests cover code in
> libpostproc?
http://coverage.ffmpeg.org/ffmpeg/libavfilter/vf_pp.c.gcov.html
I suppose the relevant tests are filter-pp{,2,3,4,5,6}.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Mon, Sep 08, 2014 at 08:13:48AM -0400, Reinhard Tartler wrote: > On Sun, Sep 7, 2014 at 5:30 PM, Michael Niedermayer wrote: > > On Fri, Sep 05, 2014 at 08:18:57AM +0200, Reimar Döffinger wrote: > >> On 05.09.2014, at 03:46, Reinhard Tartler wrote: > >> > On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer > >> > wrote: > >> >>> At the end of the day, I need a source tarball that contains > >> >>> maintained sources of a stand-alone libpostproc. I don't care too much > >> >>> how it is created, as long as it doesn't result in code-duplication > >> >>> with existing sources in Debian. > >> >> > >> >> would it work if libpostproc could be build and installed > >> >> standalone from ffmpeg git / ffmpeg release tarballs? > >> > > >> > That would be exactly the code-duplication I referred to in the text > >> > you've quoted. > >> > >> Combined with a release script doing rm of libav*? > >> I think the problem is that libpostproc just isn't a viable stand-alone > >> program, mostly due to complete lack of stand-alone testability not to > >> mention test infrastructure. > >> Keeping the separate git up-to-date certainly is an option but involves > >> extra effort (though a lot less than making libpostproc testable > >> stand-alone). > >> I don't see a good way to split the libraries into separate repositories > >> that does not involve either at least maintaining configure in each or > >> seriously harming bisecting/regression testing. > >> Release scripts that generate multiple tarballs seems more realistic than > >> splitting the repository, in case that sounds like helpful to anyone... > > > > Heres a proof of concept updated libpostproc > > > > https://github.com/michaelni/FFmpeg/tree/separated_libpostproc > > > > this is simply a clone of ffmpeg with everything unneeded > > droped and the build system from the libpostproc repository > > it builds successfully but is completely untested beyond that > > > > It seems the old buildsystem lacks HAVE_MMX*_INLINE support, this > > would need to be added, as well as updating README and all that as > > well as testing > > That repo looks promising. However, the README and installations > instructions still refer to FFmpeg which seems rather confusing to me. > Also, the licensing needs to be clarified. AFAIUI, libpostproc is GPL > only, so adding a LGPL license is also confusing at best. right, yes, ive removed them, COPYING* still contains to the GPL so that should do ive also fixed the MMX/SSE2 build, its still completey untested though beyond a simple "make" [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Mon, Sep 08, 2014 at 08:13:48AM -0400, Reinhard Tartler wrote:
[..]
> May I ask out of curiosity, what in FFmpeg actually uses libpostproc
> other than than libavfilter/vf_pp.c? You said that you prefer to
> maintain libpostproc inside FFmpeg because that way you can apply the
> FFmpeg test system on it. I wonder what automated tests cover code in
> libpostproc?
70% of pp is covered[1], through that vf_pp filter, see
fate-filter-pp{,2,3,4,5,6}. AFAIK that's the only code using libpostproc
so far in FFmpeg.
[1]: http://coverage.ffmpeg.org/ffmpeg/libpostproc/index.html
[...]
--
Clément B.
pgpsu6HZLAyuv.pgp
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Sun, Sep 7, 2014 at 5:30 PM, Michael Niedermayer wrote: > On Fri, Sep 05, 2014 at 08:18:57AM +0200, Reimar Döffinger wrote: >> On 05.09.2014, at 03:46, Reinhard Tartler wrote: >> > On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer >> > wrote: >> >>> At the end of the day, I need a source tarball that contains >> >>> maintained sources of a stand-alone libpostproc. I don't care too much >> >>> how it is created, as long as it doesn't result in code-duplication >> >>> with existing sources in Debian. >> >> >> >> would it work if libpostproc could be build and installed >> >> standalone from ffmpeg git / ffmpeg release tarballs? >> > >> > That would be exactly the code-duplication I referred to in the text >> > you've quoted. >> >> Combined with a release script doing rm of libav*? >> I think the problem is that libpostproc just isn't a viable stand-alone >> program, mostly due to complete lack of stand-alone testability not to >> mention test infrastructure. >> Keeping the separate git up-to-date certainly is an option but involves >> extra effort (though a lot less than making libpostproc testable >> stand-alone). >> I don't see a good way to split the libraries into separate repositories >> that does not involve either at least maintaining configure in each or >> seriously harming bisecting/regression testing. >> Release scripts that generate multiple tarballs seems more realistic than >> splitting the repository, in case that sounds like helpful to anyone... > > Heres a proof of concept updated libpostproc > > https://github.com/michaelni/FFmpeg/tree/separated_libpostproc > > this is simply a clone of ffmpeg with everything unneeded > droped and the build system from the libpostproc repository > it builds successfully but is completely untested beyond that > > It seems the old buildsystem lacks HAVE_MMX*_INLINE support, this > would need to be added, as well as updating README and all that as > well as testing That repo looks promising. However, the README and installations instructions still refer to FFmpeg which seems rather confusing to me. Also, the licensing needs to be clarified. AFAIUI, libpostproc is GPL only, so adding a LGPL license is also confusing at best. > also the differences in aboves repo could possibly be used to > construct a script to create a split out libpostproc for debian > if thats whats wanted. Debian already does ship a split out libpostproc. I'm happy to upgrade it to some newer version if a tarball appeared. May I ask out of curiosity, what in FFmpeg actually uses libpostproc other than than libavfilter/vf_pp.c? You said that you prefer to maintain libpostproc inside FFmpeg because that way you can apply the FFmpeg test system on it. I wonder what automated tests cover code in libpostproc? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Fri, Sep 05, 2014 at 08:18:57AM +0200, Reimar Döffinger wrote: > On 05.09.2014, at 03:46, Reinhard Tartler wrote: > > On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer > > wrote: > >>> At the end of the day, I need a source tarball that contains > >>> maintained sources of a stand-alone libpostproc. I don't care too much > >>> how it is created, as long as it doesn't result in code-duplication > >>> with existing sources in Debian. > >> > >> would it work if libpostproc could be build and installed > >> standalone from ffmpeg git / ffmpeg release tarballs? > > > > That would be exactly the code-duplication I referred to in the text > > you've quoted. > > Combined with a release script doing rm of libav*? > I think the problem is that libpostproc just isn't a viable stand-alone > program, mostly due to complete lack of stand-alone testability not to > mention test infrastructure. > Keeping the separate git up-to-date certainly is an option but involves extra > effort (though a lot less than making libpostproc testable stand-alone). > I don't see a good way to split the libraries into separate repositories that > does not involve either at least maintaining configure in each or seriously > harming bisecting/regression testing. > Release scripts that generate multiple tarballs seems more realistic than > splitting the repository, in case that sounds like helpful to anyone... Heres a proof of concept updated libpostproc https://github.com/michaelni/FFmpeg/tree/separated_libpostproc this is simply a clone of ffmpeg with everything unneeded droped and the build system from the libpostproc repository it builds successfully but is completely untested beyond that It seems the old buildsystem lacks HAVE_MMX*_INLINE support, this would need to be added, as well as updating README and all that as well as testing also the differences in aboves repo could possibly be used to construct a script to create a split out libpostproc for debian if thats whats wanted. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On 05.09.2014, at 03:46, Reinhard Tartler wrote: > On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer wrote: >>> At the end of the day, I need a source tarball that contains >>> maintained sources of a stand-alone libpostproc. I don't care too much >>> how it is created, as long as it doesn't result in code-duplication >>> with existing sources in Debian. >> >> would it work if libpostproc could be build and installed >> standalone from ffmpeg git / ffmpeg release tarballs? > > That would be exactly the code-duplication I referred to in the text > you've quoted. Combined with a release script doing rm of libav*? I think the problem is that libpostproc just isn't a viable stand-alone program, mostly due to complete lack of stand-alone testability not to mention test infrastructure. Keeping the separate git up-to-date certainly is an option but involves extra effort (though a lot less than making libpostproc testable stand-alone). I don't see a good way to split the libraries into separate repositories that does not involve either at least maintaining configure in each or seriously harming bisecting/regression testing. Release scripts that generate multiple tarballs seems more realistic than splitting the repository, in case that sounds like helpful to anyone... ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer wrote: >> At the end of the day, I need a source tarball that contains >> maintained sources of a stand-alone libpostproc. I don't care too much >> how it is created, as long as it doesn't result in code-duplication >> with existing sources in Debian. > > would it work if libpostproc could be build and installed > standalone from ffmpeg git / ffmpeg release tarballs? That would be exactly the code-duplication I referred to in the text you've quoted. Best, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Thu, Sep 04, 2014 at 07:42:00PM -0400, Reinhard Tartler wrote: > On Thu, Sep 4, 2014 at 7:27 AM, Michael Niedermayer wrote: > > Hi Reinhard > > > > On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote: > >> On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer > >> wrote: > >> > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: > >> >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer > >> >> wrote: > >> >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: > >> >> >> Hi, > >> >> >> > >> >> >> as discussed in IRC, I was trying to minimal-invasively port > >> >> >> libpostproc (the Debian source package) to x32¹. I could not > >> >> >> test it (for lack of a stand-alone test program) yet, but at > >> >> >> least I got it to build. > >> >> > > >> >> > you could try to test by buiding ffmpeg as a whole but disable asm > >> >> > everywhere except libpostproc > >> >> > that might allow "easy" testing though fate or ffmpeg with libavfilter > >> >> > >> >> Is http://git.videolan.org/?p=libpostproc.git still maintained? > >> > > >> > AFAIK, no, it seems the last commit is 2 years ago > >> > > >> > > >> >> > >> >> The Debian package tracks that repository, and ideally we could > >> >> collect the postproc patches there. > >> > > >> > libpostproc was and is maintained in > >> > git://source.ffmpeg.org/ffmpeg.git > >> > >> So the promise given in > >> https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html > >> doesn't hold anymore? > > > > Can you be a bit more specific ? what "promise" by whom exactly do > > you speak of ? > > > > The promise of having a maintained stand-alone libpostproc. > > >> > >> Any chance to make you reconsider reviving the standalone libpostproc.git? > > > > From what i remember there where some problems with that repository > > so actually maintaining it would probably imply first recreating it > > > > for example try to build a old revission: > > > > git checkout a792a836e3d9ef6f1f311604b38095e587282ca7 > > (this is libpostproc/master~20 ATM) > > ./configure > > -bash: ./configure: No such file or directory > > > > this is a problem for anyone maintaining the code as for example > > git bisect > > would not be usable at all > > > > or if you do a git show > > commit a792a836e3d9ef6f1f311604b38095e587282ca7 > > Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c > > > > Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6 > > ancestors > > > > So really, if someone wants to maintain or use libpostproc.git, first > > these things need to be fixed > > > > but i dont understand why you dont just take libpostproc > > from where its developed, tested and used ? > > > > but if it helps i guess we could copy the libpostproc from FFmpeg > > over the one in libpostproc.git (which is what reimar suggested) > > libpostproc.git was only intended to be a copy of FFmpeg with libs > > other than libpostproc removed anyway. > > > > Would this help you ? > > At the end of the day, I need a source tarball that contains > maintained sources of a stand-alone libpostproc. I don't care too much > how it is created, as long as it doesn't result in code-duplication > with existing sources in Debian. would it work if libpostproc could be build and installed standalone from ffmpeg git / ffmpeg release tarballs? i havent really investigated it but it seems with the 2 line patch below one can achive that with ./configure --enable-gpl --disable-all --enable-shared --enable-postproc && make (it also would need changing #includes "..." to <...> to use system installed libavutil headers) this seems a easier path than maintaining libpostproc.git if it would work for debian, if not iam sure we will find another solution like updating libpostproc.git. diff --git a/Makefile b/Makefile index 57f6a91..63423bf 100644 --- a/Makefile +++ b/Makefile @@ -48,7 +48,7 @@ FFLIBS-$(CONFIG_POSTPROC) += postproc FFLIBS-$(CONFIG_SWRESAMPLE) += swresample FFLIBS-$(CONFIG_SWSCALE)+= swscale -FFLIBS := avutil +FFLIBS-$(CONFIG_AVUTIL) += avutil DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset) $(SRC_PATH)/doc/ffprobe.xsd EXAMPLES_FILES := $(wildcard $(SRC_PATH)/doc/examples/*.c) $(SRC_PATH)/doc/examples/Makefile $(SRC_PATH)/doc/examples/README diff --git a/configure b/configure index 7de07c3..7a3764f 100755 --- a/configure +++ b/configure @@ -2614,7 +2614,7 @@ avdevice_deps="avformat avcodec avutil" avfilter_deps="avutil" avformat_deps="avcodec avutil" avresample_deps="avutil" -postproc_deps="avutil gpl" +postproc_deps="gpl" swresample_deps="avutil" swscale_deps="avutil" [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.ali
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Thu, Sep 4, 2014 at 7:27 AM, Michael Niedermayer wrote: > Hi Reinhard > > On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote: >> On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer wrote: >> > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: >> >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer >> >> wrote: >> >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: >> >> >> Hi, >> >> >> >> >> >> as discussed in IRC, I was trying to minimal-invasively port >> >> >> libpostproc (the Debian source package) to x32¹. I could not >> >> >> test it (for lack of a stand-alone test program) yet, but at >> >> >> least I got it to build. >> >> > >> >> > you could try to test by buiding ffmpeg as a whole but disable asm >> >> > everywhere except libpostproc >> >> > that might allow "easy" testing though fate or ffmpeg with libavfilter >> >> >> >> Is http://git.videolan.org/?p=libpostproc.git still maintained? >> > >> > AFAIK, no, it seems the last commit is 2 years ago >> > >> > >> >> >> >> The Debian package tracks that repository, and ideally we could >> >> collect the postproc patches there. >> > >> > libpostproc was and is maintained in >> > git://source.ffmpeg.org/ffmpeg.git >> >> So the promise given in >> https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html >> doesn't hold anymore? > > Can you be a bit more specific ? what "promise" by whom exactly do > you speak of ? > The promise of having a maintained stand-alone libpostproc. >> >> Any chance to make you reconsider reviving the standalone libpostproc.git? > > From what i remember there where some problems with that repository > so actually maintaining it would probably imply first recreating it > > for example try to build a old revission: > > git checkout a792a836e3d9ef6f1f311604b38095e587282ca7 > (this is libpostproc/master~20 ATM) > ./configure > -bash: ./configure: No such file or directory > > this is a problem for anyone maintaining the code as for example > git bisect > would not be usable at all > > or if you do a git show > commit a792a836e3d9ef6f1f311604b38095e587282ca7 > Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c > > Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6 > ancestors > > So really, if someone wants to maintain or use libpostproc.git, first > these things need to be fixed > > but i dont understand why you dont just take libpostproc > from where its developed, tested and used ? > > but if it helps i guess we could copy the libpostproc from FFmpeg > over the one in libpostproc.git (which is what reimar suggested) > libpostproc.git was only intended to be a copy of FFmpeg with libs > other than libpostproc removed anyway. > > Would this help you ? At the end of the day, I need a source tarball that contains maintained sources of a stand-alone libpostproc. I don't care too much how it is created, as long as it doesn't result in code-duplication with existing sources in Debian. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
Hi Reinhard On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote: > On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer wrote: > > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: > >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer > >> wrote: > >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: > >> >> Hi, > >> >> > >> >> as discussed in IRC, I was trying to minimal-invasively port > >> >> libpostproc (the Debian source package) to x32¹. I could not > >> >> test it (for lack of a stand-alone test program) yet, but at > >> >> least I got it to build. > >> > > >> > you could try to test by buiding ffmpeg as a whole but disable asm > >> > everywhere except libpostproc > >> > that might allow "easy" testing though fate or ffmpeg with libavfilter > >> > >> Is http://git.videolan.org/?p=libpostproc.git still maintained? > > > > AFAIK, no, it seems the last commit is 2 years ago > > > > > >> > >> The Debian package tracks that repository, and ideally we could > >> collect the postproc patches there. > > > > libpostproc was and is maintained in > > git://source.ffmpeg.org/ffmpeg.git > > So the promise given in > https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html > doesn't hold anymore? Can you be a bit more specific ? what "promise" by whom exactly do you speak of ? > > Any chance to make you reconsider reviving the standalone libpostproc.git? From what i remember there where some problems with that repository so actually maintaining it would probably imply first recreating it for example try to build a old revission: git checkout a792a836e3d9ef6f1f311604b38095e587282ca7 (this is libpostproc/master~20 ATM) ./configure -bash: ./configure: No such file or directory this is a problem for anyone maintaining the code as for example git bisect would not be usable at all or if you do a git show commit a792a836e3d9ef6f1f311604b38095e587282ca7 Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6 ancestors So really, if someone wants to maintain or use libpostproc.git, first these things need to be fixed but i dont understand why you dont just take libpostproc from where its developed, tested and used ? but if it helps i guess we could copy the libpostproc from FFmpeg over the one in libpostproc.git (which is what reimar suggested) libpostproc.git was only intended to be a copy of FFmpeg with libs other than libpostproc removed anyway. Would this help you ? > > > please use that for the debian package > > I fear that's not feasible at this point. Why ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer wrote: > On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: >> On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer wrote: >> > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: >> >> Hi, >> >> >> >> as discussed in IRC, I was trying to minimal-invasively port >> >> libpostproc (the Debian source package) to x32¹. I could not >> >> test it (for lack of a stand-alone test program) yet, but at >> >> least I got it to build. >> > >> > you could try to test by buiding ffmpeg as a whole but disable asm >> > everywhere except libpostproc >> > that might allow "easy" testing though fate or ffmpeg with libavfilter >> >> Is http://git.videolan.org/?p=libpostproc.git still maintained? > > AFAIK, no, it seems the last commit is 2 years ago > > >> >> The Debian package tracks that repository, and ideally we could >> collect the postproc patches there. > > libpostproc was and is maintained in > git://source.ffmpeg.org/ffmpeg.git So the promise given in https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html doesn't hold anymore? Any chance to make you reconsider reviving the standalone libpostproc.git? > please use that for the debian package I fear that's not feasible at this point. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: > On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer wrote: > > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: > >> Hi, > >> > >> as discussed in IRC, I was trying to minimal-invasively port > >> libpostproc (the Debian source package) to x32¹. I could not > >> test it (for lack of a stand-alone test program) yet, but at > >> least I got it to build. > > > > you could try to test by buiding ffmpeg as a whole but disable asm > > everywhere except libpostproc > > that might allow "easy" testing though fate or ffmpeg with libavfilter > > Is http://git.videolan.org/?p=libpostproc.git still maintained? AFAIK, no, it seems the last commit is 2 years ago > > The Debian package tracks that repository, and ideally we could > collect the postproc patches there. libpostproc was and is maintained in git://source.ffmpeg.org/ffmpeg.git please use that for the debian package We also have a testing infrastructure in place for ffmpeg.git which tests libpostproc on a wide varity of platforms, libpostproc.git lacks that. And anyone using postprocessing with FFmpeg also tests the code so bugs in postproc in ffmpeg.git should be quickly found, reported and fixes. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer wrote: > On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: >> Hi, >> >> as discussed in IRC, I was trying to minimal-invasively port >> libpostproc (the Debian source package) to x32¹. I could not >> test it (for lack of a stand-alone test program) yet, but at >> least I got it to build. > > you could try to test by buiding ffmpeg as a whole but disable asm > everywhere except libpostproc > that might allow "easy" testing though fate or ffmpeg with libavfilter Is http://git.videolan.org/?p=libpostproc.git still maintained? The Debian package tracks that repository, and ideally we could collect the postproc patches there. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi On Sun, Aug 10, 2014 at 09:10:23AM -0400, Reinhard Tartler wrote: > On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs wrote: [...] > > IMHO it's reasonable to expect core APIs to be upwards-compatible and keep > > deprecated interfaces around for another release or two. > > This is exactly what Libav is doing: The deprecation process for > symbols, APIs, enums, etc. takes *years*, because so many software > packages in Debian and else where use them, and it is so believably > painful to change them. Just have a look at the last two Libav > transitions, and the massive amount of patches it took to get packages > fixed and eventually to get Debian to the new Libav release. > > Now enter FFmpeg. > > FFmpeg has a significant higher release frequency, (it seems to me > about every 3-4 months), so that you would get a deprecation cycle > that is considerably less than a year. In practice, the deprecation > cycle more or less seems to match Libav's cycle, because at least > right now, FFmpeg tracks Libav's API. If that were not the case (and > I promise you FFmpeg would stop tracking Libav as soon as it replaces > Libav in Debian), I can almost guarantee [1] you that FFmpeg would > very much prefer to resume to the deprecation cycle the project > before: None, i.e., every piece of software is expected to keep up > with FFmpeg's master branch for reasons Jean-Yves outlines. These fears are unfounded and these predictions not only do not match reality they also lack any reason or motive for FFmpeg. We would be shooting us in our own foot if we randomly broke API or stopped integrating improvments It has always been my wish to provide the best multimedia software to the world. And sure us including all improvments and bugfixes from Libav is in line with that. also you have write access to FFmpeg git ... and iam happy to work together with andreas and anyone else on debian lifecycle releases. And you are certainly welcome too [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On Montag, 11. August 2014, Ben Hutchings wrote: > dvswitch was also broken by the removal of support for downscaled > decoding of DV video. I don't know whether that change is specific to > libav or was also made in FFmpeg. dvswitch is still broken and there is no dvswitch in jessie... We have a daily job testing against libav from git, but that was alwayys broken everyday in the last half year or so. Maybe it would be useful to setup building against ffmpeg. cheers, Holger signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, 2014-08-10 at 23:02 +0200, Andreas Cadhalpun wrote: [...] > * dvswitch: Still uses CodecID (and also avcodec_encode_video, but > that is still present in FFmpeg.) [3] [...] dvswitch was also broken by the removal of support for downscaled decoding of DV video. I don't know whether that change is specific to libav or was also made in FFmpeg. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Reinhard, On 10.08.2014 15:10, Reinhard Tartler wrote: On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs wrote: IMHO it's reasonable to expect core APIs to be upwards-compatible and keep deprecated interfaces around for another release or two. This is exactly what Libav is doing: The deprecation process for symbols, APIs, enums, etc. takes *years*, because so many software packages in Debian and else where use them, and it is so believably painful to change them. Just have a look at the last two Libav transitions, and the massive amount of patches it took to get packages fixed and eventually to get Debian to the new Libav release. Now enter FFmpeg. FFmpeg also has a deprecation process and keeps deprecated features around longer than Libav. For example, avcodec_encode_video, av_close_input_file and avcodec_decode_audio3 are still present in FFmpeg, but already removed from Libav. FFmpeg has a significant higher release frequency, (it seems to me about every 3-4 months), so that you would get a deprecation cycle that is considerably less than a year. The deprecation cycle is not related to the release frequency, as many FFmpeg release are API/ABI backwards compatible with the previous one. In practice, the deprecation cycle more or less seems to match Libav's cycle, because at least right now, FFmpeg tracks Libav's API. If that were not the case (and I promise you FFmpeg would stop tracking Libav as soon as it replaces Libav in Debian), I can almost guarantee [1] you that FFmpeg would very much prefer to resume to the deprecation cycle the project before: None, i.e., every piece of software is expected to keep up with FFmpeg's master branch for reasons Jean-Yves outlines. I think you won't be able to keep that promise, because it wouldn't make much sense to stop merging changes from Libav (especially, if they are useful) after doing it for such a long time. Even in the unlikely event that this might happen, there is no reason to change the handling of deprecations. [1] at least statements such as https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160876.html strongly suggest this (at least if you have followed the libavresample/libswresample mess). I'm understanding this mail differently: What Michael is explaining is that it is more difficult for FFmpeg to change things in libavresample than in libswresample, because Libav is unlikely to merge back changes, but FFmpeg tries to be compatible with Libav. In reality, there hasn't been any backwards incompatible change in libswresample (still soversion 0), but there has been one in libavresample (now at soversion 1). Keeping your own static version is the only reasonable approach. That may be OK on Windows. However, a proper Linux distribution is supposed to be an integrated whole and not a haphazard collection of programs, each bringing along their own copy of core libraries and their own un- or semi-fixed security problems. BTW Jean-Yves outlines an approach that used to be very common on the past: Pick some particular snapshot of FFmpeg and maintain that in a downstream project, and expect users to use that because it is too much effort to keep up with FFmpeg's release frequency. It is easy to 'keep up' with releases that are API/ABI compatible, which many FFmpeg releases are. One doesn't even have to recompile dependent programs (if they are not buggy), one can just install the new version of the libraries. Prominent examples of projects that did this (and actually, still do) include xine-lib, mplayer, xbmc, and many more. This lead exactly to the mess I was talking about in my previous email: dozens of embedded code-copies that were accepted into the Debian archive. As you must know, xine-lib and xbmc are - and mplayer was - compiled against the system version of Libav in Debian. Over many years, I've spearheaded a significant effort in Debian with packaging and in upstream with introducing a release culture in FFmpeg (as release manager) to get to somewhat same release frequencies, so that downstream projects at least had a chance to agree on common versions of FFmpeg. At the time of the split, I was worried that this work would have been in vain. It appears your work has not have been in vain, as FFmpeg's current release culture takes into account that any backwards incompatible API change means a lot of work for everyone using it. I believe this is handled now much better than in the times before the 0.5 release. If you are unhappy with how the releases are managed in FFmpeg, you can always send your concerns to ffmpeg-devel (and I think you still have commit rights for FFmpeg's git repository as well). Considering that most active developers of FFmpeg at that time (which coincidentally supported my approach to release management and frequency) joined what is now known as Libav, I continued my work as upstream release manager in Libav, because I consider Libav as much more
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs wrote: > Hi, > > Jean-Yves Avenard: >> Including rename of constants (code enums id for example). > > Another nail in libav's coffin, then. That's one way to see it. To me, this makes mythtv unsuitable for inclusion into Debian. Let me explain why: > IMHO it's reasonable to expect core APIs to be upwards-compatible and keep > deprecated interfaces around for another release or two. This is exactly what Libav is doing: The deprecation process for symbols, APIs, enums, etc. takes *years*, because so many software packages in Debian and else where use them, and it is so believably painful to change them. Just have a look at the last two Libav transitions, and the massive amount of patches it took to get packages fixed and eventually to get Debian to the new Libav release. Now enter FFmpeg. FFmpeg has a significant higher release frequency, (it seems to me about every 3-4 months), so that you would get a deprecation cycle that is considerably less than a year. In practice, the deprecation cycle more or less seems to match Libav's cycle, because at least right now, FFmpeg tracks Libav's API. If that were not the case (and I promise you FFmpeg would stop tracking Libav as soon as it replaces Libav in Debian), I can almost guarantee [1] you that FFmpeg would very much prefer to resume to the deprecation cycle the project before: None, i.e., every piece of software is expected to keep up with FFmpeg's master branch for reasons Jean-Yves outlines. [1] at least statements such as https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160876.html strongly suggest this (at least if you have followed the libavresample/libswresample mess). >> Keeping your own static version is the only reasonable approach. > > That may be OK on Windows. However, a proper Linux distribution is supposed > to be an integrated whole and not a haphazard collection of programs, each > bringing along their own copy of core libraries and their own un- or > semi-fixed security problems. > BTW Jean-Yves outlines an approach that used to be very common on the past: Pick some particular snapshot of FFmpeg and maintain that in a downstream project, and expect users to use that because it is too much effort to keep up with FFmpeg's release frequency. Prominent examples of projects that did this (and actually, still do) include xine-lib, mplayer, xbmc, and many more. This lead exactly to the mess I was talking about in my previous email: dozens of embedded code-copies that were accepted into the Debian archive. Over many years, I've spearheaded a significant effort in Debian with packaging and in upstream with introducing a release culture in FFmpeg (as release manager) to get to somewhat same release frequencies, so that downstream projects at least had a chance to agree on common versions of FFmpeg. At the time of the split, I was worried that this work would have been in vain. Considering that most active developers of FFmpeg at that time (which coincidentally supported my approach to release management and frequency) joined what is now known as Libav, I continued my work as upstream release manager in Libav, because I consider Libav as much more suited for Debian than FFmpeg. Today, I still firmly believe that this was the right move for Debian as a project. I do strongly believe that projects that require people to use FFmpeg actually mean to use their own private fork (cf. the mythtv debacle), and given the amount of packages in Debian, it would significantly much more effort to "port" (or "patch" as Andreas is phrasing it) them to some common version of FFmpeg than doing what we are doing now: Making sure they work with the version of Libav's libavcodec.so implementation. This thread has shown a couple of examples that support this argument: Mythtv, but also mplayer that claims to work with a system libavcodec.so, which is true as long as it matches the version that is was built against. This is what makes mplayer so hard to package, and was ultimately the reason why I requested mplayer's removal (which is more than ironic, given that back then, I fought with ftp-master for many years to get it included into Debian in the first place). On a related note: Most Libav developers are very tired of the constant flamewars and defamation attempts that arises from FFmpeg. Over years, Libav tries to convinced everyone by providing usable software releases. Nevertheless, this particular debate is very worrisome: The silence from the Libav camp seems to not to be taken as consent. Quite the contrary is true. How to proceed from here? TBH, I'm not sure. Ideally, both projects would find some common ground and "just merge" (however that would technically look like). However, this very debate within Debian shows that this is unlikely to happen anytime soon: There is way to much disagreement on very fundamental questions that require agreement within a free software project, and the hostile and
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/08/2014 09:22 PM, Matthias Urlichs wrote: > We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd > hate to report some intractable codec bug which Upstream closes with > an "it works with FFmpeg" comment Oh, btw, just a few days ago, that's exactly what happened on kdenlive [1]. A developer posted the following statement on an issue which is open for more than 1.5 years now: [quote] Confirm this is a libav problem, use builds with ffmpeg or wait debian (&derivatives) to bring ffmpeg back [/quote] Just thought this might fit here... Regards, Pb == References: [1] http://www.kdenlive.org/mantis/view.php?id=2943#c10195 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Quoting Bálint Réczey (2014-08-09 14:39:09) > 2014-08-09 13:41 GMT+02:00 Jonas Smedegaard : >> Quoting Bálint Réczey (2014-08-09 11:38:54) >>> Upstream makes sure all their use-cases work well with FFmpeg and >>> not interested in Libav-related issues. >> >> According to XBMC, they only make sure their code works with >> XBMC-FFmpeg. >> >> >>> I can't fix the problems because I don't have any HW reproducing >>> them, and I don't get help from Libav upstream/maintainers either in >>> fixing those issues. >> >> That sounds to me like you do not factually know if XBMC will be >> broken also when linked against FFmeg (you only really know about >> XBMC-FFmpeg). > Since XBMC switched to vanilla FFmpeg from their internal fork I would > be really surprised if XBMC did not work with the proposed new FFmpeg > packages. Whoops - I confused XBMC and MythTV. Sorry for the noise. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
2014-08-09 13:41 GMT+02:00 Jonas Smedegaard : > Quoting Bálint Réczey (2014-08-09 11:38:54) >> XBMC works with Libav for most use-cases while it fails in the rest, >> notably it can not use VDPAU acceleration which is being >> (understandably) complained about very often (#742896). Another issue >> is Libav crashing on bad input which makes XBMC/Libav unusable in PVR >> configurations when signal is corrupted sometimes (#741170). > > Ok, so you know factually that some things are broken when linking XBMC > with Libav instead of XBMC-FFmpeg. Well, it depends on the definition of factually. I could not test the VDPAU issues myself. :-) > > >> Upstream makes sure all their use-cases work well with FFmpeg and not >> interested in Libav-related issues. > > According to XBMC, they only make sure their code works with > XBMC-FFmpeg. > > >> I can't fix the problems because I don't have any HW reproducing them, >> and I don't get help from Libav upstream/maintainers either in fixing >> those issues. > > That sounds to me like you do not factually know if XBMC will be broken > also when linked against FFmeg (you only really know about XBMC-FFmpeg). Since XBMC switched to vanilla FFmpeg from their internal fork I would be really surprised if XBMC did not work with the proposed new FFmpeg packages. -dmo packages are built with external FFmpeg, too... If this test is a deal-breaker for accepting FFmpeg into experimental I can provide binaries for testing but probably most curious DD-s having the right HW would be able to test if my theory is right. > > >> I would like to have flawlessly working XBMC in Debian as well, but it >> can't happen without fixing the Libav issues I mentioned above or >> letting FFmpeg entering Debian. > > I do understand how it is easier for you to link XBMC against FFmpeg > than against Libav, since FFmpeg has similar/same API as XBMC-FFmpeg, > but it seems to me that you are jumping to conclusions when stating that > linking against (non-XBMC-)FFmpeg will make XBMC work "flawlessly". I would say it is not a mathematically correct reasoning, but a strong expectation supported by observations. Prove me wrong if you really think I'm missing something, I will stand corrected. I made falsifiable statements. By "flawlessly" I mean very close to upstream's expectations and specifically fixing VDPAU and PVR issues I mentioned earlier. Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Quoting Bálint Réczey (2014-08-09 11:38:54) > XBMC works with Libav for most use-cases while it fails in the rest, > notably it can not use VDPAU acceleration which is being > (understandably) complained about very often (#742896). Another issue > is Libav crashing on bad input which makes XBMC/Libav unusable in PVR > configurations when signal is corrupted sometimes (#741170). Ok, so you know factually that some things are broken when linking XBMC with Libav instead of XBMC-FFmpeg. > Upstream makes sure all their use-cases work well with FFmpeg and not > interested in Libav-related issues. According to XBMC, they only make sure their code works with XBMC-FFmpeg. > I can't fix the problems because I don't have any HW reproducing them, > and I don't get help from Libav upstream/maintainers either in fixing > those issues. That sounds to me like you do not factually know if XBMC will be broken also when linked against FFmeg (you only really know about XBMC-FFmpeg). > I would like to have flawlessly working XBMC in Debian as well, but it > can't happen without fixing the Libav issues I mentioned above or > letting FFmpeg entering Debian. I do understand how it is easier for you to link XBMC against FFmpeg than against Libav, since FFmpeg has similar/same API as XBMC-FFmpeg, but it seems to me that you are jumping to conclusions when stating that linking against (non-XBMC-)FFmpeg will make XBMC work "flawlessly". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, 2014-08-08 20:06 GMT+02:00 Andreas Cadhalpun : > Hi Reinhard, > > > On 08.08.2014 14:29, Reinhard Tartler wrote: >> >> On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs >> wrote: >> I intended to come up with a more timely full response, but I just >> didn't get to it so far. > > > Thanks for explaining your point of view here. > > >> For now, please refer to http://lwn.net/Articles/607662/, > > > Have a look at: http://lwn.net/Articles/608040/ > > I was not there, when the FFmpeg/Libav split happened and I don't want to > judge, whether it was a good thing or not. But it clearly caused a lot of > bad blood between the developers involved, which in my opinion hurts the > development of the multimedia framework in recent times. > > >> http://codecs.multimedia.cx/?p=370 (rather old, but still true), and > > > If these features weren't used, they wouldn't have been developed. > And many new features have been added to FFmpeg after that post. > > >> http://codecs.multimedia.cx/?p=674 (recent update on that matter) > > > Let me quote from there: > "But that’s not what kills the fun, “security holes” do. > > With an advance of automatic fuzz tools it’s easy to generate millions of > damaged files that crash your decoder and yet there are no tools for > generating correct patches. Fixing those crashes is tedious, requires a lot > of thinking (should I disable it? will it affect decoding correct files? > etc.) and in other words not fun at all." > > That seems as if he doesn't want to continue Libav development, because > fixing security issues is tedious work. > It has basically nothing to do with whether FFmpeg is of good quality > security wise or not, or a good or bad competitor against Libav. > > >> Regarding Marco's argument that libav had few friends, well, let me >> point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 >> for instance. > > > One person thinking that the code is 'beautiful' is no convincing argument. > The number of people expressing their interest in having FFmpeg back in > Debian is a lot more convincing. > > >>> IMHO the best idea at this point would be to toss out libav, and rebuild >>> the rdeps with ffmpeg. Now, before it's too late for jessie. >> >> >> I think that is totally out of question: Uploading FFmpeg to our >> archive will break the Debian archive so hard that it will take months >> to get everything back to testing, if it works at all. > > > Let me repeat what I wrote in my initial mail in this thread: > Having FFmpeg in the Debian archive breaks absolutely *nothing*, but it > gives developers and users a choice between the two. > > Even if Libav were to be removed, a transition to FFmpeg could be rather > smooth, as all the necessary patches already exist. > But you're right that the time to test the resulting packages is getting > rather short for the coming freeze. > > Still it can make sense for packages that are tested with FFmpeg upstream > and have known issues with Libav. > > So if you and the other Libav maintainers were to support the idea of having > both, the security and release teams could perhaps be convinced to allow > that. This has been my goal from the beginning and I hoped that would be > appreciated. > > >> To the best of my knowledge, there are only two high-profile projects >> that play hardball to require FFmpeg: Mplayer and mythtv. Neither of >> those do that (again to the best of my knowledge) mainly because of >> technical but rather very political reasons. The case of mplayer has >> been elaborated extensively in >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the >> following "discussion" with Reimar - my conclusion from that is while >> technically possible, nobody wants to make mplayer work with Libav - >> and that's why it was removed, not because of the FFmpeg dependency). >> For Mythtv I can only say that they didn't even bother engaging any >> discussion. > > > That FFmpeg has more features is a rather technical argument. > > Note that also many other projects are developed mainly with FFmpeg, they > just happen to not break completely when compiled against Libav. > > For example, mpv prefers FFmpeg for good reasons: > "Although mpv attempts to work well with both FFmpeg and Libav, FFmpeg is > preferred in general. This is simply because FFmpeg merges from Libav, and > seems to have more features and fewer bugs than Libav." [1] > > These features are actually requested by users, see e.g. [2]. > > >> (All) other high-profile downstream projects, including VLC or XBMC >> (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may > > > Just fine? Did you see the bugs I mentioned in my initial mail? > > And how does it come that XBMC needs the '--enable-libav-compat' configure > option, which then uses code from lib/xbmc-libav-hacks, to build against > Libav? Being the xbmc maintainer I feel being addressed and let me share my POV regarding XBMC. :-) XBMC works with Libav for most use-cases
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, Alessio Treglia: > We've spent a lot of time over the past months talking to upstreams, > forwarding them our patches and make sure their programs and libraries > work with libav. > We've spent ***months*** in making the whole thing work, and dropping > libav in favour of FFmpeg at this point, roughly few weeks from the > freeze deadline, would be definitely insane. > Yes, that work might be "wasted". But I don't think that it's a good idea to base the decision of whether or not X is better for Debian on the fact that somebody did a lot of work for Y instead. Yes, the freeze is not that far away. But frankly, how much effort would it be to switch now? As far as I can tell from this discussion, the answer is "not a whole lot". The bulk of ffmpeg/libav's reverse dependencies is just a simple binNMU away, and as the libraries seem to be co-installable we don't even need a big transition. We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd hate to report some intractable codec bug which Upstream closes with an "it works with FFmpeg" comment -- what would you recommend me to do in that situation, next year -- install the ffmpeg libs from Experimental and rebuild the offender? -- -- Matthias Urlichs ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Reinhard, On 08.08.2014 14:29, Reinhard Tartler wrote: On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs wrote: I intended to come up with a more timely full response, but I just didn't get to it so far. Thanks for explaining your point of view here. For now, please refer to http://lwn.net/Articles/607662/, Have a look at: http://lwn.net/Articles/608040/ I was not there, when the FFmpeg/Libav split happened and I don't want to judge, whether it was a good thing or not. But it clearly caused a lot of bad blood between the developers involved, which in my opinion hurts the development of the multimedia framework in recent times. http://codecs.multimedia.cx/?p=370 (rather old, but still true), and If these features weren't used, they wouldn't have been developed. And many new features have been added to FFmpeg after that post. http://codecs.multimedia.cx/?p=674 (recent update on that matter) Let me quote from there: "But that’s not what kills the fun, “security holes” do. With an advance of automatic fuzz tools it’s easy to generate millions of damaged files that crash your decoder and yet there are no tools for generating correct patches. Fixing those crashes is tedious, requires a lot of thinking (should I disable it? will it affect decoding correct files? etc.) and in other words not fun at all." That seems as if he doesn't want to continue Libav development, because fixing security issues is tedious work. It has basically nothing to do with whether FFmpeg is of good quality security wise or not, or a good or bad competitor against Libav. Regarding Marco's argument that libav had few friends, well, let me point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 for instance. One person thinking that the code is 'beautiful' is no convincing argument. The number of people expressing their interest in having FFmpeg back in Debian is a lot more convincing. IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. I think that is totally out of question: Uploading FFmpeg to our archive will break the Debian archive so hard that it will take months to get everything back to testing, if it works at all. Let me repeat what I wrote in my initial mail in this thread: Having FFmpeg in the Debian archive breaks absolutely *nothing*, but it gives developers and users a choice between the two. Even if Libav were to be removed, a transition to FFmpeg could be rather smooth, as all the necessary patches already exist. But you're right that the time to test the resulting packages is getting rather short for the coming freeze. Still it can make sense for packages that are tested with FFmpeg upstream and have known issues with Libav. So if you and the other Libav maintainers were to support the idea of having both, the security and release teams could perhaps be convinced to allow that. This has been my goal from the beginning and I hoped that would be appreciated. To the best of my knowledge, there are only two high-profile projects that play hardball to require FFmpeg: Mplayer and mythtv. Neither of those do that (again to the best of my knowledge) mainly because of technical but rather very political reasons. The case of mplayer has been elaborated extensively in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the following "discussion" with Reimar - my conclusion from that is while technically possible, nobody wants to make mplayer work with Libav - and that's why it was removed, not because of the FFmpeg dependency). For Mythtv I can only say that they didn't even bother engaging any discussion. That FFmpeg has more features is a rather technical argument. Note that also many other projects are developed mainly with FFmpeg, they just happen to not break completely when compiled against Libav. For example, mpv prefers FFmpeg for good reasons: "Although mpv attempts to work well with both FFmpeg and Libav, FFmpeg is preferred in general. This is simply because FFmpeg merges from Libav, and seems to have more features and fewer bugs than Libav." [1] These features are actually requested by users, see e.g. [2]. (All) other high-profile downstream projects, including VLC or XBMC (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may Just fine? Did you see the bugs I mentioned in my initial mail? And how does it come that XBMC needs the '--enable-libav-compat' configure option, which then uses code from lib/xbmc-libav-hacks, to build against Libav? provide them with extra features, but why on earth would anyone want 3 different implementations of a ProRes encoder (seriously, and FFmpeg seems to claim to provide "security support" for each of them), or support for fringe codecs such as Wing Command 3 (yes, you can decode the videos from that video game). One of those ProRes encoders comes from Libav and is provided in FFmp
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 8 August 2014 13:29, Reinhard Tartler wrote: > On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs wrote: >> Hi, >> >> Andreas Cadhalpun: >>> Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It >>> has been removed from sid, since it fails to build against Libav, but it >>> builds fine against FFmpeg. >>> (It uses some of the features only provided by FFmpeg.) >>> >> Yet another reason why solely depending on libav is a bad idea. >> >> That leaves the question of the "official" opinion of the libav >> maintainers (pkg-multimedia-maintainers@lists.alioth.debian.org). >> Did none of them write anything in "defense" of libav, or have I simply >> missed it? > > I intended to come up with a more timely full response, but I just > didn't get to it so far. > > For now, please refer to http://lwn.net/Articles/607662/, > http://codecs.multimedia.cx/?p=370 (rather old, but still true), and > http://codecs.multimedia.cx/?p=674 (recent update on that matter) > > Regarding Marco's argument that libav had few friends, well, let me > point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 > for instance. > >> IMHO the best idea at this point would be to toss out libav, and rebuild >> the rdeps with ffmpeg. Now, before it's too late for jessie. > > I think that is totally out of question: Uploading FFmpeg to our > archive will break the Debian archive so hard that it will take months > to get everything back to testing, if it works at all. > > To the best of my knowledge, there are only two high-profile projects > that play hardball to require FFmpeg: Mplayer and mythtv. Neither of > those do that (again to the best of my knowledge) mainly because of > technical but rather very political reasons. The case of mplayer has > been elaborated extensively in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the > following "discussion" with Reimar - my conclusion from that is while > technically possible, nobody wants to make mplayer work with Libav - > and that's why it was removed, not because of the FFmpeg dependency). > For Mythtv I can only say that they didn't even bother engaging any > discussion. > So in ubuntu, at the time we were doing libav9 transition we also still had mplayer and pleora of packages inheritance from deb-multimedia or some such repositories. I was very reluctant to remove mplayer and all the reverse-deps, as I felt it is valuable to ship mplayer. I believe it was based on unreleased experimental packaging in git and other bits [1] Later Colin Watson also provided minimal port to make it build on arm64. Unfortunately libav10 transition got entangled in too many ways and we didn't manager to port mplayer to libav10. This was attempted based on top of mplayer trunk snapshot / last stable tarball, patches from gentoo and own porting efforts from myself and sil2100/robru but albeit unsuccessfully. Under pressing wait of too many things stuck in proposed migration (britney migration) we did remove mplayer and reverse dependencies and pointed / filed bugs to port to mplayer2 or just libav-tools where appropriate. I did ponder about compiling mplayer with an embedded copy of libav9 statically linked, but ultimately decided that it's unnecessary evil and majority of use-cases are served by the current libav stack. Either of ffmpeg and libav is a big security maintenance burden, simply from nature of inherently handling complex and large streams of untrusted data. So in trusty, I did work to unsplit the packages such that libav moved from main to universe, and can be synced from debian unmodified to minimize net-total maintenance burden as now updates and packaging can be fully shared. I see moving to mplayer2 as a net positive benefit for Debian. MythTV alone, whilst important package, I don't see as special enough to grant use of an embedded copy or forcing an uncertain cost of switching back to ffmpeg. If we need to port that project, then in Debian/Ubuntu/UbuntuStudio there are enough interested people to get it done. [1] https://launchpad.net/ubuntu/+source/mplayer/2:1.1+dfsg1-0ubuntu1 Regards, Dimitri. > (All) other high-profile downstream projects, including VLC or XBMC > (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may > provide them with extra features, but why on earth would anyone want 3 > different implementations of a ProRes encoder (seriously, and FFmpeg > seems to claim to provide "security support" for each of them), or > support for fringe codecs such as Wing Command 3 (yes, you can decode > the videos from that video game). > > There are a number of legitimate requested backports, such as for some > of FFmpeg's additional filters in libavfilter, and similar. All of > them are rather easy to backport, and this is done on a regular basis. > However, with the due diligence and attention such a widely used and > high-profile library requires. > > Which brings me to my next point: Release frequency. FFmpeg has an
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On Fri, Aug 8, 2014 at 12:13 PM, Matthias Urlichs wrote: > That leaves the question of the "official" opinion of the libav > maintainers (pkg-multimedia-maintainers@lists.alioth.debian.org). > Did none of them write anything in "defense" of libav, or have I simply > missed it? > > IMHO the best idea at this point would be to toss out libav, and rebuild > the rdeps with ffmpeg. Now, before it's too late for jessie. This is an eminently bad idea. As I said before, it's too late for Jessie already. Many Jessie's multimedia framework and packages have been developed and QA'd with libav. We've spent a lot of time over the past months talking to upstreams, forwarding them our patches and make sure their programs and libraries work with libav. We've spent ***months*** in making the whole thing work, and dropping libav in favour of FFmpeg at this point, roughly few weeks from the freeze deadline, would be definitely insane. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Quoting Reinhard Tartler (2014-08-08 14:29:59) > For now, please refer to http://lwn.net/Articles/607662/, > http://codecs.multimedia.cx/?p=370 (rather old, but still true), and > http://codecs.multimedia.cx/?p=674 (recent update on that matter) > > Regarding Marco's argument that libav had few friends, well, let me > point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 > for instance. > >> IMHO the best idea at this point would be to toss out libav, and rebuild >> the rdeps with ffmpeg. Now, before it's too late for jessie. > > I think that is totally out of question: Uploading FFmpeg to our > archive will break the Debian archive so hard that it will take months > to get everything back to testing, if it works at all. > > To the best of my knowledge, there are only two high-profile projects > that play hardball to require FFmpeg: Mplayer and mythtv. Neither of > those do that (again to the best of my knowledge) mainly because of > technical but rather very political reasons. [snip] > I now seriously wonder if the last 45 minutes in which I wrote this > email wouldn't have been better spent with preparing the next upload > for stable-security. YMMV. Thanks a lot for your input, Reinhard. Even if the loud ones in this thread may not, I doubt I am the only one finding value in your references and arguments. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs wrote: > Hi, > > Andreas Cadhalpun: >> Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It >> has been removed from sid, since it fails to build against Libav, but it >> builds fine against FFmpeg. >> (It uses some of the features only provided by FFmpeg.) >> > Yet another reason why solely depending on libav is a bad idea. > > That leaves the question of the "official" opinion of the libav > maintainers (pkg-multimedia-maintainers@lists.alioth.debian.org). > Did none of them write anything in "defense" of libav, or have I simply > missed it? I intended to come up with a more timely full response, but I just didn't get to it so far. For now, please refer to http://lwn.net/Articles/607662/, http://codecs.multimedia.cx/?p=370 (rather old, but still true), and http://codecs.multimedia.cx/?p=674 (recent update on that matter) Regarding Marco's argument that libav had few friends, well, let me point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 for instance. > IMHO the best idea at this point would be to toss out libav, and rebuild > the rdeps with ffmpeg. Now, before it's too late for jessie. I think that is totally out of question: Uploading FFmpeg to our archive will break the Debian archive so hard that it will take months to get everything back to testing, if it works at all. To the best of my knowledge, there are only two high-profile projects that play hardball to require FFmpeg: Mplayer and mythtv. Neither of those do that (again to the best of my knowledge) mainly because of technical but rather very political reasons. The case of mplayer has been elaborated extensively in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the following "discussion" with Reimar - my conclusion from that is while technically possible, nobody wants to make mplayer work with Libav - and that's why it was removed, not because of the FFmpeg dependency). For Mythtv I can only say that they didn't even bother engaging any discussion. (All) other high-profile downstream projects, including VLC or XBMC (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may provide them with extra features, but why on earth would anyone want 3 different implementations of a ProRes encoder (seriously, and FFmpeg seems to claim to provide "security support" for each of them), or support for fringe codecs such as Wing Command 3 (yes, you can decode the videos from that video game). There are a number of legitimate requested backports, such as for some of FFmpeg's additional filters in libavfilter, and similar. All of them are rather easy to backport, and this is done on a regular basis. However, with the due diligence and attention such a widely used and high-profile library requires. Which brings me to my next point: Release frequency. FFmpeg has an insane frequency of releases, and still seems to "support" (at least providing updates) to all of them, including 0.5 which is currently in oldstable (needless to say none of these patches made it to oldstable-security, why is still a mystery to me). The effect of that is that downstream projects have a hard time to choose what version of FFmpeg they want to support. This brings effectively back to the situation I was in when I took over maintenance of the package many years ago: Back then, Michael Niedermeyer strongly recommended all downstreams to avoid shared libraries and just link statically against libavcodec.a to avoid problems regarding "incompatible" library versions. I see exactly this problem arising again: Both mythtv and mplayer upstream (btw, xbmc as well) bundle some copy of ffmpeg in their sources and recommend everyone to just use the internal copy to avoid problems. Needless to say that this is not acceptable for use in Debian. Yes, I agree that this situation is a mess. A big mess. My fear is that switching to FFmpeg will bring us back to the mess we where 8 years ago, and I worked on for years. Libav is far from being perfect. That's true. I don't know why exactly FFmpeg seems to have more manpower, but it's not all black or white. For instance, there are a number of developers that actively contribute to both projects and are essential in keeping both projects in good health. Also I don't really buy the security argument. True, FFmpeg has more security updates, but backporting them to Libav turned out to be difficult because many if not most of them turn out to be either incomplete, invalid or require further clarification. Libav developers prefer to go the unpleasant road of fully understanding the issue, which takes extra time. For all these reasons, I do not see the necessity to do any drastic and dangerous steps right now. I now seriously wonder if the last 45 minutes in which I wrote this email wouldn't have been better spent with preparing the next upload for stable-security. YMMV. -- regards, Reinhard ___
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Aug 08, Matthias Urlichs wrote: > IMHO the best idea at this point would be to toss out libav, and rebuild > the rdeps with ffmpeg. Now, before it's too late for jessie. Agreed. The interested parties should really raise this with the CTTE ASAP. -- ciao, Marco signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, Andreas Cadhalpun: > Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It > has been removed from sid, since it fails to build against Libav, but it > builds fine against FFmpeg. > (It uses some of the features only provided by FFmpeg.) > Yet another reason why solely depending on libav is a bad idea. That leaves the question of the "official" opinion of the libav maintainers (pkg-multimedia-maintainers@lists.alioth.debian.org). Did none of them write anything in "defense" of libav, or have I simply missed it? IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. -- -- Matthias Urlichs ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
El 28/07/2014 08:53, "Henrique de Moraes Holschuh" escribió: > However: > > The change in Debian-specific symbol versioning and sonames being done to > ffmpeg so that it is co-installable with libav *is* a problem. > > It has to be done in coordination with the Canonical guys, so that both > Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol > versioning. Otherwise, the ffmpeg packages will be of very limited use > (useless to run third-party binary-only games ;-p). Not really, ffmpeg is packaged as a secondary multimedia library, the default one still being libav. If these packages get traction, we can think of moving ffmpeg to be the default (and ship if we wish libav with the soname change). The package will be of use for the ffmpeg command line tools, and for the maintainers that decide to make the switch. For now, your binary third party games will have to link against libav. > I understand perfectly that the soname and symbol versioning clash with > libav is not ffmpeg's fault, but that's water (well, sewage) under the > bridge. We have to deal with it. Here's an alternative proposal that > should be less painful [to our users] in the long run: > > You need one of the two upstreams to do a *large* major soname bump (at > least one order of magnitude higher than what they're currently using), so > that both projects can keep evolving with little chance of soname clashes. > > Symbol versioning will take care of the rest, since both libs carry over > their major soname into the symbol version. As it was done upstream, > cross-distro/third-party compatibility problems are not increased. > > Debian will have to package this new "bumped" upstream release, and get rid > of anything built against the old one. It will be easier for Debian if it > is ffmpeg upstream that does the soname bump, otherwise we're talking about > a huge number of binNMUs. That's been discussed and ruled out in favour of not overstepping libav's namespace. > But this is all academic if the security team is not prepared to deal with > both libav and ffmpeg at the same time. That effectively forces a choice of > either libav, or ffmpeg, and not both. That is premature, let's deal with this issue when we have more data. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28.07.2014 12:20, Thorsten Glaser wrote: Andreas Cadhalpun wrote: * Do you intend to replace Libav by FFmpeg in Debian? No, there is no need to replace anything as long as it is maintained. Currently the main goal is to give multimedia maintainers a choice between the two sets of libraries to link against, and our users the choice to use the 'ffmpeg' utility. That is possible, because the packages are co-installable. (Only the *-dev packages conflict.) Hm, I wonder if this will work, see the JPEG discussion. Well, it would work, if the security and release teams would agree with it. But I'd *love* to see ffmpeg replace libav and to get my mplayer back, which is currently on hold. Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It has been removed from sid, since it fails to build against Libav, but it builds fine against FFmpeg. (It uses some of the features only provided by FFmpeg.) Best regards, Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, 28 Jul 2014, Norbert Preining wrote: > On Sun, 27 Jul 2014, Reinhard Tartler wrote: > > In [1], Moritz from the security team clearly stated that he is more > > than uncomfortable with having more than one copy of libavcodec in > > debian/testing. In consequence this means that any package that builds > > against the ffmpeg packages currently in NEW won't make it into > > testing either. I am therefore surprised about the given answer to the > > "More than uncomfortable" does not mean "will not be included" Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). I understand perfectly that the soname and symbol versioning clash with libav is not ffmpeg's fault, but that's water (well, sewage) under the bridge. We have to deal with it. Here's an alternative proposal that should be less painful [to our users] in the long run: You need one of the two upstreams to do a *large* major soname bump (at least one order of magnitude higher than what they're currently using), so that both projects can keep evolving with little chance of soname clashes. Symbol versioning will take care of the rest, since both libs carry over their major soname into the symbol version. As it was done upstream, cross-distro/third-party compatibility problems are not increased. Debian will have to package this new "bumped" upstream release, and get rid of anything built against the old one. It will be easier for Debian if it is ffmpeg upstream that does the soname bump, otherwise we're talking about a huge number of binNMUs. But this is all academic if the security team is not prepared to deal with both libav and ffmpeg at the same time. That effectively forces a choice of either libav, or ffmpeg, and not both. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On Sun, 27 Jul 2014, Reinhard Tartler wrote: > In [1], Moritz from the security team clearly stated that he is more > than uncomfortable with having more than one copy of libavcodec in > debian/testing. In consequence this means that any package that builds > against the ffmpeg packages currently in NEW won't make it into > testing either. I am therefore surprised about the given answer to the "More than uncomfortable" does not mean "will not be included" > I think it would be best if ftp-master left the ffmpeg package in NEW > until an answer to this problem has been found. Why, only because libav gets a more powerful and efficient competition? > I am curious why this is your first email about this matter to > pkg-multimedia, and why do you write this email only now? > > Moreover, I am curious why I haven't seen you working on libavcodec > bugs in Debian before, and why do you believe you can do a better job > with the ffmpeg package currently on NEW? As Marco said, why should he fix bugs in av which have been fixed since ages in ffmeg in many (most?) cases? I am all for having a good ffmpeg set of cmd line progs and libs in Debian. It is too long that this sad and useless split was made. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Jul 28, Reinhard Tartler wrote: > Moreover, I am curious why I haven't seen you working on libavcodec > bugs in Debian before, and why do you believe you can do a better job > with the ffmpeg package currently on NEW? Why should he work on libavcodec when he (along with many other people) wants ffmpeg instead? -- ciao, Marco signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun wrote: > * Does it make sense for me to switch my package? >The rule of thumb is, if your upstream uses FFmpeg for development >you probably want to switch to using it, too. In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the question above. I think it would be best if ftp-master left the ffmpeg package in NEW until an answer to this problem has been found. [1] https://lists.debian.org/debian-devel/2014/02/msg00668.html > The FFmpeg version currently in NEW has been there for more than > 2 months and is thus outdated. If you want to test the current > packages, you can build them from the repository on Alioth [17] > (e.g. using git-buildpackage). > > Furthermore, we'd like to move the FFmpeg packaging under the umbrella > of the pkg-multimedia team, because this would facilitate future FFmpeg > transitions. I am curious why this is your first email about this matter to pkg-multimedia, and why do you write this email only now? Moreover, I am curious why I haven't seen you working on libavcodec bugs in Debian before, and why do you believe you can do a better job with the ffmpeg package currently on NEW? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg and libav
On Fri, Sep 27, 2013 at 7:25 AM, Romain Bouqueau wrote: > Hi Reinhard, > >>> My advise would be to focus on Libav, as FFmpeg closely tracks >>> "upstream", and claims to ensures API/ABI compatibility. Michael >>> Niedermayer offered repeatedly in the past to merge every development >>> of Libav into FFmpeg, so that should solve your struggle for good. >>> >>> Feel free to drop by in #libav-devel if you find some API that is hard >>> to use or otherwise difficult. There are many nice guys that are happy >>> listen to your concerns! >> >> >> Ok, we'll try that. Thanks for the feedback. > > > I took time to make tests with the latest libav this morning, both trunk and > release/9 branch. > > The trunk wouldn't compile. Probably some API changes for the next release, > that's ok. Have the parts already produced deprecation warnings for libav9? > > 'release/9' is known to compile with GPAC because you and Alessio made us a > bug report in January: > * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693159 > * https://sourceforge.net/p/gpac/bugs/265/ > I can confirm GPAC still builds with the Debian unstable libav source: > * > http://ftp.de.debian.org/debian/pool/main/liba/libav/libav_9.8.orig.tar.xz, > taken from http://packages.debian.org/source/unstable/libav > > The latest 'release/9' doesn't compile. So there seem to be an API breakage > in the release/9 branch of libav. That sounds serious, can you please file a bug with full details so that I can reproduce the problem (such as what source to compile, how did you configure libav, etc.)? > > I made the same tests with FFmpeg. Short story: every version builds. > > I'm not judging or comparing the quality of both alternatives. But I mention > that libav gives us much more headache in term of API. I'm sorry to hear that. If you provided more detail, we maybe could do something about it. Take care, -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg and libav
PS: just wrote on the libav-api mailing-list http://lists.libav.org/pipermail/libav-api/2013-September/000741.html Hi Reinhard, > > My advise would be to focus on Libav, as FFmpeg closely tracks >>> "upstream", and claims to ensures API/ABI compatibility. Michael >>> Niedermayer offered repeatedly in the past to merge every development >>> of Libav into FFmpeg, so that should solve your struggle for good. >>> >>> Feel free to drop by in #libav-devel if you find some API that is hard >>> to use or otherwise difficult. There are many nice guys that are happy >>> listen to your concerns! >>> >> >> Ok, we'll try that. Thanks for the feedback. >> > > I took time to make tests with the latest libav this morning, both trunk > and release/9 branch. > > The trunk wouldn't compile. Probably some API changes for the next > release, that's ok. > > 'release/9' is known to compile with GPAC because you and Alessio made us > a bug report in January: > * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693159 > * https://sourceforge.net/p/gpac/bugs/265/ > I can confirm GPAC still builds with the Debian unstable libav source: > * > http://ftp.de.debian.org/debian/pool/main/liba/libav/libav_9.8.orig.tar.xz, > taken from http://packages.debian.org/source/unstable/libav > > The latest 'release/9' doesn't compile. So there seem to be an API > breakage in the release/9 branch of libav. > > I made the same tests with FFmpeg. Short story: every version builds. > > I'm not judging or comparing the quality of both alternatives. But I > mention that libav gives us much more headache in term of API. > > Regards, > > Romain > > ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg and libav
Hi Reinhard, My advise would be to focus on Libav, as FFmpeg closely tracks >> "upstream", and claims to ensures API/ABI compatibility. Michael >> Niedermayer offered repeatedly in the past to merge every development >> of Libav into FFmpeg, so that should solve your struggle for good. >> >> Feel free to drop by in #libav-devel if you find some API that is hard >> to use or otherwise difficult. There are many nice guys that are happy >> listen to your concerns! >> > > Ok, we'll try that. Thanks for the feedback. > I took time to make tests with the latest libav this morning, both trunk and release/9 branch. The trunk wouldn't compile. Probably some API changes for the next release, that's ok. 'release/9' is known to compile with GPAC because you and Alessio made us a bug report in January: * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693159 * https://sourceforge.net/p/gpac/bugs/265/ I can confirm GPAC still builds with the Debian unstable libav source: * http://ftp.de.debian.org/debian/pool/main/liba/libav/libav_9.8.orig.tar.xz, taken from http://packages.debian.org/source/unstable/libav The latest 'release/9' doesn't compile. So there seem to be an API breakage in the release/9 branch of libav. I made the same tests with FFmpeg. Short story: every version builds. I'm not judging or comparing the quality of both alternatives. But I mention that libav gives us much more headache in term of API. Regards, Romain ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg and libav
[keeping Rogério cc; dropping Romain now warned on posting style] Quoting Rogério Theodoro de Brito (2013-09-26 17:49:13) > On Wed, Sep 25, 2013 at 10:33 AM, Jonas Smedegaard > wrote: >> Quoting Romain Bouqueau (2013-09-25 14:23:46) >>> We would need you to provide both FFmpeg and libav as separate >>> packages in Debian. However the libraries/headers in the packages >>> have the same names. AFAIU this makes our request impossible to >>> fulfill. >> >> Not impossible, but very difficult: Those actually doing the work in >> Debian consider it too much work for too little gain. > > I support having ffmpeg in Debian. If you mean "me too" then that doesn't help: Current package maintainers of libav believe that to be the best to use for Debian, and "voting" won't change that. Someone needs to step up and technically demonstrate the feasability of packaging and maintinaing ffmpeg, either done so that it does not clash with existing libav packages or (quite unlikely!) convince current libav package maintainers that it makes sense to abandon libav. >>> However FFmpeg works better: it is more stable, the maintainers are >>> more reactive, the APIs are more stable and consistent. >> >> Above seems subjective. It will help the discussion tremendously if >> is supported by some factual non-biased comparison. > > I have taken the time to look at the commits some months ago. ffmpeg > received support for video stabilization via libvidstab (which > transcode has embedded, but transcode has some very serious > limitations), which libav didn't, ffmpeg had support for OpenCL, which > libav didn't, essentially, and ffmpeg had *many* features more, which > I needed, but which libav lacked. > > Also, essentially all (perhaps even all?) commits from libav were > imported into ffmpeg, but the converse is not true (see my coments > above). IMO above is not an unbiased comparison. But I am not interested in discussing this, just tried point out what might help support a fruitful discussion. What could help, I believe - is to include both sides of the fence, and to compare not only amount of features and commits, but also the quality of the included features. > Also, the upstream ffmpeg developers are highly annoyed with the > message that Debian's and Ubuntu's ffmpeg program emits: > > | *** THIS PROGRAM IS DEPRECATED *** > | This program is only provided for compatibility and will be removed > in a future release. Please use avconv instead. > > I understand their position and the wording is harming to their > project: the ffmpeg program that Debian *packages* may be deprecated, > but the context that this is a Debian decision is not clear and many > users understand, essentially, in absolute terms that ffmpeg is > something that they should not use (even if ffmpeg's upstream is > active). That message will soon be gone, together with the ffmpeg transitional package. >>> Note that it was not an issue until the last year because they were >>> still fairly compatible. The Debian package maintainers also seem to >>> have kept this issue away by installing old libav versions. >> >> Above seems misguided. If you compare "released code" then beware >> that what Debian calls "stable" others might call "too boring", and >> what others call "stable Debian might call "testing" or "unstable". > > Even unstable has a libav that is behind ffmpeg in terms of > functionality that the users (read: "me") may need. Above does not compare the two upstreams, but libav packaging and libav upstream! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg and libav
Hi there. On Wed, Sep 25, 2013 at 10:33 AM, Jonas Smedegaard wrote: > (please mention if you are not subscribed to the list and need copy of > replies - normal for Debian lists is to post only to list) While I am subscribed to the list, I would appreciate it if I received a copy at rbrito at ime.usp.br. > Quoting Romain Bouqueau (2013-09-25 14:23:46) >> We would need you to provide both FFmpeg and libav as separate >> packages in Debian. However the libraries/headers in the packages have >> the same names. AFAIU this makes our request impossible to fulfill. > > Not impossible, but very difficult: Those actually doing the work in > Debian consider it too much work for too little gain. I support having ffmpeg in Debian. We have packages use it (e.g., XBMC). Also, chromium embeds a copy of ffmpeg, which is not good. >> However FFmpeg works better: it is more stable, the maintainers are >> more reactive, the APIs are more stable and consistent. > > Above seems subjective. It will help the discussion tremendously if is > supported by some factual non-biased comparison. I have taken the time to look at the commits some months ago. ffmpeg received support for video stabilization via libvidstab (which transcode has embedded, but transcode has some very serious limitations), which libav didn't, ffmpeg had support for OpenCL, which libav didn't, essentially, and ffmpeg had *many* features more, which I needed, but which libav lacked. Also, essentially all (perhaps even all?) commits from libav were imported into ffmpeg, but the converse is not true (see my coments above). Also, the upstream ffmpeg developers are highly annoyed with the message that Debian's and Ubuntu's ffmpeg program emits: | *** THIS PROGRAM IS DEPRECATED *** | This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. I understand their position and the wording is harming to their project: the ffmpeg program that Debian *packages* may be deprecated, but the context that this is a Debian decision is not clear and many users understand, essentially, in absolute terms that ffmpeg is something that they should not use (even if ffmpeg's upstream is active). I sincerely think that this message should be reworded. (N.B.: I am not affiliated with anybody, I just heard what an ffmpeg developer had to say and I totally understand their position). >> This fork causes duplicated work (VLC, MPlayer, GStreamer, GPAC). I >> think it would be a good idea not to involve project contributors in >> this ego war and let them choose whichever is best for their projects. > > Above is judgemental. Please avoid that to keep discussion productive. Gee, I had some pain, initially, to "port" handbrake to Debian's libav. I only persisted because I really wanted to have handbrake use my preferred distribution with as little duplication as possible and, then, share what I had (and have other people improve what I had at the point). >> Note that it was not an issue until the last year because they were >> still fairly compatible. The Debian package maintainers also seem to >> have kept this issue away by installing old libav versions. > > Above seems misguided. If you compare "released code" then beware that > what Debian calls "stable" others might call "too boring", and what > others call "stable Debian might call "testing" or "unstable". Even unstable has a libav that is behind ffmpeg in terms of functionality that the users (read: "me") may need. Regards, Rogério Brito. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg and libav
> > My advise would be to focus on Libav, as FFmpeg closely tracks > "upstream", and claims to ensures API/ABI compatibility. Michael > Niedermayer offered repeatedly in the past to merge every development > of Libav into FFmpeg, so that should solve your struggle for good. > > Feel free to drop by in #libav-devel if you find some API that is hard > to use or otherwise difficult. There are many nice guys that are happy > listen to your concerns! > Ok, we'll try that. Thanks for the feedback. Romain ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg and libav
On Wed, Sep 25, 2013 at 2:23 PM, Romain Bouqueau wrote: > Dear Debian maintainers, > > I'm a contributor on the GPAC multimedia project. I'm writing to you because > we spend more and more time trying to keep our project compatible with both > FFmpeg and libav. This is not sustainable. > > We would need you to provide both FFmpeg and libav as separate packages in > Debian. However the libraries/headers in the packages have the same names. > AFAIU this makes our request impossible to fulfill. > > What I see is: most of the work seems to be done at the libav side. However > FFmpeg works better: it is more stable, the maintainers are more reactive, > the APIs are more stable and consistent. > > This fork causes duplicated work (VLC, MPlayer, GStreamer, GPAC). I think it > would be a good idea not to involve project contributors in this ego war and > let them choose whichever is best for their projects. > > Note that it was not an issue until the last year because they were still > fairly compatible. The Debian package maintainers also seem to have kept > this issue away by installing old libav versions. As projects evolve, we > need new features from FFmpeg/libav. Thus keeping an old libav is not > sustainable either. > > Does anyone has an idea to improve the situation? Sorry for the terse answer, but I'm currently in the middle of relocating from Europe to the US. My advise would be to focus on Libav, as FFmpeg closely tracks "upstream", and claims to ensures API/ABI compatibility. Michael Niedermayer offered repeatedly in the past to merge every development of Libav into FFmpeg, so that should solve your struggle for good. Feel free to drop by in #libav-devel if you find some API that is hard to use or otherwise difficult. There are many nice guys that are happy listen to your concerns! Best, Reinhard -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg and libav
Hi Romain, (please mention if you are not subscribed to the list and need copy of replies - normal for Debian lists is to post only to list) Quoting Romain Bouqueau (2013-09-25 14:23:46) > I'm a contributor on the GPAC multimedia project. I'm writing to you > because we spend more and more time trying to keep our project > compatible with both FFmpeg and libav. This is not sustainable. I understand your pain. > We would need you to provide both FFmpeg and libav as separate > packages in Debian. However the libraries/headers in the packages have > the same names. AFAIU this makes our request impossible to fulfill. Not impossible, but very difficult: Those actually doing the work in Debian consider it too much work for too little gain. > What I see is: most of the work seems to be done at the libav side. > However FFmpeg works better: it is more stable, the maintainers are > more reactive, the APIs are more stable and consistent. Above seems subjective. It will help the discussion tremendously if is supported by some factual non-biased comparison. > This fork causes duplicated work (VLC, MPlayer, GStreamer, GPAC). I > think it would be a good idea not to involve project contributors in > this ego war and let them choose whichever is best for their projects. Above is judgemental. Please avoid that to keep discussion productive. > Note that it was not an issue until the last year because they were > still fairly compatible. The Debian package maintainers also seem to > have kept this issue away by installing old libav versions. Above seems misguided. If you compare "released code" then beware that what Debian calls "stable" others might call "too boring", and what others call "stable Debian might call "testing" or "unstable". Here is an overview of both how long-term and how bleeding edge Debian is regarding libav: http://packages.qa.debian.org/liba/libav.html > Does anyone has an idea to improve the situation? We need to first agree that there is a situation that needs improving. As my comments above indicate, I think your input - though no doubt good intended - does not help establish such agreement. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Processed (with 1 errors): Re: ffmpeg is many years outdated
Processing commands for cont...@bugs.debian.org: > block 716735 by 706798 Bug #716735 [ffmpeg] ffmpeg is many years outdated 716735 was not blocked by any bugs. 716735 was not blocking any bugs. Added blocking bug(s) of 716735: 706798 > thanks Stopping processing here. Please contact me if you need assistance. -- 716735: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716735 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg package in Debian/Ubuntu
Fabian Greffrath greffrath.com> writes: > I am just a contributor to the *Debian packaging* of the software and > do not care that much if the libraries originate from the ffmpeg or the > libav project. Sorry to have wasted your time! Please allow me a little sarcasm: I am just an OpenSuse user and do not care that much if Debian cares about regressions etc. or not. ;-) Thank you, Carl Eugen ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg package in Debian/Ubuntu
Hi, Am 13.10.2011 23:17, schrieb Carl Eugen Hoyos: Is this purely what you expect from Michael, or did you find anything in his mail that made you believe it was written in a biased way? (I ask because I was impressed how unbiased he wrote the message - I wouldn't have been able to after what has happened.) you are right, his mail was written in a remarkably neutral tone. However, I have been told that the reasons for the fork were mostly personal ones and especially dissatisfaction with his project leadership. So, yes, I guessed about his sentiment for the fork. ;) (I am assuming you did not mean "work".) s/work/fork/ This is of course true - the reason for the failed takeover and subsequent fork was a personal vendetta against the main contributor and maintainer of FFmpeg - but the presented reasons were predominantly technical ones. And while for me, the non-technical reasons are much more important than security issues, bug fixes and features, I would have expected that here technical reasons would outweigh the non-technical ones. Well, at this point the discussion reaches far beyond my level of involvement in both projects. I am just a contributor to the *Debian packaging* of the software and do not care that much if the libraries originate from the ffmpeg or the libav project. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg package in Debian/Ubuntu
Hi! Fabian Greffrath greffrath.com> writes: > thanks for presenting your - doubtless biased, but however - point of > view. Is this purely what you expect from Michael, or did you find anything in his mail that made you believe it was written in a biased way? (I ask because I was impressed how unbiased he wrote the message - I wouldn't have been able to after what has happened.) > Am 11.10.2011 02:24, schrieb Michael Niedermayer: > > In terms of features: > > As far as I know, as an outsider, the reasons for the work were not (I am assuming you did not mean "work".) > technical ones. This is of course true - the reason for the failed takeover and subsequent fork was a personal vendetta against the main contributor and maintainer of FFmpeg - but the presented reasons were predominantly technical ones. And while for me, the non-technical reasons are much more important than security issues, bug fixes and features, I would have expected that here technical reasons would outweigh the non-technical ones. > Has the situation relaxed a bit in this regard? I am not sure how this can be answered - so far, I have not seen a single public apology from the "new team". Carl Eugen FFmpeg developer ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg package in Debian/Ubuntu
Dear Michael, thanks for presenting your - doubtless biased, but however - point of view. Am 11.10.2011 02:24, schrieb Michael Niedermayer: In terms of features: As far as I know, as an outsider, the reasons for the work were not technical ones. Has the situation relaxed a bit in this regard? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg package in Debian/Ubuntu
Hi Fabian, Dominik, Debian developers On Wed, Oct 05, 2011 at 11:43:19AM +0200, Fabian Greffrath wrote: > Dear Dominik, > > Am 23.09.2011 18:03, schrieb Dominik 'Rathann' Mierzejewski: > >Dear All, > >I'm sending this (Bcc) to Debian/Ubuntu package maintainers who are listed > >under "Original Maintainers" on http://packages.ubuntu.com/oneiric/ffmpeg > >and who seem to be doing something at least a bit related still. > > You seem to have missed Debian multimedia packages maintainers > . Shifting this > mail there as I am not going to discuss this with you in private. Thank you for moving this to a public mailing list. Dominik has pointed me to this mail, and i think its something i should as main author of ffmpeg/libav, reply to. libav forked off ffmpeg in the begin of this year. Since then libav has fallen behind ffmpeg very significantly. Also due to the unfortunate choice of the name of the fork, i should probably clarify that the ffmpeg libraries libavcodec, libavformat, libavfilter and so on are developed and maintained within the ffmpeg project. Their maintainers, reviewers and authors are still predominantly in the ffmpeg project, in some cases like libavfilter and libpostproc all authors are to 100% on the ffmpeg side of the fork. In terms of features: ffmpeg has 17 additional decoders, 11 encoders, 11 demuxers, 5 muxers, 19 native av filter and 51 non native filters that libav does not have. You only have to diff the libav*/all*.c files between ffmpeg and libav git to see this. There is no single feature in libav that ffmpeg does not have. All improvments and bugfixes from libav are always merged into ffmpeg. But changes from ffmpeg are only sometimes merged into libav, this includes some security relevant changes. In terms of bugs: Both projects in the past used roundup to track bugs. With the fork we were forced to switch to a new server&hosting and with that also choose to use trak as tracker while libav, for reasons unknown to me switched to bugzilla. Due to this, its very easy to compare the bug fixing activity as both projects started with fresh trackers. ffmpeg has 280 fixed bugs, see: https://ffmpeg.org/trac/ffmpeg/query?resolution=fixed libav has 17 fixed bugs see: http://bugzilla.libav.org/buglist.cgi?query_format=advanced&resolution=FIXED Given above, and especially the security issues, i would strongly suggest debian to reconsider the decission to package just libav. The ffmpeg team as well as I are of course happy to help with maintaining debian packages if such help is needed or wanted! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg package in Debian/Ubuntu
Dear Dominik, Am 23.09.2011 18:03, schrieb Dominik 'Rathann' Mierzejewski: Dear All, I'm sending this (Bcc) to Debian/Ubuntu package maintainers who are listed under "Original Maintainers" on http://packages.ubuntu.com/oneiric/ffmpeg and who seem to be doing something at least a bit related still. You seem to have missed Debian multimedia packages maintainers . Shifting this mail there as I am not going to discuss this with you in private. Cheers, Fabian Since the unfortunate fork of FFmpeg into Libav, the maintaner of FFmpeg package decided to follow the fork and migrated the FFmpeg package to Libav in both Debian and Ubuntu. That's not surprising, considering he was one of those who did the forking. However, this leaves Debian and Ubuntu without the FFmpeg package, while the project is still alive and well. I'm told that at least Ubuntu (and I think Debian, too) is willing to ship an FFmpeg package and handle the inevitable library name clashes with the Libav fork as long as there is a willing maintainer. Would any of you consider stepping in and filling that role? I think it's a loss for both distributions not to have FFmpeg anymore, even if for no other reason than having healthy competition. I'm writing this as the maintainer of FFmpeg packages for Fedora who decided to stay with the original project and is a bit disappointed to see Debian/Ubuntu simply drop FFmpeg. Best regards, Dominik ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg and libfaac
On Wed, Jul 20, 2011 at 14:36:30 (CEST), guanting wrote: > hi, debian maintainer > > excuse, > > I need faac encoder for my computer. > > how do i install libfaac in ffmpeg package (4:0.5.2-6, squeeze version) ? :( recompile your libav/ffmpeg package with faac installed. The packaging will enable the libfaac wrapper iff /usr/include/faac.h is present. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg
On 11-04-04 at 02:33am, Ivo wrote: > I just noticed that debian sid switched the ffmpeg package (and > related packages) to a fork that just appeared on the scene. A bunch > of guys tried to takeover the official ffmpeg site and repo and when > that didn't work (they were forced out by the official trademark > holder and founder of the ffmpeg project), they forked. I wish them > all the best, but I expect a distro that is known for its stability to > stick with the original, unless over time the fork turns out to be the > "winner". Thanks for your different view on this. Legal disputes over control of domain or project name is, however, an internal matter, not relevant for Debian (as long as _Debian_ is not violating trademarks etc.). > Just because one of the guys that tried to takeover ffmpeg.org and > related services by illegal means is one of the ffmpeg package > maintainers of both debian and ubuntu, should not be a reason to > switch. A lot of other packages depend on ffmpeg and its libraries and > unless a majority of them (i.e. the authors of said software) switch > to the libav fork, debian should IMO stick with the stable ffmpeg > project. Ah, so you are aware that this has been discussed already. So I assume you also know the technical judgement of those "hijackers", just disagree with it. I support (with current information provided) the judgement of my fellow Debian developer closely involved in the upstream code and making that judgement, yet appreciate your additional input. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-4:0.6.1-5 and jack support
Am 21.03.2011 11:00, schrieb Reinhard Tartler: TBH no idea, I would need to look into that more closely as well. I guess it's just a matter of adding the build dep and passing the right line to configure. I have added libjack-dev to Build-Depends and now ./configure shows "jack" among the Enabled indevs. The jack package's libjack0.shlibs file adds dependencies to either the libjack-jackd2-0 and the libjack-0.116 libraries with precedence on the former. So everything seems alright. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-4:0.6.1-5 and jack support
On Mon, Mar 21, 2011 at 10:12:53 (CET), Fabian Greffrath wrote: > Am 21.03.2011 09:58, schrieb Reinhard Tartler: >> Sure, feel free to go ahead (I forgot it for the last upload already) > > Alright, what's the curent best practice for building with JACK support? > Adding libjack-dev to BD and be done with it or do we need > special-casing for JACK2? TBH no idea, I would need to look into that more closely as well. I guess it's just a matter of adding the build dep and passing the right line to configure. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-4:0.6.1-5 and jack support
Am 21.03.2011 09:58, schrieb Reinhard Tartler: Sure, feel free to go ahead (I forgot it for the last upload already) Alright, what's the curent best practice for building with JACK support? Adding libjack-dev to BD and be done with it or do we need special-casing for JACK2? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-4:0.6.1-5 and jack support
On Mon, Mar 21, 2011 at 09:37:04 (CET), Fabian Greffrath wrote: > Am 18.03.2011 14:59, schrieb Reinhard Tartler: >> please file a wishlist report against libavdevice52. > > Let's just enable it in git, or not? Sure, feel free to go ahead (I forgot it for the last upload already) -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-4:0.6.1-5 and jack support
Am 18.03.2011 14:59, schrieb Reinhard Tartler: please file a wishlist report against libavdevice52. Let's just enable it in git, or not? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-4:0.6.1-5 and jack support
On Fri, Mar 18, 2011 at 13:47:16 (CET), Dragan Noveski wrote: > i am an aptosid user and using the ffmpeg-4:0.6.1-5 on my system. > if i am looking right, this version is compiled w/out jack support. > is there any special reason, or has the jack support just been forgotten > while preparing the package? > if there is any chance to include jack support in ffmpeg i would be more > than happy. please file a wishlist report against libavdevice52. I think there is no problem with that, just that nobody was able to test avdevice's jack output support. > anyway, thanks for your work and maintaining all this complicated stuff! Thanks! :-) -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg 0.6 transition
On Thu, 2011-02-17 at 21:12 +, Adam D. Barratt wrote: > [debian-devel dropped from Cc as it didn't seem relevant to the mail] > > On Tue, 2011-02-15 at 12:06 +0100, Reinhard Tartler wrote: > > It is here: http://release.debian.org/transitions/ffmpeg.html > > > > AFAIUI all packages marked red in the list above need to be rebuilt > > (i.e., binNMUed). > > I've scheduled an initial set of packages on most architectures (not > alpha, hppa or mips due to the size of their queues); let's see how that > goes. > > For reference, I've explicitly /not/ scheduled cherokee (#612482) or > libavg (#580678). So, a status update. We've now scheduled binNMUs for all the reverse dependencies other than those with pre-existing FTBFS issues; ignoring packages where we're just waiting for mips, the current issues are: * amide - FTBFS (no-add-needed, #614725) [ * blender, dvswitch - waiting for cmake ] * cherokee - RC-buggy and FTBFS (#612482); looking like a removal candidate * elmerfem - FTBFS (no-add-needed, #614952) * ffmpeg2theora - FTBFS (no-add-needed, #614996) * freej - FTBFS (#614458) * gdcm - FTBFS (no-add-needed, #614953) * kino - FTBFS (no-add-needed, #614954) * ktoon - FTBFS (#614446) [ * libavg - FTBFS (#580678); not in testing ] * libvalhalla - FTBFS due to build-dependency issues (#614989) * mediatomb - FTBFS (no-add-needed, #614956) * openmovieeditor - FTBFS (no-add-needed, #614957) * openscenegraph - FTBFS (#614467) * qutecom - not getting built on armel due to a dependency chain that ends up in the rasqal ickiness * smilutils - FTBFS (no-add-needed, #614958) * xine-lib - FTBFS due to X changes (#610635) Regards, Adam ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg 0.6 transition
On Thu, 2011-02-17 at 22:21 +0100, Benjamin Drung wrote: > Am Donnerstag, den 17.02.2011, 21:12 + schrieb Adam D. Barratt: > > I've scheduled an initial set of packages on most architectures (not > > alpha, hppa or mips due to the size of their queues); let's see how that > > goes. [...] > You don't need to binNMU audacity, because I just uploaded 1.3.12-11. Thanks for letting us know. Sadly I started at the top of the alphabetically sorted list; the audacity binNMUs have already built on three architectures. Regards, Adam ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg 0.6 transition
Am Donnerstag, den 17.02.2011, 21:12 + schrieb Adam D. Barratt: > [debian-devel dropped from Cc as it didn't seem relevant to the mail] > > On Tue, 2011-02-15 at 12:06 +0100, Reinhard Tartler wrote: > > On Di, Feb 15, 2011 at 09:31:33 (CET), Reinhard Tartler wrote: > > > > > BTW, where has mehdi's excellent transition tracker gone? > > > > It is here: http://release.debian.org/transitions/ffmpeg.html > > > > AFAIUI all packages marked red in the list above need to be rebuilt > > (i.e., binNMUed). > > I've scheduled an initial set of packages on most architectures (not > alpha, hppa or mips due to the size of their queues); let's see how that > goes. > > For reference, I've explicitly /not/ scheduled cherokee (#612482) or > libavg (#580678). You don't need to binNMU audacity, because I just uploaded 1.3.12-11. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg 0.6 transition
[debian-devel dropped from Cc as it didn't seem relevant to the mail] On Tue, 2011-02-15 at 12:06 +0100, Reinhard Tartler wrote: > On Di, Feb 15, 2011 at 09:31:33 (CET), Reinhard Tartler wrote: > > > BTW, where has mehdi's excellent transition tracker gone? > > It is here: http://release.debian.org/transitions/ffmpeg.html > > AFAIUI all packages marked red in the list above need to be rebuilt > (i.e., binNMUed). I've scheduled an initial set of packages on most architectures (not alpha, hppa or mips due to the size of their queues); let's see how that goes. For reference, I've explicitly /not/ scheduled cherokee (#612482) or libavg (#580678). Regards, Adam ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg 0.6 transition
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.release as well. On Di, Feb 15, 2011 at 09:31:33 (CET), Reinhard Tartler wrote: > BTW, where has mehdi's excellent transition tracker gone? It is here: http://release.debian.org/transitions/ffmpeg.html AFAIUI all packages marked red in the list above need to be rebuilt (i.e., binNMUed). -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg 0.6 transition
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.release,gmane.linux.debian.alioth.multimedia-maintainers as well. On So, Feb 06, 2011 at 14:29:33 (CET), Reinhard Tartler wrote: > FYI: I just accepted mehdis offer from debconf 10 to upload ffmpeg just > after the squeeze release. I've got a lot of pings and flames that this > wasn't included in squeeze, we discussed this to death in NYC, and > therefore just went ahead. Okay, FFmpeg 0.6 has now built on all architectures and is AFAIUI by itself ready for wheezy. For successful migration, I'd suggest to binNMU the following packages, which is a list of source packages, which produce a binary package that depends on libavutil49 (superseeded by libavutil50): amide aqualung audacious-plugins audacity avbin blender cherokee dvswitch electricsheep elmerfem ffmpeg ffmpeg2theora ffprobe forked-daapd freej gdcm gnash imageshack-uploader k3b kino ktoon kwwidgets libavg libphash libvalhalla lynkeos.app mediatomb mlt moon motion mpd mrpt netgen opencv openmovieeditor openscenegraph paraview performous qmmp qutecom smilutils taoframework unicap vtk vtkedge xine-lib xine-lib-1.2 (experimental only) zoneminder BTW, where has mehdi's excellent transition tracker gone? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: FFmpeg 0.6 transition
Am Sonntag, den 06.02.2011, 14:29 +0100 schrieb Reinhard Tartler: > FYI: I just accepted mehdis offer from debconf 10 to upload ffmpeg just > after the squeeze release. I've got a lot of pings and flames that this > wasn't included in squeeze, we discussed this to death in NYC, and > therefore just went ahead. > > The following source packages are affected by this upload: > [...] You forgot audacity in this list. I will do an upload containing other changes too. > Most of them should be dealt with a binNMU, but for some (mplayer, vlc, > etc.) new upstream releases are already in the pipe. I'd suggest to wait > a few days before firing binNMUs. I would like to upload vlc from experimental to unstable, but this depends on iceweasel 3.6, which is in experimental. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Ffmpeg : experimental to unstable
On Thu, Aug 05, 2010 at 09:39:26 (EDT), Eric Dantan Rzewnicki wrote: > On Thu, Aug 05, 2010 at 03:12:30PM +0200, Brent Clark wrote: >> On 05/08/2010 14:58, Reinhard Tartler wrote: >>> I've talked to the release managers on tuesday about this, and we more >>> or less agreed that it's too late for squeeze. >>> >>> I've tried, but it's no longer in my hands. >>> >> >> Thanks for replying and trying. > > For what it's worth, DebConf10 videoteam is using the experimental > ffmpeg packages backported to a squeeze snapshot. dvswitch and > ffmpeg2theora both use ffmpeg libraries. Everything is working well. So, > it might be feasible to provide backports more broadly. > > Far from ideal, but, at least it's an option. for a limited set of packages, that's indeed an option. However, we *will* break other packages with that, that's why I don't think backports.org would be a solution for that, unless we do the full transition. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Ffmpeg : experimental to unstable
On Thu, Aug 05, 2010 at 03:12:30PM +0200, Brent Clark wrote: > On 05/08/2010 14:58, Reinhard Tartler wrote: >> I've talked to the release managers on tuesday about this, and we more >> or less agreed that it's too late for squeeze. >> >> I've tried, but it's no longer in my hands. >> > > Thanks for replying and trying. For what it's worth, DebConf10 videoteam is using the experimental ffmpeg packages backported to a squeeze snapshot. dvswitch and ffmpeg2theora both use ffmpeg libraries. Everything is working well. So, it might be feasible to provide backports more broadly. Far from ideal, but, at least it's an option. -edrz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Ffmpeg : experimental to unstable
On 05/08/2010 14:58, Reinhard Tartler wrote: I've talked to the release managers on tuesday about this, and we more or less agreed that it's too late for squeeze. I've tried, but it's no longer in my hands. Thanks for replying and trying. Kind Regards Brent Clark ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Ffmpeg : experimental to unstable
On Thu, Aug 05, 2010 at 05:59:10 (EDT), Brent Clark wrote: > To whom it may concern > > Any chance of moving ffmpeg from experimental to unstable. I've talked to the release managers on tuesday about this, and we more or less agreed that it's too late for squeeze. I've tried, but it's no longer in my hands. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg 0.5.2
Am 01.06.2010 15:22, schrieb Reinhard Tartler: so nothing too important, IMO the package should be updated, we can drop some local patches by doing so. done. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg 0.5.2
On Di, Jun 01, 2010 at 15:09:09 (CEST), Fabian Greffrath wrote: > A few days ago ffmpeg released 0.5.2. Does it make sense to switch to > this version or is it just the same as 0.5.1 with two of our patches > merged? The changelog didn't read exhaustive... yes, yes and yes. so nothing too important, IMO the package should be updated, we can drop some local patches by doing so. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg 4:0.5+svn20090706-5 MIGRATED to testing
On Do, Jan 28, 2010 at 17:39:26 (CET), Debian testing watch wrote: > FYI: The status of the ffmpeg source package > in Debian's testing distribution has changed. > > Previous version: 4:0.5+svn20090706-2 > Current version: 4:0.5+svn20090706-5 Finally, yay. Andres, you offered to keep ffmpeg updated in experimental. Do you have the time to review my patches and try out the instructions in debian/README.upstream-upgrade? If it works out, let's upload to experimental! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
On Do, Jan 28, 2010 at 10:41:10 (CET), Fabian Greffrath wrote: > Am 26.01.2010 18:19, schrieb Reinhard Tartler: >>> For people from the outside, who have a look at the package, however it >>> will look somehow insane. I think a short comment (just the sentence I >>> quoted from your previous mail above) would be enough to convince >>> everyone, I guess. >> please implement this comment in the master branch, I'm heading home now! > > done. excellent, diff looks great! >> Fabian, if you want feel free to locate this patch in git.ffmpeg.org, >> download it as raw text and add it to our quilt patches queue in the >> master branch. > > It didn't apply cleanly against our master branch, e.g. there is no > libavformat/id3v1.c file, but I applied it anyway as suited just after > our 900_doxyfile patch. > > For the master.snapshot branch, I don't think it makes sense to apply it > there, because it will be obsoleted by the next snapshot anyway. indeed. I think that in general if we spot some problem in that branch, let's not fix it in the package but get it fixed upstream and 'just' update the package. The package is not suitable for squeeze anyways. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
Am 26.01.2010 18:19, schrieb Reinhard Tartler: For people from the outside, who have a look at the package, however it will look somehow insane. I think a short comment (just the sentence I quoted from your previous mail above) would be enough to convince everyone, I guess. please implement this comment in the master branch, I'm heading home now! done. Fabian, if you want feel free to locate this patch in git.ffmpeg.org, download it as raw text and add it to our quilt patches queue in the master branch. It didn't apply cleanly against our master branch, e.g. there is no libavformat/id3v1.c file, but I applied it anyway as suited just after our 900_doxyfile patch. For the master.snapshot branch, I don't think it makes sense to apply it there, because it will be obsoleted by the next snapshot anyway. - Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
On Di, Jan 26, 2010 at 16:28:00 (CET), Fabian Greffrath wrote: >> This could be a lintian bug, the whole situation maybe needs some more >> thought: we generate the shlibs file twice: first time for the internal >> dependencies, and then we regenerate them for inclusion in the >> package. The point of this excercice is to have the 'internal' >> dependencies more strict than 'external' ones. We have implemented this >> so that we make mixing ffmpeg libraries with the ones from marillat >> harder. > > Thanks, yes, I know the details. I have been "around" when this has been > implemented. ;) > > I was wondering, because lintian once throw an error because of this > hack. We have overridden it, because we called the commands in an odd > order for good reason. Apparently this check has been removed from > lintian or maybe lintian even likes the idea or whatever. ;) ok >> Perhaps this should be documented in some comment, but the rules file is >> already pretty convoluted as it is now. > > For people from the outside, who have a look at the package, however it > will look somehow insane. I think a short comment (just the sentence I > quoted from your previous mail above) would be enough to convince > everyone, I guess. please implement this comment in the master branch, I'm heading home now! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
Am 26.01.2010 16:16, schrieb Reinhard Tartler: This patch applies perfectly to upstream trunk/. Do you want to submit it yourself? If not, I'll forward it. I am not subscribed at upstream's lists and are thus rather unknown there. Would you please...? ;) -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
Am 26.01.2010 15:46, schrieb Reinhard Tartler: would be great, but symbol files do not allow the same flexibilty as a regular shlib file: We cannot implement alternative dependencies that are required for the ffmpeg-extra with symbol files. Ah yes, I forgot. Which ones? can you compile a list? Has been attached to my last reply. This could be a lintian bug, the whole situation maybe needs some more thought: we generate the shlibs file twice: first time for the internal dependencies, and then we regenerate them for inclusion in the package. The point of this excercice is to have the 'internal' dependencies more strict than 'external' ones. We have implemented this so that we make mixing ffmpeg libraries with the ones from marillat harder. Thanks, yes, I know the details. I have been "around" when this has been implemented. ;) I was wondering, because lintian once throw an error because of this hack. We have overridden it, because we called the commands in an odd order for good reason. Apparently this check has been removed from lintian or maybe lintian even likes the idea or whatever. ;) Perhaps this should be documented in some comment, but the rules file is already pretty convoluted as it is now. For people from the outside, who have a look at the package, however it will look somehow insane. I think a short comment (just the sentence I quoted from your previous mail above) would be enough to convince everyone, I guess. -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
On Di, Jan 26, 2010 at 15:31:14 (CET), Fabian Greffrath wrote: > Am 26.01.2010 15:23, schrieb Fabian Greffrath: >> - The libraries contain some typos, should we fix them? > > I tried to leave the interface untouched. This patch applies perfectly to upstream trunk/. Do you want to submit it yourself? If not, I'll forward it. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
On Di, Jan 26, 2010 at 15:23:32 (CET), Fabian Greffrath wrote: > Am 26.01.2010 13:50, schrieb Reinhard Tartler: >> This would mean that we would need to redistribute the libavcodec >> package under GPLv3. I guess this causes problems with packages with >> incompatible licenses like GPLv2 (only) and similar. > > Do you know of an GPL2-only application that links against ffmpeg > libraries (would be a silly idea anyway)? I did not investigate this, but I expect that we do have such package in debian. If I'm wrong, then I think we could proceed with this. > However, there was an approach pending to dlopen() the opencore libs > at runtime. Have you heard any news from this? I'm not aware of anyone volunteering to implement this. This would be the safest approach, though. >> I didn't think this really through, but if we find a solution, we could >> already do so for squeeze, btw. > > Technically yes, but you are right. We have to opt out any license > issues that may occur first. exactly. >> This is exactly why I sent the message to debian-release earlier >> today. short: no idea, the RT needs to decide on that. > > Alright. BTW, I have asked lintian for its opinion on the new packages: > - The library packages are still missing symbols files. would be great, but symbol files do not allow the same flexibilty as a regular shlib file: We cannot implement alternative dependencies that are required for the ffmpeg-extra with symbol files. > - The libraries contain some typos, should we fix them? Which ones? can you compile a list? > - We have an unused override debian-rules-calls-debhelper-in-odd-order, > which makes me wonder. We do indeed call debhelper commands in an odd > order, but why doesn't lintian see this anymore? This could be a lintian bug, the whole situation maybe needs some more thought: we generate the shlibs file twice: first time for the internal dependencies, and then we regenerate them for inclusion in the package. The point of this excercice is to have the 'internal' dependencies more strict than 'external' ones. We have implemented this so that we make mixing ffmpeg libraries with the ones from marillat harder. Perhaps this should be documented in some comment, but the rules file is already pretty convoluted as it is now. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
Am 26.01.2010 15:23, schrieb Fabian Greffrath:
- The libraries contain some typos, should we fix them?
I tried to leave the interface untouched.
--
Dipl.-Phys. Fabian Greffrath
Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum
Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail: greffr...@leat.ruhr-uni-bochum.de
--- ffmpeg.orig/libavcodec/mjpegdec.c
+++ ffmpeg/libavcodec/mjpegdec.c
@@ -956,7 +956,7 @@
}
if(s->avctx->debug & FF_DEBUG_PICT_INFO)
-av_log(s->avctx, AV_LOG_DEBUG, "%s %s p:%d >>:%d ilv:%d bits:%d %s\n", s->lossless ? "lossless" : "sequencial DCT", s->rgb ? "RGB" : "",
+av_log(s->avctx, AV_LOG_DEBUG, "%s %s p:%d >>:%d ilv:%d bits:%d %s\n", s->lossless ? "lossless" : "sequential DCT", s->rgb ? "RGB" : "",
predictor, point_transform, ilv, s->bits,
s->pegasus_rct ? "PRCT" : (s->rct ? "RCT" : ""));
--- ffmpeg.orig/libavcodec/opt.c
+++ ffmpeg/libavcodec/opt.c
@@ -424,7 +424,7 @@
break;
case FF_OPT_TYPE_INT64:
if((double)(opt->default_val+0.6) == opt->default_val)
-av_log(s, AV_LOG_DEBUG, "loss of precission in default of %s\n", opt->name);
+av_log(s, AV_LOG_DEBUG, "loss of precision in default of %s\n", opt->name);
av_set_int(s, opt->name, opt->default_val);
break;
case FF_OPT_TYPE_FLOAT: {
--- ffmpeg.orig/libavcodec/options.c
+++ ffmpeg/libavcodec/options.c
@@ -159,7 +159,7 @@
{"very", "strictly conform to a older more strict version of the spec or reference software", 0, FF_OPT_TYPE_CONST, FF_COMPLIANCE_VERY_STRICT, INT_MIN, INT_MAX, V|D|E, "strict"},
{"strict", "strictly conform to all the things in the spec no matter what consequences", 0, FF_OPT_TYPE_CONST, FF_COMPLIANCE_STRICT, INT_MIN, INT_MAX, V|D|E, "strict"},
{"normal", NULL, 0, FF_OPT_TYPE_CONST, FF_COMPLIANCE_NORMAL, INT_MIN, INT_MAX, V|D|E, "strict"},
-{"inofficial", "allow inofficial extensions", 0, FF_OPT_TYPE_CONST, FF_COMPLIANCE_INOFFICIAL, INT_MIN, INT_MAX, V|D|E, "strict"},
+{"inofficial", "allow unofficial extensions", 0, FF_OPT_TYPE_CONST, FF_COMPLIANCE_INOFFICIAL, INT_MIN, INT_MAX, V|D|E, "strict"},
{"experimental", "allow non standardized experimental things", 0, FF_OPT_TYPE_CONST, FF_COMPLIANCE_EXPERIMENTAL, INT_MIN, INT_MAX, V|D|E, "strict"},
{"b_qoffset", "qp offset between P and B frames", OFFSET(b_quant_offset), FF_OPT_TYPE_FLOAT, 1.25, -FLT_MAX, FLT_MAX, V|E},
{"er", "set error detection aggressivity", OFFSET(error_recognition), FF_OPT_TYPE_INT, FF_ER_CAREFUL, INT_MIN, INT_MAX, A|V|D, "er"},
--- ffmpeg.orig/libavformat/id3v1.c
+++ ffmpeg/libavformat/id3v1.c
@@ -91,7 +91,7 @@
[64] = "Native American",
[65] = "Cabaret",
[66] = "New Wave",
- [67] = "Psychadelic",
+ [67] = "Psychedelic",
[68] = "Rave",
[69] = "Showtunes",
[70] = "Trailer",
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
Am 26.01.2010 13:50, schrieb Reinhard Tartler: This would mean that we would need to redistribute the libavcodec package under GPLv3. I guess this causes problems with packages with incompatible licenses like GPLv2 (only) and similar. Do you know of an GPL2-only application that links against ffmpeg libraries (would be a silly idea anyway)? However, there was an approach pending to dlopen() the opencore libs at runtime. Have you heard any news from this? I didn't think this really through, but if we find a solution, we could already do so for squeeze, btw. Technically yes, but you are right. We have to opt out any license issues that may occur first. okay, this reads to me that the file is already understandable enough. great! :D This is exactly why I sent the message to debian-release earlier today. short: no idea, the RT needs to decide on that. Alright. BTW, I have asked lintian for its opinion on the new packages: - The library packages are still missing symbols files. - The libraries contain some typos, should we fix them? - We have an unused override debian-rules-calls-debhelper-in-odd-order, which makes me wonder. We do indeed call debhelper commands in an odd order, but why doesn't lintian see this anymore? - Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
On Di, Jan 26, 2010 at 13:35:17 (CET), Fabian Greffrath wrote: > Am 25.01.2010 16:19, schrieb Reinhard Tartler: >> Okay, I've now pushed my branch, it builds fine at least on my >> laptop. Feel free to testbuild and comment on it. > > It's still building but looks like it works fine. It should be built > against the opencore-amr[nw]b packages on Debian, though. This would mean that we would need to redistribute the libavcodec package under GPLv3. I guess this causes problems with packages with incompatible licenses like GPLv2 (only) and similar. I didn't think this really through, but if we find a solution, we could already do so for squeeze, btw. >> If it works for you, feel also free to review the instructions for >> updating the package to a new snapshot, perhaps some steps can be >> simplified. > > Do you mean debian/README.upstream-upgrade? It reads quite well, but > maybe it should be made more unambigous what the single steps are, > e.g. by enumerating them. For example, the indented code in line 29 > doesn't have anything to do with the step described in line 26, but > rather with that in line 31. okay, this reads to me that the file is already understandable enough. great! >> As for uploading it to experimental, I think we could already do this, >> but using it with binary packages from squeeze/sid will most probably >> break until they have been recompiled against the version of ffmpeg >> currently in unstable. Therefore I'd suggest to hold back this >> updated ffmpeg package to experimental until the binNMUs have been at >> least scheduled. > > Let's wait for the binNMUs, we are not in a hurry. BTW, do you know if > the binNMUs will be scheduled still before the current version has hit > testing or just after that? I mean, because if we had binNMUed packages > in both unstable and testing, we wouldn't break anything. This is exactly why I sent the message to debian-release earlier today. short: no idea, the RT needs to decide on that. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
Am 25.01.2010 16:19, schrieb Reinhard Tartler: Okay, I've now pushed my branch, it builds fine at least on my laptop. Feel free to testbuild and comment on it. It's still building but looks like it works fine. It should be built against the opencore-amr[nw]b packages on Debian, though. If it works for you, feel also free to review the instructions for updating the package to a new snapshot, perhaps some steps can be simplified. Do you mean debian/README.upstream-upgrade? It reads quite well, but maybe it should be made more unambigous what the single steps are, e.g. by enumerating them. For example, the indented code in line 29 doesn't have anything to do with the step described in line 26, but rather with that in line 31. As for uploading it to experimental, I think we could already do this, but using it with binary packages from squeeze/sid will most probably break until they have been recompiled against the version of ffmpeg currently in unstable. Therefore I'd suggest to hold back this updated ffmpeg package to experimental until the binNMUs have been at least scheduled. Let's wait for the binNMUs, we are not in a hurry. BTW, do you know if the binNMUs will be scheduled still before the current version has hit testing or just after that? I mean, because if we had binNMUed packages in both unstable and testing, we wouldn't break anything. - Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
On Di, Jan 26, 2010 at 10:55:43 (CET), Fabian Greffrath wrote: > Am 25.01.2010 16:19, schrieb Reinhard Tartler: >> Okay, I've now pushed my branch, it builds fine at least on my >> laptop. Feel free to testbuild and comment on it. > > Here it dies with: > > fatal: ambiguous argument > refs/heads/pristine-tar:ffmpeg_0.6~~svn20100124.orig.tar.gz.delta': > unknown revision or path not in the working tree. > Use '--' to separate paths from revisions > pristine-tar: git show > refs/heads/pristine-tar:ffmpeg_0.6~~svn20100124.orig.tar.gz.delta failed > /usr/bin/pristine-tar returned 128 > Couldn't run '/usr/bin/pristine-tar' Oh, I'm sorry, I forgot to push my pristine-tar branch. I've done so now. It should have worked if you would have passed the parameter '-b' to git-buildpackage: $ git-buildpackage -b -d instructs dpkg-buildpackage to avoid creating a source package. Source packages are not required for testing, only for uploading to some archive. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
Am 25.01.2010 16:19, schrieb Reinhard Tartler: Okay, I've now pushed my branch, it builds fine at least on my laptop. Feel free to testbuild and comment on it. Here it dies with: fatal: ambiguous argument 'refs/heads/pristine-tar:ffmpeg_0.6~~svn20100124.orig.tar.gz.delta': unknown revision or path not in the working tree. Use '--' to separate paths from revisions pristine-tar: git show refs/heads/pristine-tar:ffmpeg_0.6~~svn20100124.orig.tar.gz.delta failed /usr/bin/pristine-tar returned 128 Couldn't run '/usr/bin/pristine-tar' - Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
On Mo, Jan 25, 2010 at 12:38:07 (CET), Reinhard Tartler wrote: >> Same here. I've become a bit less active recently, but if there's >> something I can do to help and/or test, I'm of course there! > > Thanks. Just keep an eye on the 'master.snapshot' branch as soon as I > push my commits there. I have the branch almost ready, however I want to > clean it up a bit before public consumption Okay, I've now pushed my branch, it builds fine at least on my laptop. Feel free to testbuild and comment on it. If it works for you, feel also free to review the instructions for updating the package to a new snapshot, perhaps some steps can be simplified. As for uploading it to experimental, I think we could already do this, but using it with binary packages from squeeze/sid will most probably break until they have been recompiled against the version of ffmpeg currently in unstable. Therefore I'd suggest to hold back this updated ffmpeg package to experimental until the binNMUs have been at least scheduled. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
Am 25.01.2010 12:38, schrieb Reinhard Tartler: Why should we? This would only make sense if we would want to make these packages co-installable with the existing packages. I don't think this is worth the efford. This was misunderstanding, sorry, I placed my "+1" wrongly. I am not for renaming the source or binary packages names anyway! I just wanted to express my consent with not naming them "0.6+something" if upstream isn't even considering such a release at all. No such release is planned, and this is exactly what I want to discuss at FOSDEM. Well, fine then. ;) -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ffmpeg-snapshot
On Mo, Jan 25, 2010 at 10:53:59 (CET), Fabian Greffrath wrote: > Am 24.01.2010 20:43, schrieb Andres Mejia: >> Wouldn't it make more sense to continue with a version number >> "0.5+svn"? >> Not that it really matters to me, I'm just curious as to why "0.6" already? >> Also, shouldn't the package be named ffmpeg-snapshot, ffmpeg-trunk, or >> something >> similar? > > +1 Why should we? This would only make sense if we would want to make these packages co-installable with the existing packages. I don't think this is worth the efford. > Has upstream already announced that they are going to release a 0.6 > version at all? If not, I also think it's unwise to select this specific > version number for our own packages in advance. No such release is planned, and this is exactly what I want to discuss at FOSDEM. >> I'll volunteer to help if you wish. I could do regular uploads of the package >> depending on what interval you wanted. Of course I'll leave the initial >> packaging setup up to you. > > Same here. I've become a bit less active recently, but if there's > something I can do to help and/or test, I'm of course there! Thanks. Just keep an eye on the 'master.snapshot' branch as soon as I push my commits there. I have the branch almost ready, however I want to clean it up a bit before public consumption -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
