Re: The Case For Re-Evaluating Our Release Approach To FFMPEG
2008/9/10 Reinhard Tartler <[EMAIL PROTECTED]>: > "Null Ack" <[EMAIL PROTECTED]> writes: > >> 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. > > The main problem is lack of manpower. Every time ffmpeg is updated, we > can more or less expect applications and libraries that use them to > break. > > FWIW, the next upstream snapshot that I'm preparing for > debian/experimental right now is going to drop nearly all > patches. Packaging new snapshots should become pretty easy then. > Thanks for the responses guys. Reinhard I'm excited to hear about the progress with dropping many patches and streamlining the process for synching from SVN. I'm also thankful for your interest in bug 263153 which I think is likely fixed in the latest gstreamer ffmpeg plugin release. I understand about person power and I will comit to helping you with testing new ffmpeg releases and related applications. I have a test library that involves many different containers and compression types and other features. I'm somewhat new to gstreamer but I've got a pretty solid understanding of digital media technologies and practices. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The Case For Re-Evaluating Our Release Approach To FFMPEG
"Null Ack" <[EMAIL PROTECTED]> writes: > 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. The main problem is lack of manpower. Every time ffmpeg is updated, we can more or less expect applications and libraries that use them to break. FWIW, the next upstream snapshot that I'm preparing for debian/experimental right now is going to drop nearly all patches. Packaging new snapshots should become pretty easy then. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The Case For Re-Evaluating Our Release Approach To FFMPEG
Olá Null e a todos. On Tuesday 09 September 2008 05:56:45 Null Ack wrote: > 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 skills are not in packaging, but I can certainly assist with > testing and helping construct a freeze exception rationale for > Intrepid. Please consider. I guess some one could keep a weekly build on a PPA, get it tested by a few users, and then move that week version to backports. Still, this would have to be a some what regular schedule thing to do, but since you (and others like you) already do that from SVN, I guess a weekly task/script wont be that hard. Plus, its a great way for you to start as a Ubuntu MOTU rookie, as long as you get a sponsor. -- BUGabundo :o) (``-_-´´) http://LinuxNoDEI.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by... signature.asc Description: This is a digitally signed message part. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
The Case For Re-Evaluating Our Release Approach To FFMPEG
Gday everyone, 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 Totem. 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 builds. 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. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss