It has been a very long time since we last made a release and many did not think we would make one again but, back by popular demand, we are proud to announce a new release: FFmpeg 0.5 (http://www.ffmpeg.org/releases/ffmpeg-0.5.tar.bz2). Check out the release notes (http://svn.ffmpeg.org/ffmpeg/branches/0.5/RELEASE?revision=17805) and changelog (http://svn.ffmpeg.org/ffmpeg/branches/0.5/Changelog?revision=17727).
It is codenamed "half-way to world domination A.K.A. the belligerent blue bike shed" to give an idea where we stand in the grand scheme of things and to commemorate the many fruitful discussions we had during its development.
This release includes a very extensive number of changes, but some of the highlights are:
- Significant work to support at least decoding of all widespread mainstream proprietary codecs, such as:
- decoders and encoders
- ALAC
- Flash Screen Video
- WMAv2 decoder fixed, WMAv1/v2 encoder
- decoders
- Atrac3
- MLP/TrueHD
- On2 VP3 improvements and VP5/VP6 support
- RealAudio Cooker and fixes for 14.4 and 28.8
- RealVideo RV30/40
- WMV3/WMV9/VC-1 and IntraX8 frame support for WMV2/VC-1
- Broad coverage of widespread non-proprietary codecs, including:
- decoders and encoders
- DNxHD
- DVCPRO50 (a.k.a. DV50)
- Floating point PCM
- GSM-MS
- Theora (and encoding via libtheora)
- Vorbis
- decoders
- AAC with ADTS support and >2x the speed of FAAD! (no HE AAC support yet)
- AC-3 that is faster than liba52 in 5.1, up to 2x faster in stereo and also supports E-AC-3! Hence liba52 is now obsolete.
- DCA
- DVCPRO HD (a.k.a. DV100)
- H.264 PAFF and CQM support, plus slice-based multithreaded decoding
- Monkey's Audio
- MPEG-2 video support for intra VLC and 4:2:2
- Musepack
- QCELP
- Shorten
- True Audio (TTA)
- Wavpack including hybrid mode support
- Highlights among the newly supported container formats:
- demuxers and muxers
- demuxers
- muxers
- iPhone/iPod compatibility for MP4/MOV
- Matroska
- NUT
- Ogg (FLAC, Theora and Vorbis only)
- ShockWave Flash (SWF)
- libavdevice
- ffserver is working again.
- a shiny, new, completely revamped, non-recursive build system
- cleaner, more consistent code
- an all new metadata API
- and so much more!
Please, there are any windows binary to test?
Great to see WavPack lossy is now supported!
Well done to everyone involved in this new release of FFmpeg.
I'd love to see a rarewares-hosted build of this myself.
I'm surprised the notes don't tell the story behind the name.
For those who don't know:The bikeshed in question (http://blue.bikeshed.org/) (if that site messes with your eyes, you can change it to any color you'd like by changing the left-most string.
half-way to world domination A.K.A. the belligerent blue bike shed
I don't like the name "half-way to world domination".
I don't see the point in naming this release this way.
half-way to world domination A.K.A. the belligerent blue bike shed
I don't like the name "half-way to world domination".
I don't see the point in naming this release this way.
0.5 = 1/2
1.0 = world domination (because 1.0 is going to be so friggin' perfect nobody would want to use anything else)
One of the most complete A/V solutions in the OSS (or even the closed-sourced) world has some fun with their naming and this is a problem?
half-way to world domination A.K.A. the belligerent blue bike shed
I don't like the name "half-way to world domination".
I don't see the point in naming this release this way.
you're funny.
I'd love to see a rarewares-hosted build of this myself.
Well, I've managed to produce a MinGW compile of the base system as downloaded which I can post but do people want some of the external libs included, and, if so, which?
dare I say, all of them?
I always use the builds listed on the ffmpeg wiki, which are always all in, (with stuff like x264 too), but none seem to have 0.5 yet. I sure would like a build of .5 if you can make one. I love to have one executable which can convert literally anything.
dare I say, all of them?
I always use the builds listed on the ffmpeg wiki, which are always all in, (with stuff like x264 too), but none seem to have 0.5 yet. I sure would like a build of .5 if you can make one. I love to have one executable which can convert literally anything.
I guess I asked for that!!
I'll see what I can do for you. It may take me a day, or so as I'm no MinGW expert, but I'm sure I'll get there! I'll post back here with something to test before I post it at Rarewares.
Win32 builds will appear later here:
http://ffmpeg.arrozcru.org/wiki/index.php?title=Links (http://ffmpeg.arrozcru.org/wiki/index.php?title=Links)
I found a random copy on the Internet (http://hp.vector.co.jp/authors/VA020429/ffmpeg/ffmpeg.html) and posted it on fb2k.net (http://fb2k.net/ffmpeg-0.5.zip) for the moment. I'm not sure what all's included, but it produces ALAC files nicely. That was the aim I had for hosting it (http://fb2k.net/?p=127). As I know and trust Rarewares, I'd just as soon refer people there instead.
@Canar: from the filesize I infer it's not all in, the ffmpeg.exe I have here is around 7MB.
But, as it does encode ALAC, could you tell me if [a href='index.php?showtopic=65497']ffmpegs problems with alac[/a] have been solved in 0.5?
Uncompressed, the executable is 8.7MB. And yes, the length mismatch problem still exists.
Ah, I didn't think the executable would be that compressable. And thanks for the confirmation. I really hope they'll fix that soon, because as-is the alac encoder just isnt lossless.
http://lists.mplayerhq.hu/pipermail/ffmpeg...ary/018917.html (http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2009-February/018917.html)
ffmpeg have problem with lame 3.98.2 (no problem with 3.98), there is a patch, but looks like it was not applied:
https://roundup.ffmpeg.org/roundup/ffmpeg/issue803 (https://roundup.ffmpeg.org/roundup/ffmpeg/issue803)
"The bug disappears if you go back to LAME 3.98
Also there is a patch proposed but not applied. Good diplomacy is yet needed as neither FFmpeg nor LAME see the, ahem, issue as an own bug."
http://ffmpeg.arrozcru.com/forum/viewtopic.php?f=1&t=977 (http://ffmpeg.arrozcru.com/forum/viewtopic.php?f=1&t=977)
I found a random copy on the Internet (http://hp.vector.co.jp/authors/VA020429/ffmpeg/ffmpeg.html) and posted it on fb2k.net (http://fb2k.net/ffmpeg-0.5.zip) for the moment. I'm not sure what all's included, but it produces ALAC files nicely. That was the aim I had for hosting it (http://fb2k.net/?p=127). As I know and trust Rarewares, I'd just as soon refer people there instead.
just playing around with flash screen video, the command
>ffmpegnew -i 01_cs3_gui.avs -vcodec flashsv test.flv
produces some jumping thing that remotely looks like video
edit: must be some issue with avisynth input, command
>ffmpegnew -i 01_cs3_gui_unc.avi -vcodec flashsv test2.flv
produces a valid file.
edit2:
the real question is why even include such an ancient codec in the 1st place, when you can get a nice lossy file for web using some of the CRF modes found in x264 (crf21 will give me average bitrate of 105 Kbps), nm
OK, I've made a build, with a lot of help from the wiki, I might add, with this configuration:
FFmpeg version 0.5, Copyright (c) 2000-2009 Fabrice Bellard, et al.
configuration: --extra-cflags=-fno-common --enable-memalign-hack --enable-pthreads --enable-libmp3lame --enable-libxvid --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libfaac --enable-libgsm --enable-libx264 --enable-libschroedinger --enable-avisynth --enable-swscale --enable-gpl
libavutil 49.15. 0 / 49.15. 0
libavcodec 52.20. 0 / 52.20. 0
libavformat 52.31. 0 / 52.31. 0
libavdevice 52. 1. 0 / 52. 1. 0
libswscale 0. 7. 1 / 0. 7. 1
built on Mar 19 2009 10:45:23, gcc: 4.3.3
If this looks about right, I'll post it for testing. May be someone in the know could advise? TIA.
EDIT: Might be worth mentioning the following:
- Size (uncompressed) - 8.84MB
- Build is based on all libs being statically linked
- faac-1.26
- lame-3.98.2
- libvorbis-aoTuVb5.7
- speex-1.2rc1
- x264-snapshot-20090317-2245
- xvidcore-1.2.1
- All other libs were latest releases
- All required patches applied
- All builds made 'out of the box', subject to specified patches, using msys/mingw32/gcc 4.3.3
- Built on an Intel E4300, Asus P5N-D, XP Pro 32 bit fully up-to-date
EDIT 2: To save wasting time, I've made the build available here: http://www.rarewares.org/john33/ffmpeg0.5-win32.zip (http://www.rarewares.org/john33/ffmpeg0.5-win32.zip)
If someone would be willing to test this and let me know whether it works as expected, that would be great.
a question. Would it be possible to get only audio codecs and container formats compiled in? This is no big deal just because I am curious.
And something else which is more like an issue for me. Can anybody create a binary which includes AMR support?
Unfortunatelly this is illegal to distribute so it'll be really difficult. Hmm. but really I am too stupid to build it my-self so asking is the only option left.
Yes, building ffmpeg with only audio support would be much appreciated!
And AMR support (at least decoding) would be very nice to have too...
In general, I think it is worth managing a web-resource which would offer different compilations of ffmpeg for different platforms.
For example:
* all-inclusive ffmpeg
* audio only ffmpeg
* video only ffmpeg
* decoding only ffmpeg
... etc
and for:
* for win32
* for linux (static libs)
* etc...
I believe this would solve many problems for those who really like/need ffmpeg and don't know who to compile it by themselves.
I think its better to use shared mode, so we can update dll's without recompiling it.
@ john - did you apply mp3 patch from my previous post? I dont see sources...
@ aradzish - why not to use only all inclusive version?
So what else is missing?
Better / Full support of Rmvb from Real - Or Faster decode.
Microsoft .wmv
Vp6?
Honestly, FFmpeg is very very good..
http://lists.mplayerhq.hu/pipermail/ffmpeg...ary/018917.html (http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2009-February/018917.html)
ffmpeg have problem with lame 3.98.2 (no problem with 3.98), there is a patch, but looks like it was not applied:
https://roundup.ffmpeg.org/roundup/ffmpeg/issue803 (https://roundup.ffmpeg.org/roundup/ffmpeg/issue803)
"The bug disappears if you go back to LAME 3.98
Also there is a patch proposed but not applied. Good diplomacy is yet needed as neither FFmpeg nor LAME see the, ahem, issue as an own bug."
http://ffmpeg.arrozcru.com/forum/viewtopic.php?f=1&t=977 (http://ffmpeg.arrozcru.com/forum/viewtopic.php?f=1&t=977)
The bug-reports we received did not mention ffmpeg calling lame_encode_flush more than once. So I could not reproduce anything wrong on my side.
Thankyou very much to all the people who work on this project, thankyou John33 for the compile, and the Hydrogenaudio and Rarewares people as well
I think its better to use shared mode, so we can update dll's without recompiling it.
@ john - did you apply mp3 patch from my previous post? I dont see sources...
@ aradzish - why not to use only all inclusive version?
Forgive me if I'm being a bit dense, but I don't see a patch there other than the one to libavcodec.c that confirms the 'bug'? If someone has a fix for this, I'm more than happy to apply it.
I note and agree with the comments regarding the shared mode, I was just happy to put a full build together that seemed to work as expected! If I receive the lame patch, I'll try a full shared mode build.
Could someone please share the latest ffmpeg precompiled for linux with static libs?
Thanks.
- Seems work fine the new parameter -drc_scale <float>. Remember use -drc_scale 0.0 when you need ac3 audio to transcode.
- The multichannel audio (ac3, aac, ogg, mlp) still have problems with the wrong channelmapping.
It's worth pointing out that ffmpeg still maintains the property that if you request vorbis via -acodec vorbis you get the "ffmpeg internal" vorbis encoder while -acodec libvorbis is required to get the external encoder.
This is relevant because the internal encoder is very simplistic and clearly underperforms the reference implementation (and AoTUV, of course). I can say this on purely objective grounds— it frequently misses bitrate targets and produces streams with bad granpos values which wedge some decoders, but the encoder is also artifact prone enough that it has caused quality related complaints where users have unwittingly used it (and you can compare for yourself, I threw up some examples (http://myrandomnode.dyndns.org:8080/vorbis/) notice the significant birdie artifacts), so it even fails a simple unintentional blind test.
It's impressive and laudable work that the FFMpeg has implemented their own independent encoder that works at all. As far as I'm aware it's the only publicly available encoder not derived from libvorbis. But at the same time the quality is very low so the decision to place that encoder where users will use it without a conscious decision to do so is very unfortunate. I hope that a future version either improves the internal encoder to match libvorbis, replaces it with libvorbis (which is BSD licensed for a reason…), or at least stops giving the internal codec to users without a stern warning.
It has been a very long time since we last made a release and many did not think we would make one again but, back by popular demand, we are proud to announce a new release: FFmpeg 0.5 (http://www.ffmpeg.org/releases/ffmpeg-0.5.tar.bz2)
COOL
Check out the release notes (http://svn.ffmpeg.org/ffmpeg/branches/0.5/RELEASE?revision=17805) and changelog (http://svn.ffmpeg.org/ffmpeg/branches/0.5/Changelog?revision=17727)
Both links are broken
- Significant work to support at least decoding of all widespread mainstream proprietary codecs, such as:
- RealAudio Cooker and fixes for 14.4 and 28.8
- RealVideo RV30/40
Real support became real
- Theora (and encoding via libtheora)
- Ogg (FLAC, Theora and Vorbis only)
Any BUGzilla around ? It's buggy
Anyone can encode this one: http://freefile.kristopherw.us/uploads/temp/ffx3yuv.zi7 (http://freefile.kristopherw.us/uploads/temp/ffx3yuv.zi7) into Theora: FFW2 -i g.yuv g.ogv BTW, using AVI as output format doesn't have this problem.
Tried both executables advertised here, same result:
Page Fault :-( The EIP's do differ but the offending code is very same, some huge and boring MMX'ed code (sorry I didn't upload the full disassembly, as this probably would crash the HA server , also the addresses are resolved poorly) :
Used FFMPEG binary (but all do crash) mirrored here: http://freefile.kristopherw.us/uploads/temp/ffw2.zi7 (http://freefile.kristopherw.us/uploads/temp/ffw2.zi7)
PS: the files are 7-ZIP's
Crash report (apparently ineligible for inline posting here): http://freefile.kristopherw.us/uploads/temp/ffmpeg.txt (http://freefile.kristopherw.us/uploads/temp/ffmpeg.txt)
(http://Moderation:%20Placed%20your%20screed%20in%20a%20CODEBOX.%20%20This%20is%20the%20way%20we%20do%20things%20around%20here).
Check out the release notes (http://svn.ffmpeg.org/ffmpeg/branches/0.5/RELEASE?revision=17805) and changelog (http://svn.ffmpeg.org/ffmpeg/branches/0.5/Changelog?revision=17727)
Both links are broken
mplayerhq/ffmpeg svnweb is temporarily offline for security reasons. Here are the mirrored copies of the 0.5 release notes (http://www.ffmpeg.org/RELEASE) and changelog (http://www.ffmpeg.org/Changelog).