The Case For Re-Evaluating Our Release Approach To FFMPEG
nullack at gmail.com
Tue Sep 9 04:56:45 UTC 2008
It was suggested to me on IRC that I should discuss this matter on
this mail list.
Summary : I think we need to have regular snapshots of svn ffmpeg,
libavcodec and so forth released in both the current development build
and as backports to production builds. User's expect to have video
experiences atleast as good as Windows and Mac, and this is necessary
for actually delivering that.
My argument :
To be honest my original approach with meeting my video needs on
Ubuntu was to turf out the default apps and do my own custom compiles
of mplayer, mencoder and gnome-mplayer. This continues to work well
and frankly is still superior to what I can do under gstreamer and
totem (such as deinterlacing and other video filters). However I felt
guilty about doing this because I was not supporting the Ubuntu
principle of having one standard method for doing things and I was
restricting the value of my testing work I do on Ubuntu by not using
default applications in all circumstances. So some time ago I bit the
bullet, committed myself to using default apps and leaving mplayer for
any related tests.
I am thankful for Sebastien's updates to the gstreamer good and ugly
plugins recently, as well as the updates Intrepid has received with
However, the ffmpeg gstreamer plugin is a key plugin for most user's
multimedia experiences. It provides to gstreamer:
* 256 elements
* 39 types
Of particular note amongst these many features is that some very
common video formats are used by gstreamer, such as AVC / H.264
decoding. AVC is one of the formats that is gaining much momentum with
it being widely used in BluRay, HDDVD, some Digital Video Broadcasters
and as an efficient backup format for personal media. As a subscriber
to the ffmpeg commit mailing list I know that in the past months there
has been substantial improvement to the code for AVC decoding and the
resolution of many related bugs.
AVC is just one decoder that ffmpeg handles out of many decoders that
has had many bug fixes in the past months.
Since gstreamer released a new ffmpeg plugin I have been enthusiastic
to see this arrive into Ubuntu and have Intrepid enjoy the more
reliable video experience this would offer our users. I'm advised
though that what is needed is to upgrade ffmpeg and related libraries
across the board to deliver the new gstreamer plugin. Upgrading ffmpeg
across the board would also give benefits to more advanced Ubuntu
users, whom for example maybe conducying video transcoding via
libavcodec. They wont need to suffer known bugs with old ffmpef
I want to note how the FFMPEG project manages releases:
* They dont do them
* Their standard response in reporting bugs is to compile SVN and retest.
What seems to happen in practice for FFMPEG in Ubuntu is that it
rarely is updated - Intrepid's packages are currently seven months
old. On an upstream project that has numerous commits daily.
I feel bad for our users because I see bug reports on Launchpad that I
know is never going to go anywhere because ffmpeg currently isnt kept
up to date and is not backported for their build.
Anyone who has a passing observation of the situation has to agree
this is not ideal. I contend the risk of having old binaries in the
repos and all the problems that brings with poor user experiences
outweighs the risk that new code will bring new problems. My practical
experience of doing my own compiles of SVN head has consistently been
things are fixed and enhanced. On one occasion I had a problem where
the code would not compile and on another a bad commit occurred, which
effected functionality, but that was fixed in half a day and I simply
recompiled. Upstream strive for the SVN build to be fully functional
and in my experience thats meet on nearly all occasions.
My skills are not in packaging, but I can certainly assist with
testing and helping construct a freeze exception rationale for
Intrepid. Please consider.
More information about the Ubuntu-devel-discuss