View Full Version : CoreCodec/H.264 Codec "CoreAVC"
BetaBoy
8th September 2011, 18:01
We have now added DXVA multi-monitor support.... now to QA it for CoreAVC 3.0.1 (and 2.6.2)
cyberbeing
8th September 2011, 18:15
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
8th September 2011, 18:55
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
8th September 2011, 19:45
Till Haali adds it, we have made it available for download:
https://customers.corecodec.com/downloads.php
junh1024
8th September 2011, 23:24
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
9th September 2011, 00:01
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
9th September 2011, 01:11
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
9th September 2011, 01:27
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
9th September 2011, 03:39
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
9th September 2011, 15:49
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
9th September 2011, 16:43
Might help if you said which renderer was being used.
Barlow
9th September 2011, 17:08
That sample looks fine here with EVR-CP (nv12) and MadVR.
dead_screem
9th September 2011, 17:10
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
9th September 2011, 17:10
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
9th September 2011, 18:01
have you guys tested out v2.6.2.0 yet? That and v3.0.1.0 are on their website now.
cyberbeing
9th September 2011, 18:38
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
9th September 2011, 18:47
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
9th September 2011, 18:58
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
9th September 2011, 19:07
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
9th September 2011, 19:42
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
9th September 2011, 19:43
We also confirmed the bug for the jagginess reports (native chroma upsampling)... and working on a fix now.
BetaBoy
9th September 2011, 19:48
cyberbeing... Next up is more high10 assembly work we have been working on in an upcoming release.
dead_screem
9th September 2011, 21:23
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
10th September 2011, 00:00
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
10th September 2011, 00:00
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
10th September 2011, 00:45
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
10th September 2011, 01:03
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
10th September 2011, 01:43
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
10th September 2011, 03:43
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
10th September 2011, 04:48
CoreAVC 3.0.1, seeking bug came back. Using WMP12 or MPC-HC.
squid_80
10th September 2011, 05:01
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
10th September 2011, 05:06
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
10th September 2011, 05:33
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
10th September 2011, 10:45
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
10th September 2011, 10:45
http://img35.imageshack.us/img35/5793/crysis2gb.png
Where can i download the "video decoder performance test" ?
nevcairiel
10th September 2011, 10:49
Where can i download the "video decoder performance test" ?
Its part of GraphStudio (http://blog.monogram.sk/janos/tools/monogram-graphstudio/)
CruNcher
10th September 2011, 12:05
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
10th September 2011, 12:22
Looks like bug in benchmark OR graphs produced different number of frames.
CruNcher
10th September 2011, 12:31
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
10th September 2011, 13:04
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
10th September 2011, 13:08
@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
10th September 2011, 13:54
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
10th September 2011, 15:07
ebuss07... Read:
https://customers.corecodec.com/knowledgebase/30/Why-is-my-video-RED-Upside-down-or-have-BlackorWhite-Blocks.html
rofl, busted!
somms
10th September 2011, 15:31
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
10th September 2011, 16:12
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
10th September 2011, 16:37
@ 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
10th September 2011, 16:52
@ 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
10th September 2011, 17:52
@ 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
10th September 2011, 17:54
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
10th September 2011, 18:39
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.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.