Announcing Project Rémoulade [DivX H.264 codec]

[x264lover]

Sorry, didn't mean to interrupt but... will we able to encode into DivX h.264 with your tools or is it just a h264 decoder? And will DivX support other audio codecs such FLAC, AAC?

I know it's off-topic but I gotta ask it.

See you.

[Sophocles]

x264lover

One of my hopes as well, although we can already do that with other *.264 flavors. My hope is that it will also be followed by a DiVx certified player that will permit burning an HD backup to a standard dual layered disc with 720P/1080P.:devil:

[x264lover]

Yeah!

It would be great.
I love x264, I mean watching videos and all with this codec but I don't know how to use it properly.

[Sophocles]

I love x264, I mean watching videos and all with this codec but I don't know how to use it properly.


You will get the hang of it with a little time and practice. If you want to start encoding your own movies there are some decent easier to use applications that will simplify things a bit such as FairUse Wizard.

[DigitAl56K]

x264lover

One of my hopes as well, although we can already do that with other *.264 flavors. My hope is that it will also be followed by a DiVx certified player that will permit burning an HD backup to a standard dual layered disc with 720P/1080P.:devil:

I'll be starting another thread on that in a little while ;)

[the_corona]

I'll be starting another thread on that in a little while ;)

Can you give us any news on the decoder? Is a Beta 3 coming soon? Can we expect further speed improvement or is work focused on bug-fixes/compatibility from now on?

:thanks:

[sparky]

Beta 3 is coming. Current target is early next week. You'll see some further speed improvements. We're mostly targeting AMD's and older systems, but you'll see some gains on a P4 as well. We're also fixing bugs as we become aware of them. Beta 3 will take care of DVBViewer issues and fix a number of reported crashes.

[Shinigami-Sama]

well I just got xp64 running on my laptop
xp32 coming soon
looking forward to doing some tests now that all my machines are running

[iwod]

I'll be starting another thread on that in a little while ;)

How long is a little while :devil::devil:

[DigitAl56K]

How long is a little while :devil::devil:

I prefer to avoid giving dates because we don't want to set your expectations too early - the next beta will be released when we're happy with it. It's possible that you might see something this week :)

[Ajax_Undone]

@ DigitAl56K wondering if you guys there at Divx are going to be releasing Divx 7 with A CLI Codec... It would be Very beneficial if you did for avs apps...

[DigitAl56K]

Yes, there will be a CLI encoder available and it will accept avs input.

[Sophocles]

Yes, there will be a CLI encoder available and it will accept avs input.

I'm interested, when can we know more?

[Ajax_Undone]

Thank you very very much

[DigitAl56K]

Sophocles,

It's currently in its early stages, and again I don't like committing to dates before I'm reasonably confident in them, but a "baseline" will first be released through Project Rémoulade at DivX Labs and we'll then be looking for feedback on the kind of features and adaptations you would most like to see in order to fulfill your needs and to make it suitable for becoming an option in some of the GUI front-ends that are developed by Doom9 members.

[Sophocles]

Good enough, thanks for the reply. There seems a lot to look forward too.;)

[Ranguvar]

Yes, there will be a CLI encoder available and it will accept avs input.
Keep the good news coming :D

Can I ask a question, though? As Dark Shikari said before, why doesn't DivX simply make an x264 GUI? I'm sure there's a reason, but I'm not business-minded enough to see it :)

[Dark Shikari]

Keep the good news coming :D

Can I ask a question, though? As Dark Shikari said before, why doesn't DivX simply make an x264 GUI? I'm sure there's a reason, but I'm not business-minded enough to see it :)Probably because they spent a lot of money buying Mainconcept and now have to justify that purchase somehow ;) </cynic>

[DigitAl56K]

Well, there are many reasons. Here are a few off the top of my head: x264 is GPL'd, so what happens when we want to license an encoder library to a commercial partner so that their software can output DivX files? What do we do if we want to add some algorithm enhancement to an encoder without necessarily divulging the source? How can we provide an encoder to CE manufacturers and others that absolutely must comply to all of the profile specifications that we develop when such strict compliance is not necessarily the goal of x264? If we want to distribute an encoder to end users we can also be held accountable for all of the intellectual property it contains, so we have to be able to be accountable for and thus to control the source - something that isn't possible with x264.

I could go on, but these are just a few reasons why we might need to have our own encoder even though we recognize that x264 itself is also very good encoder.

HTH

Probably because they spent a lot of money buying Mainconcept and now have to justify that purchase somehow ;) </cynic>

If only the accounting team were busy justifying expenditures of that size! Then it would be easier for me to slip some new hardware into our budget! ;)

[Dark Shikari]

Well, there are many reasons. Here are a few off the top of my head: x264 is GPL'd, so what happens when we want to license an encoder library to a commercial partner so that their software can output DivX files?You do what my company does--separate binary. It adds nearly no overhead and is trivial--and better yet it lets you use other GPL'd libraries in the process too.
What do we do if we want to add some algorithm enhancement to an encoder without necessarily divulging the source?You stop being so secretive, especially considering rule 1 of video encoding: any sufficiently useful algorithm can and will be reverse-engineered, made better, and implemented in a competitor's product. ;)How can we provide an encoder to CE manufacturers and others that absolutely must comply to all of the profile specifications that we develop when such strict compliance is not necessarily the goal of x264?x264 is strictly compliant. Even if it wasn't, you could fix that, and such a thing would be far easier than developing a (worse) competitor.If we want to distribute an encoder to end users we can also be held accountable for all of the intellectual property it contains, so we have to be able to be accountable for and thus to control the source - something that isn't possible with x264.If you think making your own encoder makes you immune to MPEG-LA fees, you are sorely mistaken; the MPEG-LA does not make any distinction between GPL'd and non-GPL'd encoders when dealing with license fees.

I do understand the real reason though: NIH syndrome (http://en.wikipedia.org/wiki/Not_Invented_Here). Its very hard to convince a company to avoid re-inventing the wheel.

I welcome yet another competitor though; the more encoders there are in the marketplace, the better x264 looks by comparison.

[DigitAl56K]

Well, as I've said, there are many reasons and those are just a few. Perhaps it does not help to list them all and do a play-by-play analysis, so I'm not going to dissect your reply. The fact is that there will be a DivX encoder.

NIH Syndrome = funny ;)

[Sophocles]

Probably because they spent a lot of money buying Mainconcept

Which just confuses the issue for some of us since DiVx now owns Mainconcept which has an H.264 encoder, and which already has a simple graphical user interface? What's to prevent DiVx from adapting Mainconcept's encoder to suit DiVx' needs?

[Shinigami-Sama]

Which just confuses the issue for some of us since DiVx now owns Mainconcept which has an H.264 encoder, and which already has a simple graphical user interface? What's to prevent DiVx from adapting Mainconcept's encoder to suit DiVx' needs?

purchase agreements
bad code?
lazy coders on that project?
broke after that purchase?
ect
ect
ect

[Dark Shikari]

Which just confuses the issue for some of us since DiVx now owns Mainconcept which has an H.264 encoder, and which already has a simple graphical user interface? What's to prevent DiVx from adapting Mainconcept's encoder to suit DiVx' needs?How do you know that isn't what they're doing? :devil:

[cyberbeing]

I welcome yet another competitor though; the more encoders there are in the marketplace, the better x264 looks by comparison.
Which just confuses the issue for some of us since DiVx now owns Mainconcept which has an H.264 encoder, and which already has a simple graphical user interface? What's to prevent DiVx from adapting Mainconcept's encoder to suit DiVx' needs?
How do you know that isn't what they're doing? :devil:
I never really considered Mainconcept's H264 to be a poor encoder (isn't it the best of the commercial encoders???). In MSU's comparison tests it was neck and neck with x264 and in some cases better. I know x264 has made a lot of improvements since then but you never know, after some improvements of their own and a written-from-scratch Divx H264 encoder based on Mainconcept H264 IP, it may actually end up equal to or better than x264 :eek:.

If they really do succeed with making a decoder all around faster than CoreAVC then I give them a 50% chance of making an encoder that is all around better than x264 ;).

If they don't succeed with making a decoder all around faster than CoreAVC then I give them a 10% chance :devil:.

[DigitAl56K]

Guys, let's not turn this into a deathmatch before we've even released anything! I can understand that Dark Shikari is proud of x264. At the same time (and looking across threads) there is no need to suggest that because x264 exists nobody else should make an encoder or that one product must perfectly fit the needs of everybody. What's wrong with having two choices and the freedom to pick whichever you like, knowing that either can get the job done well?

With regard to MainConcept and DivX: over time knowledge will be shared, people from either team will contribute their expertise to each others work and hopefully the products that are produced become stronger as a result. At some point although there are two businesses and each may offer different products and services we should consider that they're not necessarily entirely separate. For example, anyone who has installed the DivX H.264 Decoder beta is already running code that brings together work from both teams.

Back to the encoder: If you have joined Project Rémoulade you'll have access to it as soon as it becomes available. Before then this discussion is likely to turn into a lot of speculation ;)

[Dark Shikari]

I never really considered Mainconcept's H264 to be a poor encoder (isn't it the best of the commercial encoders???). In MSU's comparison tests it was neck and neck with x264 and in some cases better.Unfortunately for Mainconcept, in the real world, PSNR doesn't actually ensure good visual quality. (http://mirror05.x264.nl/Dark/x264vsElecard/) :p (Note "Elecard" uses the Mainconcept SDK here). No psy RDO was used in that test either (didn't exist at the time). I've done more tests on other clips since then and Mainconcept pretty much sucks visually. Its a complete blurry mess that throws away detail at every chance it gets. It does have some advantages over x264--more aggressive B-frame decision and hierarchical motion estimation--but this isn't enough to compensate for its weaknesses IMO.

The MSU tests are honestly quite awful; just look back to their Xvid vs DivX comparisons where they turned on the deblocking on one product but not on the other and then went on for quite some time about how the one with the deblocker looked better.

If you are looking for a good encoder that can compete with x264, you might want to look more towards the professional arena, where you can find such industry leaders as Ateme and Scientific Atlanta. Of course, as companies that primarily produce hardware encoders, they have their own advantages and disadvantages with regard to quality.

Anyways, on the issue of DivX, I agree with Digital56k here; this is getting silly given that none of us have actually seen the encoder yet ;)

[stax76]

A cmdl encoder and mkv is what the people want, that was quite obvious. From my view a cmdl encoder means I have to build and maintain a GUI and every other frontend has to build and maintain GUI. Every guide and tutorial can only target a certain frontend. While it might be fun for some frontend authors to code codec relatated features like a codec GUI, for me it's not. Different frontends would only provide different subsets of available options, different bugs, poor documentation, does DivX really wants such a mess? I have a proposal how to achieve a unified GUI, if nobody else like DivX will build it, then I might do. It's not hard at all, all you need is a portable executable build with a tool like QT, wxWidgets, Lazarus etc., you have to pass the settings to the app using a simple file and after the app is closed read the settings back, thats it, every kid can program something like that. To make it realy easy for frontend authors the file would just contain the command line, this way the frontend wouldn't even have to build the command line. A frontend author might be able to add complete DivX support to his application in less than an hour.

[Sergey A. Sablin]

It does have some advantages over x264--more aggressive B-frame decision and hierarchical motion estimation--but this isn't enough to compensate for its weaknesses IMO.

hierarchical motion estimation? where do you take all these? :D

[Dark Shikari]

hierarchical motion estimation? where do you take all these? :DI'm making a fair assumption that Mainconcept uses pyramidal motion search unless the documentation is wrong and "motion search range" is actually "motion vector range". Feel free to correct me, of course.

No sane algorithm except pyramidal/hierarchical allows search ranges such as "64", "128", "256", "512", etc.

Of course, the documentation could just be wrong (not unlikely, given that one part of it stated that the non-SATD MB comparison metric was Median Absolute Difference rather than what it actually is, Mean Absolute Difference). Can't blame everyone for bad English :p

It'd probably be pretty easy to test whether its pyramidal or not; create a contrived situation where an object moves 200 pixels across the screen with no warning and see if the motion search catches it.

[Sergey A. Sablin]

I'm making a fair assumption that Mainconcept uses pyramidal motion search unless the documentation is wrong and "motion search range" is actually "motion vector range". Feel free to correct me, of course.

No sane algorithm except pyramidal/hierarchical allows search ranges such as "64", "128", "256", "512", etc.

nobody actually cares about real algorithm search range at any particular point, while everybody cares about the distance from (0,0), ie real movement, which can be caught by algorithm.

Of course, the documentation could just be wrong (not unlikely, given that one part of it stated that the non-SATD MB comparison metric was Median Absolute Difference rather than what it actually is, Mean Absolute Difference). Can't blame everyone for bad English :p
after this you simply can't, cause it is Sum of Absolute Differences. ;)

[Dark Shikari]

after this you simply can't, cause it is Sum of Absolute Differences. ;)Mean Absolute Difference is a bad, but often-used name in technical papers for SAD. They mean the same thing of course. Blame Elecard for using it in their docs/interface for the Mainconcept SDK encoder.

[Manao]

No sane algorithm except pyramidal/hierarchical allows search ranges such as "64", "128", "256", "512", etc.A logarithmic search could (see http://forum.doom9.org/showthread.php?p=1152700#post1152700).
any sufficiently useful algorithm can and will be reverse-engineered, made better, and implemented in a competitor's product.I disagree. Trellis quantization can't be RE'd just looking at the encoded file. So are motion estimation, bframe decision, scene cut decision, and most high level algorithms.

[Dark Shikari]

A logarithmic search could (see http://forum.doom9.org/showthread.php?p=1152700#post1152700).The odds of a really really long range logarithmic search being lucky enough to get a good candidate when checking at 256-pixel range is absurdly low, to the point where its basically useless; in fact I would suspect false positives would make it worse than a shorter range search. That's why UMH checks so many locations; a diamond search at range 256 is totally useless. A pyramidal search, however, does allow you to do such long-range checks effectively.
I disagree. Trellis quantization can't be RE'd just looking at the encoded file. So are motion estimation, bframe decision, scene cut decision, and most high level algorithms.True. Some of them can be reverse-engineered code-wise, of course. If something is truly new both theoretically and practically, its highly doubtful it would be reverse-engineered simply because one would have nothing to go on in doing so.

[Ajax_Undone]

@ Stax

I think Divx should hold a competition for the best GUI front end app for there CLI Codec... When released of course...;)

[sparky]

You stop being so secretive, especially considering rule 1 of video encoding: any sufficiently useful algorithm can and will be reverse-engineered, made better, and implemented in a competitor's product.

It does not seem to work that way with video decoding. CoreAVC has been out with essentially no performance improvements for close to 2 years and yet no one has been able to release a superior competing project via reverse engineering.

If you think making your own encoder makes you immune to MPEG-LA fees, you are sorely mistaken; the MPEG-LA does not make any distinction between GPL'd and non-GPL'd encoders when
dealing with license fees.

One of the basic principles of a successful company: ensuring freedom to operate. If you're going to release a project, make sure it does not infringe any patents. It's much easier to do that with a clean-room implementation than with an open-source project that was written by unknown developers implementing algorithms of unknown origin. Can you be sure that, in all the years of development of x264, no one has slipped any patented motion search or scene detection algorithms into it? Or even filed a patent application for an algorithm before committing the code into your repository? We certainly can't, either. The difference between you and DivX is, if something like that comes up, no one will bother going after poor x264 folks, they will sue any companies using x264's source. If we were to use your project, either by redistributing the source or simply by referring users to you, we'd potentially be risking losing huge amounts of money on litigation.

Not sure if that falls under "NIH syndrome".

(Disclaimer: I am not a lawyer, all my interpretations of patent law are nothing but my personal conjectures, and I'm not making any statements, either explicit or implied, about any projects we ever used, do use at the present time, or might use at any time in the future - open-source or otherwise, and this whole discussion is purely theoretical)

You stop being so secretive, especially considering rule 1 of video encoding: any sufficiently useful algorithm can and will be reverse-engineered, made better, and implemented in a competitor's product.

Usefulness is not limited to algorithms.

A while ago I needed to do a test comparing, among other things, x.264 and DivX MPEG-4 encoder. Obviously, x.264 beat DivX in terms of overall PSNR. Less obviously, x.264 beat DivX in terms of PSNR at fixed encoding frame rate. One area where DivX was far superior was maximum encoding speed. With a 640x352 source, DivX exceeded 200 fps in two fastest modes, and the fastest combination of features I could find for x.264 could only reach ~42 fps (albeit with higher PSNR). My conclusion was that x.264 was never targeted at high-speed encoding.

Suppose that we come out with an encoder that can do reasonable-quality H.264 at the maximum speed that is five times what x.264 can achieve. (equivalently, an encoder that can encode in real time in 5 times the resolution) Can you match this result? Sure. Will reverse engineering help you achieve that goal? Not much - mostly you'll just have to optimize your existing code.

[Dark Shikari]

It does not seem to work that way with video decoding. CoreAVC has been out with essentially no performance improvements for close to 2 years and yet no one has been able to release a superior competing project via reverse engineering.CoreAVC is primarily faster because of things that are not something that one would keep "secret"; efficient code structure which could be done by any good coder if they really really put a lot of effort into it. Their assembly was quite good--and has already all been reverse-engineered by various people. The main issue is that there's nobody who is willing to work full-time on, say, ffmpeg, for the purpose of making it faster than CoreAVC. The amount of work involved would be very large.

If I had to give a single big reason CoreAVC is fast, its because of the SSE2 deblocking, which exists in x264 but hasn't been ported to ffmpeg.One of the basic principles of a successful company: ensuring freedom to operate. If you're going to release a project, make sure it does not infringe any patents. It's much easier to do that with a clean-room implementation than with an open-source project that was written by unknown developers implementing algorithms of unknown origin. Can you be sure that, in all the years of development of x264, no one has slipped any patented motion search or scene detection algorithms into it? Or even filed a patent application for an algorithm before committing the code into your repository? We certainly can't, either. The difference between you and DivX is, if something like that comes up, no one will bother going after poor x264 folks, they will sue any companies using x264's source. If we were to use your project, either by redistributing the source or simply by referring users to you, we'd potentially be risking losing huge amounts of money on litigation.

Not sure if that falls under "NIH syndrome".

(Disclaimer: I am not a lawyer, all my interpretations of patent law are nothing but my personal conjectures, and I'm not making any statements, either explicit or implied, about any projects we ever used, do use at the present time, or might use at any time in the future - open-source or otherwise, and this whole discussion is purely theoretical)It is physically impossible to implement an H.264 encoder without violating thousands of patents. This is why the MPEG-LA exists and charges licensing fees.

A while ago I needed to do a test comparing, among other things, x.264 and DivX MPEG-4 encoder. Obviously, x.264 beat DivX in terms of overall PSNR. Less obviously, x.264 beat DivX in terms of PSNR at fixed encoding frame rate. One area where DivX was far superior was maximum encoding speed. With a 640x352 source, DivX exceeded 200 fps in two fastest modes, and the fastest combination of features I could find for x.264 could only reach ~42 fps (albeit with higher PSNR). My conclusion was that x.264 was never targeted at high-speed encoding.Not really a good test, because you're comparing between two totally different video standards, one of which is inherently a lot more complex. x264 also probably didn't have modes that were as fast as DivX's. Of course, now, things have changed; x264 is now faster on fastest settings than Xvid is on fastest settings. I haven't tested DivX, but I've never heard about DivX being particularly faster than Xvid (in singlethreaded mode at least, which is what I was testing).Suppose that we come out with an encoder that can do reasonable-quality H.264 at the maximum speed that is five times what x.264 can achieve. (equivalently, an encoder that can encode in real time in 5 times the resolution) Can you match this result? Sure. Will reverse engineering help you achieve that goal? Not much - mostly you'll just have to optimize your existing code.There is a certain amount of inherent overhead in encoding--things that you have to do in order to perform the encoding process. It will be quite obvious from the output stream which parts of the encoding such a "fast encoder" chose to ignore, since at that kind of speed you're not even going to be considering any complex algorithms and most "speed-related" decisions will be partition related or intra prediction mode related. I might not be able to tell the difference between an encoder using "subme 1" or "subme 3", but if an encoder comes up with a "subme 0" it will likely be quite clear what shortcut was taken.

Just glancing at x264's profile now, here's some "non-subtle" things you could do to make an encoder faster than x264 when using absolute fastest Baseline Profile settings:

1) Use fewer predictors for the motion search (saves ~1%)
2) Drop the qpel motion search entirely (saves ~5%)
3) Don't analyse intra blocks at all in inter frames (saves ~2%)

Note that since some of these reduce quality at a given bitrate dramatically, to compensate one will have to use higher bitrate--which slows down the entropy encoding.

[sparky]

It is physically impossible to implement an H.264 encoder without violating thousands of patents. This is why the MPEG-LA exists and charges licensing fees.

You're missing the point. First there's a group of well known patents that belongs to members of MPEG-LA and they have to be implemented by anyone who implements an H.264 encoder or decoder. We'd pay license fees for that and we'd be covered. The problem really is that there may be other _unknown_ patents outside the standard patent pool covering parts of x.264. Theoretically, someone could even file a patent application for a certain motion search algorithm, slip that algorithm into x.264 as "subme=5", wait for a successful company to come up, and then go after them in court for patent infringement, with the intention of cashing in.

Not really a good test, because you're comparing between two totally different video standards, one of which is inherently a lot more complex. x264 also probably didn't have modes that were as fast as DivX's. Of course, now, things have changed; x264 is now faster on fastest settings than Xvid is on fastest settings. I haven't tested DivX, but I've never heard about DivX being particularly faster than Xvid (in singlethreaded mode at least, which is what I was testing).

My tests were done about a year ago. I also haven't heard about XviD being particularly faster than DivX in fast modes. I could rerun some tests if you suggest fast settings for x.264.

It will be quite obvious from the output stream which parts of the encoding such a "fast encoder" chose to ignore, since at that kind of speed you're not even going to be considering any complex algorithms

You could have two encoders implementing *exactly* the same algorithms and yet you'd have massive differences in performance. Decoder operation is fully specified in standard, but speeds of different decoders can be vastly different. Just compare JM vs. ffmpeg vs. CoreAVC. Even if you rip all the assembly out of CoreAVC and stick it into JM (theoretically speaking) JM would still be a lot slower.

[Guest]

Guys, this is OT for this thread. Please take it to PM ir start a new thread. Thank you.

[sparky]

Guys, this is OT for this thread. Please take it to PM ir start a new thread. Thank you.

We're discussing a future command-line H.264 encoder that's part of Project Remoulade, how's that off-topic?

[Guest]

@sparky

You're discussing patents, etc. Take it elsewhere and don't argue about it here in this thread. Send me a PM if you have any objection.

This thread is DivX's thread about their Project Remoulade. Don't hijack it for other purposes.

[Shinigami-Sama]

I have to agree with sparky Don
patents relate to the encoder so I fail to see how its off topic
these posts on the other hand complaining about it...

[Guest]

I clearly instructed you guys to send me a PM if you want to discuss it and you have wilfully ignored my instructions. So you are struck for rule 16. Again, do not pollute this thread with off-topic argumentation.

[mdoubledragon]

Is this thread still active? Are we still going to see announcements of next releases of Divx AVC decoder here? There has been no activity since two weeks now.

[cyberbeing]

I'm assuming the long delay means that the Beta 3 decoder and the first Beta of the AVC encoder will be released at the same time.
Either that or sparky (Divx Team) has just decided to keep Beta 3 for himself because he is now feeling unloved at Doom9 after the Divx h264 encoder (incl. patent) discussion get shut down by neuron2. :devil:

[DigitAl56K]

We're trying to make sure that Beta 3 will work nicely with a handful of DVB apps and this has taken some time because we need to support more splitters, improve format negotiations, provide better error resilience and so forth. We don't require the betas to be perfect but we are aiming for a certain standard of quality before we release.

Sorry for the delay, I'm really hoping we'll get this out in the very near future and that it will be worth the wait.

[Dark Shikari]

Good news: DivX supports PCM macroblocks correctly in both CABAC and CAVLC, as far as all my tests show; Elecard Streameye doesn't, Carbon Coder doesn't, and ffmpeg didn't (until Michael and I fixed the bugs, that is--latest revision is fine).

Only other decoders I've tested that support them correctly are CoreAVC and JM.

[cyberbeing]

DigitAl56K, were you able to get the performance increases you were expecting (+10-15%?) out of AMD cpus in order to put it in line performance wise with CoreAVC?

[mdoubledragon]

Also, please inform us if the AVC decoder is going to make it to Linux or are we again going to be left out in cold? If CoreAVC was released for Linux, I am sure people would be willing to pay for it. Divx AVC decoder can exploit this market segment to gain its due share rapidly, but that is if you guys let it.

[sparky]

Also, please inform us if the AVC decoder is going to make it to Linux or are we again going to be left out in cold? If CoreAVC was released for Linux, I am sure people would be willing to pay for it. Divx AVC decoder can exploit this market segment to gain its due share rapidly, but that is if you guys let it.

Our AVC decoder already works on Linux, but there are other issues involved besides just making it work. We can't release the source, so it would have to be binary-only, compiled for specific x86 Linux distros. Our internal API is not compatible with existing apps. The low-maintenance option would be to release it and forget it, but I don't think it would be used much. Alternatively, we'd have to work on adding a mplayer/libavcodec-compatible API wrapper, work with open-source developers to integrate it into existing apps, that detracts time from core development, and the question remains how open those developers would be to helping us.

We will look into available options. At this time I think that an eventual release of an AVC decoder for Linux in some form is likely but not a sure thing.