CoreCodec/H.264 Codec "CoreAVC"

[BetaBoy]

Did what nevcairiel suggested make it into 3.0.1 to fix the memory leak issue with madVR 0.74? Would doing so break something else or be undesirable for some reason?

And then there is also the 10-bit to P010/P016 conversion being slower than it should be, at least on my AMD X2, to keep in mind.
The issue with madvr is that it should release the CoreAVC instance. We can add memory releases but the point is we shouldn't as it has the side effect of causing more bad then good, like:
- Having multiple monitors hang
- Causing multiple tray icons
- Possible setting conflicts

Was madshi doing a fix for this?

ok... on the noted conversion slowdown.

[BetaBoy]

We have now added DXVA multi-monitor support.... now to QA it for CoreAVC 3.0.1 (and 2.6.2)

[cyberbeing]

The issue with madvr is that it should release the CoreAVC instance. We can add memory releases but the point is we shouldn't as it has the side effect of causing more bad then good, like:
- Having multiple monitors hang
- Causing multiple tray icons
- Possible setting conflicts

Was madshi doing a fix for this?

That's why I asked. If CoreAVC implementing a workaround creates other issues, we'll just need to wait for madshi to fix it on his end. ;)

nevcairiel said madshi commited to fixing it in the next version of madVR, but his release schedule is semi-random so that could be today... or it may end up being a month or more away... At the very least CoreCodec should add an entry to their Support KB about this issue, directing people to upgrade or downgrade their version of madVR if they experience a leak.

[BetaBoy]

By request we have done a new Haali Media Splitter installer with the MP4 fix... We sent it to Haali to add to his site.

[BetaBoy]

Till Haali adds it, we have made it available for download:
https://customers.corecodec.com/downloads.php

[junh1024]

I have reproduced the "video offset by X pixels" bug Stephen mentioned about on a 10-bit 720*560 video

Picture here (http://i.imgur.com/evGCz.png)

Sample here (http://www.megaupload.com/?d=37QF466B)

[dead_screem]

I have reproduced the "video offset by X pixels" bug Stephen mentioned about on a 10-bit 720*560 video

Picture here (http://i.imgur.com/evGCz.png)

Sample here (http://www.megaupload.com/?d=37QF466B)

I can confirm this. And to add to this, it only happens for YV12 colorspace and even then only some videos. NV12 and other colorspaces arn't affected.

[BetaBoy]

I can confirm this. And to add to this, it only happens for YV12 colorspace and even then only some videos. NV12 and other colorspaces arn't affected.

Fixed for the next release.

[betaking]

By request we have done a new Haali Media Splitter installer with the MP4 fix... We sent it to Haali to add to his site.

:thanks: and can you report to haali .last Haali Media Splitter have ts bug! can not Connection some vc1 decoder,and ps to decoder can not Connection some lpcm audio decoder!

[BetaBoy]

We are doing QA on the final CoreAVC 3.0.1.0 and 2.6.2.0 installers now.

Here is the changelogs:
CoreAVC H.264 Video Codec - Version 3.0.1.0 (20110909)
- ADD: DXVA re-initialization when device is lost
- FIX: Catch samples that don't get properly released by EVR
- FIX: Overflow in high bit depth weighted prediction
- FIX: Bug in 10-bit SSE2 IDCT
- FIX: Missing YV12 bitdepth caused misaligned blits from i010/i009 formats
- FIX: Don't use NV12 for connection if it's disabled and DXVA is unavailable
- CHG: Use "DXVA" FourCC for NV12 subtype when it's used for DXVA connections
- CHG: Reduce CPU usage while polling for DXVA completion
- CHG: Reinitialize decoder context on input pin disconnection
- CHG: Force low latency mode when graph is paused

Haali Media Splitter - Version 1.11.288.0 (20110909)
- FIX: MP4 video output pin regression

CoreAVC H.264 Video Codec - Version 2.6.2.0 (20110909)
- ADD: DXVA re-initialization when device is lost
- FIX: Catch samples that don't get properly released by EVR
- CHG: Use "DXVA" FourCC for NV12 subtype when it's used for DXVA connections
- CHG: Reduce CPU usage while polling for DXVA completion

Haali Media Splitter - Version 1.11.288.0 (20110909)
- FIX: MP4 video output pin regression

[dead_screem]

Bug I just noticed. in the sample linked in this post http://forum.doom9.org/showpost.php?p=1524571&postcount=6692

I get green pixel corruption on some of the letters on the title when used with NV12
http://img508.imageshack.us/img508/5774/railgunop110bitmp4snaps.png (http://imageshack.us/photo/my-images/508/railgunop110bitmp4snaps.png/)

and with YUY2,UYVY and RGB output colorspaces it gets really jaggy
http://img821.imageshack.us/img821/5774/railgunop110bitmp4snaps.png (http://imageshack.us/photo/my-images/821/railgunop110bitmp4snaps.png/)

[squid_80]

Might help if you said which renderer was being used.

[Barlow]

That sample looks fine here with EVR-CP (nv12) and MadVR.

[dead_screem]

Might help if you said which renderer was being used.

After checking this, the NV12 green pixels happen with VMR-7 and VMR-9. EVR is fine.
The jaggys on YUY2,UYVY and RGB happen on VMR-7, VMR-9 and EVR
Windows XP btw.

[cyberbeing]

I get green pixel corruption on some of the letters on the title when used with NV12 and with YUY2,UYVY and RGB output colorspaces it gets really jaggy
I can reproduce both problems with 3.0.1.

YUY2/UYVY/RGB have very blocky chroma.

The green blocks seems to be a bug in NV12 levels conversion. If you using Input = Output levels there are no green blocks. TV -> PC = green blocks.

Happens with all renderers tested (Overlay-Mixer/VMR7/VMR9/EVR/EVR-CP/madVR) on WinXP SP3 x86.




There are also some very significant performance problems with various 10bit to XXX colorspace conversions. No assembly yet?

Below are some quick perf tests I did with the CoreAVC_3.0_Corruption.mkv sample I posted earlier:

YV12/NV12/I420 = ~65.8753fps

P010/P016 = ~62.1560fps

RGB32 = 35.3177fps

Problem colorspaces:
RGB24 = 12.1498fps
RGB16 = 13.2597fps
RGB15 = 13.3949fps
UYVY = 16.1888fps
YUY2 = 16.2040fps

[hajj_3]

have you guys tested out v2.6.2.0 yet? That and v3.0.1.0 are on their website now.

[cyberbeing]

Later I may do some performance testing with 3.0.1, if it doesn't look like CoreAVC is going to push out another bugfix release today. I'm curious if that high bitrate problem got fix yet.

[dead_screem]

The green blocks seems to be a bug in NV12 levels conversion. If you using Input = Output levels there are no green blocks. TV -> PC = green blocks.

Happens with all renderers tested (Overlay-Mixer/VMR7/VMR9/EVR/EVR-CP/madVR) on WinXP SP3 x86.
Looks like the reason it was working with EVR for me was because I had output levels to Auto. And when it's set to auto CoreAVC detects PC out levels for VMR-7/9 but TV for EVR and Overlay. Forcing PC out and I now experience the bug for EVR and Overlay.

I wonder why Auto level output detects different setting depending on what renderer is used?

And a feature request if I may, can we get "No change/passthrough" output level option? Basically if Input is TV then output TV and if PC input then output PC.

[BetaBoy]

Later I may do some performance testing with 3.0.1, if it doesn't look like CoreAVC is going to push out another bugfix release today. I'm curious if that high bitrate problem got fix yet.
Hold off a few more hours till we another release out... then have fun with numbers. :-)

[BetaBoy]

Later I may do some performance testing with 3.0.1, if it doesn't look like CoreAVC is going to push out another bugfix release today. I'm curious if that high bitrate problem got fix yet.
Specifically... we are doing a 3.0.2 release in a few more hours as we already have a new bug to squash. RE: the VMR7 and VMR9 green lines/dot issue.
After checking this, the NV12 green pixels happen with VMR-7 and VMR-9. EVR is fine.
The jaggys on YUY2,UYVY and RGB happen on VMR-7, VMR-9 and EVR
Windows XP btw.
Bug confirmed.

We have also tracked down the Haali's renderer as the cause of most of the high CPU usage complaints for high-bitdepth as it prefers YUY2/NV12

We are talking to Haali on how to handle it.

[cyberbeing]

BetaBoy, is there any timeline for adding optimized assembly for 420p10 to YUY2?
Out of all the problem colorspaces, YUY2 and possibly RGB24 should be prioritized since some filters actually expect them at times.

We are talking to Haali on how to handle it.
That would be amazing if Haali actually started developing Haali Renderer again, since he pretty much abandoned it cold-turkey years ago.

[BetaBoy]

We also confirmed the bug for the jagginess reports (native chroma upsampling)... and working on a fix now.

[BetaBoy]

cyberbeing... Next up is more high10 assembly work we have been working on in an upcoming release.

[dead_screem]

another bug, YUY2,UYVY TV->PC isn't working at all with 10bit, levels are still TV. Also RGB is also TV levels with 10 bit. Is this related to the jaggy bug for these colorspaces?

[blaster00]

What's this?
http://thumbnails42.imagebam.com/14878/78ed67148773422.jpg (http://www.imagebam.com/image/78ed67148773422)

Tried haali, evr(cp) render; ati and intel display card.
MPC-HC r3715 x64, coreavc 3.0.1.0
All x264 video look like this.
Haven't restart after update coreavc yet.
DXVA works fine, though.

Solved

[Keiyakusha]

That would be amazing if Haali actually started developing Haali Renderer again, since he pretty much abandoned it cold-turkey years ago.

Or at least make it opensource. Otherwise whats the point in it if noone is using this renderer anymore (accept maybe someone who don't know that there is better choices)...

[BetaBoy]

What's this?
http://thumbnails42.imagebam.com/14878/78ed67148773422.jpg (http://www.imagebam.com/image/78ed67148773422)

Tried haali, evr(cp) render; ati and intel display card.
MPC-HC r3715 x64, coreavc 3.0.1.0
All x264 video look like this.
Haven't restart after update coreavc yet.
You mind pm'ing me your registration info?

[sawg]

Please forgive me if I make any errors; my English is a little weak.

EVR CP BUG...?
Play 1080p video, CUDA can't use when EVR buffers 10~15 more.
And DXVA can't use in EVR but VMR9 is ok.

http://i.imgur.com/haYHi.jpg
http://i.imgur.com/zXp4m.jpg

[molitar]

Ok this is the worse release yet. I am not even able to play the video file it locks up mpc home completely. MPC stops responding. Even with DXVA acceleration it still failed to run. Runs perfectly fine with ffdshow that came with CCCP pack and even runs with DXVA support.

General
Unique ID : 178621245569138099216868139571076912728 (0x866133578AC06EEF88123C7B23BFD658)
Complete name : D:\01 Incomplete\Itsuka Tenma no Kuro Usagi 08+\Itsuka Tenma no Kuro Usagi - 01 [WhyNot].mkv
Format : Matroska
Format version : Version 2
File size : 517 MiB
Duration : 25mn 0s
Overall bit rate : 2 889 Kbps
Encoded date : UTC 2011-07-11 08:32:15
Writing application : mkvmerge v4.8.0 ('I Got The...') built on May 24 2011 03:12:58
Writing library : libebml v1.2.0 + libmatroska v1.1.0
Attachment : Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 25mn 0s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Original frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 116 r2019 9cc407d
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.50:0.20 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-5 / threads=24 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=19.0 / qcomp=0.70 / qpmin=10 / qpmax=31 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:0.70
Language : Japanese

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Codec ID : A_AAC
Duration : 25mn 0s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 96.0 KHz / 48.0 KHz
Compression mode : Lossy
Language : Japanese

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Language : English

Menu
00:00:00.000 : :Intro
00:02:31.960 : :Part A
00:12:31.930 : :Part B
00:24:19.930 : :Preview

[squid_80]

sawg: by setting EVR to use 20 buffers, you're using up all the VRAM and leaving none for CUDA. And if you're able to get VMR9 to use DXVA, you're using windows XP and won't get DXVA with EVR.
molitar: that's a file description, not a bug report. Please refer to this helpful post. (http://forum.doom9.org/showthread.php?p=1524801#post1524801)

[ney2x]

CoreAVC 3.0.1, seeking bug came back. Using WMP12 or MPC-HC.

[squid_80]

I think Doom9 himself would agree (http://forum.doom9.org/showthread.php?t=96137) that's not a proper bug report either. Come on guys, do you want these things fixed or are you just trying to point fingers?

[molitar]

1. Playing file using CoreAVC locks up mpc-home
2. OS - Windows 7 32bit
3. CPU - AMD Phenom 955 Quad Core
4. GPU - Radeon HD 5750
5. Video Driver version - ATI Catalyst 11.6
6. Player - MPC-HC 1.5.2.2368
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.96.14
9. Codec - CoreAVC 2.6.2
10. Output - unknown
11. Acceleration - DXVA
12. Does not matter if I use DXVA acceleration or no acceleration it still will not play the file.

[blaster00]

Something about colourspace
Start from the haali render post,with the clip rec709 (http://www.mediafire.com/?sfd13vqrgn7vh6i)
Since few people in that post and has something to do with coreavc, I'd like to continue here.
First, I assume the "c yv12 auto evr" is the right one. Which means coreavc(yv12 output)(auto input)==>EVR(cp) render
http://thumbnails44.imagebam.com/14881/3bb8e8148804350.jpg (http://www.imagebam.com/image/3bb8e8148804350)
The internal converter of coreavc seems wrong with default setting.
c rgb32 601 evr
http://thumbnails41.imagebam.com/14881/232f17148804960.jpg (http://www.imagebam.com/image/232f17148804960)
c rgb32 709 evr
http://thumbnails36.imagebam.com/14881/1e4d13148804336.jpg (http://www.imagebam.com/image/1e4d13148804336)
c rgb32 709 hr auto
http://thumbnails50.imagebam.com/14881/073f06148804964.jpg (http://www.imagebam.com/image/073f06148804964)
c rgb32 auto evr
http://thumbnails33.imagebam.com/14881/e1ef9a148804340.jpg (http://www.imagebam.com/image/e1ef9a148804340)
c yuy2 auto hr 601
http://thumbnails45.imagebam.com/14881/a37af2148804343.jpg (http://www.imagebam.com/image/a37af2148804343)
c yuy2 auto hr 709
http://thumbnails45.imagebam.com/14881/a122d5148804347.jpg (http://www.imagebam.com/image/a122d5148804347)
c yuy2 auto hr auto
http://thumbnails35.imagebam.com/14881/8ecc6e148804348.jpg (http://www.imagebam.com/image/8ecc6e148804348)

c rgb32 601 evr == c rgb32 auto evr == c yuy2 auto hr 601, wrong, I guess.
c rgb32 709 evr == c rgb32 709 hr auto == c yuy2 auto hr 709 == c yuy2 auto hr auto == c yv12 auto evr, right, I guess.
So if someone use the default setting with coreavc and evr and another one simply change to rgb32 output in coreavc are not getting the same colour, at least with this 720p clip.

[eddman]

10. Output - unknown


You can determine it this way, I think; while playing the video, right-click on the picture and go to "Filters -> Enhanced Video Renderer (custom presenter)".
Select "Pin Info" tab. It's written there.

http://s1.bild.me/bilder/030611/5020275vo1.JPG

EDIT: Now I'm officially stupid. You can't know what the output is because MPC locks-up, duh!

[blubberbirne]

http://img35.imageshack.us/img35/5793/crysis2gb.png


Where can i download the "video decoder performance test" ?

[nevcairiel]

Where can i download the "video decoder performance test" ?

Its part of GraphStudio (http://blog.monogram.sk/janos/tools/monogram-graphstudio/)

[CruNcher]

Hmm slowly i wonder if you can trust a lot of Dshow based Benchmarks anyways

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:05.169
Average FPS: 401,817
Min/Max FPS: Min: 400 Max: 405
CPU Usage (%): Avg: 00 Min: 00 Max: 01

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: ProgressiveDevice
Time: 00:05.206
Average FPS: 399,306
Min/Max FPS: Min: 399 Max: 400
CPU Usage (%): Avg: 00 Min: 00 Max: 01

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:03.108
Average FPS: 334,266
Min/Max FPS: Min: 333 Max: 337
CPU Usage (%): Avg: 10 Min: 09 Max: 11


Trying to compare DXVA2 64 Bit, but how can it be that Render time is faster but fps lower ???? (and what is now preferable, time or speed my logic would say time)

[SEt]

Looks like bug in benchmark OR graphs produced different number of frames.

[CruNcher]

i guess its better not to benchmark with the H.264 stream in *.ts and Mpegsplitter.ax

uhh in CoreAVC 3.0.1 something changed DXVA2 is now displayed (before it only showed DXVA1 but worked anyways)

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:03.130
Average FPS: 331,891
Min/Max FPS: Min: 332 Max: 332
CPU Usage (%): Avg: 09 Min: 09 Max: 09


Results of a H.264 *.mp4 parsed with Mp4splitter.ax

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:02.660
Average FPS: 378,491
Min/Max FPS: Min: 364 Max: 384
CPU Usage (%): Avg: 03 Min: 02 Max: 03

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:02.667
Average FPS: 377,490
Min/Max FPS: Min: 359 Max: 386
CPU Usage (%): Avg: 05 Min: 05 Max: 05

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: ProgressiveDevice
Time: 00:02.680
Average FPS: 375,674
Min/Max FPS: Min: 365 Max: 380
CPU Usage (%): Avg: 08 Min: 08 Max: 08

fits much better then the Mpegsplitter.ax *.ts result (of CoreAVC, most probably a interop problem with the splitter, so i guess most results i got with Graphstudio benchmarking H.264 *.ts might be wrong also, if it affects Software Rendering the same) :(

But wait MpegSplitter has this fast stream switch option hmm im not sure if i turned that off and if that might impact CoreAVCs timing behavior :( <- Nope that has no impact seems to be just the Splitter itself

[ebuss07]

similar problems here..... is it just me--new CoreAVCs seem like chewin'gum?! MeGUI/AVS/CoreAVC used to work properly... now either avScript error:directshowsource: renderfile, filter graphmanager won'talk to me OR sometimes work--but load script video preview not only colour is red and footage is upside down {like this one i downloaded:http://d01.megashares.com/?d01=ZW6IYZQ[/EMAIL] (http://d01.megashares.com/?d01=ZW6IYZQ)}

[CruNcher]

@SEt

Funny in Mpegsplitter.ax Software Rendering (now Microsofts Decoder is showing strange results)

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: DiAVC H.264 Decoder (x64)
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:05.606
Average FPS: 185,320
Min/Max FPS: Min: 181 Max: 189
CPU Usage (%): Avg: 97 Min: 94 Max: 98

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:06.691
Average FPS: 155,280
Min/Max FPS: Min: 152 Max: 163
CPU Usage (%): Avg: 81 Min: 75 Max: 84

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:07.445
Average FPS: 139,545
Min/Max FPS: Min: 135 Max: 146
CPU Usage (%): Avg: 89 Min: 80 Max: 93

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:08.431
Average FPS: 123,346
Min/Max FPS: Min: 120 Max: 126
CPU Usage (%): Avg: 86 Min: 84 Max: 89

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:08.875
Average FPS: 234,242
Min/Max FPS: Min: 227 Max: 241
CPU Usage (%): Avg: 93 Min: 91 Max: 96


Lav Splitter *.ts DXVA2

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:05.203
Average FPS: 400,130
Min/Max FPS: Min: 400 Max: 401
CPU Usage (%): Avg: 03 Min: 00 Max: 09

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: ProgressiveDevice
Time: 00:05.229
Average FPS: 398,546
Min/Max FPS: Min: 396 Max: 400
CPU Usage (%): Avg: 03 Min: 00 Max: 10

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: ModeH264_VLD_NoFGT_ClearVideo
Processor Device: ProgressiveDevice
Time: 00:03.170
Average FPS: 328,649
Min/Max FPS: Min: 316 Max: 336
CPU Usage (%): Avg: 08 Min: 03 Max: 12

Same CoreAVC result issue:


Lav Splitter *.ts Software

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: DiAVC H.264 Decoder (x64) <- Causes crash in Graphstudio (is being debugged currently see http://forum.doom9.org/showthread.php?p=1524632#post1524632)
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:14.476
Average FPS: 71,912
Min/Max FPS: Min: 72 Max: 73
CPU Usage (%): Avg: 29 Min: 24 Max: 39

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CoreAVC Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:06.544
Average FPS: 159,222
Min/Max FPS: Min: 146 Max: 170
CPU Usage (%): Avg: 82 Min: 77 Max: 89

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:07.251
Average FPS: 143,419
Min/Max FPS: Min: 132 Max: 150
CPU Usage (%): Avg: 90 Min: 84 Max: 98,

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: CyberLink Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:08.134
Average FPS: 128,346
Min/Max FPS: Min: 113 Max: 133
CPU Usage (%): Avg: 86 Min: 82 Max: 89

Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: -
Processor Device: ProgressiveDevice
Time: 00:08.673
Average FPS: 240,271
Min/Max FPS: Min: 221 Max: 252
CPU Usage (%): Avg: 93 Min: 89 Max: 97

Same issue with Microsoft and Lav Splitter in Software Rendering


Puhh so at least i can be sure all my Software Rendering measuring's where right with CoreAVC since now, though the bad results coming out from CoreAVCs DXVA2 with 2 of the most used *.ts splitter don't look good also in terms of what problems this might could produce with Splitter and Audio Decoder for different streams, though it might have todo with the DVBviewer needed changes for DVB playback, but in this case Cyberlink provides expected results and works fine since years with DVB :)

[BetaBoy]

similar problems here..... is it just me--new CoreAVCs seem like chewin'gum?! MeGUI/AVS/CoreAVC used to work properly... now either avScript error:directshowsource: renderfile, filter graphmanager won'talk to me OR sometimes work--but load script video preview not only colour is red and footage is upside down {like this one i downloaded:http://d01.megashares.com/?d01=ZW6IYZQ[/EMAIL] (http://d01.megashares.com/?d01=ZW6IYZQ)}

ebuss07... Read:
https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html

[TOM_SK]

ebuss07... Read:
https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html

rofl, busted!

[somms]

Any idea when 3.0.2 will be out for beta testing!?

I haven't had any luck w/3.0,3.01 as both caused major slowdowns with my HTPC where the audio/video would get out of synch...ended up falling back to old reliable 2.5.5...

[STaRGaZeR]

ebuss07... Read:
https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html

I'm sure you know it already, but pirated copies of CoreAVC 3.0 can be used just fine without any of those symptoms.

[Romario]

@ BetaBoy

I don't want to offend you or your company, but I must say something. It's obvious that, in recent time, CoreCodec developers can't made stable version of CoreAVC ! Even when 2.50 was released, a year or more ago, it wasn't stable. What's going on with you, people ?

Look FFDSHOW devs, they have excellent programers and FFDSHOW never have any problems in video or audio decoding.

[G_M_C]

@ BetaBoy

I don't want to offend you or your company, but I must say something. It's obvious that, in recent time, CoreCodec developers can't made stable version of CoreAVC ! Even when 2.50 was released, a year or more ago, it wasn't stable. What's going on with you, people ?

Look FFDSHOW devs, they have excellent programers and FFDSHOW never have any problems in video or audio decoding.

ffdshow DOES have problems (so does the underlaying ffmpeg), but bugs get squatted faster. I think that is because there are more programmers (i.e. volunteers, cause open source work is like voluntary work) to work on the project. ffdshow is also constantly improved upon, creating new problems. Thats why it's in, some might say, a permenent beta-status.

[eddman]

@ BetaBoy

I don't want to offend you or your company, but I must say something. It's obvious that, in recent time, CoreCodec developers can't made stable version of CoreAVC ! Even when 2.50 was released, a year or more ago, it wasn't stable. What's going on with you, people ?

Look FFDSHOW devs, they have excellent programers and FFDSHOW never have any problems in video or audio decoding.

Are you saying those based on personal experience or just by reading this thread? 2.5.5 is a pretty stable release.

I agree, they abandoned 2.0 for more than a year without releasing a single bux-fix revision, but after 2.5 they magically became super fast for some reason. Just look how fast they are fixing 2.6 and 3.0.

[DeadlyEmbrace]

Having problems when using CoreAVC with DXVA decoding enabled. (It works fine in software only mode)
It has blocks at the bottom, stalls and if you wait long enough creates tearing of the whole image. This error doesn't happen when using MPC-HC built in DXVA decoder or FFDShow DXVA decoder.

CPU: AMD Turion X2 Dual Core Mobile RM-70 2Ghz
GPU: ATI Mobility Radeon HD 3650 (Catalyst 11.8)
RAM: 4Gb

MPC-HC 1.5.3.3704
Haali Media Splitter 1.11.288.0
EVR CS
CoreAVC 3.0.1 or 2.6.2

http://i1091.photobucket.com/albums/i396/CuteD34th/Bug-Report%20images/Image1.jpg
Blocking at bottom of image

http://i1091.photobucket.com/albums/i396/CuteD34th/Bug-Report%20images/Image2.jpg
Tearing of image

[shon3i]

Simmilar behavior on my laptop which has Intel GMA 4500 MHD. Win 7 x64, lastest drivers, CoreAVC 3.0.1, DXVA mode

http://img846.imageshack.us/img846/3651/50201m2tssnapshot004141.th.jpg (http://img846.imageshack.us/i/50201m2tssnapshot004141.jpg/)

in software mode everything is great.

[Portioli]

can anybody send which are the Optimal settings for h264 interlaced material using CoreAVC [DXVA enabled]?

CoreAVC Deinterlacing : None (wave) - Single Field - Bob - Hardware [Aggressive: checked or unchecked] ?

In CCC what i choose ?
Basic Video Quality : Use Automatic or Manual Deinterlacing? If manual what option?
Everything is disabled in advanced quality.


thanks in Advance

[Romario]

Are you saying those based on personal experience or just by reading this thread? 2.5.5 is a pretty stable release.

No, no, I said 2.50, not 2.5.5. CoreAVC IS stable, 2.50 NOT.

So, I urge CoreAVC devs to speed-up development, please. It's shame that every time when you, guys, have something new and fresh ( CoreAVC 3.0 and 3.01 ) it doesn't work well in DXVA mode so well, with lot of bugs.

I again repeat, BetaBoy, I don't want to insult nobody. I am just honest.

[squid_80]

So, I urge CoreAVC devs to speed-up development, please. Version 2.x has had 3 releases in the past week alone and you're complaining development is not happening fast enough?
If you have specific problems that you want fixed, make clear and concise bug reports that will allow it to be easily reproduced (instead of just yelling "it doesn't work!").

[BetaBoy]

I again repeat, BetaBoy, I don't want to insult nobody. I am just honest.
None taken... but like squid_80 said... if you have a report to pass along please try and be as specific as you can on the issue. This helps us first to duplicate the problem and track down the issue.

As far as DXVA... there was alot going on for along time.... I am sure with everyone's help we will track down the remaining issues, but in one weeks time we pretty much squashed most of the major bugs.

So... with that. ATM we are pushing back the new 3.0.x release a day or so as we wanted to address peoples concerns of Hi10p speed. So with the next release you will see a marked improvement in speed there, especially with color adjustment enabled... and by marked I mean some will see as much as a 35-48% gain (in regards to blitting... not overall speed).

[molitar]

Can not play file at all with CoreAVC. Even tried turning off acceleration and CoreAVC 2.62 locks up mpc-home completely. Proper bug report format...

1. Playing file using CoreAVC locks up mpc-home
2. OS - Windows 7 32bit
3. CPU - AMD Phenom 955 Quad Core
4. GPU - Radeon HD 5750
5. Video Driver version - ATI Catalyst 11.6
6. Player - MPC-HC 1.5.2.2368
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.96.14
9. Codec - CoreAVC 2.6.2
10. Output - unknown
11. Acceleration - DXVA
12. Does not matter if I use DXVA acceleration or no acceleration it still will not play the file.

General
Unique ID : 178621245569138099216868139571076912728 (0x866133578AC06EEF88123C7B23BFD658)
Complete name : D:\01 Incomplete\Itsuka Tenma no Kuro Usagi 08+\Itsuka Tenma no Kuro Usagi - 01 [WhyNot].mkv
Format : Matroska
Format version : Version 2
File size : 517 MiB
Duration : 25mn 0s
Overall bit rate : 2 889 Kbps
Encoded date : UTC 2011-07-11 08:32:15
Writing application : mkvmerge v4.8.0 ('I Got The...') built on May 24 2011 03:12:58
Writing library : libebml v1.2.0 + libmatroska v1.1.0
Attachment : Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 25mn 0s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Original frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 116 r2019 9cc407d
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.50:0.20 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-5 / threads=24 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=19.0 / qcomp=0.70 / qpmin=10 / qpmax=31 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:0.70
Language : Japanese

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Codec ID : A_AAC
Duration : 25mn 0s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 96.0 KHz / 48.0 KHz
Compression mode : Lossy
Language : Japanese

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Language : English

Menu
00:00:00.000 : :Intro
00:02:31.960 : :Part A
00:12:31.930 : :Part B
00:24:19.930 : :Preview

[squid_80]

What does "locks up" mean? It becomes non-responsive and has to be killed with task manager? Or it just doesn't play? Or it crashes with an error dialog?
Also please PM your registration info to either BetaBoy or myself.

[molitar]

What does "locks up" mean? It becomes non-responsive and has to be killed with task manager? Or it just doesn't play? Or it crashes with an error dialog?
Also please PM your registration info to either BetaBoy or myself.

Locks up as everything stops responding in Windows 7 and Windows 7 turns that ghosted white color.. I have to end task to kill the process so I can use windows again.

Windows Application log.

Faulting application name: mpc-hc.exe, version: 1.5.2.3268, time stamp: 0x4e070934
Faulting module name: mpc-hc.exe, version: 1.5.2.3268, time stamp: 0x4e070934
Exception code: 0xc0000005
Fault offset: 0x000729e5
Faulting process id: 0xf40
Faulting application start time: 0x01cc704601e208c8
Faulting application path: C:\Program Files\Combined Community Codec Pack\MPC\mpc-hc.exe
Faulting module path: C:\Program Files\Combined Community Codec Pack\MPC\mpc-hc.exe
Report Id: 421a87dd-dc39-11e0-9903-6c626d7151e7

[wanezhiling]

http://www.gokuai.com/f/4181C9d8cXt3H69C

Turn dxva or cuda on and try this sample, please.

[blubberbirne]

Its part of GraphStudio (http://blog.monogram.sk/janos/tools/monogram-graphstudio/)

lol i used graphstudio since years, but i never recognised this feature :thanks:

[Stormbreaker]

After buying today CoreAVC 3.0.1, I experienced a disappointment. For the first version of all, when having checked DXVA the icon for me as a ATi user turns red.

The picture stays black and - if at all anything - diplays garbage.
Mobillity Radeon HD3470
Mobillity modded 11.6 driver

:mad:

Furthermore, still high end videos are being desynced. Also I wonder, though it doesn't work why not always the icon turns red though I've checked DXVA in the options.

:mad:

[BetaBoy]

Strormbreaker... welcome to Doom9.

To better help us help you, please fill in the blanks below:

1. The picture stays black and - if at all anything - diplays garbage. high end videos are being desynced. Also I wonder, though it doesn't work why not always the icon turns red though I've checked DXVA in the options.
2. OS -
3. CPU -
4. GPU - Mobillity Radeon HD3470
5. Video Driver version - Mobillity modded 11.6 driver
6. Player -
7. Renderer -
8. Splitter -
9. Codec -
10. Output -
11. Acceleration - DXVA
12. Other specific things that might help -


Also a sample file might help (if possible).... also define 'High End' videos for us please... and be specific on what features the content was encoded with.

[molitar]

I am awaiting some feedback on my bug. I pm my registration and serial number to squid_80 as I was asked to. Any idea why Corecodec is not working for me at all?

[squid_80]

If I find something I will let you know, but at this point it seems to be a unique issue.

[molitar]

If I find something I will let you know, but at this point it seems to be a unique issue.

Ok thanks for the update squid_80

[BetaBoy]

Those people experiencing issues with ZoomPlayer are urged to upgrade to the latest version v8.0 RC3 as we have a report it fixes the current issues. We are still working with Blight on the other reports.

[nars]

I'm having a weird problem with 2.6.x and 3.0.x versions... with DVB-T streams on DVBViewer (I think also with mpc but I didn't tested it properly yet), while playing I do notice that "timing" doesn't seem "linear"... not sure how can I explain it exactly... imagine a movie film "rotating" at non linear speed, sometimes slower, sometimes faster than normal... it's not a "look and notice it" thing, but after watching for a few minutes we notice it on people motion (suddenly almost running instead of walking...), etc... I did downgraded to 2.5.5 (a few times) and I can't see such problem anymore... I did tried it with every minor version and got same problem with all versions greater than 2.5.5... I did even tried to change some options at codec properties to check if it could help but it doesn't... I did always ended downgrading to 2.5.5 and for sure no problem with this version.

more details:
- noticing it with 576i dvb-t streams
- not using dxva (you know I can't use it on dvbviewer)
- cpu is not overloaded while playing... cpu usage 14% to 20%
- graphics card: ati hd6570
- windows xp sp3

anyone else noticing similar problem? am I becoming mad? :)

maybe related to the increased buffers? do all versions have them?

[mdlenoir]

I have questions. CoreAVC 2.5.5 is fine when playing h264 files before, very low cpu rate. But there exists some problems after i update to 2.6.x or 3.0.1. Is it normal？

Here is a sample：http://wjy.xunlei.com/d/NKPEULZOBETR

2.5.5：lots of Mosaics
2.6.x：still a little
3.0.1：no Mosaics, but very high CPU rate (40~60%)

Intel E8400 3.0G
nVidia GTX260+ (Driver 280.26 WHQL, )
Windows 7 x64
MPC-HC 1.5.3.3720 （EVR custom）
Haali Media Splitter （1.11.96.14）
CoreAVC （CUDA）

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I find high rate cpu problem, CoreAVC doesn't use CUDA acceleration. I don't know why. My setting is ok, cause when I playing other files, the icon shows CUDA mode on and the cpu rate is normal (7~10%). But this file, is it fake? No...... what's the problem?

[nussman]

@nars: Could you upload a testfile?

[CiNcH]

@ nars,

I have experienced the same problem. That is why I said that CoreAVC still does not function perfectly together with the DVBSource filter. It is as if timestamps jitter a lot at the renderer. Jitter grows with time until the renderer has to start dropping frames.

Also in my case, the DVBSource filter sometimes performs a graph stop/run due to a buffer overflow. Seems that CoreAVC is processing slower than data is coming in. Not good since we can't vary the DVB stream speed. The DVBSource uses the stream PTS for timing.

[squid_80]

I find high rate cpu problem, CoreAVC doesn't use CUDA acceleration. I don't know why. My setting is ok, cause when I playing other files, the icon shows CUDA mode on and the cpu rate is normal (7~10%). But this file, is it fake? No...... what's the problem?
It's a 10-bit H264 stream, which requires CoreAVC 3.x (and more CPU power than normal files) and isn't compatible with hardware decoding.

[squid_80]

Also in my case, the DVBSource filter sometimes performs a graph stop/run due to a buffer overflow. Seems that CoreAVC is processing slower than data is coming in. Not good since we can't vary the DVB stream speed. So the DVBSource has to use the stream PTS for timing.

This actually sounds exactly like a DTS vs. PTS problem.

[CiNcH]

This actually sounds exactly like a DTS vs. PTS problem.
Can you get into detail? I am not much into this stuff as I am not developing the DVBSource. But I can forward the information.

[squid_80]

I'd need a sample first to make sure I'm not just guessing.

[mdlenoir]

It's a 10-bit H264 stream, which requires CoreAVC 3.x (and more CPU power than normal files) and isn't compatible with hardware decoding.

So 10-bit files can't be hardware decoded right now？sad...
Hope you genius make it better, cheers....:thanks:

[CiNcH]

I'd need a sample first to make sure I'm not just guessing.
I guess that it is related to the jitter/timestamp issue. I will have to verify it with files first.

[JEEB]

So 10-bit files can't be hardware decoded right now？sad...
Hope you genius make it better, cheers....:thanks:
TL;DR You'll get your support as soon as someone makes the hardware capable of hi10p, and as soon as that can be accessed via some API (be it CUVID, DXVA or whatever). Just don't expect it to be a priority for any company doing user-level hardware.

(the only reason user-level hardware got normal high profile support was the fact that Blu-ray and DTV can use it, hi10p is only used in professional areas [as well as in personal encodes of people lately], so there's no pressing reason for companies to actually add hi10p support onto their hardware :P )

[mdlenoir]

we can hope, we can wait, everything will be fine... somebody gives me a time machine...╮(￣▽￣")╭

[hardkorn]

Has anyone having problems with CoreAvc 3.0.1 in flipping the video? It happens with kmplayer, potplayer, MPC-HomeCinema with video processing disabled. I don't like their internal decoding. If I enable video processing and flip the picture (there's an option in those players) it shows the picture as it should, but eats a lot of memory, almost to a halt.


Also, I can only choose RGB15 AND RGB16 in CoreAvc. All other output formats turn the picture red.

Any thoughts?

[Mixer73]

Has anyone having problems with CoreAvc 3.0.1 in flipping the video? It happens with kmplayer, potplayer, MPC-HomeCinema with video processing disabled. I don't like their internal decoding. If I enable video processing and flip the picture (there's an option in those players) it shows the picture as it should, but eats a lot of memory, almost to a halt.

https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html

[Romario]

BetaBoy, I have one little feature request for future release, for example 3.03 or 3.1. I used ffdshow debug decoder lot of years until now, and I love FFDSHOW because he have verz nice debug decoder. Can you, please, at least consider something similiar which FFDSHOW have ?

I mean specificaly on debug decoder (information about codec, audio bitrate and video bitrate during playing )

[CiNcH]

@ squid_80,

I also verified the high jitter with file playback via DVBSource. It only seems to happen with interlaced content though. 1080p24 (m2ts from a Blu-Ray) and 720p50 (either live or file) are both fine.

I think that you already have some 1080i TS samples to test this with? I used the EVR Custom Presenter within the DVBViewer which currently times samples only according to their timestamps. So IMHO the timestamps from the decoder or mixer jitter a lot.

CoreAVC 2.6.2 settings: SW mode, NV12, hardware deinterlacing

I did not try 1080i with other splitters yet. Maybe the problem is present there too.

[clsid]

Have all HMS regressions been fixed?
Why isn't Haali site updated yet?

[BetaBoy]

Have all HMS regressions been fixed?
Why isn't Haali site updated yet?
No, only some of the more immediate issues were fixed and we added support for MVC in preparation for releasing CoreMVC.

Haali not updating the site is mostly attributed to IBC and his lack of time from the day job atm. This is why we updated the splitter and released it in CoreAVC and for download on our site.

[nars]

I made a mistake in my previous post... I'm getting the problem with 576i (not 576p), post edited... I can post some samples later if you are interested, need to find some images where it can be really easy to notice.

CiNcH: did you tested if you notice similar jitter with 2.5.5? Because apparently I don't see the problem (if it's really the same thing) with that version and previous ones... also just for curiosity do you do you have an ati or nvidia?

[CiNcH]

I made a mistake in my previous post... I'm getting the problem with 576i (not 576p)
I actually thought so. Never seen 576p for DVB.

CiNcH: did you tested if you notice similar jitter with 2.5.5?
I didn't as 2.5.5 does not perform proper hardware deinterlacing with most splitters anyway.

also just for curiosity do you do you have an ati or nvidia?
AMD Radeon HD 6570. But it shouldn't really matter IMHO.

[Livias]

I registered this forum, specifically to offer feedback using 3.0.1 on my run of the mill netbook. I bought CoreAVC specifically for 10-bit H264 stream 720p playback on my netbook, and while the performance is descent, it is not stellar. When there is a lot going on in a scene, sometimes coreAvc skipsframes. CoreAVC needs to be faster, have more software optimizations for underpowered hardware especially netbooks users, which I assume are a significant percent of CoreAVC users.

[clsid]

No, only some of the more immediate issues were fixed and we added support for MVC in preparation for releasing CoreMVC.

Haali not updating the site is mostly attributed to IBC and his lack of time from the day job atm. This is why we updated the splitter and released it in CoreAVC and for download on our site.Just to be clear, I was talking about regressions in the new version compared to the 03/03/2011 version.
The MP4 issues were fixed, right? What other regressions are left, if any?

Can you post a link to the latest version?

[squid_80]

Just to be clear, I was talking about regressions in the new version compared to the 03/03/2011 version.
The MP4 issues were fixed, right? What other regressions are left, if any?

Can you post a link to the latest version?

https://customers.corecodec.com/downloads.php

[BetaBoy]

We are planning to do a release this week... Likely sooner then later but we are holding off on features like deblocking for our ASM, more 10bit optimizations, etc. for the followup release (v3.1).

[RoadPizza]

Like several others, I've lurked for quite some time here, and joined just to post my question. It is not a bug report per se, but I will try to stick to the proper format anyway:

1. CoreAVC runs faster/better for me without CUDA enabled
2. OS - Windows XP SP3
3. CPU - Core 2 Quad Q9650
4. GPU - GeForce GTS 450
5. Video Driver version - 6.14.12.8026
6. Player - MPC-HC v1.5.2.3456
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.288.0
9. Codec - CoreAVC all versions from 2.5 up
10. Output - ?
11. Acceleration - CUDA or none

On a whim I downloaded the clip from post #6809. I noticed that there were a couple of freezes & skips when playing the file with CUDA enabled. Not a big deal, but less than perfect. When I tried it with CUDA disabled, it played fine. So I tested some other clips and other versions of CoreAVC and discovered that on my system every clip I tried actually plays better with CUDA off. I've always just assumed that hardware is better that software when it comes to decoding, but for me it seems to be not true.

What I'd like to know is if this is normal behavior given my system, or if I may have a problem somewhere in my setup. Thanks for any answers!

[D.A.S.]

1. Wrong aspect ratio (black bars appear)
2. OS - Windows 7 SP1 32bit
3. CPU - AMD Phenom II X4 940
4. GPU - Radeon HD 5670
5. Video Driver version - 11.8
6. Player - MPC-HC v1.5.3.3731
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.96.14
9. Codec - CoreAVC 3.0.1
10. Output - NV12
11. Acceleration - DXVA on 8-bit, 10-bit DXVA is not working


8-bit 1080p Print Screen, If use Alt+I screenshot normal
http://img703.imageshack.us/img703/2987/coreavc391printscreen8b.th.png (http://img703.imageshack.us/img703/2987/coreavc391printscreen8b.png)

10-bit 1080p Print Screen
http://img638.imageshack.us/img638/599/coreavc391printscreen10.th.png (http://img638.imageshack.us/img638/599/coreavc391printscreen10.png)

Alt+I
http://img215.imageshack.us/img215/2475/coreavc391alti10bit.th.png (http://img215.imageshack.us/img215/2475/coreavc391alti10bit.png)

If use Ffdshow/Lav all is well.

[squid_80]

I've always just assumed that hardware is better that software when it comes to decoding, but for me it seems to be not true.

Unless you've got an underpowered system (below a core2) software decoding will nearly always outperform hardware. GPU decoding is typically optimized for playing (in real-time, not as fast as possible) streams that match run of the mill blu-ray specs, not high performance.

[eddman]

Unless you've got an underpowered system (below a core2) software decoding will nearly always outperform hardware. GPU decoding is typically optimized for playing (in real-time, not as fast as possible) streams that match run of the mill blu-ray specs, not high performance.

Yes, If you have a strong enough CPU there isn't really much of a reason to use hardware decoding. Software decoding is faster in most cases and there'll be far less compatibility problems with non-standard videos compared to hardware.
For me these are the main usage scenarios for hardware decoding:

1. The CPU is weak and unable to play HD h.264 videos.
2. The CPU is strong but you want to reduce its utilization and use it for some other task while watching a video.

[whiskey]

Any ideas why with version 3.0.1.0 all my vids in MPC are upside down and have no color ? No clue how to fix this maybe somebody had similar issue ?

[squid_80]

Aye matey! Seems the booty you've been plundering was booby trapped! (https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html)

(Happy International Talk Like A Pirate Day, for those unaware. Note however that your pirate impersonations shouldn't include actual stealing.)

[whiskey]

Aye matey! Seems the booty you've been plundering was booby trapped! (https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html)

(Happy International Talk Like A Pirate Day, for those unaware. Note however that your pirate impersonations shouldn't include actual stealing.)


Hmm Now I see I thought there had like 2 versions paid and free one I get it now

[Gav80K]

I'm also experiencing a noticeable performance drop with CUDA acceleration since I upgraded to 3.0.1 and it's now faster with GPU acceleration disabled. My observations are based on the fact that I make regular use of the skip 5 seconds feature in MPC-HT. When you skip it presumably has to decode the video from the last key frame to the point you skip to, making it quite computationally intensive. With version 2.5.1 the skip used to occur pretty much instantly, but in 3.0.1 there is a long delay of 1-2 seconds before the video resumes play. Even with low bitrate 720p it's painfully slow so I went back to 2.5.1 and it's back to it's normal speed.

GPU decoding is typically optimized for playing (in real-time, not as fast as possible) streams that match run of the mill blu-ray specs, not high performance.

That may be so, but there's still no reason for it to be substantially slower than 2.x. The main reason I use CoreAVC is so I can employ a low power CPU, and therefore have an entirely passively cooled media PC. I don't want to have to use a CPU that requires fan cooling, though with the lack of Hi10P CUDA acceleration and the slow CUDA performance in general it looks like I no longer have a choice.

I'll have to get a more powerful processor and was considering these (mostly because they're the fastest 2 and 4 core CPUs with a 65W TDP):

Intel Core i7 2600S with 4 HT cores at 2.8GHz (http://ark.intel.com/products/52215/Intel-Core-i7-2600S-Processor-%288M-Cache-2_80-GHz%29)
Intel Core i3 2125 with 2 HT cores at 3.3GHz (http://ark.intel.com/products/59080/Intel-Core-i3-2125-Processor-%283M-Cache-3_30-GHz%29)

I was wondering effectively CoreeAVC makes use of multiple cores. Is it better to have four cores or two cores with a higher clock speed?

What about FFDShow (which I use as a backup); does that take full advantage of multi-core processors?

Thanks for your advice.

[squid_80]

I'm also experiencing a noticeable performance drop with CUDA acceleration since I upgraded to 3.0.1 and it's now faster with GPU acceleration disabled. My observations are based on the fact that I make regular use of the skip 5 seconds feature in MPC-HT. When you skip it presumably has to decode the video from the last key frame to the point you skip to, making it quite computationally intensive. With version 2.5.1 the skip used to occur pretty much instantly, but in 3.0.1 there is a long delay of 1-2 seconds before the video resumes play. Even with low bitrate 720p it's painfully slow so I went back to 2.5.1 and it's back to it's normal speed.


That may be so, but there's still no reason for it to be substantially slower than 2.x. The main reason I use CoreAVC is so I can employ a low power CPU, and therefore have an entirely passively cooled media PC. I don't want to have to use a CPU that requires fan cooling, though with the lack of Hi10P CUDA acceleration and the slow CUDA performance in general it looks like I no longer have a choice.

As evidenced by the changelog, there haven't been any changes to the CUDA decoding since 2.5.0 so I can't explain these slowdowns you're seeing.

[nm]

I'll have to get a more powerful processor and was considering these (mostly because they're the fastest 2 and 4 core CPUs with a 65W TDP):

Intel Core i7 2600S with 4 HT cores at 2.8GHz (http://ark.intel.com/products/52215/Intel-Core-i7-2600S-Processor-%288M-Cache-2_80-GHz%29)
Intel Core i3 2125 with 2 HT cores at 3.3GHz (http://ark.intel.com/products/59080/Intel-Core-i3-2125-Processor-%283M-Cache-3_30-GHz%29)

I was wondering effectively CoreeAVC makes use of multiple cores. Is it better to have four cores or two cores with a higher clock speed?

That 4-core i7 is much faster with both CoreAVC and current libavcodec (in ffsdshow-tryouts etc.).

[Gav80K]

That 4-core i7 is much faster with both CoreAVC and current libavcodec (in ffsdshow-tryouts etc.).

Thanks for the advice. I'll go for that.


As evidenced by the changelog, there haven't been any changes to the CUDA decoding since 2.5.0 so I can't explain these slowdowns you're seeing.

When I noticed the long delay that occurred when skipping in 3.0.1 I tried putting it on my desktop PC (which is probably a violation of the licence agreement) and found the same slow performance with CUDA on that, so there definitely seems to be an issue. I seem to recall that I had to uninstall everything (CoreAVC 3.0.1, Haaali Media Splitter and CCCP) before putting CoreAVC 2.5.1 to get the old performance back so maybe the issue is with Haaali Media Splitter or some other external component.

From what you said in an earlier posts it sounds like software decoding is better anyway so I'll just get a new PC.

[eddman]

I'll have to get a more powerful processor and was considering these (mostly because they're the fastest 2 and 4 core CPUs with a 65W TDP):

Intel Core i7 2600S with 4 HT cores at 2.8GHz (http://ark.intel.com/products/52215/Intel-Core-i7-2600S-Processor-%288M-Cache-2_80-GHz%29)
Intel Core i3 2125 with 2 HT cores at 3.3GHz (http://ark.intel.com/products/59080/Intel-Core-i3-2125-Processor-%283M-Cache-3_30-GHz%29)

I was wondering effectively CoreeAVC makes use of multiple cores. Is it better to have four cores or two cores with a higher clock speed?

You might want to take a look at these too:

Core i5 2390T / 2 cores / 2.7 GHz / 35 W TDP (http://ark.intel.com/products/53448)
Core i5 2500T / 4 cores / 2.3 GHz / 45 W TDP (http://ark.intel.com/products/52212)

I'd say a quad-core with lower clock speed is better than a dual-core with higher clock speed.

[Gav80K]

You might want to take a look at these too:

Core i5 2390T / 2 cores / 2.7 GHz / 35 W TDP (http://ark.intel.com/products/53448)
Core i5 2500T / 4 cores / 2.3 GHz / 45 W TDP (http://ark.intel.com/products/52212)

I'd say a quad-core with lower clock speed is better than a dual-core with higher clock speed.

Thanks for the suggestions, but I'll probably go with the faster Core i7 2600S to try and keep the skip time as short as possible.

I use the Coolermaster Hyper Z600 which can handle up to an 89W CPU with passive cooling so I should be fine with the 65W i7 2600S.

[nm]

Thanks for the suggestions, but I'll probably go with the faster Core i7 2600S to try and keep the skip time as short as possible.

Well, if skipping was instantaneous with CoreAVC 2.5, it started decoding from the nearest or next keyframe instead of the exact requested frame. If your CoreAVC 3.0 setup does skip to non-keyframe positions and therefore does unnecessary work, I'd suggest finding out the source of the problem instead of throwing hardware and money to work around the issue.

[Gav80K]

Well, if skipping was instantaneous with CoreAVC 2.5, it started decoding from the nearest or next keyframe instead of the exact requested frame. If your CoreAVC 3.0 setup does skip to non-keyframe positions and therefore does unnecessary work, I'd suggest finding out the source of the problem instead of throwing hardware and money to work around the issue.

When I said "pretty much instantly" I meant "an insignificant amount of time that caused no distraction". It now takes about four times as long so you're left with a pause that can last as much as two seconds, which is rather irritating. It does definitely decode from the last keyframe with 2.5.1, otherwise the video would have turned into a mess each time I skipped. It's the same on two PCs with significantly different hardware, so there does seem to be an issue with CUDA acceleration.

With no CUDA support for Hi10P I'd have to get a new PC anyway, so it's not really a major issue, but it is strange the performance has dropped so much.

[ajp_anton]

If you feel adventurous, get a "regular" CPU and undervolt it to get the same result as with a more expensive S or T model. Also, you have access to higher performance when seeking (which is so fast your cooling won't be affected).

[cyberbeing]

We are planning to do a release this week.

Is there a tentative changelog for 3.02 at this point?

[RoadPizza]

Thank you for the answers to my question about software vs hardware decoding. I have one other question that I have seen asked several times in this thread, but never answered. What, exactly, does the deblocking option "skip when safe" do? Thanks!

[BetaBoy]

Is there a tentative changelog for 3.02 at this point?

Its a floating target atm as we want to address both the bugs and speed concerns. But we were side tracked a few days as we have been working on the CoreAVC Developer SDK.... which is now updated to 3.0.2.

[nibus]

Does the new CoreAVC 3 decode 10-bit without the change in colors that is/was present in ffdshow? And has anyone really noticed big improvements from 10-bit in general?

[squid_80]

What, exactly, does the deblocking option "skip when safe" do? Thanks!

From the Help page in the filter properties:
Skip when safe - skip deblocking step when decoding B-frames.

[RoadPizza]

From the Help page in the filter properties:

I found that of course. I know I'm a newbie, but give me a little credit for having searched for my answer first :-)

I'm looking for a bit more detail... For example, from post #3890 in this thread:

"Do you mean NAL units designated as disposable (unreferenced B-frames), or do you really mean all B-frames? If the latter, its certainly not safe."

Also, if it really is safe to do this, why isn't it just part of the spec in the first place? Or at least the CoreAVC default? Thanks for any info.

[squid_80]

It means unreferenced B-frames. Skipping deblocking is not part of the spec at all, it degrades the image quality. The term "safe" means the image errors caused by lack of deblocking won't accumulate over time (because they will only apply to individual frames that aren't referenced by others).

[flapane]

With latest version of CoreAVC (2.5.5) on 7 x64 and HD5670, DXVA worked great with MPC-HC, but I couldn't enable it on WinTV live HDTV. The tray icon remains blue and the cpu sits at about 60%.
Furthermore, a guy from the WinTV tech support asked for more informations on CoreAVC API needed to set the GPU acceleration. I suppose that it may help to better understand the problem.
Any hints?
Thanks

Tried 3.0.1, nothing changed. The tray icon is still blue.

[nussman]

Take a look at page 331.
The infos für WinTV tech support could be found there!

[CiNcH]

Guess this is the same problem as with the DVBViewer. CoreAVC requires the splitter to deliver SPS/PPS at connection time. If the splitter does not deliver, CoreAVC falls back to SW mode.

[nussman]

@flapane: Please let us know how WinTV tech support thinks about it!

[CiNcH]

@flapane: Please let us know how WinTV tech support thinks about it!
They won't have any opinion. Believe me ;) . Does WinTV use the MS MPEG-2 demultiplexer?

[flapane]

I think they'd gladly work together with CoreAVC devs in order to solve the issue, otherwise we'll never get HW acceleration: http://www.hauppauge.co.uk/board/showthread.php?22237-CoreAVC-DXVA-support&p=103351#post103351

[CiNcH]

I now tried WatchTVPro. It uses the MPEG-2 Demultiplexer. Most DVB BDA apps do. The result is no DXVA (see here (http://members.inode.at/762450/coreavc/mpeg_demux_coreavc.jpg)). The WinTV guys can't solve this issue. Only if they develop their own splitter which adheres to the CoreAVC rules.

[flapane]

As you can see on Hauppage forum, they sent an e-mail to CoreAVC devs, without luck.

[CiNcH]

CoreCodec is aware of the issue. All you can do is sit back an wait (hope). nussman posted a reference to the discussion with technical background...

[dead_screem]

betaboy, any news on 3.0.2?

[D.A.S.]

1. Not working DXVA
2. OS - Windows 7 SP1 32bit
3. CPU - AMD Phenom II X4 940
4. GPU - Radeon HD 5670
5. Video Driver version - 11.8
6. Player - MPC-HC v1.5.3.3739
7. Renderer - EVR custom pres **
8. Splitter - Haali 1.11.96.14
9. Codec - CoreAVC 3.0.1
10. Output - NV12
11. Acceleration - DXVA on.

Sample
http://www.multiupload.com/4RR117CUFZ

Built-in decoder MPC-HC works with DXVA.

If the file is repackage a new version of mkvmerge then DXVA to work on CoreAVC 3.0.1

[kirakami]

when will CoreAVC 3.0.2 release?
will CoreAVC 3.0.1 also work on my old pc's with Nvidia Ge-Force 4 MX440?
what are steps to enable HW acceleration on CoreAVC with MPC-HC?

[BetaBoy]

An update for all... we are taking a little more time in devel and going right to CoreAVC 3.1 and adding more features, speed enhancements then planned. On apps that that do not conform to proper SPS handling... we added a work around for 3.1.

This new work might delay adding 4:4:4 profile support (which is mostly done anyway) but based on the feedback we feel the potential delay is worth it.

[Mangix]

will CoreAVC 3.0.1 also work on my old pc's with Nvidia Ge-Force 4 MX440?

no. cpu decoding still works though.

that card was released in 2003 i think. 8 years wow...

[mkanet]

I just upgraded my display card to a 4th generation Nvidia Purevideo HD card.. GT545. I was told it has the best decoding that Nvidia has to offer.

I am curious which of the following would take advantage of my graphics card's decoding capabilities the best:

1. Windows 7 64bit "DTV-DVD Video Decoder"
2. CoreAVC 3.0.1 Cuda
3. CoreAVC 3.0.1 DXVA


Above, when I mean "best", I mean in respect to bluray spec H.264 decoding.

Shamelessly, I really, REALLY wanted LAV Video decoder to work since it also supports mpeg2/VC1; however, on my machine, it has unacceptable stability issues under my directshow software. CoreAVC, "knock on wood" works no matter settings I choose... just not sure which is ideal for my needs.

[Asmodian]

Well the GT 545 (I have one too) isn't actually any better than any of the rest of the fermi cards, only the GT520 (as far as I know) has Purevideo HD feature set D, the fifth generation of purevideo.

That said, the GT 545 is one of the better cards as the GT520 doesn't have enough cores to do the best deinterlacing.

CoreAVC Cuda is what you want.

[mkanet]

Thanks. I mean the GT 545 was better than generation 3, 2, and 1. I upgraded from an GT8500.

What's the difference between CoreAVC Cuda and the decoder that comes with Win7?

If I want cuda for mpeg2 and VC1, what decoder can I use if LAV Video has stability issues on my system?

EDIT: I just realized, I also have latest version of TMT5 installed on my machine. I already use it's audio decoder. Doesn't it's video decoder already support cuda for all popular video formats? I vaguely remember that TMT started supporting cuda back in version 3.

This may sound like a dumb question, but isn't this the same kind of cuda that's used in CoreAVC and LAV Video?

Well the GT 545 (I have one too) isn't actually any better than any of the rest of the fermi cards, only the GT520 (as far as I know) has Purevideo HD feature set D, the fifth generation of purevideo.

That said, the GT 545 is one of the better cards as the GT520 doesn't have enough cores to do the best deinterlacing.

CoreAVC Cuda is what you want.

[Mixer73]

This may sound like a dumb question, but isn't this the same kind of cuda that's used in CoreAVC and LAV Video?

You're getting confused by the fact that there's a few different paths to the same hardware decoders.

CoreAVC and TMT will use standard DXVA, where you just offload the processing to the hardware and it gets played.

CUDA is a programming interface to use the shaders on your graphics card, but it also allows a function called CUVID which is a way to interface to the DXVA decoding and let you have access to capabilities which are not available through standard DXVA - like subtitles, madVR etc. I think CoreAVC labelling this "CUDA" is a bit of a misnomer.

Now I'm not half as smart as a lot of the guys here but I hope this clears things up for you.

[LigH]

It has been explained and criticized dozens of times already. The hardware accellerated video decoders don't use CUDA to calculate the decoding, they just use it to let the video pass to the PureVideo hardware decoding engine (V2 or newer). "Misnomer" is indeed a matching rating ... "CUDA" sounds so conveniently advertizing; "CUVID" instead is less famous, although more correct.

[SEt]

It does use CUDA, but not for decoding h264/vc1 itself - for reading decoded data from videocard. It's quite expensive process too.

mkanet, it was said many times that all decoders that correctly decode h264 are equal. Zero quality difference, be it hardware or software. Nowadays there is no much reason for caring about hardware decoding (unless your CPU is seriously outdated or you want to save every possible bit of energy or want hardware deinterlacer). As about problems with LAV - they are likely due to something bad installed on your system (hint: codecpacks).

Also even if different codecs use the same DXVA or CUDA decoders - it doesn't mean they work exactly the same. Because there are plenty of places before and after them where mistakes can be made.

[CruNcher]

It has been explained and criticized dozens of times already. The hardware accellerated video decoders don't use CUDA to calculate the decoding, they just use it to let the video pass to the PureVideo hardware decoding engine (V2 or newer). "Misnomer" is indeed a matching rating ... "CUDA" sounds so conveniently advertizing; "CUVID" instead is less famous, although more correct.

Actually for Mpeg-2 Bitstreams it does use CUDA to fix a Hardware issue in VP2 upto VP4 ;)

Also even if different codecs use the same DXVA or CUDA decoders - it doesn't mean they work exactly the same. Because there are plenty of places before and after them where mistakes can be made.

Yep true true even DXVA decoder can differ greatly especially in efficiency and bugs i remember the 60 fps playback problem on my VP2 that only Cyberlink was able to cope with on VMR9 compared to all the other DXVA implementations (which was really unique) :P
And imho it is still the most efficient DXVA implementation for both NT 5/6 and GPUs compared to others, though it also has it's drawbacks with some not so widespread bitstreams that other implementation again do better with :)

[jmelan]

any update on a release date for coreMVC?

[cyberbeing]

Progress report on CoreAVC 3.1 as well?

[CiNcH]

"QA" must be hard at work...

[BetaBoy]

We finished our current todo for our 3.1 core work. We have added 4:4:4 profile support and fixed most of the reported bugs as well as added a bunch of 10 bit optimizations.

We still have some directshow work to do, so let's see how the next week work goes.

[BetaBoy]

any update on a release date for coreMVC?

With the recent microsoft additions to MVC in directshow/windows 7. We will release a consumer decoder after we add those additions. Also we wanted to wait till we added 4:4:4 support which is now done. So likely sometime at or around CES.

Note that the CoreMVC Library SDK (non-directshow) has aleady been released for Developer / OEM integration and is being used for consumer 3D applications.

[robpdotcom]

Any news on getting a fix for the Haali/TrueHD issue?

[Livias]

@BetaBoy, are you talking about CES as in next January?

[Mitchan81]

I recently purchased CoreAVC 3.0.1 for use DXVA with my Intel G45 GPU - X4500HD

Now I was looking to buy an NVIDIA card (Intel have 23.976hz playback issue) but I did not understand about what parameters should I look to use all features of CoreAVC's CUDA decode? ram? gpu clock? number of cuda core? VPA3-4-5? etc etc

which card should I buy?

[LoRd_MuldeR]

I recently purchased CoreAVC 3.0.1 for use DXVA with my Intel G45 GPU - X4500HD

Now I was looking to buy an NVIDIA card (Intel have 23.976hz playback issue) but I did not understand about what parameters should I look to use all features of CoreAVC's CUDA decode? ram? gpu clock? number of cuda core? VPA3-4-5? etc etc

which card should I buy?

Shouldn't matter, because DXVA as well as "CUDA acceleration" (actually CUVID) doesn't use the GPU at all!

DXVA and CUVID are just two different API's to access the card's built-in "video engine" (called "PureVideo" in NVidia jargon). But these are separate/dedicated circuits, not the actual GPU!

And, most important, the video engine is pretty much identical between "low end", "performance" and "high end" cards.

(Just be sure you buy a card that has the latest incarnation of the "PureVideo" engine on board. The latest version currently is VP5. Funny enough, the "high end" cards still use VP4)

[Mitchan81]

(Just be sure you buy a card that has the latest incarnation of the "PureVideo" engine on board. The latest version currently is VP5. Funny enough, the "high end" cards still use VP4)

Exact!!! The only one with VP5 is GT520 (64bit bus, 1gb ddr3)
So... you're telling me that gt520 is faster then gtx590 (384bit x 2 bus, 3072 MB ram etc etc) with CorAVC - CUDA acceleration (PureVideo HD) ?

[nm]

GT 520 decodes faster (H.264 video at 120 fps instead of 60 fps), but if you also want to postprocess (deinterlace, denoise, ...) HD video on the GPU, then the other parameters such as the number of CUDA cores do matter. GT 520 may not be fast enough when using multiple filters at the same time -- it can barely manage the "temporal-spatial" deinterlacing mode for 1080i30.

[nevcairiel]

I would not buy the 520, its too slow. Go with a 430 or 440, or if you want some more, a 450 or 550.

[Mitchan81]

I would not buy the 520, its too slow.

slow for what? LAV CUVID or madVR?


if you want some more

yes.. but more WHAT??? :D

I need only HTPC video card. No games.

thx for your support ;)

[nevcairiel]

The 520 is too slow for anything. It can't even properly do full quality deinterlacing, be it with EVR or anything else.

[eddman]

I recently purchased CoreAVC 3.0.1 for use DXVA with my Intel G45 GPU - X4500HD

Now I was looking to buy an NVIDIA card (Intel have 23.976hz playback issue) but I did not understand about what parameters should I look to use all features of CoreAVC's CUDA decode? ram? gpu clock? number of cuda core? VPA3-4-5? etc etc

which card should I buy?

Here, read up and decide.

http://www.anandtech.com/show/4380/discrete-htpc-gpus-shootout/1

[rica]

Hi guys!

I just purchased CoreAVC to test its mvc deoding capability.
Can somebody guide me how it is possible on GraphStudio?

Which splitter, which renderer?

Thanks.


_ _ _ _

[LoRd_MuldeR]

I just purchased CoreAVC to test its mvc deoding capability.

Aren't CoreAVC and CoreMVC two different products, with the latter still to be released (as a standalone product)? :confused:

http://forum.doom9.org/showpost.php?p=1535817&postcount=6889

[rica]

Aren't CoreAVC and CoreMVC two different products, with the latter still to be released (as a standalone product)? :confused:

http://forum.doom9.org/showpost.php?p=1535817&postcount=6889

Please checkout changelog:

http://corecodec.com/products/coreavc/changelog

- ADD: Support for MVC 3D videos

[Keiyakusha]

Please checkout changelog:

http://corecodec.com/products/coreavc/changelog

I only see "SDK: Initial support for MVC (CoreMVC) integration" which means you're not getting MVC in CoreAVC.
"ADD" is just for haali splitter. So after all you can't watch MVC with CoreAVC

[LoRd_MuldeR]

I only see "SDK: Initial support for MVC (CoreMVC) integration"

Yup. It means that they have added MVC support to their SDK (Software Development Kit), which other companies can license for their own products.

Still "CoreAVC" and "CoreMVC" are two separate stand-alone products. And only the latter will support MVC.

Also the MVC support that has been added to Haali's Splitter means that you will be able to use Haali's Splitter in conjunction with CoreMVC, once the latter is released. Nothing more.

(Please correct me if I'm wrong...)

[rica]

I only see "SDK: Initial support for MVC (CoreMVC) integration" which means you're not getting MVC in CoreAVC.
"ADD" is just for haali splitter. So after all you can't watch MVC with CoreAVC

I understand with "add", you can watch MVC with Haali?

[Keiyakusha]

I understand with "add", you can watch MVC with Haali?
Well in theory yes, but of course if you also have MVC decoder that can work with it. I don't have such decoders so have no idea if haali really works as advertised.
EDIT: oh, BTW, I was just told that MVC stream is backward compatible with AVC so someone probably tried that already and can tell better if haali really works

[rica]

Then i spend money for nothing.

[madshi]

Well, I think it was pretty clear that CoreMVC would be a separate product. You gotta inform yourself before making a purchase... ;)

[rica]

Well, I think it was pretty clear that CoreMVC would be a separate product. You gotta inform yourself before making a purchase... ;)

I'm lucky; at least the cost of purchasing unless informed was just 12 USD :o

[BetaBoy]

Rica... PM me ill issue you a refund.

As stated CoreMVC is a separate product, but at its core it uses CoreAVC. Technically we already addd support for Haali's splitter for MVC streams with the 3.0 release but we are adding support for the MS directshow MVC spec before we release CoreMVC.

[rica]

Rica... PM me ill issue you a refund.

As stated CoreMVC is a separate product, but at its core it uses CoreAVC. Technically we already addd support for Haali's splitter for MVC streams with the 3.0 release but we are adding support for the MS directshow MVC spec before we release CoreMVC.

Thanks a lot betaboy but this is my fault and i don't need any refund. And i'm happy with my new toy :)

But i wouldn't object to any discount ticket when you released Core MVC :)

[n3w813]

The 520 is too slow for anything. It can't even properly do full quality deinterlacing, be it with EVR or anything else.

I have a GT520 and it can decode 1080p60 Blurays without issues with Lav Video w/CUVID and MadVR. :) I've never tried interlaced content though. :p

[Thunderbolt8]

how many 1080p60 BDs are actually out there?

[nevcairiel]

how many 1080p60 BDs are actually out there?

None, its not a valid format for Blu-ray.
You can get 1080i60 or 720p60, but not 1080p60.

[kirakami]

i have CoreAVC 3.0.1 installed
Can CoreAVC alone Output P010 without using madVR??? have anyone tried.
i m using MPC-HC.

[XRyche]

i have CoreAVC 3.0.1 installed
Can CoreAVC alone Output P010 without using madVR??? have anyone tried.
i m using MPC-HC.

CoreAVC 3.01 can handle P010 but......MadVR is the only renderer that can output P010 atm. If you use haali, any flavor EVR, Overlay, any flavor VMR, etc.... it outputs in 8 bit format. To my understanding (which admittedly is very limited) it all gets displayed on your monitor as 8 bit anyways (dithered or not). I could be wrong though so if someone more knowledgeable could set me straight I'd appreciate it.
Oh MPC-HC tester builds for internal renderer fixes http://forum.doom9.org/showthread.php?t=161047
can surface display 32 bit but it uses shaders to do this and can be very unstable. That said, personally I like it.

[sneaker_ger]

MadVR is the only renderer that can output P010 atm.

IIRC, though madVR accepts P010 input, it can not output 10 bit.

[XRyche]

IIRC, though madVR accepts P010 input, it can not output 10 bit.

It does output 10 bit on the surface but your monitor can't.

[sneaker_ger]

Those are only for its internal processing, I think. Final output is always dithered down to 8 bit max.

[pankov]

It does output 10 bit on the surface but your monitor can't.
I think you are wrong.
madVR always outputs 8bit. When it get's 10bit input it dithers it down to 8bit

[madshi]

AFAIK madVR is the only renderer which *accepts* P010 (unless JanWillems has changed VMR/EVR accordingly). The whole madVR processing chain is 16bit+, so full use of P010 is made. However, final output is currently always dithered down to 8bit, but the dithering makes sure that most of the high bitdepth information is still intact, so the 8bit output is not really a problem. 10bit output is eventually planned for a future version. FWIW, the best solution for image quality is to have the dithering done as the last step in the processing chain. So having madVR do it is better than to have CoreAVC do it.

[SEt]

CoreAVC works just fine with P010 and P016 without MadVR - for example with my renderer (it's private one). So, I think there is no problems in CoreAVC's implementation if that is what you are concerned about.
But if you want P010 for "higher quality" with MPC-HC - don't bother, you won't see the difference between decent renderer fed with 8 and 10 bit data.

[XRyche]

Well...I'm glad that I put that qualifier to my answer. Thanks for setting me straight madshi and company :) .

[LoRd_MuldeR]

Rule #6 post and follow-up's have been removed. Discussion about "pirated" software is not allowed.

[Thunderbolt8]

does coreavc actually use frame-based multi-threading? or only multi-threading based on slices?

if frame-based multi-threading, is there any limitation regarding the number of threads which can be used for decoding?

[LoRd_MuldeR]

CoreAVC does not need slices in the H.264 stream to do multi-threaded decoding:
http://img832.imageshack.us/img832/9826/coreavcperf.png

(It scales up to at least 4 threads, as you can see. I don't have a machine with even more cores)

[kirakami]

Which Nvidia Graphic cards can actually output P010/P016?
Are there even monitor's available yet that can show
10-bit color space without dithering to 8-bit?
Not dithered to 8-bit by monitor before hit the display
even if card can output 10-bit

[Paladin77]

I enjoyed this product. Although I did switch to better free alternatives which provide better performance especially with my 10 bit anime titles. Still it does a great job!

As for 10 bit dithering. So far madVR is unmatched due to what madshi explained. Dithering occurs at final step of processing.

[The Seeker]

Is there a list somewhere detailing CoreAVC's supported ATI GPUs?

Edit: Never mind, mine is supported.

[06_taro]

The latest mmg recognizes ttf font as "application/x-font-ttf" as default MIME type.
Haali(v1.11.288.0) fails to load this type of embedded font, it only load "application/x-truetype-font" fonts, which are detected as default MIME type in old versions of mmg.
Other splitter like LAV/AV/Gabest (All latest, older versions like Gabest before svn r3802 are not included) can load "application/x-font-ttf" fonts.

Forgive me if Haali's issues are not supposed to be here.

[cyberbeing]

The latest mmg recognizes ttf font as "application/x-font-ttf" as default MIME type.
Haali(v1.11.288.0) fails to load this type of embedded font, it only load "application/x-truetype-font" fonts, which are detected as default MIME type in old versions of mmg.
In mmg 5.1.0, OTF fonts are now identified as application/vnd.ms-opentype instead of application/x-truetype-font as well, so I'd assume they are also affected?

[benus]

It seems that the new version of CoreAVC is gonna be released on Monday:

http://twitter.com/corecodec

[LoRd_MuldeR]

It says that the work on finalizing v3.1 begins on Monday. Not that this work will be completed on Monday...

[BetaBoy]

On Monday we will begin working on putting together the various projects we have been working on for CoreAVC 3.1.

[cyberbeing]

Will an updated Haali Splitter which fixes the unsupported MIME type font loading issues be included with v3.1 or sometime after?

[madshi]

Bug report:

It seems that CoreAVC does not set the "IMediaSample2::GetProperties" flag "AM_VIDEO_FLAG_REPEAT_FIELD". This is an important piece of information which is needed to reliably detect a 3:2 pulldown pattern for IVTC algorithms. Without this flag, soft-telecined content will look like 2:2 while hard-telecined content will look like 3:2.

[wanezhiling]

Here's a sample (http://uploadingit.com/file/bvjftldv095pahat/no%20dxva.avi), cuda ok, but dxva failed...


Another sample (http://uploadingit.com/file/erzothack7ksfyk3/1%20(1)-001%20(1)-001%20(1)-001.mkv):there's lots of skipped frame with dxva or cuda mode...

[vivan]

This site is down.
http://2.firepic.org/2/images/2011-12/11/rhmeo1mqltdm.png
UPD: now it's up, but it says that file not found. And that their service is broken.

[BetaBoy]

Madshi.... can you supply an example for us to look at?

[madshi]

Sure, try this one:

http://madshi.net/repeatFirstField.evo

If you look at the h264 bitstream, you'll find the following pic_struct variations:

3: top field, bottom field
4: bottom field, top field
5: top field, bottom field, top field
6: bottom field, top field, bottom field

For these pic_struct variations, CoreAVC should output the following flags via IMediaSample2.Get/SetProperties:

3: AM_VIDEO_FLAG_FIELD1FIRST
4: 0
5: AM_VIDEO_FLAG_REPEAT_FIELD | AM_VIDEO_FLAG_FIELD1FIRST
6: AM_VIDEO_FLAG_REPEAT_FIELD

Thanks!

[wanezhiling]

This site is down.
http://2.firepic.org/2/images/2011-12/11/rhmeo1mqltdm.png
UPD: now it's up, but it says that file not found. And that their service is broken.

cuda ok, but dxva failed (http://www.mediafire.com/?4yk1pi21wd0tbuv)...

lots of skipped frame with dxva or cuda mode... (http://www.mediafire.com/?wykw88vi5p8nqi5)

[BetaBoy]

madshi... can you explain this a little more. If "hard telecine" is used there are no flags in the source so we have no idea what to set, and for "soft telecine" streams coreavc ignores the flags so the original rate is used.

[madshi]

madshi... can you explain this a little more. If "hard telecine" is used there are no flags in the source so we have no idea what to set, and for "soft telecine" streams coreavc ignores the flags so the original rate is used.
There's nothing you can do about hard telecine. But for soft telecine you should pass the flags downstream. You don't need to do anything with the flags yourself, just set them in the properties of the IMediaSample2 you output. That's really all you need to do, should be very easy to do, and there should be no negative side effects at all.

You may wonder why this might be useful. After all if you simply ignore soft-telecine, we get perfect progressive output, right? Well, that's true for HD DVD and Blu-Ray. But some countries are now broadcasting in h264, and we can't expect the broadcast to always stick to soft-telecine. The broadcasts might switch between soft-telecine and hard-telecine in the middle of the stream. I don't have a sample for that, but it happens very often with MPEG2 broadcasts (plenty of samples for that) so I would expect this to eventually happen with h264 broadcasts, too. In order to properly IVTC such streams, it is very useful to know which frames are hard-telecined and which are soft-telecined and how they are soft-telecined. That's why it would be useful if CoreAVC could pass the soft-telecine flags downstream.

I'm working on an IVTC algorithm for madVR, and it's working pretty well for MPEG2 broadcasts, even if there are mixed hard-telecined and soft-telecined sections, as long as the MPEG2 decoder outputs the proper soft-telecine flags. So this is why I'm now asking you for this, too, just to make sure that IVTC will work well for h264 broadcasts with mixed hard-telecined and soft-telecined frames, too.

[mp3dom]

Well, that's true for HD DVD and Blu-Ray. But some countries are now broadcasting in h264, and we can't expect the broadcast to always stick to soft-telecine.

It happens with Bluray too... especially on trailers that are edited at 60i for 'broadcast' purpose but gets a mixture of hard and soft pulldown encode while on disk.

[madshi]

It happens with Bluray too... especially on trailers that are edited at 60i for 'broadcast' purpose but gets a mixture of hard and soft pulldown encode while on disk.
Didn't know that. Do you happen to have a sample?

[mp3dom]

I don't have a sample here with me but it can be created. A lot of bd encoders have a built-in IVTC so they can encode both soft and hard pulldown (soft when they catch the pattern and hard when they're unable to detect it).
It can happens with 1080i contents but also with 480i (always referred to AVC encode)

[madshi]

Would it be easy for you to create such a sample? It would be quite useful for testing purposes. If you can do this, maybe you can pick a sample with a lot of movement in it, so that it's easy to see whether IVTC succeeded or not?

[mp3dom]

Here: http://www.mediafire.com/?s9wr6ljdrl3ew9a
Both 1080i60 and 480i60 (don't know if there are flag differences).
There are 2 segments in each file, first segment is hard pulldown, second is soft.

[madshi]

Here: http://www.mediafire.com/?s9wr6ljdrl3ew9a
Both 1080i60 and 480i60 (don't know if there are flag differences).
There are 2 segments in each file, first segment is hard pulldown, second is soft.
Thank you!! :)

I can confirm that with these test samples, my (work-in-progress) IVTC algorithm reliably detects a 3:2 cadence in the hard-telecine section with both CoreAVC and LAV Video Decoder. When the soft-telecine section begins, with CoreAVC my IVTC algorithm detects a cadence break and detects a new 2:2 cadence for the 2nd half of the samples. When using the LAV Video Decoder, the cadence stays unbroken at 3:2 for the full runtime of both samples, because LAV Video Decoder forwards the soft-telecine flags to madVR. The SD and HD samples behave identically.

[mp3dom]

Glad it helps :) The samples are bd-compliant, so it's the way an hypothetical bluray could look.

[kieranrk]

I don't have a sample for that, but it happens very often with MPEG2 broadcasts (plenty of samples for that) so I would expect this to eventually happen with h264 broadcasts, too. In order to properly IVTC such streams, it is very useful to know which frames are hard-telecined and which are soft-telecined and how they are soft-telecined. That's why it would be useful if CoreAVC could pass the soft-telecine flags downstream.


Generally speaking, you don't set your encoders to do pulldown detection if you're sending captions because it has bad hardware support. This applies to AVC broadcasts as well so I think this issue will be quite rare.

[drmpeg]

Generally speaking, you don't set your encoders to do pulldown detection if you're sending captions because it has bad hardware support. This applies to AVC broadcasts as well so I think this issue will be quite rare.

Almost every 1080i pay TV channel in the US has IVTC enabled on their encoders.

Ron

[BetaBoy]

madshi... we are on the fence here about your post. It's our general opinion that this is not a bug and that it's more of a feature request. So to that...

CoreAVC already removes soft pulldown by itself. If the stream switches between soft and hard then those sectors have no relevance to each other so the flags are then useless. Also, since we are already undoing the soft telecine it would be bad (in our opinion) to pass the progressive frames with those flags set.

So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer.

The only way to properly fix hard interlacing is to use a deinterlacer that is designed to do it.

[madshi]

we are on the fence here about your post.
"On the fence" isn't too bad, it means you're still open for discussion... :D

CoreAVC already removes soft pulldown by itself. If the stream switches between soft and hard then those sectors have no relevance to each other then the flags are useless. Also, since we are already undoing the soft telecine it would be bad (in our opinion) to pass the progressive frames with those flags set.

So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer.
You're saying that users would get an interlaced picture if you set the telecine flags. But I don't think that's true. Anyway, can you describe a setup for me where setting the telecine flags would result in a loss of quality? The LAV Video Decoder does (always) set the telecine flags, so it should be easy to test. If you're right then LAV Video Decoder should show soft-telecined content at a lower quality compared to CoreAVC with some renderers.

The only way to properly fix hard interlacing is to use a deinterlacer that is designed to do it.
And that is exactly what I'm working on. But CoreAVC is making things harder than necessary. CoreAVC sets the media type information to 30fps, but for soft-telecined sections only sends 24fps, without telecine flags. So basically CoreAVC is lying. If you remove the telecine flags then you should set the media type information to 24fps. Of course that will make problems with content that has hard-telecine sections, so that brings me back to my argument that there's no reason not to set the telecine flags.

If the stream switches between soft and hard then those sectors have no relevance to each other then the flags are useless.
I'm sorry to say but this is just not true. If you look at such mixed hard-/soft-telecined streams, if you honor the soft-telecine flags you always end up with exactly 60 fields per seconds, no matter how often the stream switches between soft- and hard-telecine. If you silently drop the telecine flags, the deinterlacer will neither get 48 fields per second, nor 60 fields per second, but something in between, every time the stream switches between soft <-> hard telecine. If you have ever tried writing an IVTC algorithm then you should know that this is not a good situation. Getting exactly 60 fields per second is a requirement of most IVTC algorithms. How else can you detect a 3:2 pattern in the stream? If you get e.g. 55 fields per second, the 3:2 cadence will be broken several times and applying IVTC will become extremely hard to do.

[06_taro]

So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer.

Then you can provide an option for end users to decide whether to maintain pulldown flags and handle them after decoding, or to drop the flags with 24fps film content output directly as in the present version. Those who never meet mixed soft/hard telecined films and don't use any IVTC/deinterlacing postprocessing can still choose the second one to avoid getting interlaced content, but for those who prefer a more reliable IVTC algorithm which can handle mixed soft/hard telecined contents, the first one is much better for most ( if not all ) IVTC algorithms.

[dead_screem]

CoreAVC already removes soft pulldown by itself.

define remove?

lav and other decoders I used as well (mpeg-2 decoders mostly), leave the indicated output framerate alone at 29.97 so hard telecine parts of a mixed stream play back at 29.97 (or 59.94) but soft telecine parts of the stream play back at 23.976. In coreavc soft telecine plays back at 29.97, the same as hard telecine.

at the very least, this should be an option to do it as in lav, so users can (when madshi's ivtc renderer is done) play back 29.97 hard and soft telecine streams as well as mixed hard/soft at 23.976

[v_spec]

In version 3.01 I noticed a new output option '9/10 bit', but whenever I check the box then hit Apply and OK the box is unchecked when I go back into decoder properties. What does that mean? Is it a problem with CoreAVC or my hardware?

[cyberbeing]

It's neither a problem with CoreAVC or your hardware. The '9/10 bit' check-box is only a toggle for showing/hiding P010 & P016 in the output format box. The '9/10 bit' check-box does not affect anything but the GUI.

The real options to enable/disable high bitdepth output are the P010 & P016 check-boxes. As long as they are checked, they are enabled and available for use with 9/10 bit h264 video and a supporting video renderer. (Currently only madVR supports P010/P016 input).

[v_spec]

Thanks for clearing that up. I've been reading up on madVR for the past couple of hours and was thinking if there is a noticeable difference in quality between the non-9/10 bit h264 video and 9/10 bit video?

[cyberbeing]

There is a noticeable quality difference between 10-bit x264 and 8-bit x264.

Yet there is hardly any quality difference between CoreAVC outputting 10-bit x264 as dithered 8-bit YV12 vs 10-bit P010. Both ways are eventually output to your display as 8-bit.

If you are using madVR there is a minor technical benefit of outputting P010, since madVR can then do other processing gamut/gamma/yuv->rgb using the full 10-bit data and dither to 8-bit for your display as the last step. Would you notice the difference of madVR processing 8-bit input vs 10-bit input, probably not. But depending how close you look, you may notice a difference in dithering quality & noise pattern.

[Keiyakusha]

and was thinking if there is a noticeable difference in quality between the non-9/10 bit h264 video and 9/10 bit video?
You should think of 10bit as "yet another switch in x264 that improves quality during encoding" And resulting 10bit file is "yet another video format"
^very simplified explanation
The switch in the coreavc and other decoders tells what they should do, leave 10bit format as is so it will be dithered to 8bit later (by madvr for example) or dither it by itself. So nothing is wrong if you don't see the difference.

[NikosD]

@BetaBoy

Hello.

Is there any plan of supporting resolutions beyond 1920 x 1088, like 4K x 2K (3840 x 2160) in DXVA mode and suitable hardware of course ?

Thanks!

[hajj_3]

I doubt there is any hardware that can accelerate 4k out there.

The Cortex A8 Allwinner A10 ARM has built-in support for hardware decode of 2k but i'm not aware of anything with 4k.

If Intel/AMD/Nvidia comes out with 4k hardware decode support i'm sure CoreAVC/DiAVC will support it.

[Keiyakusha]

i doubt there is any hardware that can accelerate 4k out there.


gt 520

[wanezhiling]

http://www.mediafire.com/?7vc5zl5tbm9y55p
GF119, dxva 2160p. :D

[NikosD]

Radeon 5000 series with UVD 2.2 are capable of 4K since April 2010 with Catalyst 10.4
But there were no suitable decoders/players to support it due to Nvidia restrictions.

As I have proved here http://forum.doom9.org/showthread.php?t=163110 even UVD 2.2 is more capable than most people think.
UVD3 supports 4K too.

I thought now that there is VP5 which seems capable of 4K, Nvidia should be more flexible to allow 4K in general and pull back the pressure of not allowing 4K decoding on ATI hardware.

[rica]

Still waiting for CoreMVC.

[NikosD]

http://www.mediafire.com/?7vc5zl5tbm9y55p
GF119, dxva 2160p. :D

For me - 5750 UVD2.2 - it's not working even though DXVA checker says about the Device decoders:

"ModeH264_VLD_NoFGT: DXVA2, 720x480 / 1280x720 / 1920x1080 / 3840x2160"
"ModeH264_VLD_NoFGT_Flash: DXVA2, 720x480 / 1280x720 / 1920x1080 / 3840x2160"

So from the side of hardware and driver, UVD 2.2 is capable of 4K x 2K and if CoreAVC DXVA is capable of 4K x 2K, as it is clearly seen by your screenshots, then the problem must be an artificial restriction in everything else but VP5 inside the code of CoreAVC DXVA.

DXVA checker reports for clips beyond 1080p and CoreAVC DXVA the following:

"ModeUnknown (NV12): DXVA1 (VMR)"

and of course it's not working.

@BetaBoy

I would like to check my "fused" 5750-6750 card in 4K x 2K DXVA with its "supernatural" video decoding capabilities as I have clearly demonstrated here:
http://forum.doom9.org/showthread.php?t=163110

[Cyber-Mav]

Radeon 5000 series with UVD 2.2 are capable of 4K since April 2010 with Catalyst 10.4
But there were no suitable decoders/players to support it due to Nvidia restrictions.

what restrictions are these you speak of imposed by nvidia?

[NikosD]

Because VP4 is very slow at high bitrate clips as you can see here http://forum.doom9.org/showthread.php?t=163110, UVD2.2 was forced to be incapable too for 4K x 2K in order to have comparable performance with VP4.

Nvidia had always a few ways to do things like "The Way it's meant to be played"

UVD2.2 in 5xxx series was too fast when introduced back in October 2009 and with Catalyst 10.4 - on April 2010 -it was ready for H.264 L5.1 including 4K, as it is written in Catalyst 10.4 Release Notes.
I can send you the file if you can't find it with google.

As you can see at the above link, UVD2.2 is more powerful than it seems and the reason that is lowered is not Nvidia only, but ATi too, mainly ATi I could say.

ATI wanted to sell UVD3 for MPEG2_VLD, MPEG4ASP_VLD and 4K H.264 playback.

All of them are features of UVD2.2, that have never activated in order to "push" you to buy the next generation card.

Even now if you force MPEG2_VLD, MPEG4ASP_VLD and 4K H.264 playback in UVD2.2, you get a normal playback mode with a GREEN FRAME covering the picture of the video file.

They don't want you to see the clip! :)

Of course all of the above are a joke, just a conspiracy theory I invented with my vivid imagination...

[Cyber-Mav]

if ati uvd 2.2 is so fast then why doesnt it show so in the benchmarks? looks like its either more of a hardware limitation or a driver lmitation. nothing is showing that its being held back by nvidia. last time i checked its the standard dxva mode that ati uses for hardware acceleration, and there is nothing nvidia can do to influence dxva acceleration.

unless you mean that the uvd2.2 is being held back by not having cuda support?

if you get green frame during playback its usually a sign that your hardware cant decode properly due too an out of spec input file. i get that a lot on my old mkv media player if i encode files with too many reference frames.

[clsid]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?

[robpdotcom]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?

I'm interested to know this as well.

[nevcairiel]

Whatever happend to CoreMVC? Wasn't it supposed to be released right after CoreAVC 3?
It seems to have a big marketing advertisement page on their website, but no download/purchase possibility.

[BetaBoy]

Whatever happend to CoreMVC? Wasn't it supposed to be released right after CoreAVC 3?
It seems to have a big marketing advertisement page on their website, but no download/purchase possibility.
It has been out since last February, but only for OEM licensing in both library and directshow forms. Based on feedback we opted to push out a consumer directshow decoder till after we added 4:2:2 and 4:4:4 in CoreAVC. We will revisit a possible release afterwards.

[BetaBoy]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?
The fix will be included in the next CoreAVC release.

[CruNcher]

@Dan
i hope it isn't to late yet, though maybe this is already fixed then you can ignore it :)

http://www.mediafire.com/?rnj806aa6tgjrp9

the issue is after the glitch Lav Splitter,Haali Splitter,MPC-HC splitter (Lav Audio) doesn't Recover with CoreAVC it begins to stutter (frames are dropped) (Software,DXVA,cuvid not tested) it works fine with Lav Video (any mode, cuvid not tested) see https://forum.doom9.org/showpost.php?p=1554770&postcount=8655

[NikosD]

@BetaBoy

Is it possible to clarify which path do you enable in order to HW accelerate H.264 files on Intel's QuickSync HW ?

There are a lot of confusing and contradicting issues regarding Intel's HW acceleration.

For example CoreAVC 2.x has DXVA support which utilises ModeH264_VLD_NoFGT but not for Intel.
It doesn't work.
It was Core AVC 3.x which added Media SDK and GMA support.
Do you use ModeH264_VLD_NoFGT or ModeH264_VLD_NoFGT_ClearVideo in order to HW accelerate H.264 files in CoreAVC 3.x ? Or something else ?
Because the performance of CoreAVC DXVA with QuickSync HW, indicates that it uses some direct mode of DXVA and not copy-back like QuickSync decoder by Egur.
At the same time using Intel's Media Checker tool, I saw that CoreAVC 3.x during HW accelerated playback on QS HW doesn't use Media SDK decode operations.
No HW calls, no SW calls of Media SDK.

So what is the mystery of CoreAVC 3.x and what's missing from CoreAVC 2.x ?

Is it a direct use of Media SDK - without copy-back- that Media Checker is not capable to catch ?

Thanks in advance.

[CruNcher]

it uses the ClearVideo mode like any other ISV does, copy back makes no sense for a On screen Decoder if you have Native DXVA support why the heck you would want to use copy back for playback ?
Copy Back makes sense to be used in a Decoding(DSP,GPU)->Encoding(Software,DSP,GPU) scenario where you balance both out so the CPU overhead can be compensated efficiently so the Encoding stays lower Power and Faster then without Copy Back (Software Decoding) :)
Or if you still need acceleration and lower power and combine it with a 3D renderer (for example a Broadcast Editing system with complex layer setups) :)
But for a consumer Playback system it makes no sense and isn't beneficial @ all @ least on Windows

[NikosD]

I didn't say CoreAVC uses copy-back.
I said the opposite, that they don't use it.

But CoreAVC supports Media SDK after CoreAVC 3.x.
ClearVideo support was there in CoreAVC 2.x, but QS HW support in CoreAVC 2.x wasn't.

You put PotPlayer and MPC-HC in ISV's too ?

What do they (PotPlayer and MPC-HC) use with their internal codecs in order to accelerate in QS HW the H.264 video ?

[CruNcher]

I didn't say CoreAVC uses copy-back.
I said the opposite, that they don't use it.

But CoreAVC supports Media SDK after CoreAVC 3.x.
ClearVideo support was there in CoreAVC 2.x, but QS HW support in CoreAVC 2.x wasn't.

You put PotPlayer and MPC-HC in ISV's too ?

What do they (PotPlayer and MPC-HC) use with their internal codecs in order to accelerate in QS HW the H.264 video ?

The same ClearVideo DXVA interface, though CoreAVC uses some clever workarounds the same as Mirillis does for several special decoding issues :)

Not every DXVA decoder is the same only because its using the same interface :)

Arcsoft and Cyberlink are currently also going this way trying to fix issues with workarounds

[NikosD]

Apparently MPC-HC doesn't have access to ClearVideo documentation because they have disabled DXVA acceleration for QS HW.

It doesn't work for them and they haven't found those clever workarounds you mention.

Splash and PotPlayer work fine with QS HW.
But I think PotPlayer doesn't have access to ClearVideo too, like MPC-HC.

How did they do it ?

[nevcairiel]

How did they do it ?

Probably stole it somewhere, like all their other stuff.
Also, PotPlayer uses Erics QS decoder.

[NikosD]

Probably build it by themselves, because there is no free code accessible for that task.
Erics QS decoder is an alternative mode for PotPlayer, like many others.

But their own internal codecs provide native DXVA acceleration for H.264 and MPEG-2, without using quicksync.dll

@Cruncher
If PotPlayer had access to ClearVideo documentation, they would have added VC-1 DXVA acceleration for QS HW, too.
Which is ClearVideo only.

So PotPlayer doesn't use ClearVideo for H.264, either.
They do it natively.

And what about MS DS/MFT ?
Do they use ClearVideo too?

[CruNcher]

they think practical why reinvent if someone did it already though they try to fix things no one tackled yet but give nothing back that's the shame of it :(
Though they don't do very advanced workarounds their workarounds are mostly container analyze based (MediaInfo) and just turning stuff on and off (still they have no automatic QS fallback for some of these issues which is the easiest way to fix them) when they think its better todo so but the other go into the bitstream level itself ;)

[TheShadowRunner]

Hi Betaboy,
Here's a report for a hi10p decoding bug:
The sample: cqm_sample.mkv (https://www.yousendit.com/download/T2djZUNuTkFoeVpBSXRVag)
LAV decodes it fine, but as you can see Core gives a huge artifact.
It's apparently due to the use of cqm.
Hope it helps.

[BetaBoy]

Hi Betaboy,
Here's a report for a hi10p decoding bug:
The sample: cqm_sample.mkv (https://www.yousendit.com/download/T2djZUNuTkFoeVpBSXRVag)
LAV decodes it fine, but as you can see Core gives a huge artifact.
It's apparently due to the use of cqm.
Hope it helps.

We are looking into it, thx for the sample.

[CruNcher]

@Dan

https://forum.doom9.org/showpost.php?p=1554111&postcount=6977

[BetaBoy]

CruNcher.. got it... fixed, thx.

[BetaBoy]

Hi Betaboy,
Here's a report for a hi10p decoding bug:
The sample: cqm_sample.mkv (https://www.yousendit.com/download/T2djZUNuTkFoeVpBSXRVag)
LAV decodes it fine, but as you can see Core gives a huge artifact.
It's apparently due to the use of cqm.
Hope it helps.
Fixed. Thx again for the report!

[dead_screem]

Care to comment on when the next version will be out? Twitter says "Feburary" but that is kinda vague, especially since there was going to be a quick turnaround 3.0.2 bug fix only release, but you guys decided to wait for 3.1 to release those fixes, and 3.1 was supposed to start finalizing last Dec 12... So, when's it coming out?

[BetaBoy]

As with all of our releases its a moving target based on feedback and where we are at with it, so its ready when its done. As you can see above we are also addressing other reported bugs as they are being reported as well as doing some work on Haali's Splitter so this has also affected our timeline.

At the moment it is looking like we are gonna push out adding 422 (444 will likely make it) with the next release to make sure the newer changes are solid before committing it. We will however likely still stick with it as a milestone in calling it 3.1 though considering all the work we have done on it.

We have a few smaller todo's with include Chroma MC ASM and 444 filter work, so we are close.

[kerman]

Doesnt CoreAVC supports VC-1? I have it as the main external filter on mpc-hc but doesnt run on VC-1 streams. It does on h.264/x264, but never with VC-1. I use MPC-HC x32 with madVR and Haali media source. OS Win7x64.

Also, on h.264 decoding doesnt enable dxva2 (tray icon is always blue), although I have dxva checked on properties. I have an AMD HD6950. Should I check/uncheck anything on CCC or mpc-hc?

[nevcairiel]

CoreAVC is only for ... AVC1, as the name suggest, also known as H.264. VC-1 is a different codec entirely, and not supported by CoreAVC.
I'll admit that the "AVC1" and "VC-1" might be confusing at times, but AVC1 is just an alternate name for H.264.

[kerman]

Thanks, yes I just got confused. BTW, is there any "champ" on VC-1 codec performance? Mainconcept, Arcsoft, Cyberlink...? I mean, similar to CoreAVC with H.264

[betaking]

Thanks, yes I just got confused. BTW, is there any "champ" on VC-1 codec performance? Mainconcept, Arcsoft, Cyberlink...? I mean, similar to CoreAVC with H.264

Microsoft>Cyberlink>Arcsoft>Mainconcept!

[Midzuki]

Microsoft>Cyberlink>Arcsoft>Mainconcept!

I agree, Mainconcept's VC-1 decoder is sluggish as hell :p

BUT maybe it's good enough for accurate frameserving via DirectShowSource() :D

[CruNcher]

yep normaly Mainconcept does excellent work but the VC-1 Decoder is far from that and it's funny seeing Cyberlink and Arcsoft beating it but i guess Mainconcept doesn't invest much resources into it's Developing ;)

[robpdotcom]

@BetaBoy
Any news on fixing the TrueHD mediatype issue with Haali splitter? If it has been fixed already, could to link to a new build so we don't have to wait until next CoreAVC release?The fix will be included in the next CoreAVC release.

I'd also like to request that Haali change the way it deals with subtitle streams - right now it loads default subs automatically, but I think everyone would be happier if it only loaded forced subs.

Also, is there a way to allow the video renderer to do the deinterlacing? I only see the option to set:

None (weave)
Single Field
Bob
Hardware

There is no option to output interlaced frames.

[Thunderbolt8]

I think everyone would be happier if it only loaded forced subs.not me ;)