ffmpeg next steps, was: next mplayer upload

Reinhard Tartler siretart at tauware.de
Tue Jun 9 13:26:28 UTC 2009


Fabian Greffrath <greffrath at leat.rub.de> writes:

> Reinhard Tartler schrieb:
>> It won't change much. I already have "permission" to ship an unstripped
>> source in ubuntu/main.
>
> Will you still have to disable the affected codecs in debian/confflags
> for ubuntu/main?

AFAIUI no, at least not until some patent holder complains.

>> Yes, because the main benefit of doing is is the additional external
>> libraries I can depend on in the unstripped branch. The most important
>> ones include x264 and libmp3lame. the name "unstripped" is clearly
>> misleading, so at some point we should clear up the naming. However I
>> don't think this is a good time to implement such a change, at least not
>> until we don't know how debian stands here.
>
> Well, I think I need an idea about the naming scheme in order to
> rephrase the critical parts of ffmpeg's debian/README.Debian file.

Hm. how about ffmpeg-extra as source package and 'libavcodec-extra-52'?

>> TBH, I'm still in favor of shipping an build-and-install shell script in
>> /usr/share/doc/ffmpeg that downloads and builds from git all packages
>> that we are not able to provide in debian proper.
>
> I like this approach for packages like lame and x264, but I am all
> against it for ffmpeg - given that the only difference between Debian's
> ffmpeg and upstream can be vanished by the following command:
>
> sed -e "/^disable_encoders/s/^/#/g" debian/confflags
>
> If the source code is really the same for ffmpeg-debian and ffmpeg and
> we will get full functionality by removing seven disable_encoders-lines
> in debian/confflags, what sense does it make to let users checkout an
> entire git-repository?
>
> For additional external codecs we already check the presence of their
> header files in debian/confflags and configure the package accordingly,
> so the only change necessary to enable them would be some added
> Build-Depends - which is again nothing that would justify maintaining an
> entire separate ffmpeg branch IMHO.

That's a good point. That sounds like a download and build script would
be easy to create:

,----
| apt-get source -d ffmpeg
| dpkg-source -x  ffmpeg-$VERSION.dsc ffmpeg-extra
| cd ffmpeg-extra
| sed -e "/^disable_encoders/s/^/#/g" debian/confflags
| dpkg-buildpackage -us -uc
`----

So let's say this: if the unmodified source gets accepted into debian,
and we're confident that ftp-master agrees here, we can ditch the
master.unstripped branch in favor of this approach, OK?

>> BTW, in order to get there, I think the packages mp3lame and x264 should
>> be updated so that the master.unstripped branch can be built against
>> them. IIRC both packages haven't been moved from svn to git yet, so I'll
>> work on that next. Since ubuntu does ship these packages, I'd like to
>> maintain them under the pkg-multimedia umbrella. Any objections?
>
> I am all for maintaining them under pkg-multimedia, since I already
> maintain some of these package privately. Please consider the packages
> found at http://debian.greffrath.com/unstable/ for lame.

thanks, I'll consider them!

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4



More information about the pkg-multimedia-maintainers mailing list