×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

FFmpeg 1.0 MultiMedia Library Released

Soulskill posted about a year and a half ago | from the onward-and-upward dept.

Media 82

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

82 comments

Now that's how to use version numbers (0)

Anonymous Coward | about a year and a half ago | (#41490975)

Make them mean something. Anything. Otherwise, don't use numbers at all.

Re:Now that's how to use version numbers (3, Funny)

Anonymous Coward | about a year and a half ago | (#41491131)

FFmpeg Frosty First edition?

MPEG-LA (3, Interesting)

tepples (727027) | about a year and a half ago | (#41491149)

Might FFmpeg 1.0 mean that MPEG-LA members are ready to pull the trigger on suing the maintainers of projects using FFmpeg?

Re:MPEG-LA (4, Informative)

Anonymous Coward | about a year and a half ago | (#41491909)

No. ffmpeg people don't distribute binaries and our mostly outside the US. MPEG-LA has repeatedly affirmed that source code alone is fine with them. This had been affirmed by Ryan Rodriguez of MPEG-LA that shipping source code is not a product.

http://forum.doom9.org/showthread.php?p=1431854#post1431854 [doom9.org]

There's plenty reasons to dislike MPEG-LA without making shit up.

Re:MPEG-LA (0)

Anonymous Coward | about a year and a half ago | (#41492159)

He said 'maintainers of projects using FFmpeg', those people usually ship binaries.

Re:MPEG-LA (1)

Anonymous Coward | about a year and a half ago | (#41492489)

MPEG-LA probably _loves_ FFMPEG. A huge chunk of media products are based on it, and all MPEG-LA has to do is detect the FFMPEG bits by signature then pursue license fees. Because they can see the source, and can probably tell which bits are compiled in, they'll know which patents are involved right off the bat.

It could hardly get any better for them...

Re:MPEG-LA (2)

wdef (1050680) | about a year and a half ago | (#41497287)

There are a LOT of commercial projects that use FFmpeg but pay for licensing for the particular codecs enabled. MPEG-LA, VIA (AAC), and Thomson (MP3) have no problem with that or where the codec implementation came from so long as the client the client is paying.

My bigger complaint is an oddity of their H.264 licensing that requires *every* H.263 decoder installed to be paid for separately. This means the H.264 decoder in OSP Flash, the H.264 decoder in the Gstreamer plugin and the H.264 decoder in FFmpeg all count, so it's 3 decoders not one in there and you pay for three decoders per unit Software decoders count separately to hardware decoders. And it's not really clear if the H.264 hw decoder in the GPU is a full decoder or not. MPEG LA agreed with me that it is not a fully functioning decoder since it requires the graphics driver and libva to be useful.

With mp3 and AAC licensing you only pay for *one* decoder no matter how many are installed per device.

Re:MPEG-LA (1)

wdef (1050680) | about a year and a half ago | (#41497299)

Correction:

that requires *every* H.263 decoder

should read

that requires *every* H.264 decoder

Re:MPEG-LA (1)

Anonymous Coward | about a year and a half ago | (#41492029)

Only if they were in the United States and shipping binaries. FFmpeg only distributes source and let's others ship the binaries. Third parties in the US who compile and ship FFmpeg without a license would have an issue.

Re:MPEG-LA (1)

tepples (727027) | about a year and a half ago | (#41495813)

If I were to distribute a package containing MinGW (a Windows port of GCC) and the source code of FFmpeg such that the installer compiles the source code, along with an offer to distribute the source code of MinGW, would I run into a problem? (Yes I know you're not a lawyer.)

Re:Now that's how to use version numbers (3, Insightful)

TheRealMindChild (743925) | about a year and a half ago | (#41491179)

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"

Re:Now that's how to use version numbers (2)

hairyfeet (841228) | about a year and a half ago | (#41494909)

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.

Re:Now that's how to use version numbers (1)

TheRealMindChild (743925) | about a year and a half ago | (#41495093)

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.

Re:Now that's how to use version numbers (1)

hairyfeet (841228) | about a year and a half ago | (#41497357)

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.

Re:Now that's how to use version numbers (0)

aliquis (678370) | about a year and a half ago | (#41491291)

MyMultimediaLibrary RatherCrappy.BugsExpected.PatentedVideoCode

Re:Now that's how to use version numbers (1)

Bill, Shooter of Bul (629286) | about a year and a half ago | (#41493861)

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...

Re:Now that's how to use version numbers (1)

Goaway (82658) | about a year and a half ago | (#41495059)

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?

Video orientation (1)

Anonymous Coward | about a year and a half ago | (#41491245)

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.

Re:Video orientation (5, Funny)

Anonymous Coward | about a year and a half ago | (#41491381)

using an iPhone.

Found your problem

Re:Video orientation (0)

Anonymous Coward | about a year and a half ago | (#41492719)

Did you try reporting the issue (especially with sample video files), or can you at least check to see if it remains an issue?

Believe it or not, but not everyone has an iPhone or anyone nearby that can give them access to one. I for one certainly never knew of the issue, being that I've never encountered iPhone videos outside of what's on YouTube.

Re:Video orientation (0)

Anonymous Coward | about a year and a half ago | (#41493145)

The thing is Youtube doesn't serve you the original file, they recode it, and in the process convert the orientation flag correctly. That's why you didn't find the problem. With respect to the "provide sample", all the times I've watched a developer forum (vlc/handbrake/other) they say "yeah, we don't support that and have no interest, keep your samples".

Re:Video orientation (5, Funny)

Anonymous Coward | about a year and a half ago | (#41493029)

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.

You're holding it wrong.

Re:Video orientation (2)

Chrisq (894406) | about a year and a half ago | (#41494375)

You're holding it wrong.

Just tell him to let go, there's no need to post about it

Does it support Intel's Quick Sync? (0)

snikulin (889460) | about a year and a half ago | (#41491305)

I overheard they had some ideological(?) issues with that in the past.
As a consumer I really want this feature, even if a kitten suffers somewhere because of this feature.

Re:Does it support Intel's Quick Sync? (3, Interesting)

fuzzyfuzzyfungus (1223518) | about a year and a half ago | (#41492335)

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...

Re:Does it support Intel's Quick Sync? (-1, Flamebait)

snikulin (889460) | about a year and a half ago | (#41493671)

Well, now I understand why an average pretty girl won't go out with an average geek.
She instinctively knows she will hear someday "Honey, you won't get that pretty car (ring, sofa, pony) because a) it's incompatible with my Linux server and b) Saint Stallman does not approve it too".

Re:Does it support Intel's Quick Sync? (0)

Anonymous Coward | about a year and a half ago | (#41494133)

Now you're just trolling.

Your original post might have been construed as a legitimate question, but now it just looks like no one bit your "ideological(?) issues" flamebait so you're just spouting nonsense.

Re:Does it support Intel's Quick Sync? (-1, Flamebait)

snikulin (889460) | about a year and a half ago | (#41495493)

Well, now I'm pissed off.
Let's take a closer look.

1. A certain company (organisation) shouts in every nook and corner how its product is superior to everything else and how evil competitors screw them unfairly and deny them wider market share.

2. A clueless customer (me) asks whether he can have this wonderful product plus a certain feature. The company's answer is firm "no" because The Balance of The Force will be tipped in a wrong way.

3. The customer complains that's this is a nonsense. The company issues a press release saying that Jose the Customer is a troll.

Now we have to find a way for this company (organisation) to increase its market share.
They have a brilliant business plan: Kill off all Jose the Clueless Customers! Only wise bearded customers will survive and the market share will soar!

Either bend over to customers' needs however stupid they are or stop moaning about evil competition.
Meanwhile I will continue to suffer with my paid copy of inferior TMPGEnc Video Mastering Works.

----
Q: How do you know if someone is a FOSSie?
A: Don't worry, they'll fucking tell you.

Re:Does it support Intel's Quick Sync? (0)

Anonymous Coward | about a year and a half ago | (#41495985)

I was going to explain in detail how stupid you're being, but it made my brain hurt just thinking about it.

Re:Does it support Intel's Quick Sync? (1)

FrangoAssado (561740) | about a year and a half ago | (#41496587)

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!

Re:Does it support Intel's Quick Sync? (0)

Anonymous Coward | about a year and a half ago | (#41496631)

Documentation? Here you go: http://software.intel.com/en-us/vcsource/tools/media-sdk

Re:Does it support Intel's Quick Sync? (-1)

Anonymous Coward | about a year and a half ago | (#41495375)

You're a dumb nigger.

Re:Does it support Intel's Quick Sync? (0)

Anonymous Coward | about a year and a half ago | (#41492423)

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)?

Intel should develop or get it developed (2)

Ilgaz (86384) | about a year and a half ago | (#41492585)

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.

Which binary is 1.0? (0)

Anonymous Coward | about a year and a half ago | (#41491319)

Which one is 1.0?

http://ffmpeg.zeranoe.com/builds/ [zeranoe.com]

Re:Which binary is 1.0? (0)

Anonymous Coward | about a year and a half ago | (#41492761)

pacman -S ffmpeg
emerge ffmpeg

Take your pick.

Re:Which binary is 1.0? (0)

Anonymous Coward | about a year and a half ago | (#41493413)

That would be git-a74f292 [videolan.org], the current compiled revision in that page at the time of writing is 5 revisions older than that.

Out of beta? (0)

ericloewe (2129490) | about a year and a half ago | (#41491407)

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.

Re:Out of beta? (4, Insightful)

BanHammor (2587175) | about a year and a half ago | (#41491761)

Well, it's not that these projects were in beta for way too long, it's just that they are being honest about it.

Re:Out of beta? (1)

ericloewe (2129490) | about a year and a half ago | (#41492177)

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!"

Re:Out of beta? (0)

Anonymous Coward | about a year and a half ago | (#41492221)

They have long not been in beta or anything. It's just that they were going by the old 1.0 is perfect and for the multimedia which is an ever moving target, that's tough to do. And at least they didn't have to drop any numbers unlike many other programs have done before. Generally most revisions are of higher quality than average gold release and it was beta only in the minds of Debian's very special maintainers that need the code bitrotten to a fine cheese-like state and of course from a numbered release - it's not Stable until there's mold growing on the upstream's previous stable release!

Re:Out of beta? (4, Interesting)

davydagger (2566757) | about a year and a half ago | (#41492297)

open source projects stay in beta as long as need be, and don't rush to ship 1.0 or major releases until ready.

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 .0 versions long before they are ready because they release cycles and deadlines.

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.

Re:Out of beta? (1)

donaldm (919619) | about a year and a half ago | (#41497985)

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.

Big thanks to the developers (5, Informative)

sl4shd0rk (755837) | about a year and a half ago | (#41491473)

For all their ardous work!

FFMpeg donations page is here:
http://ffmpeg.org/donations.html [ffmpeg.org]

Re:Big thanks to the developers (3, Funny)

equex (747231) | about a year and a half ago | (#41491699)

No PayPal option ?

Re:Big thanks to the developers (0)

Anonymous Coward | about a year and a half ago | (#41493539)

That's the one format FFMPEG doesn't support...

Re:Big thanks to the developers (0)

Anonymous Coward | about a year and a half ago | (#41495529)

No Bitcoin option either. What's a nerd to do. :(

Re:Big thanks to the developers (0)

Anonymous Coward | about a year and a half ago | (#41492149)

Ardous? Most certainly all the suing has put strain on both renmants of FFmpeg and libav that was forked off when most developers left FFmpeg. As for arduous work... shouldn't it go to libav where most of devs went?

Re:Big thanks to the developers (0)

Anonymous Coward | about a year and a half ago | (#41495997)

Most certainly all the suing has put strain on both renmants of FFmpeg and libav that was forked off when most developers left FFmpeg.

Apparently you can blame libav for that: http://www.ffmpeg.org/legal.html

Re:Big thanks to the developers (0)

Anonymous Coward | about a year and a half ago | (#41498185)

How about you listen to the other side as well? I didn't see how it started but from what I personally witnessed both sides were "Our lawyer will be contacting you soon". Blaming libav for that is a bit much especially because majority forked away only because minority owned the domain (and FFmpeg trademark?) while they only had the trademark to logo. Basically the open source version of patent war. And we all know that's just scumbags fighting other scumbags.

Re:Big thanks to the developers (0)

Anonymous Coward | about a year and a half ago | (#41505049)

No FFmpeg developer has ever hired a lawyer, only the fork has. This is of course much easier for the fork, as they control the FFmpeg foundation with all the donations given to FFmpeg before the fork...

Re:Big thanks to the developers (1)

Ilgaz (86384) | about a year and a half ago | (#41492645)

For all their ardous work!

FFMpeg donations page is here:
http://ffmpeg.org/donations.html [ffmpeg.org]

I really wonder how many software and hardware vendors which rely on it hit that donation button. Half of media apps I use and paid for has ffmpeg embedded.
Could be none.

Re:Big thanks to the developers (0)

Anonymous Coward | about a year and a half ago | (#41505059)

Could be none.

Very close to none;-(

Re:Big thanks to the developers (0)

PhrostyMcByte (589271) | about a year and a half ago | (#41495591)

The developers are at http://libav.org/ [libav.org] Well, most of them. FFmpeg had some serious project management issues, and so many of the developers forked it to create Libav a while ago. I wish them both all the progress in the world, but this just feels like a cheap way to get back many of the users they lost.

Re:Big thanks to the developers (3, Informative)

KritonK (949258) | about a year and a half ago | (#41497081)

Libav is a fork of ffmpeg, even if its developers, who are former ffmpeg develeopers, claim otherwise.

Libav proponents argue [multimedia.cx] that theirs is the better fork.

Others say [blog.pkh.me] the opposite.

Trying to decide which fork to use, I read these two accounts and concluded that both(!) were saying "stick with ffmpeg". If you are interested in the issue, read these two references and decide for yourself.

Re:Big thanks to the developers (1)

makomk (752139) | about a year and a half ago | (#41499205)

Last I heard, libav had managed to piss off a fairly large chunk of the developer base too through the really disruptive way they handled their fork.

Lots of great pro features! (4, Insightful)

Panaflex (13191) | about a year and a half ago | (#41491865)

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!

Re:Lots of great pro features! (0)

Anonymous Coward | about a year and a half ago | (#41493719)

ffmpeg could debayer redcode... until Red added encryption.

ffmpeg also lacks support for Adobe Cinema DNG which would be a useful additon. Especially since those fucking geniuses over at Adobe dropped their own open standard just as it was becoming viable (ikonoskop, Black Magic Design).

Re:Lots of great pro features! (1)

NJRoadfan (1254248) | about a year and a half ago | (#41496607)

It'll also open up long dead codecs like Microsoft Video 1 and IBM Ultimotion.

12 years to release version 1 ?? (3, Funny)

Anonymous Coward | about a year and a half ago | (#41492433)

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 !

Re:12 years to release version 1 ?? (0)

Anonymous Coward | about a year and a half ago | (#41496803)

While I get that its sarcasm, Firefox also had a head start. They released from Netscape source as Mozilla and then dropped down to Firefox and later adopted a regular release schedule that's not necessarily reflecting an actual version but a "release".

Branching in Matroska files? (2)

BLKMGK (34057) | about a year and a half ago | (#41492463)

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...

Re:Branching in Matroska files? (0)

Anonymous Coward | about a year and a half ago | (#41493781)

Why do they refuse to do it?

Because that would be awesome.

Re:Branching in Matroska files? (1)

b4dc0d3r (1268512) | about a year and a half ago | (#41495239)

It seems no patch has been adequate. Either the FFMpeg architecture cannot deal with it, or people who patch don't understand FFMpeg enough to submit a clean patch. Sample:

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-August/041721.html [mplayerhq.hu]

either implement it cleanly or
go away

They refuse to apply terrible patches. Another question is why don't they work on it themselves, to fix an obvious deficiency? I don't have an answer to that.

Re:Branching in Matroska files? (1)

BLKMGK (34057) | about a year and a half ago | (#41504493)

I had been told it wasn't being done for "security reasons" although I've yet to find that actually stated but this was relayed to me by an XBMC dev so I put some weight to it. The XBMC guys won't touch this until the ffmpeg guys do it. I note that the message you linked was from 2008 - 4 years ago! This has obviously been an issue for awhile and honestly it sucks. I understand the Anime community wants this because they like to slice off the start and endings of shows and only store them once, I want it because I like to be able to watch multiple versions of BD rips. I was working with a guy who was making tools to help build files to be played back like this, it was storing the extra pieces on the ends of the movies so the main path played fine but it's still a bit of a PITA to build them and with no player available to me I stopped doing it :-(

I'd also like to see work done to create menus for MKV files. The format is apparently able and since so far no one seems able to handle the BD menus it would be nice to have an alternative - especially if it could be used to choose playback paths! This won't be ffmpeg's job I don't think but it's sorely needed IMO.

XBMC can now sort of playback BD images, I guess at some point we'll just rip them as images unencrypted. I'd still like to compress the damn things though, BD is huge!

Re:Branching in Matroska files? (0)

Anonymous Coward | about a year and a half ago | (#41505077)

Could you point to the trac ticket where the problem is described in a reproducible way?
https://ffmpeg.org/trac/ffmpeg/report/1

YUO FAIL IT... (-1)

Anonymous Coward | about a year and a half ago | (#41492525)

BSD culminated in I 3urnt 0ut. I Of the above

Some great new features (0)

Anonymous Coward | about a year and a half ago | (#41493533)

There are some great new features in this release:

new option: -progress
Scene detection in libavfilter
concat filter
F4V muxer
faststart option in the MOV/MP4 muxer

The faststart is one I was waiting to see ages ago :) Can't wait to see the next version of Tremendum Transcoder making use of these new features! :)

VLC Relase in the works? (0)

Anonymous Coward | about a year and a half ago | (#41493809)

Anybody knows how long beforce vlc uses it?

Fabrice Bellard? (1)

funfail (970288) | about a year and a half ago | (#41493981)

How come neither the article nor the official site (ffmpeg.org) does not mention Fabrice Bellard [wikipedia.org], the original author?

Re:Fabrice Bellard? (0)

Anonymous Coward | about a year and a half ago | (#41495361)

because you didnt send a patch to include the history of the project on the website?

ffmbc (4, Informative)

illtud (115152) | about a year and a half ago | (#41494757)

If you're in broadcast, check out ffmbc [google.com] 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.

But can it make decent MP4 containers yet? (2)

wdef (1050680) | about a year and a half ago | (#41497381)

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?

Re:But can it make decent MP4 containers yet? (1)

NearO (591410) | about a year and a half ago | (#41498273)

That's actually mencoder's fault. It has problems muxing to basically anything but AVI. If you use ffmpeg directly, you can make MP4 files just fine. For mencoder, it's unlikely that the situation will change, as it is basically no longer maintained.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...