CoreCodec/H.264 Codec "CoreAVC" [Archive] - Page 3

TEB

5th January 2006, 14:55

with this build of mplayer (http://www.aziendeassociate.it/cd//mplayer/mplayer2005.11.23.P4.7z) and this command line :
mplayer "file.mkv" -vo null -benchmark
I obtain 106,7 fps

PS : I edited my last post with a test on a hd source

I tested on Saggitares x264HP_IceAge_720p_1250.mp4 on that mplayer build and TCPMP build (-nosound as default)

Mplayer w/directshow as -vo 36fps -vo null 63fps
TCMP/AVC w/directshow as -vo 77fps -vo null 97fps

URL \x264HP_IceAge_720p_1250.mp4
Size 12923107
Platform Windows
OS Version 5.01
Clock speed 3590 Mhz
Video output DirectDraw 1280x1024 32bits Lookup
Video zoom 1280x720 -> 1280x720

My comment: Man this is impressive :) Keep up the good work and keep the builds coming!
Btw do u support mpeg2-ts demuxing and decoding in hd and sd?
I see that u dont use HT or Multicore/smp, is this planned to be implemented?

rozemab

5th January 2006, 15:23

yes, I was referencing the player, not the directshow filter.

Caroliano

5th January 2006, 16:20

My rounded results in a 1.7GH celeron with an 640x352 High profile Noir opening:

file -> ffdshow -> chegepuga: ~40fps
file -> coreavc -> chegepuga: ~65fps
file -> coreavc -> ffdshow -> chegepuga: ~58fps

The last is because I cant plug the coreavc into Video Render directly. If I try that the FFDShow apears automaticaly between them. Even though can conect it directly to chegepuga... maybe a compatibility bug?

bond

5th January 2006, 16:48

The last is because I cant plug the coreavc into Video Render directly. If I try that the FFDShow apears automaticaly between them. Even though can conect it directly to chegepuga... maybe a compatibility bug?coreavc doesnt make a colorspace conversion, so it only outputs yv12. afaik old video renderer doesnt like yv12 input. try vmr7

Caroliano

5th January 2006, 17:15

coreavc doesnt make a colorspace conversion, so it only outputs yv12. afaik old video renderer doesnt like yv12 input. try vmr7
I'm not familiar with Graphedit yet. It shoud be in graph -> insert filters, but where? In directshow tree? Other tree? It has exactly this name?

bond

5th January 2006, 17:27

I'm not familiar with Graphedit yet. It shoud be in graph -> insert filters, but where? In directshow tree? Other tree? It has exactly this name?in the mpc options you can enforce what renderer you want to use

MatMaul

5th January 2006, 17:49

I have edited my fps for ffdshow because there are wrong (I used a YV12->RGB conversion...)

now the values are good and it appears ffdshow=mplayer ( normal :D , they use the same library for decode...)

Caroliano

5th January 2006, 17:49

I tried VRM7 windowed in MPC but this way apear a lot of blocking and some artifacts in motion. With renderless is the same thing, plus that I cant see anything in fullscreen (very strange artifacts). I'm using ffdshow for an directshowsource() encode right now, this can be the problem, I don't know.

Also, it don't afect graphedit. I'm doing anything wrong?

GhengisKhan

6th January 2006, 01:16

This decoder is awesome - have it running from a USB drive and it almost allows me to play Apple Trailers in 1080p.

Great work Picard!

GhengisKhan

Edit. P.S. Picard do you think you could get 1080p to play perfectly for me (1.6Ghz Intel Centrino proc.)
P.P.S. Any updates about the encoder or other development... Picard... Betaboy...anyone?
P.P.P.S. How's soon can we expect a full decoder (all features implemented)?

Thanks, you guys are great!

MatMaul

6th January 2006, 02:28

Edit. P.S. Picard do you think you could get 1080p to play perfectly for me (1.6Ghz Intel Centrino proc.)

I can decode 1080p films with my pentium m @1,73ghz (about 35 fps)

GhengisKhan

6th January 2006, 04:06

Yeah, that's what I meant by saying it wasn't quite perfect yet. It's almost like I can reach it. It was like this in 720p before in Quicktime on my 1.6Ghz -almost there, but still dropping some frames. I'm sure by the time the new release comes out (the one Betaboy is probably demoing at CES), I will be able to watch 1080p trailers from www.apple.com/trailers perfectly (my brother wants to buy that new Panasonic HD camera which records in 1080p HD so this is really important to me - so I can watch what he records).

GhengisKhan

P.S. It takes too long to be allowed to post - I couldn't post when all the good stuff was being talked about... and I'm leaving (skiing) the day after I'm allowed... this sucks (Picard do me a favor and hold off on the release wait about 5 days - then release a big sucker. Just for me? Just kidding, it would be nice though... I'm so addicted to TCPMP...)

CruNcher

6th January 2006, 07:32

Panasonic HD camera which records in 1080p HD

Hmm but im sure it won't record in H.264, so for the raw stuff you should have no problems watching it on your specs with a fast Mpeg-2 Decoder with DXVA support.

@picard
im not sure but it seems to be the same decoding bug that AlexW experienced http://forum.doom9.org/showpost.php?p=762293&postcount=94
in this sample http://rapidshare.de/files/10498977/coreavc_decoding_prob.mp4.html

when useing (bframes 2)
--analyse all --8x8dct <- i have not such Decoding problems but when useing
--analyse p8x8,b8x8,i4x4,i8x8 --8x8dct the problems as the sample shows occour

Selur

6th January 2006, 19:31

Ok, seems like I'm doing something wrong, I downloaded tcpmp.win32.0.71g.zip (from http://picard.exceed.hu/tcpmp/test/) and ice_age_2-tlrD_h1080p.mov (from http://www.apple.com/trailers/fox/ice_age_2/hd/), remuxed ice_age_2-tlrD_h1080p.mov into ice_age_2-tlrD_h1080p.mp4 using Quicktime 7pro.
Then I unziped tcpmp.win32.0.71g.zip, started player.exe, ignored the message about the aac audio decoder, opened the mp4 file and tried to play it. => 100% CPU usage and a no way watchable (to slow, skipping frames) playback. Playback works fine in TCMP using ffdshow for Audio&Video decoding, no problem watching the mp4 smoothly. (70-99% CPU usage, would be a bit less if I would use ffdshow to convert the aac stream on the fly to ac3)

Shouldn't this work? Am I doing something wrong?

Cu Selur

Ps.: running WinXpro 32bit with newest updates, 2GB RAM, Athlon 64bit 3500+, display resolution: 1920x1200.

bond

6th January 2006, 19:35

selur, you need to get avc.plg, which is available together with the aac.plg in an extra package on the page

Selur

6th January 2006, 19:40

Ah, okay, thx.
Just tested the directshowdecoder. :)
CPU usage dropped to 46-75%, nice. :D

Thx, bond worked fine, CPU usage even dropped another 5%. ;)

Cu Selur

Ps.: Nice work CoreCoded-Team :D

JoeBG

6th January 2006, 19:49

selur, you need to get avc.plg, which is available together with the aac.plg in an extra package on the page

@ Selur

You got it? :D

Selur

6th January 2006, 20:26

yup, that's why I inserted 'Thx, bond worked fine, CPU usage even dropped another 5%.' :D

cjei

7th January 2006, 01:54

I hope CoreAVC can have these color conversion options :
ColorMatrix("Rec.709->Rec.601")
ColorMatrix("Rec.601->Rec.709")
ColorYUV(levels="TV->PC")

Because vmr7&9 seems to need PC scale YUV
and overlay needs Rec.709 for HD.

falcon2000eg

7th January 2006, 03:18

Is there any way of adjusting brightness/contrast?

yes i hope that (in the dshow decodr i mean) to quit using ffdshow.

[Toff]

7th January 2006, 11:41

yes i hope that (in the dshow decodr i mean) to quit using ffdshow.

Graphic cards already have settings for that, why would you want to have settings in each video decoder ? That mean that each time you install a new decoder, you have to tweak its settings. If you want to have 2 or more configurations, for example for day and night, you need to change again all the settings in all the video decoders.

[)370|\|470!2

7th January 2006, 11:58

']Graphic cards already have settings for that, why would you want to have settings in each video decoder ? That mean that each time you install a new decoder, you have to tweak its settings. If you want to have 2 or more configurations, for example for day and night, you need to change again all the settings in all the video decoders.

It's not always help to brighten the picture, especially when color conversion applied. Darken details are still unwatchable.

[Toff]

7th January 2006, 12:20

It's not always help to brighten the picture, especially when color conversion applied. Darken details are still unwatchable.

How would that be different with decoder level brigthness settings ?

[)370|\|470!2

7th January 2006, 12:29

']How would that be different with decoder level brigthness settings ?

Hmm, just thought, that applying brightness before rendering on more deeper level is more effective...

bobololo

7th January 2006, 19:23

bond

7th January 2006, 19:34

I did a quick test using TheGreatestGame_HD_AVC.mp4 trailer (1920x1080p) available from nerodigital.com and timeCodec from Haali. I'm running an AMD X2 4400+ @ 2420 MHz.

Nero: 52.3 fps
CoreAVC: 45.3 fps
Ateme: 30.6 fps

As you can see CoreAVC shows really good performance it's only beaten by nero decoder which exploits both cores of my CPU while others don't.well bobololo left some of his values away:
the values he posted are for plain decoding (eg via avisynth). for playback (via directshow) the display fps shown by haalis tool are important and these are in bobololo's setup:

CoreAVC: 45.1 fps
Nero: 36.1 fps
Ateme: 30.6 fps

as you can see coreavc is faster than nero for playback, even altough nero is multithreaded and coreavc isnt, so i wouldnt say nero is able to beat it at all

videomixer9

7th January 2006, 20:48

Athlon XP 3000+, 1 GB Dualchannel DDR333 RAM, TheGreatestGame_HD_AVC.mp4, Haali timeCodec

ffdshow 04 Jan 2006
User: 173s, kernel: 0s, total: 174s, real: 180s, fps: 21.1, dfps: 20.3
CoreAVC:
User: 107s, kernel: 0s, total: 107s, real: 111s, fps: 34.1, dfps: 32.8

Plays fine and in sync with CoreAVC and stutters otherwise, I guess I say byebye to ffdshow, too bad I cannot use quicktime decoder in timeCodec as I'm sure that one would be by far slower, tried with an apple trailer that stutters around totally in Quicktime Player and test result was this, besides the totally fluent playback in the player (x-men_3-pre_teaser_h1080p.mov):
User: 42s, kernel: 0s, total: 42s, real: 48s, fps: 55.7, dfps: 49.4
Apple ever going to update their crappy decoders? I got lots of ppl that think their PC is not ready for HDTV stuff because of the bad performance of Quicktime ...

Hope CoreAVC will be improved and regularly released soon!

SeeMoreDigital

7th January 2006, 20:52

What a fabulous little MPEG-4 AVC decoder....

With it I've been able to play some 1280x720 samples quite perfectly, samples that previously stuttered ;)

Great work guys.... once AR signalling detection is included, it will be a brilliant little MPEG-4 AVC decoder :)

Cheers

bobololo

8th January 2006, 04:46

well bobololo left some of his values away:
the values he posted are for plain decoding (eg via avisynth). for playback (via directshow) the display fps shown by haalis tool are important and these are in bobololo's setup:

CoreAVC: 45.1 fps
Nero: 36.1 fps
Ateme: 30.6 fps

as you can see coreavc is faster than nero for playback, even altough nero is multithreaded and coreavc isnt, so i wouldnt say nero is able to beat it at all

LOL that's really funny to see how strong you're defending OSS things (is CoreAVC OSS btw ?) against evil commercial things ;). That even brings you to post mis-leading information without rigorously checking them !

To come back to the topic, our main interest here is to compare the raw performance of the decoders no matter what there is around (dshow, displaying, rendering, etc.). And this raw performance is indicated by the fps entry from timeCodec as Haali explained to you. I provided the figures corresponding to it in my post above.

The display fps (dfps) gives the actual framerate of the whole display graph if I understand correct and therefore it includes many things like parsing, rendering, output color conversion, displaying, etc. that are to my opinion out of the previous scope.

I don't know the reason why the dfps is quite lower with nero decoder, but it's rather abnormal since I used the null renderer in which case the fps should be close to the dfps (as it's verified with other decoders btw). I have the feeling that for some reasons, an unknown additional filter had been added in nero's case and drastically slowed down the display graph given its poor result. Whatever the cause, it doesn't change the raw performance figures showing that nero is faster than CoreAVC and there is no discussion possible here (unless there are some issues in the way timeCodec does its job).

And as a conclusion to my 2 cents' comment :), I would suggest you to spend your energy bitching CoreAVC devs to exploit MT optimization to definitively bring it far ahead from others decoders instead of trying to arrange actual facts that don't please your taste ;). That would be much more useful for the development progress !

fight2win

8th January 2006, 08:20

hi,
i have done some avc encodes using megui x264, high profile with jvt turned on, so will core avc decoder be able to play them?

bond

8th January 2006, 13:20

LOL that's really funny to see how strong you're defending OSS things (is CoreAVC OSS btw ?) against evil commercial things ;). That even brings you to post mis-leading information without rigorously checking them !coreavc is not oss, as i see it its indeed a "commercial" solution, given away for free tough (till now)

i simply posted the info you left away, i see nothing wrong with that

To come back to the topic, our main interest here is to compare the raw performance of the decoders no matter what there is around (dshow, displaying, rendering, etc.). And this raw performance is indicated by the fps entry from timeCodec as Haali explained to you. I provided the figures corresponding to it in my post above."our" interest is not what you described here, as its not your job to decide what our main interest is.

imho the main interest is how nero and coreavc perform during playback, as currently avc decoders are as good as always used for playback
if nero does some wierd colorspace conversion or something else during playback which slows it down, it still makes it slower than coreavc during playback

therefore the dfps value is interesting and shows that during playback coreavc is faster than nero
you should have at least provided us that info

Sagittaire

8th January 2006, 15:00

Bond use simple core CPU
bobololo use dual core CPU

perhaps simple SMTP optimisation for Nero Decoder ... ???

lexor

8th January 2006, 15:09

Bond use simple core CPU
bobololo use dual core CPU

perhaps simple SMTP optimisation for Nero Decoder ... ???
that's not what's happening above, from my understanding of what bobololo did, is that he just measured performance of pure decoding (without playback) to raw of each decoder. bond posted bobololo's figures but with playback component added in, I think the number bond posted are also from bobololo's test not bond's own, just bobololo didn't post those since he compared the raw perfomace.

As you can see both ateme and coreavc didn't take a performance hit (barely a dent in decimal part) when you add the playback component in (since they are both single threaded, just like dsfilters and players) whereas nero took a nose dive since its multi-threaded performance was negated by necessity to wait for the single threaded dsfilters and players.

I think the result of the comparison that bobololo made is that it doesn't matter if one step is multi-threaded, you gotta get all software in your playback chain multi-threaded, or you don't get benefit. Thanks for that bobo :) makes me feel better about not having dual core just yet.

Doom9

8th January 2006, 15:16

well, since there's such a significant difference between pure decoding and the whole playback stream, that would warrant some investigation on which filter uses how much CPU time so see if there's a bottleneck somewhere, if there's a filter that may be unable to cope with the amount of data the decoder feeds it and starts to choke. Comparing the CPU usage in both scenarios might also be interesting.. are both cores really being maxed out in the DShow scenario? If not but they are in the pure decoding scenario, that would be a strong indicator that one of the additional filters used by dshow playback causes a slowdown.

And as far as QT goes.. perhaps Apple will learn by the year 3000 but I wouldn't expect anything before that. They may make good video editing software but encoding and decoding video is another story entirely.

CruNcher

8th January 2006, 15:59

bobololo use dual core CPU

I think he uses a P4 Hyperthreading Cpu no Dual Core, anyway
all of you here entirely forget what CoreAVC is about and that it's still in early Development and from that result it shows here in that state as a ST Decoder against an MT Version of Neros Decoder i would call that allready much better low level optimized and in ST Mode it looks completly different, because that's what Picard optimized CoreAVC initialy for (showcased on CES @ the Sandisk and HP booth) Single Core Mobile Devices and now with the first Dual Core Mobile Devices and Multimedia CE Devices showing up im sure Picard gonna enhance it even further also in that direction and it really seems to be a Dshow bottleneck like lexor said that the Nero filter can render faster in MT mode but can't display it out as fast. But anyway in my eyes that doesn't make Neros Decoder better even if it could provide the same speed for the output :P

Before Picard goes on optimizing it for Dual Core i think it's more important to fix the for now last known Decoding bug inside it. That would be http://forum.doom9.org/showpost.php?p=762293&postcount=94

lexor

8th January 2006, 16:12

I think he uses a P4 Hyperthreading Cpu no Dual Core, anyway

I'm running an AMD X2 4400+ @ 2420 MHz.
how did you get P4 out of that? :cool:

videomixer9

8th January 2006, 16:27

I'm quite amazed the difference between X2 4400+ and XP 3000+ is only ~11fps with CoreAVC, guess the 4400+ is only given with both cores fully used ... so far the test seem to be kinda unfair and I'd wonder how it'll turn out once CoreAVC does multithreading ... if Nero would equally spread the load on the two cores the amount of fps bobololo reached isn't that impressive really ... it'd mean that Nero only got 26,15 fps out of each core, that's less fps than CoreAVC managed on my single core XP 3000+. Considering the overclocking from 2200mhz to 2420mhz this is a real bad performance imo.

Doom9

8th January 2006, 16:28

it really seems to be a Dshow bottleneck like lexor said that the Nero filter can render faster in MT mode but can't display it out as fast.That's not correct. There's decoding, and then there's filters after it.. it really needs to come down to analyzing the filter and what percentage of CPU they use (in relation to the complete available CPU power). Assuming everything before the decoder filters is the same, and further assuming that there's just the renderer after the decoder, the renderer might be doing something screwed up. Since when it comes to raw decoding power, the Nero decoder appears to be the fastest, and it no longer is when there's a renderer in the picture, wouldn't it be reasonable to suspect the renderer as a bottleneck, and that much of a bottleneck that it actually punishes fast decoders?

videomixer9

8th January 2006, 16:47

null renderer is shit, vmr7 has better dfps on my system :)
(at least with fps this low, on mpeg4 decoding with over 300fps it cannot keep up, still quite mysterious)

CruNcher

8th January 2006, 17:05

@lexor
oops yeah i oversaw that last time i spoke with him about the results of the Nero filter he was on a P4 HT ;)

bobololo

8th January 2006, 21:16

Whatever the cause, it doesn't change the raw performance figures showing that nero is faster than CoreAVC and there is no discussion possible here (unless there are some issues in the way timeCodec does its job).

Thanks to Haali's help, we finally sorted out what was happening. Due to the way timeCodec is measuring the decoding time, it doesn't account all running threads which cause the incorrect fps measurement with nero decoder since is multithreaded. According to Haali, dfps when using null renderer is close enough to the actual decoding fps (less than 1% error when using long enough clip). So finally, I redid my bench and the results are summarized as follow :

CoreAVC: 48.6 fps
Nero: 39.6 fps
Ateme: 33.6 fps
ffdshow: 30.7 fps

On my AMD X2 @ 2420 MHz (I recently upgraded my hardware from a P4/HT @ 3 GHz) which means that if there isn't any further measurement mistake, CoreAVC outperforms any decoders around even without exploiting MT. It's just impressive, and we'll have some hard work to catch up ;) !

update: added ffdshow's result

PicardGK

9th January 2006, 01:09

Actually I'am not at CES, but busy with Symbian porting of TCPMP.

I found the decoding bug (bframe + 8x8dct) and the problem with mkv under TCPMP. But as I understand the CoreAVC ddshow filter was not effected by this mkv timing problem.

I will compile a new TCPMP build tomorrow.

Multithreaded decoding, x86-64bit build are on my todo list, the problem is time and I have to prioritize. Probably adding some mmx color space transformation support will be the first (which will also help TCPMP with other codecs)

CQM support was added a while back. The second version of ddshow filter already has it, but TCPMP binaries not yet.