CoreCodec/H.264 Codec "CoreAVC"

[BetaBoy]

I think that's their "hack" to avoid the Microsoft decoders and allow CoreAVC 2.0 to be used inside WMP/WMC ;)

And you can turn it off in Haali's options :p

Hack? I'd not even compare that to that of renaming DLL's and the like . In fact we have had no less then a dozen companies that have emailed us since the CoreAVC 2.0 / Haali launch, asking for information on how they can do the same thing for their applications.

Almost each of the companies stated that the solution to add a custom mediatype to bypass mediafoundation is the easiest way to not fall into the pitfalls that they each have tried to work with, with little success.

Did I say that MF is evil? :-)

[LoRd_MuldeR]

I didn't want criticize your method. Instead it should be criticized that such workarounds (if you prefer that word) are needed. Oh, and I used the quotation marks for a reason ;)

BTW: I wonder how long it will take until M$ comes up with a way to block your method ^^

[avivahl]

So you guys simply "fake" the FOURCC code of the H.264 stream to be something else in order to avoid Microsoft's decoder from accepting it? What if I'll install Haali Media Splitter and want ffdshow to decode the video...? Would ffdshow accept this FOURCC code?

[LoRd_MuldeR]

So you guys simply "fake" the FOURCC code of the H.264 stream to be something else in order to avoid Microsoft's decoder from accepting it? What if I'll install Haali Media Splitter and want ffdshow to decode the video...? Would ffdshow accept this FOURCC code?

Did you read the last few posts in this thread? It appears you didn't, because the answer to your question was given twice already :p

Anyway, ffdshow does support Haali's new "custom" H.264 media type already:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=3169

[avivahl]

Did you read the last few posts in this thread? It appears you didn't, because the answer to your question was given twice already :pOh, i missed the line that says "you can turn it off in Haali's options"... So wait a minute... Is it the default value (faking FOURCC set to ON) when installing Haali as standalone?

[LoRd_MuldeR]

Oh, i missed the line that says "you can turn it off in Haali's options"... So wait a minute... Is it the default value (faking FOURCC set to ON) when installing Haali as standalone?

Yes, because otherwise people will complain that they can't use anything but Microsoft's H.264 decoder in WMP/WMC :rolleyes:

Remember that without the "custom media type" workaround we can't even use ffdshow in WMP/WMC, at least not without the help of clsid's tool.

And as ffdshow accepts Haali's workaround, you'd only need to turn off the custom media type for other H.264 decoders...

[avivahl]

Thank you for the clear information! :)

[squid_80]

Yes, because otherwise people will complain that they can't use anything but Microsoft's H.264 decoder in WMP/WMC :rolleyes:

Remember that without the "custom media type" workaround we can't even use ffdshow in WMP/WMC, at least not without the help of clsid's tool.

Hasn't anyone bothered to check what those registry entries are after installing CoreAVC?

[Ice =A=]

Congratulations on releasing CoreAVC 2.0!

And while we're at it I wanted to say again that ANY 720p AVC video file I ever tested did run flawlessly on an Intel Atom single core with CoreAVC 1.5 upwards! (On any other cpu out there 720p playback is fast enough anyway.)
Nevertheless I'd welcome any speed improvements on Atom cpus which might result in saving some energy and extending run time!

So for me bying CoreAVC 2 depends on speed improvements on Atom cpus and I'm really looking forward to some benchmarks! :)

[lnatan25]

I didn't want criticize your method. Instead it should be criticized that such workarounds (if you prefer that word) are needed. Oh, and I used the quotation marks for a reason ;)

BTW: I wonder how long it will take until M$ comes up with a way to block your method ^^
How about developing a Media Foundation codec, instead of resorting to hacks? No quotation marks are required, this is indeed a hack, even if it is a mild one.

[BetaBoy]

Why? Simple why should developers adopt a technology that provides no added value other then lock them into DRM restrictions?

[lnatan25]

The DRM facilities are there only if you want them.

You don't want to adopt, that's fine, just don't take offense when your bypass method is called what it is, a hack. MF evil or not, you made a hack around it. :)

[BetaBoy]

Please... if that were the case then everyone would be making MF codecs... but the truth is they are not. If 'you' want to call a custom mediatype a hack then so be it, in the end it bypasses MediaFoundation and that's all that counts to most of us.

[Ice =A=]

Just my opinion:
If I had to choose between DRM or any kind of proprietary solution on one side and a workaround or hack or whatever you call it on the other side I'd choose the latter without hesitation!

The DRM facilities are there only if you want them.It's just that I don't want them to be possibly there!!! :)

[lnatan25]

It's just that I don't want them to be possibly there!!! :)
May I ask what operating system you are using?

[BetaBoy]

lnatan25... I see where you are going? We could make it possible that the custom mediatype to only be used in Windows 7. I'll sync with guys on it.

[Disabled]

Isn't WMP the only app that uses MF? Wouldn't it even be more feasable to only use the new mediatype when a MF compatible app is used?

[lnatan25]

WMP and WMC, and possibly any future media application by Microsoft.

[squid_80]

How about developing a Media Foundation codec, instead of resorting to hacks? No quotation marks are required, this is indeed a hack, even if it is a mild one.
"Hey let's use this new framework from MS called activemovie."
"Hey let's use this new framework from MS called directshow."
"Hey let's use this new framework from MS called DMOs."
"Hey let's use this new framework from MS called Media Foundation."

I think you can see where I'm going here.

[BetaBoy]

lnatan25... I see where you are going? We could make it possible that the custom mediatype to only be used in Windows 7. I'll sync with guys on it.
I was reminded that's how it works now... Win 7 only.

[lnatan25]

BetaBoy, any news on when the CorePlayer Mobile platform will receive the H.264 decoding improvements?

[BetaBoy]

We are planning to release CorePlayer 2.0 in Q1 next year that will feature the current improvements as well as the ARM Cortex NEON A8 improvements for AVC (and AAC, MP3, ASP by then).

We will be demo'ing at CES and if anyone wants to see whats going on with it and our other products, pls email: info@corecodec.com with the blog, companies you are with and I'll give you a schedule of our planned CES events.

[lych_necross]

How about developing a Media Foundation codec, instead of resorting to hacks? No quotation marks are required, this is indeed a hack, even if it is a mild one.
The reason is simple. No offense intended, but I believe that programmers are inherently lazy and choose to implement "hacks" to fix problems instead of rewriting the offending code correctly.

[BetaBoy]

The reason is simple. No offense intended, but I believe that programmers are inherently lazy and choose to implement "hacks" to fix problems instead of rewriting the offending code correctly.
That's not the case here that's for sure. MF codecs are as simple to make as directshow ones.

[88keyz]

Did my own little tests to compare performance of CoreAVC 2.0 with MPC Video Decoder r.1448 and here are my results using the following MKV file:


General
Complete name : C:\Sample.720p.AC3.x264.mkv
Format : Matroska
File size : 78.5 MiB
Duration : 1mn 2s
Overall bit rate : 10.5 Mbps
Encoded date : UTC 2007-07-22 17:15:17
Writing application : mkvmerge v2.0.2 ('You're My Flame') built on Mar 5 2007 12:54:12
Writing library : libebml v0.7.7 + libmatroska v0.8.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Muxing mode : Container profile=Unknown@5.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 2s
Bit rate : 9 698 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.439
Stream size : 72.1 MiB (92%)
Language : English

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 1mn 2s
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Surround: L R, LFE
Sampling rate : 48.0 KHz
Video delay : 8ms
Stream size : 4.76 MiB (6%)


System:
Windows 7 Ultimate x64
Core i7 860
8 GB DDR3-1333
MPC-HC r.1448 - x64

CPU Software Decoding:
CoreAVC 2.0 - 5.94% Avg. CPU usage
MPC Video Decoder r.1448 - 8.17% Avg. CPU usage

GPU Accelerated Decoding:
CoreAVC 2.0 - 2.13% Avg. CPU usage
MPC Video Decoder r.1448 - 1.94% Avg. CPU usage

So as you can see CoreAVC is the faster software decoder (which I think we all knew) but DXVA is still quicker than CUDA when it comes to GPU acceleration. The difference is minimal but it is there.

Also, for those of you with Windows 7 there is a great little tool out there that will allow you to select the system default decoder for many of the most popular codecs. Works great and its something I would highly recommend.

Preferred Filter Tweaker for Windows 7 (http://www.codecguide.com/windows7_preferred_filter_tweaker.htm)

[lnatan25]

The reason is simple. No offense intended, but I believe that programmers are inherently lazy and choose to implement "hacks" to fix problems instead of rewriting the offending code correctly.
I really have no problem with this. The majority of their target audience is using DirectShow, so for now at least, they don't find reason in maintaining two different branches - one for DS and one for MF. What I was commenting on, was that BetaBoy took offense to the word "hack". :)

[me7]

So as you can see CoreAVC is the faster software decoder (which I think we all knew) but DXVA is still quicker than CUDA when it comes to GPU acceleration. The difference is minimal but it is there.

This is already well known. DXVA and CUDA use the same decoding hardware, but DXVA outputs the video directly after decoding while CoreAVC + CUDA copies each frame back into RAM first, which does take longer but allows other filters (like subtitle filters) to alter the frame.
It's not a disadvantage, it's a feature :)

[dimitrik]

I really have no problem with this. The majority of their target audience is using DirectShow, so for now at least, they don't find reason in maintaining two different branches - one for DS and one for MF. What I was commenting on, was that BetaBoy took offense to the word "hack". :)

And as part of that audience, I have an added reason for supporting this which is that ALL my codecs are directshow filters, not just CoreAVC. So bypassing MF is definitely something I want for all filetypes, hence I resort to this and other similar hacks to be able to set up my HTPC the way I want to. Or I stick with Vista (which for now is actually fine).

But if I have to use MF codecs which will restrict my ability to play each filetype with the best possible decoder, I might as well bite the bullet and switch to XMBC under linux or something, which will have a learning curve but finally free me from the MS cr*piness.

As for calling it a hack or not, to each his own. I'm fine with calling it anything, why should it matter as long as it gets me where I want to go today:p

[JeffBDVS]

Can anyone (Core-folk or not) confirm or deny a crash in VirtualDub when using CoreAVC as the DirectShowSource decoder in an AviSynth MT script that resizes HD video down to SD frame sizes? Setting MTMode to (2,0) causes the crash. If I set MTMode to (3,0), then the script runs at only 3 -4 fps on an 8-core machine.

Thanks,
-Jeff

[Blue_MiSfit]

But if I have to use MF codecs which will restrict my ability to play each filetype with the best possible decoder, I might as well bite the bullet and switch to XMBC under linux or something, which will have a learning curve but finally free me from the MS cr*piness.


Then forget about any DirectShow decoders :) You loose ffdshow and avisynth post processing in Linux.
~MiSfit

[ChronoCross]

/me prods BetaBoy for returning customer email.

ffdshow is just not doing it for me...

[lnatan25]

Can anyone (Core-folk or not) confirm or deny a crash in VirtualDub when using CoreAVC as the DirectShowSource decoder in an AviSynth MT script that resizes HD video down to SD frame sizes? Setting MTMode to (2,0) causes the crash. If I set MTMode to (3,0), then the script runs at only 3 -4 fps on an 8-core machine.

Thanks,
-Jeff
Confirmed.

And to stop CoreAVC being the DirectShow source used, you have to disable the input colorspace. :rolleyes: What is the point of having a "Preferred decoder" check box, when it has no effect whatsoever? :rolleyes:

[JeffBDVS]

Confirmed.

And to stop CoreAVC being the DirectShow source used, you have to disable the input colorspace. :rolleyes: What is the point of having a "Preferred decoder" check box, when it has no effect whatsoever? :rolleyes:
Thanks for confirming that.

CoreAVC may not be the sole guilty party here. I updated AC3 Filter to 1.63b, and I'm running some tests now where I set the MTMode to (3,0) before the DirectShowSource command, and then switch to MTMode(2) after it. With CUDA preferred in CoreAVC, I've gotten a couple of short conversion runs at frame rates of 30 - 50 fps without crashing.

I'm running a long test now. The short tests ended up with artifacts in the output files, but that may be an output codec issue. The short tests were done with UT 7.02, but the long test is being done with Lagarith.

-Jeff

[mandarinka]

post 5265 (http://forum.doom9.org/showpost.php?p=1348040&postcount=5265)

Sadly, it seems that the bug that caused coreavc 1.9.5 to crash or corrupt decoded video is still alive and well in version 2.0.
Are there any plans to look into this?

[JeffBDVS]

Thanks for confirming that.

CoreAVC may not be the sole guilty party here. I updated AC3 Filter to 1.63b, and I'm running some tests now where I set the MTMode to (3,0) before the DirectShowSource command, and then switch to MTMode(2) after it. With CUDA preferred in CoreAVC, I've gotten a couple of short conversion runs at frame rates of 30 - 50 fps without crashing.

I'm running a long test now. The short tests ended up with artifacts in the output files, but that may be an output codec issue. The short tests were done with UT 7.02, but the long test is being done with Lagarith.

-Jeff
MT in AviSynth with CoreAVC 2.0 is unusable. Even with the filter tweaks to prevent crashing VirtualDub, the final output is time-jumbled. Some frames appear whole seconds before they're supposed to, some frames are missing completely. Apparently the multi-threaded MT pipeline and CoreAVC's multi-threading are incompatible unless MT is slowed waaay down.

The artifacts I mentioned were eliminated by adjusting settings in the players I used to view the video, so CoreAVC isn't introducing any artifacts, even in the time-jumbled clips. Both UT and Lagarith produced high-quality output, which I was able to confirm after the settings adjustments.

So far, software decoding with CoreAVC (versus CUDA GPU decoding) seems to be the way to go for me.

-Jeff

[squid_80]

What is the point of having a "Preferred decoder" check box, when it has no effect whatsoever? :rolleyes:
The checkbox lowers the decoder's priority from preferred to normal. If it still gets used then your other decoder has the same/lower priority, or doesn't handle the required input/output formats.

[saint-francis]

Personally I have never been able to use DirectShowSource with SetMTMode (2,0) You have to start with (3,0) and switch to (2,0) after. This isn't a CoreAVC bug. It has to do with DSS.

[JeffBDVS]

Personally I have never been able to use DirectShowSource with SetMTMode (2,0) You have to start with (3,0) and switch to (2,0) after. This isn't a CoreAVC bug. It has to do with DSS.
Thanks!

The filter tweaks I mentioned in my last post? Your solution is exactly what I did to fix the crash when CUDA was enabled. I should have been more specific.

If software rendering in CoreAVC is used instead, the 3-then-2 solution results in conversion frame rates less than 10 fps. Bad juju.

The new, big problem is the converted output video and its jumbled frames when using MT. I *don't* have a solution for that other than to not use MT.

-Jeff

[Virtual_ManPL]

bump, not fixed in CoreAVC Professional 2.0.0

I find 2 bugs in CoreAVC Professional 1.9.5.0

1 bug
I see blocks in CUDA mode, soft mode decode this properly
x264 - core 55 - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:-6:-6 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=2 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=2 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=250 keyint_min=25 scenecut=40(pre) rc=2pass bitrate=5299 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30 zones aq=1:0.3:15.0
file:
CoreAVC-large-motion-vectors-x264-b0rk.mkv (http://www.cccp-project.net/beta/test_files/CoreAVC-large-motion-vectors-x264-b0rk.mkv)
http://img101.imageshack.us/img101/9430/coreavc1.th.png (http://img101.imageshack.us/i/coreavc1.png/)



2 bug
frames are wrongly decoded in CUDA and soft mode, internal MPC-HC decoder decode this properly
OLS05lossless--avisource_82_92.mp4
x264 - core 55 svn-663C - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=7 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=32 chroma_me=1 trellis=1 8x8dct=1 cqm=2 deadzone=21,11 chroma_qp_offset=0 threads=1 nr=0 decimate=1 mbaff=0 bframes=2 b_pyramid=1 b_adapt=1 b_bias=0 direct=2 wpredb=1 bime=1 keyint=240 keyint_min=25 scenecut=40 rc=2pass bitrate=1717 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30
file:
OLS05lossless--avisource_82_92.mp4 (http://www.cccp-project.net/beta/test_files/OLS05lossless--avisource_82_92.mp4)

CoreAVC
http://img192.imageshack.us/img192/4695/coreavc2.th.png (http://img192.imageshack.us/i/coreavc2.png/)
internal MPC-HC decoder
http://img192.imageshack.us/img192/6159/mpchc.th.png (http://img192.imageshack.us/i/mpchc.png/)



and you can also try other files on this FTP (http://www.cccp-project.net/beta/test_files/) to check that everything working properly with CoreAVC 2.0 before official release ;)

[squid_80]

I told you, those streams are invalid.

[Virtual_ManPL]

and I told you too :p


first file is properly decoded in soft mode, not in CUDA

second file is decoded with less errors, look even on SS (better error resilnience?) in soft mode in MPC-HC (DiAVC in near future will decode this like MPC-HC decoder or better like I heard), CoreAVC have problems with it

[iSunrise]

@BetaBoy:
Thanks for the great release. I have a rather complex chain setup, and from now on I can use CoreAVC 2.0.0 (with CUDA enabled) as a decoder, together with ffdshow as a post-processor AND madVR or Haali as renderer, while CPU usage is extremely low on a Core i7. I also have a very demanding avisynth MT script running which works very well with it.

One _very annoying_ and related bug, however, is that Haali`s new splitter package, v1.9.355.21 (which also comes with CoreAVC 2.0.0) doesn´t recognize VC-1 streams in M2TS containers anymore, while v1.9.42.1 worked flawlessly. I hope this issue can be solved quickly.

Keep up the good work and a happy new year in advance.

[JeffBDVS]

One _very annoying_ and related bug, however, is that Haali`s new splitter package, v1.9.355.21 (which also comes with CoreAVC 2.0.0) doesn´t recognize VC-1 streams in M2TS containers anymore, while v1.9.42.1 worked flawlessly.
Concur.

-Jeff

[JohnnyFu]

v1.9.355.21 (which also comes with CoreAVC 2.0.0) doesn´t recognize VC-1 streams in M2TS containers anymore, while v1.9.42.1 worked flawlessly. I hope this issue can be solved quickly.

Keep up the good work and a happy new year in advance.

Oh my gosh... and I thought haali couldn't handle VC-1 in m2ts at all. I remuxed tons of VC-1 streams into matroska containers during christmas days haha....

However, I second your last comment!

[jj666]

and I told you too :p


first file is properly decoded in soft mode, not in CUDA

second file is decoded with less errors, look even on SS (better error resilnience?) in soft mode in MPC-HC (DiAVC in near future will decode this like MPC-HC decoder or better like I heard), CoreAVC have problems with it

File #1 is a rule 6 violation, so you shouldn't ask about it here.

Cheers,

-jj-

[Virtual_ManPL]

Who cares about stupid rules (I dunno even where is the topic about it...) :rolleyes:

IMO better is helping in bug reporting...
And thats is only SAMPLE, not full movie or sth ;)

[Guest]

Who cares about stupid rules (I dunno even where is the topic about it...) :rolleyes:
Your attitude has just bought you a rule 6 strike. You may not discuss warez here.

[rpm7200]

coreavc rgb32 is really bad but ffdshow's rgb32 is good. please download this youtube video's and force coreavc and ffdshow rgb32 output. they output are really different. it is very important. sample is here http://www.youtube.com/watch?v=LN5lF4dp3cs

[leeperry]

has there been any test w/ a wattmeter between CUDA and software decoding? apparently CUDA would consume far less electricity?

[JohnnyFu]

has there been any test w/ a wattmeter between CUDA and software decoding? apparently CUDA would consume far less electricity?

Not CUDA but DXVA....
Leistungsaufnahme (Power Consumption) - BluRay
http://www.computerbase.de/artikel/hardware/grafikkarten/2009/test_grafikkarten_2009/22/#abschnitt_bluraymultimonitorverbrauch

Leistungsaufnahme (Power Consumption) - Idle / Last (Load)
http://www.computerbase.de/artikel/hardware/grafikkarten/2009/test_grafikkarten_2009/21/#abschnitt_leistungsaufnahme

Sorry it's a german site...