CoreCodec/H.264 Codec "CoreAVC"

[Mixer73]

Mixer73... Depending on which method used for DXVA, it will always use less CPU over CUDA. RAM usage in our testing is negligible outside of the GPU, but the wave in recent months has been an increasing number of apps going 64bit. Windows 7 (and cheap ram) imho is driving this and that's a good thing, although technically there are not many advantages for decoding.

Clarify for me, CUDA will use less CPU than outright DXVA or the other way around.

I'm a fan of your product, seat of the pants tells me it worked better with CoreAVC than Win7's default codec, but I feel that I want to install as few third party things as possible on the machine.

[CiNcH]

Clarify for me, CUDA will use less CPU than outright DXVA or the other way around.
AFAIK, CUDA copies back the decompressed video into main memory, which takes some CPU time. The pro is that you can post process video in "software".

[Shii]

As stated, CoreAVC 2.0 w/Haali splitter now makes MKV the default for directshow

What about mp4? Will WMC and WMP use CoreAVC 2.0 for decoding mp4 h264 files?

[hydra3333]

... and you can only go back and blame MS for creating MediaFoundation which is really not needed (in our opinion) unless you want to push EVR/DXVA, DRM, or finite Codec/Splitter control (although some would argue this point). Does anyone see a compelling reason to switch after seeing this comp chart? http://msdn.microsoft.com/en-us/library/aa468614.aspx#appendix_feature_comparisons__zftb

Nope, M$ are only in it for the almighty US $ that they and their rich mates pray to... text from that M$ link says it all
The key feature of Media Foundation that supports protected content is the Protected Media Path (PMP), which provides a protected environment for running audio and video processing pipelines.
i.e. they want to suck the life out of your PC and stop you from doing things you want to on your own PC ... and you pay for the privilege of them sticking it to you.

cheeky so and so's, they've lost the plot about who their customer really is... unless big content is bribing them to do it.

[G_M_C]

Nope, M$ are only in it for the almighty US $ that they and their rich mates pray to... text from that M$ link says it all

i.e. they want to suck the life out of your PC and stop you from doing things you want to on your own PC ... and you pay for the privilege of them sticking it to you.

cheeky so and so's, they've lost the plot about who their customer really is... unless big content is bribing them to do it.

Hmm, your opinion of DRM is quite clear. But I think you overreact somewhat.

Most PC's dont even have a BD-drive or another component that requires PMP/PAP. Most people just want to use youtube or what not. And realistically speaking; Most people play MKV's or AVI (i.e the wellknown "x264-somegroup" type videos) too. And MS codecs makes it easy for clueless-n00bs (*) to do so without having to mess with codec-packs or worm-toolbar-spyware-infected-shit .

The bad thing is that they made it impossible for people that are NOT clueless n00bs (*) to choose their own software. Personally, i'd even consider buying a Win7-N (without windows media-player), cause i dont like MS mediaplayer. With my current Win XP I don't use it ever, and i've blocked it with my firewall atm. But I fear that i dont have freedom anymore in Win7, hence my idea of buying Win7-N. They should also have made a Win7/Stripped-edition, without mediaplayer or MS codecs; I would have bought that.

Anyway; Just wait a few months and there will probably a plethora of tools circumventing this Mediafoundation hinderence ;)

((*) clueless n00b => (C) Doom9 ;) )

[hydra3333]

Thanks for the label :p If you don't care what people do with your PC whilst making you pay for it, then that's up to you.

MS codecs and the stuff that goes with it don't work as well as say this codec here nor ffdshow... and witness media foundation whos primary purpose is to lock stuff down... agh, you're entitled to your view.

I too await tools and techniques built for the users to use as they choose not as enforced by the mates of big content.

[dimitrik]

Well.... I disagree.

CoreAVC already works on x64 just fine, my desktop rig is such. Its not a 64bit component but then you have to have every filter in the chain being 64bit which complicates matters, even if you wanted to use 64bit MPC-HC with CoreAVC 64bit when its out, you can do that but I just don't see any real benefit. 64bit seems to me to be the revolution that never was.

If it wasn't for the large amounts of cheap RAM I'm not sure anybody would be rushing out to get x64 OS.

And CoreAVC isn't as critical to 7 as it was to Vista IMO, with 7 having a working default h.264 codec built in. Vista was much harder to get to play DXVA in MCE. CoreAVC 'may' be better on 7 but even as an owner of CoreAVC I'm not sure if I will install it on my 7 rig.

Well, it's your right to disagree and I appreciate your points. However I don't think you are the whole of the market.

While x64 users might not be the biggest share of the market, they're growing fast and for valid reasons which makes us an important segment for CoreAVC to address - 32-bit will eventually disappear, just like 16-bit did. To take your points one by one:

1) It's good that you are happy with the 32-bit codecs, and so am I - on my desktop. But on my HTPC I want to run windows media center, which is only 64-bit on Win7 x64. So if I want to use CoreAVC, I'm stuck with 32-bit windows - not cool.

2) Why not cool? Well, for one thing x64 windows is significantly more robust, responsive and faster on newer systems. It can access all the physical memory, has better threading on multi-core CPUs, and fully utilizes the 64-bit CPU capabilities. In most tests, x64 systems beat x86 systems hands down. True it does little for decoding, but it does a lot for everything else.

3) About a year ago windows x64 adoption was tripling every 3 months. It has possibly accelerated since especially with win 7 coming out and MS encouraging adoption of the x64 platform.

4) As for your choice to stick with the MS codecs, that's fine if DXVA is all you care about. Speaking for both me and many other HTPC users, we want subtitles (not available with MS codecs and WMF, multiple-audio streams (also not possible - you need haali), more audio decoding and processing options (forget it, you're stuck with the MS audio decoder only - at least in MC) and lots of other things which the default codecs don't support or allow you to configure.

As for DXVA - seriously who cares? Most CPU's today handle 1080p in software just fine. I heat is a problem, you can buy a 2-core energy efficient CPU for less than $100. DXVA might be useful for a couple of years but just ask yourself who cares about hardware accelerated DVD decoding today?

[Virtual_ManPL]

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 ;)

[hydra3333]

Latest new nvidia driver 195.62 says
"Adds support for OpenCL 1.0 (Open Computing Language) for all GeForce 8-series and later GPUs."
Does that change anything ?

[LoRd_MuldeR]

No, it doesn't. And it has been explained a dozen times why OpenCL isn't relevant for CoreAVC.

:search:

[roozhou]

No, it doesn't. And it has been explained a dozen times why OpenCL isn't relevant for CoreAVC.

:search:
It is not easy to explain to those who knows little about computer architecture. People see those words in NV's new drivers and believe GPU+OpenCL may help speed up everything.

[LoRd_MuldeR]

It is not easy to explain to those who knows little about computer architecture.

That's why it has been explained in this thread. More than one time ;)

[TheShadowRunner]

Please take as much time as you want to release 2.0, but by all means correct the "live resolution switching issue (http://forum.doom9.org/showthread.php?p=1282057#post1282057)" before release!

[mandarinka]

Oh, I also have an issue with resolution switching, this time with both software and hardware mode. Actually, I don't use coreAVC myself (although I admire how it's optimized for K7/K8!), a friend pointed out the error for me.

What happens: there are video corruptions or crashes if you encounter/seek through a resolution change in h.264 video - in my case they are two matroska segments linked together into one merged timeline. I used different pps/sps id for both segments when encoding to x264 (I also found out that I have to use raw output in x264, for those who are interested), which causes filter chain reconnection (?) and enables decoder to switch the resolution.

This works perfectly with most if not all renderes - if I use divx decoder or ffdshow-tryouts (in its case, it works with revision 3008 and lower, there is a regression after that, coincidentally). Obviously this is with haali splitter, else there would be no linking.
Now with coreavc (both software and hardware decoding), one gets video corruption when the resolution switches, and the decoding isn't corrected in further gops either, it even corrupts when you seek elsewhere - forward, or back to the previous segment. I checked if the decoder switches the resolution, and it apparently does so (else the video would be totally beyond recognition from my experience), mybe the parsing somehow seems to get glitched, resulting in the corruptions.

Because the affected video files (movie with changing AR) were too cumbersome, I made a couple of small samples with the same workflow, to replicate the issue.

------------------------------------------------------------
http://www.mediafire.com/?2z1ziktwlyj
http://www.mediafire.com/?tmvmjn2nemz

They are for demostration purposes only (pardon for disclaiming :eek:). Video was borrowed from import ntsc dvd of Osamu Tezuka's Cleopatra movie, audio is a random mp3 with some amateur performance (used just to simulate audio track, note that it's intentionally the same for both parts) and subtitle script muxed in is just a dummy (added for the same reason)...

x264 commandline:
--crf 19 --no-mbtree --tune grain --b-pyramid --keyint 48 --preset slow --sps-id 1 --output "cleoA.264"
--crf 19 --no-mbtree --tune grain --b-pyramid --keyint 48 --preset slow --sps-id 2 --output "cleoB.264"


sample mkvmerge 2.4.2 commandline (the same is used for segment A too, simple blocks not enabled):
-o cleoB.mkv --priority lower -s 0 -D -A sample.ssa -a 0 -D -S BABICKA.MP3 --default-duration 0:24000/1001fps -d 0 -A -S cleoB.264 --track-order 2:0,1:0,0:0
------------------------------------------------------------
So much for the report, thanks for your attention!

PS: Hello to forum members :)

[Edit:] PPS: I tried this (http://forum.doom9.org/showpost.php?p=1348169&postcount=211) version of Diavc; it doesn't show the corruptions I was experiencing with coreavc and links fine if width of video changes, while for some reason crashing on height change (so not a complete pass).

[Mixer73]

2) Why not cool? Well, for one thing x64 windows is significantly more robust, responsive and faster on newer systems. It can access all the physical memory, has better threading on multi-core CPUs, and fully utilizes the 64-bit CPU capabilities. In most tests, x64 systems beat x86 systems hands down. True it does little for decoding, but it does a lot for everything else.

Personally I've yet to see a single benchmark that actually shows this.

Potentially the adoption of a new 'lowest common denominator' instruction set optimisation could provide a speed boost but I'm yet to see any applications that can back this up.

You're right, unlike most here I don't use subs or any such thing so I don't have those requirements, but I still had CoreAVC on my Vista system because it was the simplest and most compatible solution. However, I see no point at all in running 64bit for a MCE platform - I fail to see any benefits at all for this usage, so I'm running 32bit.

I have no argument that its the right way to go, but the way I see it, right now, it costs a lot of development time and money, without providing any additional benefits to the consumer.

My POV on this is influenced by my employment position, which is in the video editing & video compression fields. Personally there have been better ways for our staff to spend their development time to give more features for our customers than to work on 64bit code which at this point in time doesn't deliver a tangible benefit across all relevant areas.

Indeed as you've stated its something that will need to be done, but there's more productive areas IMO.

[Guest]

Debate about x64 Windows is OT here. Please start a new thread in an appropriate forum.

[squid_80]

I find 2 bugs in CoreAVC Professional 1.9.5.0

1 bug
I see blocks in CUDA mode, soft mode decode this properly

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/)
Looks like it was encoded with an old build of x264, which didn't restrict vertical motion vectors properly.


2 bug
frames are wrongly decoded in CUDA and soft mode, internal MPC-HC decoder decode this properly

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/)

I tried the following decoders and none of them decoded the clip properly:
- DivX
- ArcSoft
- ffmpeg
- DiAVC
- MPC-HC DXVA

[Virtual_ManPL]

Looks like it was encoded with an old build of x264, which didn't restrict vertical motion vectors properly.
dunno, soft mode works good, CUDA not ;)


I tried the following decoders and none of them decoded the clip properly:
- DivX
- ArcSoft
- ffmpeg
- DiAVC
- MPC-HC DXVA
but MPC-HC can

[Astrophizz]

MPC-HC (internal) is ffmpeg...

[sneaker_ger]

Can someone enlighten me about the reference frame limit of CoreAVC in CUDA mode? On the CoreCodec site it says that 16 frames is the limit but on many pages it says that the limit is actually 15 frames. Or does this depend on the version of CoreAVC, the resolution, graphic card and frame rate?
And how does CoreAVC decide if it will decode a video with CUDA or in pure software mode? Does it only read the level or does it inspect the x264 info (if x264 was used and the info not stripped)?

[honai]

squid_80 answered this a while back:

http://forum.doom9.org/showthread.php?p=1262588#post1262588
http://forum.doom9.org/showthread.php?p=1192953#post1192953
http://forum.doom9.org/showthread.php?p=1262558#post1262558

[sneaker_ger]

That answers my first question, thank you! The formulation on the CoreAVC page (http://forum.corecodec.com/viewtopic.php?f=3&t=69) can lead to misunderstanding.
Still leaves me wondering about those "out-of-order frames" though. How does CoreAVC make sure those frames won't get corrupted e.g. by using pure software mode?

[schweinsz]

I find 2 bugs in CoreAVC Professional 1.9.5.0

1 bug
I see blocks in CUDA mode, soft mode decode this properly
The.Illusionist.2006.HDTV.720p.x264-iLL.mkv
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 ;)

I extracted the raw 264 bitstream in OLS05lossless--avisource_82_92.mp4 and decode it to locate the error and I found it is a corrupted bitstream. When MB with (mbx=26, mby=1)is decoded, the end_of_slice_flag=1 in the first P picture with POC=4, so I believe no decoder can get the "correct" result, the needed operation is error concealment.

[Virtual_ManPL]

@ schweinsz - yep, it's probably like you said, but look how decode this newest MPC-HC in soft mode vs your decoder, CoreAVC (CUDA & soft) and DivX (+ MPC DxVA decoding)
only with MPC decoder in soft mode I get not pixelated frame like you can see on attached SS, odd ;p

[Keiyakusha]

Maybe it works in MPC because of some bug ^_^

Anyway may I ask about status of this multi-something bug in CoreAVC 2.0? Its not that I'm asking about releasing it now, I just thought that bug was not so serious...

[schweinsz]

@ schweinsz - yep, it's probably like you said, but look how decode this newest MPC-HC in soft mode vs your decoder, CoreAVC (CUDA & soft) and DivX (+ MPC DxVA decoding)
only with MPC decoder in soft mode I get not pixelated frame like you can see on attached SS, odd ;p

The first P picture with poc=4 is almostly same with the preceding I picture with poc=0, if error concealment is done, the P picture will be recovered perfectly. the current DiAVC is without the error concealment and I will add it after beta version is released.

[bluebebe]

hi there, i thought it was another error with the encoder, but its coreavc, it produces in a few videos of mine errors like this:

http://i46.tinypic.com/23j692o.jpg

http://i46.tinypic.com/4kzq6w.jpg


It is a bug or what? when i try decoding a x264 thru ffdshow i dont have that artifacts. hope anyone can tell me what the problem is.

[JEEB]

You might want to read some of the last pages of this thread. I think it's pretty sure that it's just the decoding bug/feature that's present in the 1.X series of CoreAVC and that has been fixed/added for quite some time already, just that CoreCodec hasn't gotten to releasing their 2.X version yet (which contains the support for weightp). nvidia's VP2 decoding doesn't have problems with decoding such content, just to note it one more time (CoreAVC's CUDA feature uses the VP2 hardware on the GPU).

You might want to use another decoder until CoreAVC 2.X gets released, and then check if it contains enough reasons for you to upgrade :)

[squid_80]

It's virtually impossible to confirm the cause of a problem from screenshots, stream samples are needed.

[bluebebe]

no samples needed, with cuda the video is working fine. thanks for help :)

[pankov]

Well, I too have problems (very rare to be fair) with CoreAVC's decoding.
Here is a sample showing the problem captured in the picture bellow. The same file plays fine both with FFDShow and MPC-HC decoders.
[link removed]

http://img44.imageshack.us/img44/3894/samplemkv00000.th.jpg (http://img44.imageshack.us/i/samplemkv00000.jpg/)

I'm using ATI so I don't have a chance to test it with CUDA. Can someone confirm/deny that this is the same weightp problem?

[pankov]

no, it's a sample I've found on the net with complaints about bad quality and just wanted to check if the problem was present on my machine too.
As you can see - it does and I'm still not sure which is the problem the source or CoreAVC.

I read that it's not against the rules to post samples, but if I misread/misunderstood the rules I'll remove it.

[Stephen R. Savage]

If it was encoded with x264, you can look at the headers in a hex editor (search for ASCII string "x264"). Streams encoded with weight-p on will display either "wpredp=1" or "wpredp=2". If it was not encoded with x264, you probably have to use a stream analyser like Elecard StreamEye or something.

[LoRd_MuldeR]

If it was encoded with x264, you can look at the headers in a hex editor (search for ASCII string "x264").

Or more user-friendly, look at the x264 encoding parameters with a tool like MediaInfo or AVInaptic :)

[weasel_]

Well, I too have problems (very rare to be fair) with CoreAVC's decoding.
Here is a sample showing the problem captured in the picture bellow. The same file plays fine both with FFDShow and MPC-HC decoders.
[link removed]

http://img44.imageshack.us/img44/3894/samplemkv00000.th.jpg (http://img44.imageshack.us/i/samplemkv00000.jpg/)

I'm using ATI so I don't have a chance to test it with CUDA. Can someone confirm/deny that this is the same weightp problem?
put in mediainfo and see if weightp=2

[pankov]

Well, I did try this (with the latest version from sourceforge - GUI 0.7.25) and here is the result
Writing library : x264 core 79 r1342 e8501ef
Encoding settings : cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=esa / subme=10 / psy=1 / psy_rd=1.0:0.3 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-4 / threads=6 / nr=0 / decimate=0 / mbaff=0 / constrained_intra=0 / bframes=5 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / wpredp=2 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / mbtree=0 / bitrate=14648 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=30 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.70

I have to admit I don't understand 90% of these parameters but I do see that there is no wieghtp or alike.

[kemuri-_9]

I have to admit I don't understand 90% of these parameters but I do see that there is no wieghtp or alike.

weightp is written as wpredp in the SEI,
see the wpredp=2 in your options there which indicates weightp 2 was used.

[pankov]

10x for the help
Now I'm officially a "victim" of the weightp bug/feature of CoreAVC
;)

[BetaBoy]

Well... a good thing now is that we are reworking how we handle MV's now (we now support non-spec compliant streams), which in-turn had a direct effect on our current weightp support.

[ajp_anton]

Will the 64-bit version be any faster? And if so, how much?

[BetaBoy]

Will the 64-bit version be any faster? And if so, how much?

We've discussed this several times here in this thread, but... you'll likely see negligible speed improvements for 64bit. I'll leave it for you all to tell us that after its released just how 'true' that to be, but I think many of you will be surprised.

[Snowknight26]

Any updates on that one bug you guys were aware of that hadn't been fixed at the time you mentioned it... whatever that bug was/is?

[BetaBoy]

iirc I did state its a weightp bug related to our support for the updated x264 and is a part of what we are working on now.

[hajj_3]

don't suppose you have a new eta?

[dead_screem]

Well... a good thing now is that we are reworking how we handle MV's now (we now support non-spec compliant streams), which in-turn had a direct effect on our current weightp support.

How is it supported? With two internal decoders? One with spec compliant MV limits and the other unlimited? (as mentioned a few times in this thread,). Or just one decoder with unlimited MV support?

[Hans Ohlo]

it is really disappointing as always with core. we get an eta for the avc decoder and haali with x64 support weeks ago and still nothing. really great as always. we should have known better.

[Shakey_Jake33]

In fairness, people have been fussing for support for out of spec MVs and the like for ages, and people critisised CoreCodec a few pages ago for not supporting it. I don't think it's necessarily fair to critisise them for doing what people have asked them to do.

[Snowknight26]

iirc I did state its a weightp bug related to our support for the updated x264 and is a part of what we are working on now.

My mistake - I thought there was only one bug in CoreAVC and HMS, not simply CoreAVC. You mentioned in one of your previous posts you were only aware of one bug in the 2.0 codebase, but I skipped over the part where you mentioned that you don't work in tandem with Haali. Bummer.

[hydra3333]

it is really disappointing as always with core. we get an eta for the avc decoder and haali with x64 support weeks ago and still nothing. really great as always. we should have known better.
Crikey, you're a bit on the down side ! Cheer up mate, when it arrives think how you'll enjoy it then.

[DigitalDeviant]

it is really disappointing as always with core. we get an eta for the avc decoder and haali with x64 support weeks ago and still nothing. really great as always. we should have known better.

LOL, when has Core ever met a release date they set? This has been a tradition going back to 1.0 back in April 2006, why break it now?