Project Rémoulade Update: DivX H.264 Decoder Beta 3

[DigitAl56K]

DivX H.264 Decoder Beta 3 is now available. This release improves performance for older AMD CPUs, introduces preliminary support for DVB applications, adds support for baseline profile, and greatly improves stability of the decoder. To read more about Beta 3, view the change log, and learn how you can help us further improve the decoder, please view the article at DivX Labs (http://labs.divx.com/node/7085).

Thanks to everyone who has contributed to the project so far!

[CiNcH]

From a first test I can say that DVBViewer works like a charm with it, currently watching 'The Tailor of Panama' on ORF 1 HD (720p50), 50 fps and no jitter.
1080i is a pain without a post processor however ;) . Read somewhere that the decoder should check 1080i itself and deinterlace it? Read it on the Remoulade's project comments I guess. This does not seem to work properly yet.
What does it currently output? YV12? Just recognized that the DVBViewer does not display any OSD's any longer. Same happens with other decoders that use the YV12 colorspace. At least I think that it was this one. Seems some conflict within the renderer with the colorspace used for OSD or something...

[DigitAl56K]

Hi CiNcH :)

Yes, de-interlacing is not implemented yet but I'm glad to hear it's working well for you otherwise. The decoder currently prefers YV12 color if the renderer will accept this when the format is negotiated. I think the decoder should be more configurable in this regard in future.

Thanks for your assistance with DVBViewer!

[pitch.fr]

it's not a matter of Reclock.

your decoder says 25 fps to ffdshow for 23.976/24 fps

I've been talking about this problem for a while now, guess it's not on top of your priority list to have a decoder decoding at the right frame rate :(

http://forum.doom9.org/showpost.php?p=1181312&postcount=314

[cyberbeing]

I'm glad to see beta3 fixed the instant crash I was having with that large h.264 transport stream I sent you.

I'll do some performance testing later.

Edit: I'm still seeing some brief blocking (it's no longer green which I guess is an improvement) when seeking on that Blu-ray m2ts sample I sent, and it wasn't fixed in Beta2 either but I forgot to mention it.

[DigitAl56K]

pitch.fr: Seems like we're commenting on two websites.

I'm going to try to get it fixed in Beta 4. Beta 3 has been focused around improving performance, stability, and accepting input from DVB applications.

We aren't ignoring the issue, it's simply necessary to break the work up so that we can continue to release betas with new functionality and enhancements.

I'll let you know once we work on this particular problem. I appreciate your frustration, but hang in there.

cyberbeing: Glad to hear it! :)

[Dark Shikari]

Still blackscreens on the predictive lossless test footage, but I assume you haven't implemented that one yet.

[KEROLiUKAS]

http://advancedplayground.co.cc/2008/09/12/divx-h264-beta-3-testing/

Some tests..Not much improvement in performance, but that's to be expected, I mean, it's not like I was expecting a 20 fps jump.

[Dark Shikari]

http://advancedplayground.co.cc/2008/09/12/divx-h264-beta-3-testing/

Some tests..Not much improvement in performance, but that's to be expected, I mean, it's not like I was expecting a 20 fps jump.How about adding ffmpeg-mt to the test?

[DigitAl56K]

Dark Shikari: Correct, we were already too far through testing to add it to Beta 3.

[MatMaul]

yes it would be good to can choose the output colorspace, with an ordered list like in coreavc.

NV12 support and set of the dwInterlaceFlags of VIDEOINFOHEADER2 when an interlaced stream is detected would be good too, then we could use hardware deinterlacing.

EDIT : I'm seeing some blocks too at the first frames of some h264 ts interlaced samples
for example, this one (http://x264.nl/h.264.samples/force.php?file=./premiere-paff.ts) and this one (http://x264.nl/h.264.samples/force.php?file=./euro1080.hd5.ts)
no problem with coreavc

[LoRd_MuldeR]

A quick test of DivX H.264 Decoder Beta-3 against latest CoreAVC Decoder and ffdshow:

E:\HD\PlanetEarthSample.mkv

[ffdshow-tryouts r2099]
User: 129s, kernel: 13s, total: 142s, real: 367s, fps: 70.2, dfps: 27.2
User: 132s, kernel: 11s, total: 144s, real: 368s, fps: 69.4, dfps: 27.1
User: 129s, kernel: 13s, total: 143s, real: 360s, fps: 69.8, dfps: 27.8

[CoreAVC 1.8.0]
User: 53s, kernel: 0s, total: 53s, real: 78s, fps: 186.5, dfps: 127.1
User: 43s, kernel: 0s, total: 43s, real: 77s, fps: 229.0, dfps: 129.4
User: 53s, kernel: 0s, total: 53s, real: 78s, fps: 187.6, dfps: 127.2

[DivX H.264 Beta-3]
User: 22s, kernel: 0s, total: 22s, real: 61s, fps: 441.7, dfps: 163.4
User: 22s, kernel: 0s, total: 22s, real: 61s, fps: 437.5, dfps: 163.7
User: 26s, kernel: 0s, total: 26s, real: 62s, fps: 376.2, dfps: 161.0

[Dark Shikari]

Something seems rather odd there; ffmpeg's decoder is faster on 32-bit than CoreAVC (though only by a small margin) when decoding with just one core. At least on Core 2, it might be different on other CPUs.

Unless you're using an 8-core machine, that test doesn't seem right...

[cyberbeing]

File 1
User: 13s, kernel: 0s, total: 13s, real: 260s, fps: 776.7, dfps: 41.0 FFDshow r2110
User: 12s, kernel: 0s, total: 12s, real: 161s, fps: 831.5, dfps: 66.3 Divx Beta3
User: 8s, kernel: 0s, total: 8s, real: 158s, fps: 1242.8, dfps: 67.5 CoreAVC 1.8.0.0

File 2
User: 1s, kernel: 0s, total: 1s, real: 18s, fps: 1106.5, dfps: 77.8 FFDshow r2110
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 1412.9, dfps: 130.3 Divx Beta3
User: 0s, kernel: 0s, total: 0s, real: 10s, fps: 2135.8, dfps: 135.5 CoreAVC 1.8.0.0

File 3
User: 1s, kernel: 0s, total: 2s, real: 21s, fps: 504.2, dfps: 48.4 FFDshow r2110
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 750.5, dfps: 86.7 Divx Beta3
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 846.8, dfps: 89.3 CoreAVC 1.8.0.0

File 4
User: 5s, kernel: 0s, total: 5s, real: 56s, fps: 390.9, dfps: 39.9 FFDshow r2110
User: 5s, kernel: 0s, total: 5s, real: 31s, fps: 428.1, dfps: 71.9 Divx Beta 3
User: 3s, kernel: 0s, total: 3s, real: 29s, fps: 680.5, dfps: 75.8 CoreAVC 1.8.0.0

File 5
User: 9s, kernel: 0s, total: 9s, real: 106s, fps: 452.7, dfps: 40.9 FFDshow r2110
User: 9s, kernel: 0s, total: 9s, real: 57s, fps: 465.5, dfps: 76.3 Divx Beta 3
User: 6s, kernel: 0s, total: 6s, real: 58s, fps: 641.0, dfps: 74.4 CoreAVC 1.8.0.0

File 6
User: 5s, kernel: 0s, total: 5s, real: 56s, fps: 1004.0, dfps: 104.7 FFDshow r2110
User: 5s, kernel: 0s, total: 6s, real: 26s, fps: 957.9, dfps: 219.3 Divx Beta 3
User: 4s, kernel: 0s, total: 4s, real: 25s, fps: 1272.8, dfps: 230.2 CoreAVC 1.8.0.0
Seems better but on most samples still ~5% slower then CoreAVC 1.8.0.0

System specs: AMD X2 4800+ @2.64Ghz, 2GB DDR433 2-3-3-6, nVidia 7800GTX 512 (Forceware 177.89), Windows XP SP3

[crypto]

Big improvement on PAFF interlaced streams, which gave black frames on the earlier betas. All samples I tried are now playing back fine. :)

[pitch.fr]

pitch.fr: Seems like we're commenting on two websites.
OK, cool :thanks:
coz there's been a new beta of Reclock that fixes the frame rate detection problem with Haali's Renderer.

but because your decoder says 25 fps to FFDSHOW for 23.976/24 fps h264 video streams....then it's impossible to use.

If I force 23.976/24 fps with Reclock anyhow, then I get some terrible judder......because your decoder says it's outputting 25 fps :(

works fine for 25/29.97 movies, though.

would love to try your decoder :cool:

[clsid]

@everyone that posts timecodec benchmarks, please mention what CPU you have ;)

[LoRd_MuldeR]

@everyone that posts timecodec benchmarks, please mention what CPU you have ;)

I have added "My Specs" to my sig long ago, so I don't need to post my CPU type every time :p

[SeeMoreDigital]

I have added "My Specs" to my sig long ago, so I don't need to post my CPU type every time :pIndeed....

Around three years ago I suggested we have a "Forum Members Gear" (http://forum.doom9.org/showthread.php?t=98293) sticky for this kind of thing ;)

[DigitAl56K]

Edit: I'm still seeing some brief blocking (it's no longer green which I guess is an improvement) when seeking on that Blu-ray m2ts sample I sent, and it wasn't fixed in Beta2 either but I forgot to mention it.

I will retest it on Monday.

[BetaBoy]

@everyone that posts timecodec benchmarks, please mention what CPU you have ;)

I was just gonna say the same thing ;-)

[ricardo.santos]

Something seems rather odd there; ffmpeg's decoder is faster on 32-bit than CoreAVC (though only by a small margin) when decoding with just one core...

not surprising at all, playback, seeking are much faster using ffdshow, i as also surprised as theres loads of claims that CoreAVC is the best/fastest/less resources.

When using CoreAVC playback after seeking actually took more than 1 or 2 seconds while it was "instant" with FFDSHOW.

Can the divx decoder be installed and uninstalled without affecting h264 playback on the system? (leftovers)

[BetaBoy]

not surprising at all, playback, seeking are much faster using ffdshow, i as also surprised as theres loads of claims that CoreAVC is the best/fastest/less resources.

When using CoreAVC playback after seeking actually took more than 1 or 2 seconds while it was "instant" with FFDSHOW.
(leftovers)

There is a seeking bug in CoreAVC atm that we are fixing for the next release.

[cyberbeing]

I will retest it on Monday.

Did you have any luck reproducing the problem?

[pitch.fr]

...and with the 23.976/24 movies giving 25fps in ffdshow ? :p

[DigitAl56K]

Did you have any luck reproducing the problem?

Sort of. This clip is damaged to begin with, but I do see some blocks on seeking. I believe the decoder is trying to show the picture buffer as early as possible, whereas CoreAVC for example is waiting a few frames after a seek until it has a good picture buffer to display. There also seems to be an issue with the jitter on this clip, so we'll look into it further.

pitch.fr: I keel j00! ;) (yes, I can reproduce it ;))

[Flaarn]

Quite an improvement in speed decoding with the beta 3 on one of my older pc's here with decoding bbc hd, though I did note the occasional glitch, I believe bbc may have changed something on certain content as dgavcdec throws up a forbidden nalu at the same point, keep the improvements coming, for me a great improvement over beta 2.

[neuron2]

I believe bbc may have changed something on certain content as dgavcdec throws up a forbidden nalu at the same point I can have a look at it if you can make the stream available to me.

[Flaarn]

not a fan of public upload sites, but as this is something new only seen it the last couple of weeks and may affect decoders in varying ways, here we go. forbidden_nalu.ts (http://uploaded.to/?id=287hia)

[cyberbeing]

I just ran into a nasty bug in Beta3 when using MKV ordered chapters and segment linking. DigitAl56K, I've uploaded problem file to the ftp.
http://img523.imageshack.us/img523/6810/ordchseglinkni0.png

[DigitAl56K]

Thanks Cyberbeing and Flaarn, I'm grabbing the files now.

[Dark Shikari]

Any update on which beta version will have Predictive Lossless support? x264 now uses it instead of the old lossless method, so all newly encoded files will fail under DivX.

[DigitAl56K]

Dark Shikari: I don't have the full committed list for the next beta yet, as soon as I do I will let you know.

Flaarn: Would you mind uploading the file linked above to our FTP (same account as before should work). I'm currently getting 3.5kb/sec and don't have much confidence the download will complete successfully.

[Flaarn]

should already be there, the public upload was more for neuron2's benefit, I hate the damn things, I saw the same issue as mentioned, in a ts again tonight, darned broadcasters changing things.

[cyberbeing]

I seem to have found another bug. For 704x400 with a 711x400 anamorphic stretch, Divx Beta3 is stripping the aspect ratio info which results in it being displayed wrongly at 704x400.

Edit: After looking into it further, it seems like this only happens when it's outputting to VSFilter. Other decoders don't have this issue so it seems for some reason Beta3 refuses to output aspect ratio info to VSFilter.

XForm In

- Connection media type:

Video: MPEG4 Video (H264) 704x400 (711:400) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 171

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 711
dwPictAspectRatioY: 400
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 39
dwProfile: 0x00000064
dwLevel: 0x0000001f
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 704
biHeight: 400
biPlanes: 1
biBitCount: 24
biCompression: avc1
biSizeImage: 0
biXPelsPerMeter: 704
biYPelsPerMeter: 711
biClrUsed: 0
biClrImportant: 0


XForm Out

- Connection media type:

Video: YV12 704x400

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 422400
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 0

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 704
dwPictAspectRatioY: 400
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 704
biHeight: 400
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 422400
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

[DigitAl56K]

Cyberbeing,

I can't reproduce the issue screenshotted above. I've tried mplayer2 and MPC HC with Beta 3, Haali splitter, and the MPC internal MKV splitter on two separate Intel systems and one AMD system roughly matching your configuration.

Can you give me the specific builds of MPC (and, if relevant, Haali Splitter) that you are using here, whether it's MPC or MPC HC, what the renderer selection is, and a step by step on what to click from the point you open the program?

Thanks.

[cyberbeing]

Edit: Oops, you said screenshotted, so I guess you were talking about the one with the green screen and blocking? Info for what versions I use is the same as below. It occurs with every renderer even with VSFilter unregistered (other h264 decoders don't have any issues). I'm still using an AMD X2 4800+ and 7800GTX 512 w/ Forceware 177.83 drivers on WinXP SP3.

Hmm step by step would be the following:

Open Haali Media Splitter Settings and set Input > Try to Open Linked Files = YES
With MPC, open the EP1.mkv I uploaded to the FTP with OP.mkv and ED.mkv in the same directory.
Press the next chapter button in MPC.
There should now be a green screen and blocking (this part is the OP.mkv which is being added within, not before/after, the EP1.mkv)
Press the next chapter button again.
Blocking and green screen should be gone (EP1.mkv resumes playing)
Press the next chapter button in MPC.
There should now be a green screen and blocking (this part is the ED.mkv which is being added within, not before/after, the EP1.mkv)
Press the next chapter button again.
Blocking and green screen should be gone (EP1.mkv resumes playing)

Open Haali Media Splitter Settings and set Input > Try to Open Linked Files = NO
Open each file individually.
Confirm that there is no blocking when played individually.

________________________________________
I'm using the latest MPC (http://downloads.sourceforge.net/guliverkli2/mplayerc_20081005.zip?modtime=1223216005&big_mirror=0) and VSFilter (http://downloads.sourceforge.net/guliverkli2/VSFilter_20080828.zip?modtime=1219924736&big_mirror=0) from Guliverkli2 along with the latest Haali Media Splitter (http://haali.cs.msu.ru/mkv/MatroskaSplitter.exe).
________________________________________

About the second problem:

I guess I should have noted that it only happens on some anamorphic MKVs but not all. If you still can't reproduce, I'll upload some samples that run into the issue.

Output for broken 720x480 (4:3) anamorphic MKV decoded with Beta 3.

- Connected to:

CLSID: {9852A670-F845-491B-9BE6-EBD841B8A613}
Filter: DirectVobSub (auto-loading version)
Pin: Video

- Connection media type:

Video: YV12 720x480

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 518400
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 0

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 720
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 518400
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 00 00 00 00 00 00 00 00 d0 02 00 00 e0 01 00 00 ........Ð...à...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 d0 02 00 00 ........(...Ð...
0050: e0 01 00 00 01 00 0c 00 59 56 31 32 00 e9 07 00 à.......YV12.é..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Output for working 720x480 (4:3) anamorphic MKV decoded with Beta 3.
- Connected to:

CLSID: {9852A670-F845-491B-9BE6-EBD841B8A613}
Filter: DirectVobSub (auto-loading version)
Pin: Video

- Connection media type:

Video: YV12 720x480 (4:3)

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 518400
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 0

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 5760
dwPictAspectRatioY: 4320
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 518400
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 00 00 00 00 00 00 00 00 80 16 00 00 e0 10 00 00 ........€...à...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 d0 02 00 00 ........(...Ð...
0050: e0 01 00 00 01 00 0c 00 59 56 31 32 00 e9 07 00 à.......YV12.é..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

I'll restate that it only happens when it's connecting to VSFilter (the renderer used seems unrelated) and no other decoder has this issue.

[DigitAl56K]

Cyberbeing: I think I'm going to need a clip for the SAR problem because I've been trying to reproduce it today and so far I've failed to do so.

Do you know what display dimension is actually marked in the MKV file as opposed to in the bitstream?

Can you also tell me which build of VSFilter you are using?

[cyberbeing]

I'm using the latest MPC (http://downloads.sourceforge.net/guliverkli2/mplayerc_20081005.zip?modtime=1223216005&big_mirror=0) and VSFilter (http://downloads.sourceforge.net/guliverkli2/VSFilter_20080828.zip?modtime=1219924736&big_mirror=0) from Guliverkli2 along with the latest Haali Media Splitter (http://haali.cs.msu.ru/mkv/MatroskaSplitter.exe).


Along with VSFilter 20080828 linked to in my previous post, I've also tested it with the older 20080612 build and the problem was still there.

Do you know what display dimension is actually marked in the MKV file as opposed to in the bitstream?
This is hard to know for sure considering MKVtoolnix seems to strip aspect ratio info from the bitstream when muxed.

Files uploaded to ftp: AR_Incorrect.mkv and AR_Correct.mkv

[neuron2]

I believe bbc may have changed something on certain content as dgavcdec throws up a forbidden nalu at the same point, keep the improvements coming, for me a great improvement over beta 2. The stream contained a NALU with forbidden_zero_bit set. The current recommendation is for the decoder to discard the NALU. I did that in DGAVCDec and DGAVCDecNV, so you won't get the popups anymore and the streams decodes fine. Thanks for pointing this out.

[DigitAl56K]

cyberbeing: We looked at the aspect issue and initial inspection indicates that Haali splitter may be patching the SPS on the fly, with our decoder behaving correctly based on the information it actually receives.

BetaBoy: Can you comment, or give Mr Haali a prod? :)

[IgorC]

Late but I found that Divx H.264 decoder benefits more from dual channel memory than CoreAVC.

WinXP sp3, CPU e2160

Old results with single channel 512 Mb 667 Mhz from here http://forum.doom9.org/showpost.php?p=1142489&postcount=146
Divx Beta 2 - 45.6 dfps
CoreAVC 1.7 - 48.7 dfps

Dual channel 2x1gb 667 Mhz.
Divx Beta 3 - 53.8 dfps
CoreAVC 1.8.5 - 51.3 dfps

I admited there wasn't performance improvements from Beta 2 to 3.

It's history. For the first time Divx is first for me.

[Dark Eiri]

^ Isn't a good part of that speed increase because you compared 512 MB versus 2 GB?

[LoRd_MuldeR]

^ Isn't a good part of that speed increase because you compared 512 MB versus 2 GB?

Nope, as 512 MB should be far enough memory for a H.264 decoder.

MediaPlayerClassic still remains below 128 MB of physical memory while playing a 1080p H.264 video using CoreAVC Decoder:

http://img72.imageshack.us/img72/4051/peakmemorypl9.th.png (http://img72.imageshack.us/img72/4051/peakmemorypl9.png)

[IgorC]

Task manager and Everest both reported memory used less than 512 Mb (total for system during the test)
Maybe the main advantage was that dual channel speed ups onboard video as in my case. However I don't know what kind of impact it can produce on NULL video benchmarking.

[Sharktooth]

... or coreavc uses the cache more efficiently.