View Full Version : Announcing Project Rémoulade [DivX H.264 codec]
Inventive Software
19th May 2008, 16:17
DigitAl56k or SeaBass or myself. What account name did you use?
I sent a PM to DigitAl56k, and I got a response, so I think my ISP's being a bit screwy of late. :)
I've downloaded it, and ran it on a couple test files, so far it seems noticably slower than ffdshow_tryouts. I'm getting timecodec and I'll give some numbers in a bit.
EDIT: 3 hours later, some concrete numbers with ffdshow and DivX. ffdshow wins out this time.
DivX H.264 Decoder
User: 3746s, kernel: 2s, total: 3749s, real: 3824s, fps: 20.1, dfps: 19.7
ffdshow_tryouts rev 1960
User: 3311s, kernel: 2s, total: 3314s, real: 3390s, fps: 22.7, dfps: 22.2
Post-processing was disabled on ffdshow. Single core, Celeron 800 MHz, 128 KB cache, Coppermine P3 based.
I have a copy of CoreAVC I obtained a while back, I'll install and try that and see how it performs.
Ajax_Undone
19th May 2008, 20:52
All of my x.264 HD files encoded with RipBot's 4.0 1080P profile playback at any where from 8.7 FPS to 23.4 FPS Dont know whats up but I get the full 30 FPS with Core... All tested with MPC...
Quad Core Phenom 9500 4 GB 800mhz of ram 32 Bit Windows Vista Ultimate...
KEROLiUKAS
19th May 2008, 22:29
KEROLIUKAS : you forgot to disable the postprocessing in ffdshow ? Or do you have a quad core ?
Ahhh, probably, i knew it couldn't be this good. I was running default settings on both.
AMD 4200+ x2 AM2
I'll update my results later without post proccesing, and hopefully some CoreAVC results.
Actually, it turns out post proccesing was off.
DigitAl56K
19th May 2008, 23:45
Hey guys, we're working on a new build that should perform better on AMD processors.
I'll also contact a few of you later via PM with upload locations for sample clips. I went through PM's at Labs earlier so if you sent us a request check your PM's and e-mail.
Regarding the drawing issue on the nVidia 8800GTX, I have the same model here at my desk with an identical problem. We looked into it for an entire day. I'm asking around for a contact at nVidia so that we can help them reproduce the effect.
Stay tuned :)
KEROLiUKAS
20th May 2008, 00:09
Hey guys, we're working on a new build that should perform better on AMD processors.
I'll also contact a few of you later via PM with upload locations for sample clips. I went through PM's at Labs earlier so if you sent us a request check your PM's and e-mail.
Regarding the drawing issue on the nVidia 8800GTX, I have the same model here at my desk with an identical problem. We looked into it for an entire day. I'm asking around for a contact at nVidia so that we can help them reproduce the effect.
Stay tuned :)
Any ETA on the next build? I'm running an AMD CPU, so I'm excited.
DigitAl56K
20th May 2008, 00:42
Should be real soon KEROLiUKAS, we're just cleaning up a few loose ends.
I also wanted to add a reply on Linux since several people have asked. We actually have a linux build of the decoder but as you can imagine there is a lot of work still to be done on our Windows tool set and these will be the first products to be released. As for a Linux version, if you're interested please start a new thread because here we intend to focus on our current beta. Also note that we can't commit to a timeline for a Linux version, but understanding your intentions around a linux decoder from DivX may help us to prioritize it.
KEROLiUKAS
20th May 2008, 00:45
Should be real soon KEROLiUKAS, we're just cleaning up a few loose ends.
I also wanted to add a reply on Linux since several people have asked. We actually have a linux build of the decoder but as you can imagine there is a lot of work still to be done on our Windows tool set and these will be the first products to be released. As for a Linux version, if you're interested please start a new thread because here we intend to focus on our current beta. Also note that we can't commit to a timeline for a Linux version, but understanding your intentions around a linux decoder from DivX may help us to prioritize it.
All right, thanks for the info, i'll be checking LABS later tonight hoping for somehting...
DigitAl56K
20th May 2008, 00:54
We'll send out an e-mail to the group when it's ready :)
Beastie Boy
20th May 2008, 08:55
I also wanted to add a reply on Linux since several people have asked. We actually have a linux build of the decoder but as you can imagine there is a lot of work still to be done on our Windows tool set and these will be the first products to be released. As for a Linux version, if you're interested please start a new thread because here we intend to focus on our current beta. Also note that we can't commit to a timeline for a Linux version, but understanding your intentions around a linux decoder from DivX may help us to prioritize it.
:thanks:
Manao
20th May 2008, 09:10
KEROLiUKAS : what version of FFDShow are you running ? I don't doubt that DivX is faster than FFDshow on your dual core, but it shouldn't be more than twice faster (see cyberdeing timings, on a relatively equivalent CPU : http://forum.doom9.org/showthread.php?p=1139209#post1139209), so that may be explained by a very old version of FFDShow.
MarcioAB
20th May 2008, 12:29
Any plans to support or collaborate with hardware acceleration ( Windows DXVA ).
It works well with MPC-HomeCinema DXVA-enabled internal decoder, but it does not work directly on GraphEdit with "Use Clock" turned off so, can not compare.
clsid
20th May 2008, 12:30
Yes, ffdshow has become significantly faster in the past months.
CiNcH
20th May 2008, 12:46
It works well with MPC-HomeCinema DXVA-enabled internal decoder, but it does not work directly on GraphEdit with "Use Clock" turned off so, can not compare.
It does not make sense to test DXVA anyway. Bitstream mode is supposed to decode at real-time without CPU intervention.
CiNcH
20th May 2008, 18:51
Concerning the DVBViewer DVBSource problem... I just played a H.264 Blu-Ray m2ts file over the filter and some frames (but very few, only saw a still image with the DivX logo) were decoded until it crashed.
bob0r
20th May 2008, 19:02
@DigitAl56K
If you ever decide to make your product free, x264.nl still needs an x264.ax in the package :D
I am not interested to test the decoder now, as i HATE email, but you can test all Satellite samples yourself:
http://x264.nl/h.264.samples
http://files.x264.nl/h.264.samples.13.apr.2008.europe
DigitAl56K
20th May 2008, 19:56
If you ever decide to make your product free, x264.nl still needs an x264.ax in the package
Believe me when I say there are a lot of supporters for a free decoder, including me! We are looking at the various licensing costs and nothing is off the table, but the truth is that pricing, if any, has not been set yet. When we come closer to an actual release you'll be the second to know ;)
Thanks CiNcH for the additional info on the DVBViewer issue. Regarding DXVA, as I've mentioned on labs several of us are very excited by the idea of DXVA support. Whether this will make the first release or not I'm not sure yet. Our current focus is to round out software decoding, DXVA may depend on the time we have available.
KEROLiUKAS
20th May 2008, 22:26
KEROLiUKAS : what version of FFDShow are you running ? I don't doubt that DivX is faster than FFDshow on your dual core, but it shouldn't be more than twice faster (see cyberdeing timings, on a relatively equivalent CPU : http://forum.doom9.org/showthread.php?p=1139209#post1139209), so that may be explained by a very old version of FFDShow.
ffdshow tryouts revision 1723
Inventive Software
20th May 2008, 23:15
Get a newer version. ffdshow's changed quite a bit since then.
MarcioAB
21st May 2008, 00:26
Regarding DXVA, as I've mentioned on labs several of us are very excited by the idea of DXVA support. Whether this will make the first release or not I'm not sure yet. Our current focus is to round out software decoding, DXVA may depend on the time we have available.
On the original post I also suggested "collaboration" with DXVA. I have no idea if that is technically possible but it could be nice to have some kind of DXVA post processing (Deband-like) to remove/minimize blocks. So, CPU usage can stay something between 2% and full-sofware decode. Maybe that could give some uniqueness to DivX H264 ...
tomos
21st May 2008, 02:05
a collabaration would be nice, might get around the problems with decoding AVC files beyond 4.1, e.g pass what you can to the GPU, do the rest with CPU? possible?
KEROLiUKAS
21st May 2008, 03:17
Redone all tests using the latest ffdshow, and added CoreAVC, also disabled logo in DivX h.264.
File 1:
DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 868.0, dfps: 117.6
ffdshow
User: 2s, kernel: 0s, total: 2s, real: 23s, fps: 532.2, dfps: 60.6
CoreAVC
User: 1s, kernel: 0s, total: 1s, real: 10s, fps: 1397.0, dfps: 132.1
File 2:
DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 8s, fps: 997.8, dfps: 171.2
ffdshow
User: 1s, kernel: 0s, total: 1s, real: 21s, fps: 742.4, dfps: 68.3
CoreAVC
User: 0s, kernel: 0s, total: 0s, real: 7s, fps: 1600.0, dfps: 197.9
File 3:
DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 9s, fps: 978.7, dfps: 147.7
ffdshow
User: 1s, kernel: 0s, total: 1s, real: 22s, fps: 861.9, dfps: 65.3
CoreAVC
User: 0s, kernel: 0s, total: 0s, real: 8s, fps: 1592.4, dfps: 169.3
File 4:
DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 12s, fps: 923.2, dfps: 126.1
ffdshow
User: 2s, kernel: 0s, total: 2s, real: 21s, fps: 631.3, dfps: 72.2
CoreAVC
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 1223.2, dfps: 138.4
Tests using build 1945 of ffdshow.
Chart of my data:
http://img153.imageshack.us/img153/289/chartcopy22ro3.jpg
LOL, it took me a few minutes to figure out some Excel stuff.
Sorry for the innaccurate results at first, all sorted out now..
Yes, DivX and Core are faster because of frame level parallelism, ffdshow has only cabac splitting.
Please test using one decoding core to see the differences.
Shinigami-Sama
21st May 2008, 05:37
Yes, DivX and Core are faster because of frame level parallelism, ffdshow has only cabac splitting.
Please test using one decoding core to see the differences.
it has slices as well
but not many encodes have slices anymore...
Manao
21st May 2008, 06:20
KEROLiUKAS: I still think there's a problem. You're the only guy with a dual core who finds that DivX is faster than CoreAVC.
On a side note, change the name of the video files in your post to something less conspicuous.
On a second side note, don't think I have something against you, it's just that I see strange unexplainable timings and I like to know why.
sparky
21st May 2008, 09:09
As nice as these results look, I'm having a hard time believing that beta1 is 30% faster than CoreAVC on any clip :) maybe there really is something wrong. (Unless it's something like CAVLC + no B-frames + no 8x8). We're getting an X2 set up, we'll get a clearer idea what to expect.
What's the renderer and the graphics card?
Beta 2 is getting real close, I can't make any promises but I'm hoping to push it tomorrow.
KEROLiUKAS
21st May 2008, 14:20
KEROLiUKAS: I still think there's a problem. You're the only guy with a dual core who finds that DivX is faster than CoreAVC.
On a side note, change the name of the video files in your post to something less conspicuous.
On a second side note, don't think I have something against you, it's just that I see strange unexplainable timings and I like to know why.
Yea i think so too, i think that may be the case, as it's really weird... Later today I am going to post screenshots of my settings for Core and you guys can tell me what's wrong... Maybe it was something to do with something else running?
IgorC
21st May 2008, 15:52
KEROLiUKAS
Did you test latest version of CoreAVC 1.7?
KEROLiUKAS
21st May 2008, 22:33
http://img174.imageshack.us/img174/8328/corsetji4.jpg
Ice =A=
21st May 2008, 22:38
You could try switching deinterlacing to "hardware".
KEROLiUKAS
21st May 2008, 22:43
You could try switching deinterlacing to "hardware".
That didn't affect it..But crap i think i know what i did, i turned off deblocking in DivX h.264, gonna do the same in Core and re run the tests...
Edit:
Alright, fixed my original post, with real results, same settings.
Inventive Software
22nd May 2008, 01:32
@KerOLiUKAS: Please don't use offensive language. This is a family forum. :)
KEROLiUKAS
22nd May 2008, 02:09
@KerOLiUKAS: Please don't use offensive language. This is a family forum. :)
IDK what you're talking about :D
(edited it out :P )
Deblocking ON
http://img519.imageshack.us/img519/3459/chartdeblocksv1.jpg
Inventive Software
22nd May 2008, 04:56
CoreAVC wins out in this instance then. :)
Is there a way to batch run timecodec on different decoders?
KEROLiUKAS
22nd May 2008, 13:03
CoreAVC wins out in this instance then. :)
Is there a way to batch run timecodec on different decoders?
Yeah, i was wondering that too. It would be nice to create a batch and have them all run...
MarcioAB
22nd May 2008, 14:49
Is that possible that we all use one same sequence of video (let's say 3K or 4K frames) and check the results relative our hardware differences ?
My results (on Intel 6600 + nVidia 8600 GTS + XP SP3) indicated DivX and CoreAVC almost with the same results.
rack04
22nd May 2008, 15:32
My test Results:
Settings:
http://i11.photobucket.com/albums/a199/rack04/ffdshow1of2.jpg
http://i11.photobucket.com/albums/a199/rack04/ffdshow2of2.jpg
http://i11.photobucket.com/albums/a199/rack04/DivX.jpg
File 1:
General
Complete name : C:\Documents and Settings\xxxxx\Desktop\64827461.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 81.1 MiB
Duration : 1mn 41s
Overal bit rate : 6724 Kbps
Encoded date : UTC 2008-05-21 13:26:03
Tagged date : UTC 2008-05-21 13:26:03
Writing application : Yamb 2.0.0.8 [http://yamb.unite-video.com]
Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.1
Format settings, CABAC : No
Format settings, ReFrames : 2
Codec ID : avc1
Duration : 1mn 41s
Bit rate mode : VBR
Bit rate : 6532 Kbps
Maximum bit rate : 12.6 Mbps
Width : 1280 pixels
Height : 690 pixels
Display aspect ratio : 1.855
Frame rate mode : CFR
Frame rate : 23.976 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.308
Stream size : 78.8 MiB
Encoded date : UTC 2008-05-21 03:03:40
Tagged date : UTC 2008-05-21 13:26:07
Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Duration : 1mn 41s
Bit rate mode : VBR
Bit rate : 188 Kbps
Maximum bit rate : 325 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 2.27 MiB
Encoded date : UTC 2008-05-21 13:26:06
Tagged date : UTC 2008-05-21 13:26:07
DivX H264 Decoder Filter
Renderer = VMR9
User: 4s, kernel: 6s, total: 10s, real: 22s, fps: 226.0, dfps: 110.1
Renderer = NULL
User: 2s, kernel: 0s, total: 2s, real: 15s, fps: 867.4, dfps: 154.8
ffdshow video Decoder
Renderer = VMR9
User: 32s, kernel: 0s, total: 33s, real: 36s, fps: 72.5, dfps: 66.3
Renderer = NULL
User: 31s, kernel: 0s, total: 31s, real: 34s, fps: 76.3, dfps: 71.1
File 2:
General
Complete name : C:\Documents and Settings\xxxxx\Desktop\sample.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 50.5 MiB
Duration : 1mn 8s
Overal bit rate : 6197 Kbps
Encoded date : UTC 2008-05-21 14:07:21
Tagged date : UTC 2008-05-21 14:07:21
Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4
Codec ID : avc1
Duration : 1mn 8s
Bit rate mode : VBR
Bit rate : 6096 Kbps
Maximum bit rate : 15.6 Mbps
Width : 1280 pixels
Height : 544 pixels
Display aspect ratio : 2.35
Frame rate mode : CFR
Frame rate : 19.181 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.456
Stream size : 49.7 MiB
Encoded date : UTC 2008-05-21 14:07:21
Tagged date : UTC 2008-05-21 14:07:24
Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Duration : 1mn 8s
Bit rate mode : VBR
Bit rate : 96.0 Kbps
Maximum bit rate : 137 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 812 KiB
Encoded date : UTC 2008-05-21 14:07:24
Tagged date : UTC 2008-05-21 14:07:24
DivX H264 Decoder Filter
Renderer = VMR9
User: 1s, kernel: 2s, total: 4s, real: 12s, fps: 288.3, dfps: 102.2
Renderer = NULL
User: 1s, kernel: 0s, total: 1s, real: 10s, fps: 998.9, dfps: 128.1
ffdshow video Decoder
Renderer = VMR9
User: 1s, kernel: 0s, total: 1s, real: 15s, fps: 762.8, dfps: 84.3
Renderer = NULL
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 998.9, dfps: 91.7
speedxl
25th May 2008, 03:51
Since DivX, its supported in Ps3, it means you will update the ps3 decoder, when this decoder gets released? i hope you are coding too for the cell platform.
Fuse-One
25th May 2008, 15:03
Since DivX, its supported in Ps3, it means you will update the ps3 decoder, when this decoder gets released? i hope you are coding too for the cell platform.
That all depends on Sony not DivX themselves, me thinks.
Brother John
25th May 2008, 18:02
Another single core test from me. Not too much difference from ffdshow. On the whole DivX just works without needing any attention. Nice work for the first beta. 0-255 range output would be nice, but OTOH using ffdshow as postprocessor is no problem and doesn’t seem to change speed noticeably.
TEST RESULTS:
Pentium M Dothan, 1.6 GHz, single core
WinXP
DivX H.264 Beta, defaults, logo disabled. Additionally I tested without multithreading because of my CPU -> no significant difference.
ffdshow_rev1971_20080523_clsid_sse_icl10, defaults
Clip1:
NULL
DivX: User: 1669s, kernel: 2s, total: 1672s, real: 1699s, fps: 101.9, dfps: 100.3
ffds: User: 1821s, kernel: 2s, total: 1823s, real: 1846s, fps: 93.4, dfps: 92.3
VMR9
DivX: User: 1629s, kernel: 9s, total: 1639s, real: 2771s, fps: 103.9, dfps: 61.5
ffds: User: 1837s, kernel: 7s, total: 1844s, real: 2568s, fps: 92.4, dfps: 66.3
Clip2:
NULL
DivX: User: 73s, kernel: 0s, total: 73s, real: 75s, fps: 859.8, dfps: 838.5
ffds: User: 93s, kernel: 0s, total: 93s, real: 96s, fps: 673.1, dfps: 652.0
VMR9
DivX: User: 64s, kernel: 0s, total: 64s, real: 526s, fps: 977.5, dfps: 119.7
ffds: User: 89s, kernel: 0s, total: 90s, real: 526s, fps: 698.7, dfps: 119.8
Clip1 Info
Play duration: 01:53:36 (6816.04 s)
Container type: matroska
[ Video track ]
Codec ID: V_MPEG4/ISO/AVC
Resolution: 716 x 436
Frame aspect ratio: 179:109 = 1.642201
Pixel aspect ratio: 16:11 = 1.454545
Display aspect ratio: 2864:1199 = 2.388657 (~2.35:1)
Framerate: 25 fps
[ About H.264 encoding ]
User data: x264
User data: core 59 r858 0903472
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2008
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=4
User data: deblock=1:0:-1
User data: analyse=0x3:0x133
User data: me=hex
User data: subme=7
User data: brdo=0
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=0
User data: 8x8dct=1
User data: cqm=0
User data: deadzone=4,4
User data: chroma_qp_offset=0
User data: threads=1
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: bframes=16
User data: b_pyramid=0
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40
User data: rc=crf
User data: crf=18.5
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=1.00
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: aq=2:1.00
SPS id: 0
Profile: High@L5.1
Num ref frames: 4
PPS id: 0
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
Clip2 Info
Play duration: 00:35:03 (2102.533333 s)
Container type: MP4/MOV
[ Video track ]
Codec: avc1
Resolution: 320 x 240
Frame aspect ratio: 4:3 = 1.333333
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 4:3 = 1.333333
Framerate: 29.970036 fps
[ About H.264 encoding ]
User data:
SPS id: 0
Profile: Baseline@L1.3
Num ref frames: 1
PPS id: 0
Entropy coding type: CAVLC
Weighted prediction: No
Weighted bipred idc: No
Number of frames: 63013
Drop/delay frames: 0
Corrupted frames: 0
P-slices: 62521 ( 99.219 %) #########################
B-slices: 0 ( 0.000 %)
I-slices: 492 ( 0.781 %)
SP-slices: 0 ( 0.000 %)
SI-slices: 0 ( 0.000 %)
plonk420
26th May 2008, 06:38
sorry for being lame, but what's a quick way to get the FPS of a clip when dumping output to null? (yes, i understand it's testing raw decode performance)
DigitAl56K
26th May 2008, 22:11
what's a quick way to get the FPS of a clip when dumping output to null?
Google "Haali Timecodec"
Beta 2 is now available from the Project Rémoulade homepage (http://labs.divx.com/ProjectRemoulade). The list of changes and some of the known-issues can be found over at DivX Labs.
I'll also be taking care of some more group sign-ups this afternoon.
LoRd_MuldeR
26th May 2008, 23:47
Here is some Performance test from my Q6600:
E:\HD\Trailer\Apple\syriana_h1080p.mov
[DivX H.264 Decoder - Beta 2]
User: 9s, kernel: 0s, total: 9s, real: 17s, fps: 355.3, dfps: 191.5
[CoreAVC Decoder - Trial Version]
User: 7s, kernel: 0s, total: 7s, real: 16s, fps: 480.6, dfps: 212.8
[ffdshow-tryouts - rev1971]
User: 33s, kernel: 0s, total: 33s, real: 41s, fps: 102.4, dfps: 81.6
Also the playback problems with my own encodes seem to be solved. Good job! :)
Brother John
26th May 2008, 23:54
A quick test before going to bed: The first 6min from Clip1 in post #139. Logo disabled.
VMR9
Beta1: User: 80s, kernel: 0s, total: 81s, real: 145s, fps: 111.9, dfps: 62.3
Beta2: User: 76s, kernel: 0s, total: 76s, real: 141s, fps: 118.5, dfps: 64.4
ffds: User: 116s, kernel: 9s, total: 125s, real: 146s, fps: 72.3, dfps: 62.2
NULL
Beta1: User: 82s, kernel: 0s, total: 82s, real: 84s, fps: 109.5, dfps: 107.3
Beta2: User: 77s, kernel: 0s, total: 77s, real: 78s, fps: 117.5, dfps: 115.4
One possible bug: For anamorphic video and when using MPC internal splitter (http://sf.net/projects/guliverkli2) DivX ignores the AR info resulting in wrong playback AR if the AR flag is only set in the Matroska container and not in the bitstream. I’m not exactly sure if this is DivX’s fault.
Combinations that fail:
MPC internal + DivX
MPC internal + DivX + ffdshow as postprocessor
Combinations that work:
Haali + DivX
Haali + DivX + ffdshow as postprocessor
Haali + ffdshow
MPC internal + ffdshow
On ffdshow’s "output" tab "set pixel ar" and "allow output format chages" are checked. If the AR flag is set in the bitstream (or bitstream + container) the problem does not occur. Also the MP4 container is not affected.
CPU Info
http://brother-john.net/files/cpu.png
Cache latency computation, ver 1.0
www.cpuid.com
Computing ...
stride 4 8 16 32 64 128 256 512
size (Kb)
1 3 3 3 3 3 3 3 3
2 3 3 3 3 3 3 3 3
4 3 3 3 3 3 3 3 3
8 3 3 3 3 3 3 3 3
16 3 3 3 3 3 3 3 3
32 3 3 3 7 3 3 3 3
64 3 4 5 9 10 10 10 10
128 3 4 5 9 10 10 10 10
256 3 4 5 9 10 11 10 10
512 3 4 5 9 10 10 10 10
1024 3 4 5 9 10 10 10 11
2048 3 4 5 9 14 14 15 15
4096 3 4 5 26 48 170 170 173
8192 3 4 5 26 52 175 174 177
16384 3 4 5 26 51 172 174 173
32768 3 4 5 26 50 173 173 175
2 cache levels detected
Level 1 size = 32Kb latency = 3 cycles
Level 2 size = 2048Kb latency = 10 cycles
cyberbeing
27th May 2008, 03:03
This time the timecodec tests were all done with YV12 because there is now no way to force YUY2 in Divx H264.
Blu-ray 1920x1080 High 4.1 (CABAC/4 Ref) 25.3Mbps
User: 1s, kernel: 0s, total: 1s, real: 20s, fps: 510.9, dfps: 44.0
User: 1s, kernel: 0s, total: 1s, real: 16s, fps: 654.4, dfps: 56.0
User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 434.6, dfps: 50.6
________________________________________________________________________
________________________________________________________________________
1920x800 High 5.1 (CABAC/5 Ref) 16.6Mbps
FFDshow Rev. 1972
User: 2s, kernel: 0s, total: 2s, real: 25s, fps: 478.7, dfps: 41.5
CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 15s, fps: 999.0, dfps: 68.9
Divx H264 Beta 2
User: 1s, kernel: 0s, total: 1s, real: 16s, fps: 644.2, dfps: 65.5
________________________________________________________________________
________________________________________________________________________
1920x800 High 5.1 (CABAC/11 Ref) 11.1Mbps
FFDshow Rev. 1972
User: 2s, kernel: 0s, total: 3s, real: 32s, fps: 490.4, dfps: 46.2
CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 19s, fps: 828.7, dfps: 78.5
Divx H264 Beta 2
User: 2s, kernel: 0s, total: 2s, real: 20s, fps: 589.7, dfps: 72.2
________________________________________________________________________
________________________________________________________________________
1280x536 High 5.1 (CABAC/6 Ref) 8Mbps
FFDshow Rev. 1972
User: 1s, kernel: 0s, total: 1s, real: 23s, fps: 1031.2, dfps: 84.2
CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 1534.5, dfps: 137.1
Divx H264 Beta 2
User: 1s, kernel: 0s, total: 1s, real: 15s, fps: 1171.8, dfps: 132.8
________________________________________________________________________
________________________________________________________________________
720x480 High 5.1 (CABAC/10 Ref) 0.8Mbps
FFDshow Rev. 1972
User: 12s, kernel: 0s, total: 12s, real: 71s, fps: 1549.2, dfps: 278.1
CoreAVC 1.7 Pro
User: 10s, kernel: 0s, total: 11s, real: 33s, fps: 1785.5, dfps: 590.2
Divx H264 Beta 2
User: 8s, kernel: 0s, total: 8s, real: 36s, fps: 2257.4, dfps: 543.2
Seems like the speed for Beta 2 is virtually the same as Beta 1 on my AMD X2, but it's possible it might be 1-2% faster.
I also noticed a problem that the uninstaller of Beta 1 is going to delete my whole Divx directory (which I have Divx Pro installed) on reboot. The uninstaller should probably be modified to not delete the whole directory if other Divx stuff is installed.
Edit: Well it seems that even though the uninstaller said it was going to delete the Divx directory on reboot, when I rebooted it didn't.
Inventive Software
27th May 2008, 03:37
I've still to do some representative numbers with deblocking enabled in ffdshow-tryouts and DivX H.264 Beta 1 decoders, but this is the result for H.264 Beta 2 decoder, inloop deblocking enabled, and for some strange reason I can't fathom multithreading enabled on a single core machine (would that make a difference?) Same file as before:
User: 3084s, kernel: 3s, total: 3087s, real: 3146s, fps: 24.4, dfps: 24.0
Seems SSE's really helping. :)
IgorC
27th May 2008, 05:19
Beta 2 is 4% faster then Beta 1 here.
It comes closer to CoreAVC's perfomance
Sample 300.2006.1080p.BluRay.DTS.x264-CtrlHD.sample.noaudio.mkv
CPU: E2160
Divx beta 1
Null
User: 6s, kernel: 0s, total: 6s, real: 36s, fps: 231.9, dfps: 43.9
VMR9
User: 13s, kernel: 0s, total: 13s, real: 48s, fps: 119.2, dfps: 32.9
VMR7
User: 6s, kernel: 12s, total: 18s, real: 42s, fps: 85.2, dfps: 37.7
Divx beta 2
Null
User: 5s, kernel: 0s, total: 5s, real: 35s, fps: 273.2, dfps: 45.6
VMR9
User: 5s, kernel: 0s, total: 5s, real: 46s, fps: 270.3, dfps: 34.2
VMR7
User: 5s, kernel: 8s, total: 14s, real: 39s, fps: 111.2, dfps: 40.4
CoreAVC 1.7
Null
User: 4s, kernel: 0s, total: 4s, real: 32s, fps: 330.3, dfps: 48.7
VMR9
User: 4s, kernel: 0s, total: 4s, real: 44s, fps: 329.2, dfps: 35.8
VMR7
User: 5s, kernel: 4s, total: 9s, real: 35s, fps: 165.4, dfps: 45.8
the_corona
27th May 2008, 07:38
So it's still not faster in Beta2 than CoreAVC despite claims being made over a week ago with an older Version (the scaling of the charts is.......well, very interesting too (read: highly misleading!).
Now it's really no problem that its still slower, even if it'll never be and be like that when it's final or something, it's plenty fast. What I don't like is the mis-guidance that'll have us believe its actually faster (nobody except Divx seems to see this) on you're fancy charts.
Just be honest, give us progress updates and talk to you're (potential) customers not like they are idiots. I would have been far more excited had you stated something like "while you're not quite the fastest, you agressivley continue to work on it, blablabla, but also focus on compatibility and stability" and being able to confirm this rather than "look at us, we're the fastest zomg!" only to find out myself.......no, not really.
Marketing at it's "best".
PS: I will test on both an Intel and AMD machine tonight.
Shinigami-Sama
27th May 2008, 07:57
to be fair
they have 8 thread support and core only has four
so put it on an octobox and it will be faster
but other than I do agree with you
DigitAl56K
27th May 2008, 08:06
@the_corona: I can reliably reproduce that performance on our test box as spec'd in detail on DivX Labs. The system was not specially selected, just one that we had available for testing at the time.
We're currently investigating why the decoder is not performing as well on other systems, which is part of the beta process. Right now we're suspicious that the L2 cache size plays an important role. If that proves to be true we will make adaptations in future betas. The performance information being published at Doom9 and elsewhere by others is helping us to track down these issues. To help us further, when you post performance numbers please also tell us in detail about your CPU as a tool such as CPU-Z reports, including the L2 cache spec.
Beta software is not perfect out of the gate and you'll see further improvements in upcoming releases.
plonk420
27th May 2008, 08:13
beta1:
des-800-wg.mp4 [file (http://www.megaupload.com/?d=VVN85SZ7)]
CoreAVC: User: 7s, kernel: 0s, total: 7s, real: 26s, fps: 1932.0, dfps: 580.7
Divx b1: User: 12s, kernel: 0s, total: 13s, real: 30s, fps: 1179.5, dfps: 500.6
Divx b2: User: 12s, kernel: 0s, total: 13s, real: 28s, fps: 1178.1, dfps: 539.8
des-lossless.mp4 [PNGs 1 (http://www.megaupload.com/?d=DHTBVLH7) / 2 (http://www.megaupload.com/?d=73N7NISE)]
CoreAVC: User: 9s, kernel: 0s, total: 9s, real: 24s, fps: 1679.0, dfps: 634.0
Divx b1: User: 12s, kernel: 0s, total: 13s, real: 30s, fps: 1183.7, dfps: 505.5
Divx b2: User: 12s, kernel: 0s, total: 12s, real: 28s, fps: 1190.9, dfps: 542.7
fallingdown-4800-av-5b.mp4 [link (http://www.megaupload.com/?d=D8QEHW4R)]
CoreAVC: User: 10s, kernel: 0s, total: 10s, real: 55s, fps: 1730.3, dfps: 323.4
Divx b1: User: 16s, kernel: 0s, total: 17s, real: 56s, fps: 1050.2, dfps: 314.5
Divx b2: User: 15s, kernel: 0s, total: 15s, real: 53s, fps: 1147.8, dfps: 335.7
masagin-3200-av.mp4 [link (http://www.megaupload.com/?d=9XC9NN7A)]
CoreAVC: User: 16s, kernel: 0s, total: 16s, real: 73s, fps: 1741.7, dfps: 389.4
Divx b1: User: 28s, kernel: 0s, total: 28s, real: 79s, fps: 1000.4, dfps: 360.7
Divx b2: User: 25s, kernel: 0s, total: 25s, real: 74s, fps: 1104.3, dfps: 383.6
jpod.s01e01.720p.hdtv.x264-hdq.mkv
CoreAVC: User: 36s, kernel: 0s, total: 36s, real: 237s, fps: 1723.7, dfps: 265.6
Divx b1: User: 56s, kernel: 1s, total: 57s, real: 221s, fps: 1095.4, dfps: 285.1
Divx b2: User: 58s, kernel: 1s, total: 60s, real: 236s, fps: 1052.4, dfps: 267.3
User: 54s, kernel: 1s, total: 55s, real: 235s, fps: 1144.6, dfps: 268.2 (2nd run)
test1-200.mkv [link (http://www.megaupload.com/?d=NKXP5QCW)]
CoreAVC: User: 5s, kernel: 0s, total: 5s, real: 20s, fps: 5361.6, dfps: 1474.8
Divx b1: User: 11s, kernel: 0s, total: 11s, real: 22s, fps: 2585.8, dfps: 1306.3
Divx b2: User: 10s, kernel: 0s, total: 11s, real: 21s, fps: 2673.2, dfps: 1378.4
are there any grainy clips to try out there? (what i wouldn't give for a blu-ray of Firefly so i could play or convert Out of Gas...)
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.