CoreCodec/H.264 Codec "CoreAVC"

[Sasovics]

If any of you guys manage to get CoreAVC work with AviSynth, please let us know....

I don't really like FFDShow, I'd be much happier if it would work with AviSynth...

[Sagekilla]

You can use CoreAVC through Avisynth if you have Haali and use DirectShowSource.

At least that lets me do it.

[idbirch2]

I don't think we're doing anything wrong, Sasovics. I'm beginning to think the issue is with CoreAVC. I used AviSynth 2.58a 070917 like ACrowley suggested above (thanks!) and tried graphedit from Jay Bee's advice from above (Thanks!) and the results are pretty much the same. I think the issue is in version 1.6 of CoreAVC. Check out this thread (http://www.corecodec.com/forums/index.php?topic=544.0) at Core's site, especially the comments like "Coreavc is useless to me now." ;) Another indication is that Jay Bee's post above mentions that interlacing in CoreAVC crashes, but in 1.6 the ability to turn off deinterlacing was removed. Unfortunately, I can't find any way to rollback to 1.5. Ver 1.6.1 is said to be coming soon. We'll see.

Edit: Here's another clue that may be related: In ver 1.6's changes is included "Rewrite of the Directshow wrapper for better compability"

Langman
I can confirm this. I was trying to serve up an x264 and an AVC BluRay stream into HCEnc using avisynth. HCEnc would crash straight away and playing the avs in Media Player gives me the access violation errors. I rolled back to 1.5 and suddenly it works fine again.

[mikegun]

hi,

since I'm now owning a full hd device I'm having trouble with 1080p matroska files. decoder is core avc 1.6 pro.
my system freezes randomly and I have to turn off my htpc to reboot.
everything was fine with 720p output resolution. but with 1080p output there is trouble. I changed renderers from vmr7 to overlay, but that didn't changed anything. now it seems like a workaround could be to set refreshrate to 50hz instead of 60hz.
can anyone confirm that there is an issue or should I downgrade to 1.5 ?

regards,

mike

[nm]

Random freezing indicates a driver problem or hardware malfunction, which could be caused by bad memory (run memtest86+ (http://www.memtest.org/)) or overheating (is your system overclocked?).

[mikegun]

maybe it's the driver. haven't had any problems with 720p@60hz

[John64]

Windows x64 has been out since around 2005. It is currently 2008 and still there is no native 64bit H.264 decoder. I understand that it is complicated to account for differences in 64bit compilers and libraries. Windows Vista x64'd Media Center ships only as a 64bit binary as well as only allowing SPDIF pass-through from 64bit applications. Because of this, I need to use a 64bit H.264 decoder. While ffdshow-tryout has preliminary support for 64bit systems, its video component is by no means complete. This is one area where CoreCodec could really capitalize in my opinion. By not offering 64bit builds of your product you are loosing the customers who, like me, may only consider using your product for this purpose. When ffdshow-tryout 64bit builds work at the level of their 32bit counterparts, I will likely not consider your product, especially since the current ffdshow-tryout builds decode at more than acceptable speed on my system, aside from a couple artifacts.

I am wondering what is slowing down your release of a 64bit binary. Is it that you rely on mingw-w64 for compiling your code? If that is the case, why not contribute to a tool that you profit from by helping it support Windows X64 properly. Is it possible for a beta/alpha 64bit build that people can try, even if it is unofficial, unsupported and unoptimized?

By the way, I am not just using Vista X64 for the sake of using 64bit Windows. I am going to be running 8gb of ram in this machine by the end of next week, and a dual booting isn’t an option.

You mentioned earlier that there will be 64bit native builds this year, any idea when, even if it is just a guess?

[KoD]

I always wonder if the number of systems running 64bit OSes out there really justifies developing 64 bits builds of programs that do interesting low level work. Would be interesting to see some real statistics, like how Valve (http://www.steampowered.com/status/survey.html) does for its SteamPowered users, but this time for people at large.

My guess (highly biased) is that there are so few people running those OSes that development money and time would better be spent somewhere else in all cases.

[tomos]

i would imagine that people running 64bit windows OS's would be a % or less IMO

i mean when i uploaded my stats to steam I was honestly shocked at how the VAST majority of their users had single core CPU's. dual core usage was tiny and quad core? 2-3 % iirc.

[John64]

but that audience is useless for comparison to the audience of multimedia users. Gamers know that most games are optimized for single fast processors, not dual cores. In this situation, this is all the users of one specific game. It doesn't say anything about whether these users spend money on software or hardware. You are also forgetting that XP X64 was not only really hard to find, it was released a long time after XP 32bit, was mainly for a targetted audience and wasn't really XP. XP X64 was Server 2003 for the desktop in actuality.

Vista has 32 and 64bit releases at the same time. Also, there are a bunch of security benefits for using 64bit vista, and the 4gb memory boundary is already a problem for new computers. Most current computers bought are going to have 2gb of ram, which doesn't cross the boundary, however, 4gb is very soon going to be the norm for new computers, and 4gb requires a 64bit operating to make use of all of your 4gb unless you want to run Server 2003 or linux as some of your address space is used for hardware (700mb for me). PAE is available, but is a big hack. It is just 36/40 bit addressing with mapping functionality. This does nothing but increase latency and limiting compatibility

I think it is a chicken and egg situation as far as 64bit goes. We need more people to use 64bit before a lot of companies support it, but companies won't support it unless there are a lot of users.

Saying few people run 64bit without any substantiation is short sited, especially since most computers capable of running Vista are 64bit capable, and all consumer copies of vista come with the 64bit option.

All that aside, all I am saying is that I will only consider buying CoreAVC if it comes to market first with a reliable 64bit AVC decoder. Take that and do whatever you want with it.

CoreAVC focuses on effeciency. FFDshow/libavcodec have the same feature set as CoreAVC in the 32bit windows platform. They both have SMP support. The only major advantage is that it decodes slightly more efficiently (maybe ~10%) however, a lot of x264 encoded media doesn't even work properly with CoreAVC.

Doing a simple recompilation of your existing code with a 64bit compiler shouldn't be a major issue, unless you are using Mingw-W64, and in that case, maybe supporting that project would be the best option.

[Shinigami-Sama]

I agree
the only thing keeping masses of people from running 64bit is the fact that there isn't a whole lot of consumer 64bit apps
they could make a killing being the first on the block for 64bit

[Romario]

So, where is our CoreAVC guy to answer on this questions?

BetaBoy, please tell us your plans about 64-bit build?

[ADude]

CORE - Please release the new version and fix the DVB issue in the next version.

[squid_80]

Doing a simple recompilation of your existing code with a 64bit compiler shouldn't be a major issue, unless you are using Mingw-W64, and in that case, maybe supporting that project would be the best option.
If it's written in assembly (and probably is considering the speed) it all needs to be changed for x64. Worse still if it uses __asm {} blocks and visual studio, since inline assembly isn't supported for x64.
In short it's a bigger job than just recompiling. Being a commercial operation, CoreCodec would have to justify the cost of all this work with what they immediately expect to gain from it. Then you'd also probably have to maintain two separate codebases (for x86 and x64) making sure any bugfixes go into both, so ongoing costs are increased as well.

[John64]

is inline assembly not supported by current compilers or just in general on the x64 platform?

If it were done in C/C++ with no assembly as i beleive the current ffdshow-tryout 64bit builds are done, it should at least work. Having said that, it performs like a dog (40% of a Q6600). As i said before, the only way i am going to spend money on something i can get for free is if it has a workable 64bit implementation, since currently the 32bit ffdshow more than exceeds my needs and expectations

[squid_80]

Inline assembly is not supported by Visual Studio when targetting the x64 platform. Intel's compiler has no problem with it.

[ChronoCross]

is inline assembly not supported by current compilers or just in general on the x64 platform?

If it were done in C/C++ with no assembly as i beleive the current ffdshow-tryout 64bit builds are done, it should at least work. Having said that, it performs like a dog (40% of a Q6600). As i said before, the only way i am going to spend money on something i can get for free is if it has a workable 64bit implementation, since currently the 32bit ffdshow more than exceeds my needs and expectations

the whole lack of 64-bit software is what prevents me from upgrading to vista. I'm not going to waste time on 64-bit unless there is some stuff that actually uses it (if even a little). Plus Vista 32-bit is a waste I'm better off with XP.

I haven't really seen anything that benefits greatly from 64-bit other than native 4+GB Memory addressing. It does have potential however I am skeptical about it's true benefits as all my experiences with it thus far have been troublesome.

[John64]

Well, it is more evolution than revolution. It does have performance benefits for code that takes advantage of it. I am not really good with cpu architecture or assembly, but i beleive it has double the general purpose registers and something else that makes it even faster in 64bit mode. There are security benefits from using a 64bit os. The (extremely major) drawback is the prevalence of DRM. No driver can be installed unless it is digitally signed, which means that you won't be able to develop your own drivers. The only reason i care about 64bit AVC is that i can't output SPDIF unless i am using a 64bit media player. If it weren't for DRM, i would be fine.

Another nice thing about 64bit windows is that it is a dividing line, since certain assumptions can be made about hardware as to performance levels. It also allows API's and ABI's to be changed since everything needs a port anyway.

That all doesn't change the fact that i will buy the first good and reliable H.264 decoder to market. FFDshow-tryout works 100% in Windows Media Player, but has bugs in Media Center.

[Eretria-chan]

Inline assembly is not supported by Visual Studio when targetting the x64 platform. Intel's compiler has no problem with it.
I believe Microsoft wants to get rid of inline assembly altogether ;)

I am not really good with cpu architecture or assembly, but i beleive it has double the general purpose registers and something else that makes it even faster in 64bit mode.
Plus 64-bit registers! This can make the process able to process more data at once.
But I don't know how effective it is due to SSE since it has typically had precision up to 128-bits or so for a long time.

[John64]

that is stupid on microsoft's behalf. That is a feature that they shouldn't be exerting control on.

Either way, 64bit is a better architecture. Right now, the *only* issue i have is the lack of a good native 64bit H.264 decoder. Nothing else is a problem, since every other application works wonderfully under WoW64

[squid_80]

(Once again I must apologise for pulling a thread off-topic. Twice in two days.)
that is stupid on microsoft's behalf. That is a feature that they shouldn't be exerting control on.It's MS. They would like everyone to be dependant on *their* inventions... In this case it's .NET. They're not ashamed to remove beloved features (inline asm) or deprecate standard C functions (memcpy/set, strlen/cpy/dup, printf, scanf etc.) to help "push" people the way they want.Either way, 64bit is a better architecture.For sure. Writing assembly in x64 is great, 15 (+rsp) gp registers means you almost never have to spill and 16 XMM registers eliminates some issues caused by needing aligned memory for SSE vs. being able to use unaligned MMX. I find speed in most cases is just an added benefit, being able to write a whole function without allocating any space on the stack for variables is so much easier.

[CruNcher]

CoreAVC interoperability problems list:
Sonic HD Demuxer (EVO) (Hardware Deinterlacing Detection Fails frames get droped)
Sonic MPEG Demultiplexer (EVO) (No Connection Possible)
Mainconcept Mpeg Demultiplexer (EVO) (No Connection Possible)
Arcsoft MPEG Demux (EVO) (No Connection Possible)

Practicly all of those Decoders from these Companies are interoperable to each others Splitter/Demulitplexer, only CoreAVC has major problems here.

Mainconcept Mpeg Demultiplexer:
Mainconcept H264 Decoder = OK
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK (old Mainconcept Decoder)
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Sonic HD Demuxer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = Hardware Deinterlacing Problems (frames skipped)

Sonic MPEG Demultiplexer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Arcsoft MPEG Demux:
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

[BetaBoy]

CoreAVC interoperability problems list:
Sonic HD Demuxer (EVO) (Hardware Deinterlacing Detection Fails frames get droped)
Sonic MPEG Demultiplexer (EVO) (No Connection Possible)
Mainconcept Mpeg Demultiplexer (EVO) (No Connection Possible)
Arcsoft MPEG Demux (EVO) (No Connection Possible)

Practicly all of those Decoders from these Companies are interoperable to each others Splitter/Demulitplexer, only CoreAVC has major problems here.

Mainconcept Mpeg Demultiplexer:
Mainconcept H264 Decoder = OK
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK (old Mainconcept Decoder)
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Sonic HD Demuxer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = Hardware Deinterlacing Problems (frames skipped)

Sonic MPEG Demultiplexer
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

Arcsoft MPEG Demux:
Arcsoft Video Decoder = OK
Cyberlink H264 Decoder = OK
Sonic H264 Decoder = OK
Sonic Cinemaster Video Decoder = OK
CoreAVC 1.6 = No Connection

We are aware of the issue and are working on the fix... in the meantime today we are releasing CoreAVC 1.6.5

On 64bit.... yes it is planned for a later release... but likely this would not be till 2.0 with the release of the CoreAVC encoders.

Also note in 3 weeks on February 21st we are releasing CorePlayer Pro for XP/Vista and OS X that will have CoreAVC Pro integrated into it. On XP/Vista our AVC testing shows at least a 8-15% improvement over the directshow version of CoreAVC. While OS X..... well its not even close as we are at least 40% faster then Quicktime / Quicktime Pro ;-) . . . CorePlayer Pro for Linux is planned for release in April (x11, GTK and QT, QTopia). Also on interface's... this is also the first desktop release to the public of our CoreUI widget interface (think QT but faster, simplier, and lighter).... we will post this on CoreForge.org in the next couple of weeks as OSS.

[BlackSun]

We are emailing people with the 1.6.5 update right now. It takes some time to send all those emails, so please be patient.

Here is the changelog:
CoreAVC H.264 Video Codec - Version 1.6.5.0 (20080129)
- Add: Ignore past display order frame when invalid
- Add: Disable deblocking option for slower computers
- Add: Support for MV out of specs (fix artifacts for buggy files)
- Fix: Green frames display with incomplete frames
- Fix: Some minor improvements with DVB Viewer
- Fix: Deinterlacing fixes with internal bob
- Fix: Settings dialog glitchs
- Fix: Renamed Weave deinterlacing to "None (Weave)" to avoid confusion
- Fix: Others internal fixes

[bob0r]

We are emailing people with the 1.6.5 update right now. It takes some time to send all those emails, so please be patient.

Here is the changelog:
CoreAVC H.264 Video Codec - Version 1.6.5.0 (20080129)
- Add: Ignore past display order frame when invalid
- Add: Disable deblocking option for slower computers
- Add: Support for MV out of specs (fix artifacts for buggy files)
- Fix: Green frames display with incomplete frames
- Fix: Some minor improvements with DVB Viewer
- Fix: Deinterlacing fixes with internal bob
- Fix: Settings dialog glitchs
- Fix: Renamed Weave deinterlacing to "None (Weave)" to avoid confusion
- Fix: Others internal fixes

Nice! :thanks:

[Jay Bee]

Geez, do you guys even test your decoder before release? All the interlaced files at http://x264.nl/h.264.samples/ deinterlace at 25 fps instead of 50 fps. Deinterlace mode is set to Hardware. Also the decoder only shows a black screen when connected to EVR (in Win XP). Back to 1.5 for me. I'm really tempted to go and buy a dxva capable GPU now so that I can use Cyberlink decoder. The waiting time for a working CPU decoder is getting ridiculous.

[Atak_Snajpera]

connected to EVR (in Win XP)

EVR is available in Vista

[bob0r]

Geez, do you guys even test your decoder before release? All the interlaced files at http://x264.nl/h.264.samples/ deinterlace at 25 fps instead of 50 fps. Deinterlace mode is set to Hardware. Also the decoder only shows a black screen when connected to EVR (in Win XP). Back to 1.5 for me. I'm really tempted to go and buy a dxva capable GPU now so that I can use Cyberlink decoder. The waiting time for a working CPU decoder is getting ridiculous.

Most Samples are 25fps progressive.
Blend = 25fps deinterlace
Bob = 50fps deinterlace
Hardware = I agree, this is a weird name for what used to be DirectShow deinterlacing, not 100% what that does though.

EVR is Vista indeed, some have made XP patches but they are not 100% confirmed or used widely.

You can indeed buy another GFX card, as long as you like no deblocking in GPU hardware mode, oh and no crop/color flags reading. Cyberlink fails epicly on those.

CoreAVC = read even set crop flags CoreAVC = read and set color flags correctly: INPUT: TV, OUTPUT: PC = black==black on LCD-PC monitors.

If you really want to spend some money, i recommend an Intel Q6600 Processor + CoreAVC, even 40mbit H.264 files play like mpeg1 files then :)

(And yes, CoreAVC is still the fastest decoder, yet Cyberlink isn't far away if you dont count deblocking :p)

[nm]

You can indeed buy another GFX card, as long as you like no deblocking in GPU hardware mode, [...]
I thought that problem only concerned the previous GPU generation (GeForce 7xxx, Radeon 1xxx). Do the newer cards, that do most of the decoding on hardware, also cheat on deblocking?

[ADude]

Betaboy -

The "Haali Media Splitter" that is installed by CoreAVC Pro 1.6.5 - what version is that ?

More than the number, I'm wondering whether:

- You get the latest "stable" or "release" version just before you create a new installer

OR

- You get the latest "beta" version just before you create a new installer

OR

- Oops, we actually don't always remember to check for new versions of it when we release our own new version (I included this choice, because it is the usual operating mode for other paid software like Zoom Player...)

[Figured I'd get a faster response here than on the Core Forums. ;) ]

[Disabled]

Great news and a big thank you for including the bad MV fix.

@ADude They included the latest version from 29/12/2007, the installer is a different binary though (72kb smaller but same content)

[Jay Bee]

EVR is available in Vista

Many players can use EVR in XP too. My point is that ZP+CoreAVC_1.5+EVR works fine while now most files just show a black screen.

Most Samples are 25fps progressive.
Blend = 25fps deinterlace
Bob = 50fps deinterlace
Hardware = I agree, this is a weird name for what used to be DirectShow deinterlacing, not 100% what that does though.


I'm obviously talking about the samples that are true interlaced, not the 25 fps files that are encoded as if. I don't have a problem with the name "Hardware", it seems clearer to me than the name directshow deinterlacing. My problem is that CoreAVC is supposed to tell my GPU to do deinterlacing without destroying the temporal resolution. Again, it worked fine in 1.5, got broken in 1.6 and isn't fixed properly now, months later.


You can indeed buy another GFX card, as long as you like no deblocking in GPU hardware mode, oh and no crop/color flags reading. Cyberlink fails epicly on those.

CoreAVC = read even set crop flags CoreAVC = read and set color flags correctly: INPUT: TV, OUTPUT: PC = black==black on LCD-PC monitors.

If you really want to spend some money, i recommend an Intel Q6600 Processor + CoreAVC, even 40mbit H.264 files play like mpeg1 files then :)

Deblocking works on the newer generation of cards, just not on mine. While there may be a colour flag problem, that is surely a small problem compared to deinterlacing problems. A Quad core CPU won't do anything to help hardware deinterlacing and a GPU upgrade would be cheaper anyway.

And yes, I agree that CoreAVC is by far the fastest and most compatible decoder. I'm just annoyed that real world use like watching HDTV is given so little consideration compared to watching Apple trailers and pirated anime. When I bought CoreAVC 2 years ago I thought it would enable me to just throw in a DVB-S2 card and allow me to watch HDTV. To this day I haven't bought the card because I can't justify spending money on something that doesn't work. And I'm annoyed that Core always take months to release new versions and I usually need about two minutes to find new problems.

I thought that problem only concerned the previous GPU generation (GeForce 7xxx, Radeon 1xxx). Do the newer cards, that do most of the decoding on hardware, also cheat on deblocking?

As far as I know the newer cards don't cheat but it's hard to find any real information on this as most people don't care.

EDIT: when set to "bob" the EVR problem goes away. But it also brings my X2@2.8 Ghz to it's knees.

[John64]

what is the timeframe on version 2.0 when the encoder and 64bit directshow filter is out?

[Sasovics]

We are emailing people with the 1.6.5 update right now. It takes some time to send all those emails, so please be patient.

Here is the changelog:
CoreAVC H.264 Video Codec - Version 1.6.5.0 (20080129)
- Add: Ignore past display order frame when invalid
- Add: Disable deblocking option for slower computers
- Add: Support for MV out of specs (fix artifacts for buggy files)
- Fix: Green frames display with incomplete frames
- Fix: Some minor improvements with DVB Viewer
- Fix: Deinterlacing fixes with internal bob
- Fix: Settings dialog glitchs
- Fix: Renamed Weave deinterlacing to "None (Weave)" to avoid confusion
- Fix: Others internal fixes

What about avisynth compatibility ?

[Viper Zx]

Version 1.6.5 is a trial version!?

In ONE week she is expired! Try it!


http://www.corecodec.com/forums/index.php?topic=683.0


Edit:
You must reload the 1.6.5 Update, there was a silent update, it´s OK now. :)



Tschau

Viper Zx

[BlackSun]

Version 1.6.5 is a trial version!?

In ONE week she is expired! Try it!



The mailling list got buggy when I updated the file to fix a latest bug and mixed files, if you got such version, please go to: http://www.coreavc.com/retrieve

[pankov]

BlackSun/Betaboy,
I've been asking for a long time for a way to change the email that is currently active for my purchase. In my case the purchase was made from a friend of mine because PayPal/Core wasn't available for my country yet. I don't want to bug her every time a new version is out or I have to retrieve a new download link (like in this case with the mixed up files) so I just want you to change my registration from hers e-mail address to my personal. Will this be possible and how?

[Selur]

Got the same problem,...

[BlackSun]

Unfortunately the way we send new version (e-junkie) does not allow to change user data (which is sad, I agree). Later we hope to have our own simple solution that would allow such things.

[BetaBoy]

Jay Bee.... Test? Extensively, we even have half the Doom9 Elite testing prior to each release and the issue was _not_ reported. So atm we are looking into the EVR issue... and we have already identified the issue with interoperability and it will be fixed with the next release.

[CruNcher]

Glad to hear that you found the interoperability problems with the other Demultiplexers :) and also nice to hear that CorePlayer Desktop is ready to be released, so i suspect that http://www.betaplayer.com/ and http://www.coreplayerx.com/ are also not far away from seeing the shine of the morning sun? ;)

[BetaBoy]

CorePlayerX has changed direction slightly... It will still remain as an OEM licensable stand alone installer for IE, FF, Moz, Netscape, and Opera...

But the biggest news is our addition of an HTML5 Web-Kit / Safari plug-in (OS X, iPhone, Windows, Linux). All of which will be installed into both CorePlayer versions later this year. However the iPhone version of CorePlayer Mobile will get the HTML5 plug-in first for Web-Kit in April/May.

[Momber]

Hi!

Thanks for re-introducing the deblocking options. With them it's indeed possible to shave a few percent off CPU usage, which is my main concern.

However, 1.6.5 doesn't seem to make good use of both my (logical) CPU threads. Previous versions fared better in that regard.

Here is a comparison with a late build of ffdshow (rev1803_20080120_xxl), used on a high bitrate 720p x264 file.

http://img85.imageshack.us/img85/5127/core165xu2.jpg

Regards
S.

[Dark Shikari]

What does "skip when safe" actually do?

Does it mean "skip unreferenced B-frames"? Does it mean "skip when the threshold is high enough that it would have minimal effect at that QP"?

[ChronoCross]

Hi!

Thanks for re-introducing the deblocking options. With them it's indeed possible to shave a few percent off CPU usage, which is my main concern.

However, 1.6.5 doesn't seem to make good use of both my (logical) CPU threads. Previous versions fared better in that regard.

Here is a comparison with a late build of ffdshow (rev1803_20080120_xxl), used on a high bitrate 720p x264 file.

http://img85.imageshack.us/img85/5127/core165xu2.jpg

Regards
S.

does even distribution really matter? In this case the one CPU is much lower than the second but the overall usage is less than ffdshow so your still getting better performance.

[BetaBoy]

nice to hear that CorePlayer Desktop is ready to be released

A note with CorePlayer Pro.... its really only for a small demographic at this time in the 1.xx phase. Its by no means a WMP, ZP, MPC, TCMP from a 'features' perspective. IE; no-dvd, blu-ray, subtitle, CDA support at this time... However its CORE is a great base to begin with to add all those desktop related features into.

[Momber]

does even distribution really matter?
Not in the example obviously. But when I try to play a 1080p file, one thread goes through the roof while the other one has cycles to spare.

[bmnot]

What does "skip when safe" actually do?

Does it mean "skip unreferenced B-frames"? Does it mean "skip when the threshold is high enough that it would have minimal effect at that QP"?

I'd like to know this too.

[ChronoCross]

Not in the example obviously. But when I try to play a 1080p file, one thread goes through the roof while the other one has cycles to spare.

Does the clip play choppy due to it?

[Jay Bee]

Jay Bee.... Test? Extensively, we even have half the Doom9 Elite testing prior to each release and the issue was _not_ reported. So atm we are looking into the EVR issue... and we have already identified the issue with interoperability and it will be fixed with the next release.

Good to hear that you are looking into it. BTW the deinterlacing problem is not just with EVR, it's with WMR7/8 as well. And even if your l33t testers didn't report deinterlacing problems, I did, over two months ago (http://forum.doom9.org/showpost.php?p=1060900&postcount=3289). And so did Momber (http://forum.doom9.org/showpost.php?p=1060668&postcount=3284) who you even replied to. The problem is still there. I'll post it here again, this time with some colourful bits.

1.5

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Output

- Connection media type:

Video: YUY2 1472x1080 (491:270) 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YUY2 {32595559-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3179520
cbFormat: 1152

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

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x000000a1
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 1964
dwPictAspectRatioY: 1080
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1472
biHeight: -1080
biPlanes: 1
biBitCount: 16
biCompression: YUY2
biSizeImage: 3179520
biXPelsPerMeter: 1555200
biYPelsPerMeter: 2121120
biClrUsed: 0
biClrImportant: 0



1.6

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Output

- Connection media type:

Video: YUY2 1472x1080 (7447:4096) 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YUY2 {32595559-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3179520
cbFormat: 1152

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

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000025
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 7447
dwPictAspectRatioY: 4096
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1472
biHeight: -1080
biPlanes: 1
biBitCount: 16
biCompression: YUY2
biSizeImage: 3179520
biXPelsPerMeter: 4096
biYPelsPerMeter: 5585
biClrUsed: 0
biClrImportant: 0




I don't know exactly what the values of the flags stand for but I know that 1.5 works and 1.6.x doesn't.