Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
15th May 2008, 04:34 | #1 | Link |
Registered User
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
|
Announcing Project Rémoulade [DivX H.264 codec]
It is with great pleasure that I can finally unveil Project Rémoulade and its first release, the DivX H.264 Decoder!
DivX H.264 Decoder Beta 1 decodes H.264 High, High 10, and High 4:2:2 profile streams including full interlace support and is multithreaded for accelerated decoding on up to 8 CPUs. Based on our own testing, we believe that it may be the fastest decoder currently available, but we'd like to get your feedback too. We're looking for people interested in testing this beta as well as future releases from the project. We're starting out with a closed group with limited capacity and over the coming hours/days we'll be sending out invitations to participate. Although I plan to contact a number of the forum members here at Doom9 with invitations you will need a free account at DivX Labs in order to join the Project Rémoulade group. If you don't get an invitation in the next 24 hours (please be patient) and you would like to participate it's important that you follow the instructions at the bottom of the Beta 1 article (i.e. create a DivX Labs account and send me a PM via DivX Labs with your details). Note that I will also reply to PM's through Doom9 but without your DivX Labs user name it's impossible to add you to the group.
__________________
DivX Plus Web Player 2.0 (MKV & AVI) (Embed generator) DivX H.264 Decoder with DXVA support Developer portal Last edited by Guest; 16th May 2008 at 05:20. Reason: fix title typo |
15th May 2008, 04:40 | #2 | Link | ||
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Quote:
|
||
15th May 2008, 04:58 | #3 | Link |
Registered User
Join Date: Apr 2005
Location: San Diego, CA
Posts: 90
|
Well, it's strange to have to think about it, but does this thread need to moved over to the H.264/AVC forum?
Big kudos to Al for getting everything in shape to share. We do really look forward to your feedback, good and bad, as we recognize this is just the first step in what is sure to be a long process, to get to where we want DivX H.264 ultimately to be. We surely know we're stepping into a crowded area, but our goal is to create technologies and tools that benefit everybody in the community. Hopefully we won't make too many mistakes along the way, but I'm very confident you all will let us know when we do! If anybody has any questions don't hesitate to contact DigitAl56k or myself, or come to DivX Labs and let us know directly. |
15th May 2008, 05:02 | #4 | Link |
komisch
Join Date: Aug 2006
Posts: 3
|
making ask to invite easier
tomorrow we will add an email alias for the project to make it easier for people sign up.
It will be projectremoulade at divx dot com. That way I don't have to keep reading Al's PMs :P and we can all add users to the project. |
15th May 2008, 05:11 | #5 | Link | |
DivX Connected Freak
Join Date: Jan 2008
Posts: 18
|
Quote:
Btw, anyone hungry for a screenshot atleast, check here: http://connunity.com/forum/viewtopic.php?t=157 |
|
15th May 2008, 05:32 | #6 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
I notice you intentionally didn't use VBV or AQ in your x264 test encode...
Quote:
|
|
15th May 2008, 05:49 | #7 | Link |
Registered User
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
|
We didn't intentionally not use them, we just needed to create a couple of test clips specifically for the beta (rather than re-use the clips we run during development), and I didn't set those options.
We added you to the Project Rémoulade group, and you should have access to the Beta 1 download from the group homepage. Please test the decoder for yourself and let us know how you get on, the more feedback the better Note that the last chart on our page is specifically around scalability, and was run on an 8-core box, but CoreAVC only supports 4 threads (shown on the chart). I will edit the labs article now to make that clearer. If you want to compare how the DivX decoder scales with multi-threading look at the single vs dual core charts above. Again, you can also run your own tests!
__________________
DivX Plus Web Player 2.0 (MKV & AVI) (Embed generator) DivX H.264 Decoder with DXVA support Developer portal Last edited by DigitAl56K; 15th May 2008 at 05:51. |
15th May 2008, 05:50 | #8 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Thanks, I'll grab a copy! |
|
15th May 2008, 05:56 | #11 | Link |
DivX Connected Freak
Join Date: Jan 2008
Posts: 18
|
^ Hehe, you're only human, everybody forgets... :P
I'm not too good with these encoding terms, so is there a chance that aq is going to alter the results in a big way? Last edited by KEROLiUKAS; 15th May 2008 at 05:58. Reason: typo |
15th May 2008, 05:58 | #12 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
This is actually quite impressive.
I tested it on my ultimate torture clip: A 2160p (!!) 50fps 100 mbps video. On a Core 2 Duo 2Ghz T7200: DivX FPS: 8.7 CoreAVC FPS: N/A, it crapped out when I tried to TimeCodec it. FFDshow-Tryouts rev1355 FPS: 3.7 I'm also getting steady 60-75% CPU usage for decoding 10 megabit 1080p "300". Quite nice. My next step will be to throw absolutely bizarre H.264 streams at it until it breaks. Doubtful.
__________________
Follow x264 development progress | akupenguin quotes | x264 git status ffmpeg and x264-related consulting/coding contracts | Doom10 Last edited by Dark Shikari; 15th May 2008 at 06:02. |
15th May 2008, 06:02 | #13 | Link | |
DivX Connected Freak
Join Date: Jan 2008
Posts: 18
|
Quote:
I'm going to sleep now, you have fun playing with your codec, hehe. Regards, Karolis. |
|
15th May 2008, 06:16 | #14 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Ugh... first bit of dissatisfaction.
DivX's decoder incorrectly ignores the header bit that states "qp0 should be interpreted as lossless." Unfortunately, this means that despite the DivX decoder's incredibly fast CABAC decoding it is completely useless for dealing with lossless content. Both CoreAVC and FFDshow can handle the lossless content correctly. I would hope this would not have been ignored given the implementation of such relatively obscure features like High 10 and 4:2:2, which are much more difficult to implement than lossless, which literally consists of a couple dozen lines of code in order to bypass iDCT/dequant (basically trivial).
__________________
Follow x264 development progress | akupenguin quotes | x264 git status ffmpeg and x264-related consulting/coding contracts | Doom10 Last edited by Dark Shikari; 15th May 2008 at 06:23. |
15th May 2008, 06:26 | #15 | Link | |
Registered User
Join Date: Nov 2002
Location: San Diego, CA
Posts: 936
|
Quote:
Please keep in mind when you're testing that this is beta 1, whereas the other decoders you've been using have been available publicly for quite some time - i.e. we do expect some issues to come up. We'll nail as many as possible as quickly as possible and get beta 2 up for you guys. |
|
15th May 2008, 06:38 | #16 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
One general note about lossless: the original lossless profile specified has been removed from the H.264 standard (but everyone still uses it). In its place, they added a new one which uses a limited form of pixel prediction, making it slightly better (but not nearly as good as if it used a good prediction method, like paeth/median). As far as I can tell, nobody supports this yet, so it isn't particularly important to implement it. Now, the question comes up: how do you tell the difference between these two lossless profiles? The answer is the profile ID--encoders should correctly write the ID, so if you want to include support for both lossless modes, you can check the profile ID to check which one should be used. |
|
15th May 2008, 06:57 | #17 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Hmm, it appears there's still a lot of room for improvement here. As far as I can tell, DivX's decoder contains no SSE3, no SSSE3, and no SSE4
SSSE3 is useful for palignr (luma MC) and pmaddubsw (chroma MC), for example. There's also some general serious fail in the code, such as emms being put after some assembly functions, which wastes clocks since floating point code is never or almost never used in a decoder (emms should be put before float functions, not after asm functions). There's also the fact that I'm seeing the frame pointer being used, in other words the code was compiled without -fomit-frame-pointer or its <insert compiler name here> equivalent. I also get the feeling from reading some extremely bad assembly in here that this was built using an autovectorizing compiler of some sort. For example, an 8x7 VSAD (for adaptive deinterlacing, I assume) that keeps its sum in a GPR and repeatedly adds to it from MMX registers (WTF?!). That must be slowing down the function by at least a factor of 3 or 4.
__________________
Follow x264 development progress | akupenguin quotes | x264 git status ffmpeg and x264-related consulting/coding contracts | Doom10 Last edited by Dark Shikari; 15th May 2008 at 07:26. |
Tags |
coreavc, divx, h264 decoder, remoulade |
|
|