FFE: ffmpeg 0.5

Bug #340303 reported by Sindhudweep Sarkar
40
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ffmpeg (Ubuntu)
Fix Released
Undecided
Unassigned
Nominated for Jaunty by Sindhudweep Sarkar
ffmpeg-debian (Debian)
Fix Released
Unknown
ffmpeg-debian (Ubuntu)
Fix Released
Undecided
Unassigned
Nominated for Jaunty by Sindhudweep Sarkar

Bug Description

     * A description of the proposed changes, with sufficient detail to estimate their potential impact on the distribution

Currently, jaunty ships a snapshot of ffmpeg dated from 20090204. This update would bring us to the latest release of ffmpeg. In fact, this updates the snapshot to ~20090303.

    * A rationale for the exception, explaining the benefit of the change

gst-ffmpeg already includes that release, having the two in sync lowers the risk of causing crashers caused by a version skew

    * Any additional information which would be helpful in considering the decision

debian/unstable already ships the 0.5 release in unstable. It is very likely that we can keep the ffmpeg packages in sync for a longer time, which results in more testing of the codebase and easier maintenance.

Testpackages and rebuilds of reverse dependencies can be found in siretart's PPA (for intrepid only ATM, sorry). So far, no regressions have been spotted.

original report follows:

Binary package hint: ffmpeg

ffmpeg releases quite rarely, though they aim to keep a stable source trunk. Ubuntu uses an svn snapshot from february 4th.

ffmpeg released version .5 today with significant stabilizations. Complete announcement http://www.ffmpeg.org/ and changelog http://svn.ffmpeg.org/ffmpeg/branches/0.5/Changelog?revision=17727

description: updated
Changed in ffmpeg:
status: New → Triaged
Revision history for this message
Reinhard Tartler (siretart) wrote :

The current package in jaunty is pretty recent, but I could easily update it to 0.5 in jaunty as well. Since we are in FeatureFreeze this requires a freeze exception as outlined at https://wiki.ubuntu.com/FreezeExceptionProcess

For you convenience, I've attached the upstream diff to this bug.

Revision history for this message
Reinhard Tartler (siretart) wrote :

Sindudweep, would you be willing to continue the FreezeExceptionProcess?

Revision history for this message
Travis Watkins (amaranth) wrote :

The diff seems to be reversed.

Revision history for this message
Sindhudweep Sarkar (sindhudweep-sarkar) wrote :

Reinhard,

I'm not sure i'm qualified since i'm neither the maintainer of ffmpeg package nor am I an upstream developer of the project; Here are my thoughts on it. Hopefully a good dialogue will help us formulate if it's worth it to break the freeze.

From my understanding some api/abi changes were made september of last year to ffmpeg. I am guessing that the current versions of mplayer and vlc have either adapted or are using their own versions of libavcodec and libavformat. I expect on the whole for .5 to not be very different than how svn was feb 4th. From what I can gather, ffmpeg itself was in a psuedo freeze to prevent regressions, and theoretically new features can't cause regressions. The only thing somewhat troublesome are fixes to timestamp handling for x264. This could cause other bugs to appear. Given the above, .5 primarily represents bugfixes and cleanup to what was in the code base on february 4th, and from a release engineering point of view it represents a common point for other distributions to grab onto perhaps making maintainance cheaper.

Pros
------
Upstream release instead of svn means possibly more collaboration with other distributions and possibly more stable bugfixing in the future.

Less patches and cleanups should, in theory, need to be maintained from the upstream version by tracking it more closely.

Bug Reporting upstream is easier with a tagged branch that upstream expects bugs from than from an older svn build likely to make upstream more unhappy.

Fixes to VDPAU support should make some nvidia blog users happy.

Cons
------
Bug fixes to h264 timestamp handling could cause regressions.

FFMPeg developers probably don't want to backport features to .5; Few "end user" features in .5 that were not in svn on feb. 4th. Other distributions could just as easily choose to track svn.

If vaapi isn't backported to .5, netbook users with poulsbo and others with via chrome 4xx/5xx will probably want karmic to track svn not .5+backports.

Not sure what others think; I'd imagine ffmpeg is pretty popular so hopefully someone has some strong opinions to the points above and other benefits/concerns to upgrading.

Revision history for this message
Reinhard Tartler (siretart) wrote : Re: [Bug 340303] Re: Please sync with upstream release of ffmpeg .5

Sindhudweep Sarkar <email address hidden> writes:

> I'm not sure i'm qualified since i'm neither the maintainer of ffmpeg
> package nor am I an upstream developer of the project

that's not really necessary. The process requires mainly to investigate
the changes that has been done between the version currently in ubuntu
and version 0.5.

AFAIUI, the changes not too grave, but still considerable. I don't
*expect* regression but I wouldn't be surprised if there were.

For the other issues I can only suggest to file bugs in launchpad with
references in what upstream svn revision they have been fixed,
preferably linked to upstream bug reports. That's a convenient way for
documenting your research on the changes in the proposed new package. I
expect that most of the issues you've noted are already in the package
in jaunty, but without better references, I cannot check that.

if you want something to test, you can fetch the 0.5 package from my
ppa.

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

Revision history for this message
Sebastian Dröge (slomo) wrote : Re: Please sync with upstream release of ffmpeg .5

gst-ffmpeg already contains ffmpeg 0.5 internally (but we're building against the packaged ffmpeg of course). It'd be great if gst-ffmpeg and ffmpeg could be in sync, also from what I saw there were many bugfixes in the last weeks in ffmpeg that would be nice to have in jaunty.

description: updated
Revision history for this message
Sindhudweep Sarkar (sindhudweep-sarkar) wrote : Re: [Bug 340303] Re: Please sync with upstream release of ffmpeg .5

Yes, almost all of the commits are bug fixes. My only concern would be
the bug fixes towards the h264 timestamps which is a fix to something
that is technically wrong but did not afaik cause any end user bad
behavior. It may be "wrong" but it was working and many users will be
upset if that changes.

On Wed, Mar 11, 2009 at 11:12 AM, Sebastian Dröge
<email address hidden> wrote:
> gst-ffmpeg already contains ffmpeg 0.5 internally (but we're building
> against the packaged ffmpeg of course). It'd be great if gst-ffmpeg and
> ffmpeg could be in sync, also from what I saw there were many bugfixes
> in the last weeks in ffmpeg that would be nice to have in jaunty.
>
> --
> Please sync with upstream release of ffmpeg .5
> https://bugs.launchpad.net/bugs/340303
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
nullack (nullack) wrote :

I have conducted fairly wide tests on AVC playback using my own compiles and have not identified any problems with properly encoded H.264 streams with the release code.

Its an essential upgrade to the release revision given the number of fixes committed to SVN.

Revision history for this message
Sindhudweep Sarkar (sindhudweep-sarkar) wrote :

Well it seems like sebastian, and nullack are for the feature freeze exception, and I am certainly not opposed to it. I propose a division of labor to push this ffe through.

From my point of view the diff seems somewhat cumbersome to dissect into individual bugs and fixes. I think a reasonable course of action would be to see how different the ubuntu source was from upstream on 20090204 and then look at each commit using ffmpeg's git or svn repo. If we dived the number of commits by the people that want this it shouldn't be so bad. There were 28 days for changes to be made to the source so roughly between sebastian, nullack and myself we should each have to go through 9 days of commits. This would allow us to build up the bug documentation necessary to convince the release managers to break the freeze per what Reinhard said.

I will examine changes made from February 4th through February 13th; as well as test Reinhard's ppa version of ffmpeg.

Revision history for this message
Sebastien Bacher (seb128) wrote :

I'm not convinced we should spend those efforts before being asked for that, we are still before beta and the upgrade might be accepted on the basis that most changes are bug fixes, that sync between gstreamer and ffmpeg would be good and that debian uses it too

Revision history for this message
Sindhudweep Sarkar (sindhudweep-sarkar) wrote :

well my own build of ffmpeg .5 statistically should work with all 1.5 tb of avc files with a > 95% confidence level; I'm certainly satisfied.

Ubuntu Release seems subscribed already. Do we need to do anything more to proceed?

Revision history for this message
Martin Pitt (pitti) wrote :

release ack:

It appears that the 0.5 release was well tested already. I understand that 0.5 doesn't change ABI compared to what we already have in jaunty? If that is so, then please go ahead.

If it does introduce a new SONAME, we need to coordinate the rebuilds, as there are quite a few reverse dependencies. In this case, please get a list of affected packages and determine who will oversee the rebuilds.

Thank you!

Revision history for this message
nullack (nullack) wrote :

Sindhudweep there is no AVC decoder that will decode all AVC file types. The profiles are simply too broad and the levels too many within the standard for all AVC streams to play with the one decoder. Just like how no one AVC encoder will encode for all profiles and levels. For the ffmpeg decoder I have not found any avc content that does not play that is supposed to be supported by ffmpeg.

Revision history for this message
Sindhudweep Sarkar (sindhudweep-sarkar) wrote :

@nullack: Indeed. Most of my content does not fall under any one profile however. I have a good variety encoded with strange motion estimation and b-frame counts. What i meant was that i did not see any regressions compiling ffmpeg .5 vs svn20090204.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ffmpeg-debian - 3:0.svn20090303-1ubuntu1

---------------
ffmpeg-debian (3:0.svn20090303-1ubuntu1) jaunty; urgency=low

  * FFE granted in LP: #340303.

  * merge from debian/unstable.
  * remaining changes to debian:
    - don't build-depend on libfaad-dev, disabling faad decoder.

ffmpeg-debian (3:0.svn20090303-1) unstable; urgency=low

  * New Upstream Version (svn revision 17737 libswscale revision 28799)
    - Electronic Arts TQI decoder
    - OpenJPEG based JPEG 2000 decoder
    - NC (NC4600) camera file demuxer
    - Gopher client support
    - MXF D-10 muxer
    - generic metadata API
  * debian/get-orig-source.sh: Track the version 0.5 release branch. The
    version number does not really reflect this, but this package is
    actually very close to the 0.5 release branch.
  * various cleanups to improve get-orig-source.sh
  * Remove liba52 from the suggests field in debian/control.ffmpeg, as
    ffmpeg does no longer use it since upload 0.svn20080206-10.
  * Fix the Vcs-Git urls to the correct locations.
  * The libavformat52 now links against libavcodec52, which breaks
    applications that *ALSO* link against libavcodec51. Adding a
    Breaks: libavcodec51 should prevent this and (hopefully) Closes: #516885.
  * improve parallel builds on SMP/multicores by supporting the parallel
    flag in DEB_BUILD_OPTIONS, and default to the number of available CPUs
    on i386 and amd64.
  * Drop unapplied patches from debian/patches.
  * bump shlibs version.

ffmpeg-debian (3:0.svn20090204-3) unstable; urgency=low

  [ Fabian Greffrath ]
  * remove libasound2-dev from build-depends on non-Linux archs

  [ Reinhard Tartler ]
  * fix postinst generation by calling dh_installdeb after dh_makeshlibs
  * upload to unstable

 -- Reinhard Tartler <email address hidden> Fri, 13 Mar 2009 08:54:33 +0100

Changed in ffmpeg-debian:
status: Triaged → Fix Released
Revision history for this message
Reinhard Tartler (siretart) wrote :

accepted in jaunty

Changed in ffmpeg (Ubuntu):
status: New → Fix Released
Changed in ffmpeg-debian (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.