Slashdot Mirror
FFmpeg 1.0 MultiMedia Library Released
An anonymous reader writes "The free software FFmpeg multi-media library that's used by VLC, MPlayer, Chrome, and many other software projects has reached version 1.0 after being in development since 2000. The 1.0 release incorporates new filters/decoders and other A/V enhancements. The code is available from FFmpeg.org."
FFmpeg Frosty First edition?
Might FFmpeg 1.0 mean that MPEG-LA members are ready to pull the trigger on suing the maintainers of projects using FFmpeg?
I do not have version numbers for my software. It starts with MySoftwareX Build 1, and goes from there. I like to think "Problem Solved"
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
I wonder if they've finally managed to integrate correct video orientation handling when dealing with QuickTime movies. Lack of support was the reason VLC was unable to show QuickTime videos recorded using an iPhone.
http://ffmpeg.org/download.html#releases
For all their ardous work!
FFMpeg donations page is here:
http://ffmpeg.org/donations.html
Join the Slashcott! Feb 10 thru Feb 17!
Well, it's not that these projects were in beta for way too long, it's just that they are being honest about it.
ffmpeg supports both Avid DNxHD and Apple ProRes codecs, REDCODE decode, EXR, DPX, and all the best unencumbered formats as well. This means that most pro video and film production can integrate into OSS with much more ease than ever before. It also means that proprietary data lock-in is on the way out.
Way to go ffmpeg!
I said no... but I missed and it came out yes.
That's a good point. "Here's our software. It should be stable, but it's beta, so don't rely on it too much." beats "Hey, we're out of beta! What? Bugs? We'll take care of that in 1.1!"
If you use homebrew, I just pushed a new post on how to upgrade to FFmpeg 1.0 http://jasonormand.com/2012/09/28/how-to-install-ffmpeg-10-on-osx-mountain-lion/
open source projects stay in beta as long as need be, and don't rush to ship 1.0 or major releases until ready.
.0 versions long before they are ready because they release cycles and deadlines.
The good news for us, is that they allow the community to help ironing out the bugs, which for many don't show up until long repeated usage. The more people there are to report failures, the better.
compared this with commerical software. Especially microsoft. They release
OpenSSL spent 15 years before a 1.0 release. Noveau almost 10.
I think its a sign of many long standing projects maturing, and that linux is ready for prime time.
Unless I'm gravely confused, ffmpeg seems like a curious place for Quick Sync support. Quick Sync is an independent, comparatively inflexible(though fast), h.264 hardware encoder and decoder, not a set of instructions or an architectural feature that would speed up a software decoder. Why would a tool that is largely a collection of highly flexible software encoders and decoders be interested?
I can see how some of the video player programs that use ffmpeg might have reason to also have the option to use quick sync, on supported platforms; but that would really be up to them...
Stop slacking guys! Take a look at Firefox. Work as hard as they do and in 8 years you too can have a version 16 !
This would make my day, I understand they refuse to do it though. Really sucks when you want to have both Theater AND Director's cut releases of BluRay...
Build it, Drive it, Improve it! Hybridz.org
Sounds like you're getting ahead of yourself there. Before you ask if ffmpeg supports quicksync, maybe you should ask if Intel supports quicksync yet. Anyone have an URL of a page at intel.com (or whereever), where Intel says how to do it (e.g. op codes)?
If a feature is important to a cpu vendor, it is up to them to code an initial, up to ffmpeg coding standards patch and invite the community to progress it, with a good donation to the project.
ffmpeg being free and opensource doesn't mean they should waste precious development time to code a non portable enhancement.
Ok, so you're more in favor of
Chrome ButteryFly Sandwich
Followed by
Chrome Unripe Egg
Followed by
Chrome Lantern of Medicraty
Followed by
Chrome Furry Enchilada
ect...
Well.. maybe. Or Maybe not. But Definitely not sort of.
How come neither the article nor the official site (ffmpeg.org) does not mention Fabrice Bellard, the original author?
Search RapidShare and MegaUpload!
And what, exactly, does this number mean?
If you're in broadcast, check out ffmbc a broadcast-oriented ffmpeg fork. My dabbling has been with producing IMX (SMTPE D10) as an archival format for video and film archive digitiziation and although you can cook it up with ffmpeg, ffmbc makes it a doddle. The hard work has been done by the ffmpeg folks, and it's a wonderful tool.
I used ffmpeg for producing a side-by-side video of a reference uncompressed YUV vs samples of MJPEG2000 & MPEG2 at various compression ratios for a double-blind subjective quality assessment together with overlaid captions - took me a day or so going from never having used it before. Think of it as ImageMagick for video, rather than just a transcoding library.
Whilst I'm here, can I give a shout out for mediainfo(Hi Jerome!) as a technical metadata extraction tool for Video (if you're using it in an archival repository, use the mpeg7 or pbcore xml output - almost hidden features). Don't be fooled by the home page screenshot - the linux command line version is where it's at.
Ya know many here say 'Old hairy he hates FOSS' but I actually thought version numbers were one of the things they just nailed. First number is the version, and the number after the dot would let you know if it was beta or stable, odd for beta or testing, even for stable. What could be simpler? its the same reason i love AMD GPUs now, as the numbers since they bought ATI now make sense and are easy to follow, first number is series, second number tells you whether its low, midrange, or high end, and the third number tell you where it fits into that segment, with 3 being low, 5 mid, 7 high, and 9 dual chip. Again what could be simpler?
Frankly I wish more software would follow these examples instead of the Chrome/Firefox version number pissing contests. You just don't get any real information from their numbers, you can't tell if its just a bug fix or a whole rebuild, the numbers just don't tell you shit. So kudos to the FFmpeg guys for having sane version numbers, nice to see in this day and age of version number spinning.
ACs don't waste your time replying, your posts are never seen by me.
It "means something" to go to 1.0 after over a decade of development, and after being in production use in innumerable places?
It means what, exactly?
That isn't simple. Grandpa would have a hard time wrapping his head around such an arcane versioning system (why is 2.3 of program x breaking crap all over the place?! Isn't it better than my current working version of 2.2?!).
Alpha and Beta don't even need to be part of the stable release version. Like having Build 1, 2, 3... for releases, you can simplify it as Build 2 Alpha 3, or Build 5 Beta 2.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Nice story, but I really don't see the connection with reality.
Your original post got two answers: one saying that it wouldn't make sense to add the feature you want, and another saying that Intel should provide documentation.
You, on the other hand, imply that the reasons given by the ffmpeg authors for not implementing the feature you want are "Saint Stallman does not approve it" and "The Balance of The Force will be tipped in a wrong way", and you give no evidence of that at all.
Better luck on your future trollings!
That's nice, how about replying to the relevant post?
That would be fine, or even label say "Verson 2 testing" versus "version 2 stable" but you really do need to know this kind of information because otherwise tracking down where a problem may lie can be a royal PITA because you don't know if that release is a bug fix or a whole new rebuild with the problems that come with that.
ACs don't waste your time replying, your posts are never seen by me.
Muxing into MP4 containers was only semi-working for years and years and couldn't be recommended. This meant making MP4 was broken in mencoder as a consequence. Is it fixed yet? Please?
It's interesting how so many projects that were in beta for so long (though widely used and considered essentially stable) are finally getting the 1.0 treatment.
When I write code I initially set the version of my code to 1.0 which basically means it could crash or do horrible things to the environment. In other words not to be used by anyone not encased in flame and bullet proof armour. There are many who prefer using 0.0 to designate the first version of their software however to the average person who would use that software (ie. the majority) versions starting at 1.1 or preferably 1.2 and above is much more preferred than 0.1 or 0.2. Still it is not wrong to start your version at 0.0 but you should not be surprised if the majority of people think the software is either an "alpha" or "beta" version until the version number is above 1.
The problem of determining "alpha" or "beta" software unless explicitly mentioned is also problematic since a 0.2 or 1.2 version could be a relatively stable version or it may be really dangerous to use. For anyone using software it is best to have access to the source even though you may never actually need to look at it otherwise you really have to trust the person or the site you are getting the software from. Basically when downloading software "caveat emptor" applies. This is not to say that FFmpeg is bad or even risky since I use "ffmpeg-0.10.4-2.fc17.x86_64" with VLC from the Fedora repositories and I don't have any issues with it.
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.