CoreCodec/H.264 Codec "CoreAVC"

[cyberbeing]

cyberbeing... we cannot duplicate the memory leak here... can you provide versions numbers so we can dig deeper?

The problem only seems to happen with when CoreAVC 3.0 is used with madVR 0.74. What seems to be happening is instead of old CoreAVC instances being killed or reused, a new CoreAVC instance is created for each new video opened while the old instance(s) just hang around idle, holding onto memory. That would explain why memory usage increases as it does.

MPC-HC r3677
madVR 0.74
Haali Splitter 1.11.96.14 (until MP4 bug is fixed)
WinXP SP3 x86


madshi would need to chime in, since for all I know this could be half a madVR bug. I rolled back to madVR 0.73 and the bug disappeared. The odd part is it only happens with CoreAVC and madVR 0.74. FFDShow or other decoders with madVR 0.74 are fine.

[Kurtnoise]

We have taken down 2.x purchasing.... about to push 3.0 live for everyone.
After selecting CoreAVC 3.0 and clicking in "order now", CoreAAC is selected instead...

[nevcairiel]

madshi would need to chime in, since for all I know this could be half a madVR bug. I rolled back to madVR 0.73 and the bug disappeared. The odd part is it only happens with CoreAVC and madVR 0.74. FFDShow or other decoders with madVR 0.74 are fine.

This is actually a madVR bug. It keeps a reference to the decoder around, and therefor its never properly destructed when the directshow graph is re-built.
madshi knows, and confirmed that its fixed for the next version (whenever that'll be)

To avoid huge memory leaks like this in CoreAVC, i would however recommend to free the memory buffers when the input pin is disconnected, and not wait until the filter is destructed. (Which is why it doesn't show up on other filters, they do exactly that)

[BetaBoy]

After selecting CoreAVC 3.0 and clicking in "order now", CoreAAC is selected instead...

Fixed... thx for the report. We are also about to 4x the VM resources since the load is high atm.

[cyberbeing]

BetaBoy, are 10bit optimizations for older AMD processors like my X2 4800+ (939) already in CoreAVC 3.0? Doing some benchmarks with VMR9, CoreAVC seems to struggle considerably more than FFDShow with sudden sudden bitrate fluctuations where my CPU is struggling to playback in real-time. Peak CPU is higher and Min FPS dips lower compared to FFDShow in such situations. Average FPS is usually marginally better with CoreAVC though, but that doesn't help much if Min FPS drops below real-time.

CoreAVC 3.0 compared to FFDShow r3978 (3-threads)
AMD X2 4800+ @ 2.64Ghz | WinXP SP3 x86
Various 1080p/720p 10bit H.264 samples

-5% to +10% Avg FPS (CoreAVC is better)
-2% to +1% Avg CPU (CoreAVC is better)

-15% to +5% Min FPS (FFDshow is better)
+2% to +10% Peak CPU (FFDshow is better)


Using 10bit (P010) or 16bit (P016) output to madVR is even worse, seemingly adding an additional 5-10% overhead to Avg and Peak CPU and worse FPS all-around.

Hopefully you can sort out these higher CPU spikes from sudden bitrate fluctuations in a future 3.x version. It's the difference between smooth playback (ffdshow) and dropped frames (coreavc) on some 10bit 1080p samples, especially once subtitles enter the picture.

[nevcairiel]

I would've thought P010 output uses less CPU (afterall, you don't need to apply dithering) - unless madVR itself uses more CPU with 10-bit input.

You should compare using a codec benchmark like in GraphStudio, taking the renderer out of the equation. If someone does, i would appreciate also including LAV Video in that comparison (both in 8-bit dithered and 10-bit native mode). ;)
I would do it, but i'm not sure i'll be buying 3.0, i have no need for it.

[ranpha]

You should compare using a codec benchmark like in GraphStudio, taking the renderer out of the equation.

I would have done so if GraphStudio doesn't crash when I tried to do benchmarking 10-bit clips with LAV Video. timecodec also cannot be used because of the same problem.

As a last resort, I tried using DXVA Checker to do the benchmarking, and there are some 'interesting results'. I don't really trust DXVA Checker as a benchmarking tools though. DXVA Checker and Graphstudio gives different results for the same clip when benchmarking with CoreAVC 3.

[CruNcher]

DiAVC kills both though the features of DiAVC are still limited so overhead might be lower still but it looks very good designed (and optimized for Intel) overall :)

http://img560.imageshack.us/img560/2003/comparex264performancei.png

[nevcairiel]

DiAVC kills both

How can it, it doesn't even play 10-bit files yet. :p

I would have done so if GraphStudio doesn't crash when I tried to do benchmarking 10-bit clips with LAV Video. timecodec also cannot be used because of the same problem.

With 0.34? I've run some extensive tests during the development of 0.34, and i didn't see any crashes. Any particular clip?
Guess thats off-topic for this thread though. :p

[devil-strike]

I read here that the new coreavc is working again with dvbviewer? but here is not working at all, dvbviewer sees the codec in the cofig page, but it wont work and falls back to microsoft dtv codec, but if i disable ms codec it also wont work with coreavc2.6.1, if i install old 2.5.1 or 2.5.5 it working again.

btw, using win7 64bit.

[CruNcher]

How can it, it doesn't even play 10-bit files yet. :p



With 0.34? I've run some extensive tests during the development of 0.34, and i didn't see any crashes. Any particular clip?
Guess thats off-topic for this thread though. :p


That's true but he seems to be optimizing it to the last drop schweinsz remembers me of Picard when everything started with CoreAVC, he is really fast for a 1 man machine (though CoreAVC is hardly that 1 man machine anymore) ;)
Also as you see i didn't compared with CoreAVC 3.0 yet and if you compare features vs overhead surely he would lose then currently ;)

also


- ADD: DXVA fallback to software
- ADD: New assembly engine
- ADD: New assembly IDCT
- ADD: New assembly motion compensation
- ADD: New assembly inter-prediction
- ADD: New assembly weighted prediction
- ADD: Improved assembly 8 bit performance


good feeling :)

And the 3.0 update is so evil huge (including all the DXVA2 improvements and additions) i hope alot of good beta tester where involved here :)

[ranpha]

With 0.34? I've run some extensive tests during the development of 0.34, and i didn't see any crashes. Any particular clip?
Guess thats off-topic for this thread though. :p

It happened with all 10-bit clips I have, whether the ones I made myself or the ones 'made by others'.

[nevcairiel]

It happened with all 10-bit clips I have, whether the ones I made myself or the ones 'made by others'.

I think i found the cause, any follow up should be moved over to the appropriate thread, though.

http://forum.doom9.org/showthread.php?p=1524388#post1524388

[Fadeout]

Surely there's something wrong. I have at least twice the CPU usage with CoreAVC DXVA compared to native MPC-HC DXVA. Also some very high peaks.

CPU is being used somehow even if the video is in DXVA. I have almost the same CPU usage with DXVA and software (DXVA is enabled as it shows both the red icon and [DXVA] on MPC).

[Barlow]

I just noticed the same thing. This is with 3.0 btw.

[CruNcher]

I hope they don't enabled the 1080p 60 fps fallback to Software for every DXVA scenario (config), though that you see the RED icon would be strange :(

[Fadeout]

This CPU usage on DXVA seems to happen already in 2.6.1.

EDIT: Yep, 2.5.0 is fine. The problem shows up in 2.6.0 and continues in all following versions.

EDIT2: More things. I'm testing with this file: Planet_Earth_From Pole_to_Pole_1080p_sample_16ref.mkv

And DXVA can't produce smooth playback. Very stuttery. 2.5 worked fine, as well MPC-HC internal DXVA.

[CruNcher]

What OS and Card (DSP) ?

[Fadeout]

I'm on W7 64b and ati 4850 if you're asking me.

Tried to use a x32 version of MPC-HC but it seems to deliver the same problems. Playback isn't smooth in DXVA. Software mode instead performs similar to 2.5, but it also has the tendency to go crazier if you repeat tests. 2.5 was usually more constant.

Summarizing: it's a problem that shows up in 2.6. High CPU usage in DXVA, and very stuttery playback. Especially evident with this clip:
Planet_Earth_From Pole_to_Pole_1080p_sample_16ref.mkv

[Fadeout]

Also, testing the various version and codecs at the moment I get the best performance with MadVR internal codecs even compared to CoreAVC or DiAVC.

Very low CPU usage with MadVR and smooth playback with that sample.

[BetaBoy]

Thank you for the reports everyone.

[sawg]

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

http://i.imgur.com/fuckK.jpg
http://i.imgur.com/jrtX4.jpg
Open CUDA and 1080p video, EVR Buffers >17 will error.

[dansus]

I have this bug on WinXP SP3 x86 with the new Haali Splitter 1.11.233.7. All MP4 have no video with an empty video output pin.

Same here, XP SP3 x86.

[Stephen R. Savage]

CPU: Intel Core 2 Duo T7250 "Merom" (2.00 GHz)
OS: Microsoft Windows Server 2008 R2 Standard

GraphStudio 0.3.2.0 was used for all measurements.
Reported values are the average of three independent trials.
Standard deviation was below 1% of mean for all tested software.
Output accuracy was evaluated visually for each decoder.

All software used was 32-bit. 10-bit samples were decoded to
8-bit formats in all cases to better represent typical usage
scenarios.

Software Tested:
DiAVC 1.2.6
CoreAVC 3.0
ffdshow (CLSID) r3978
LAV Filters 0.34

1080p, 10-bit, 8750 kbps
========================
CoreAVC: 30.4 fps
ffdshow: 35.7 fps
LAV Filters: 38.2 fps

720p, 10-bit, 1850 kbps
========================
CoreAVC: 60.4 fps
ffdshow: 67.3 fps
LAV Filters: 77.5 fps

720p, 8-bit, 2620 kbps
======================
DiAVC: 157.6 fps
CoreAVC: 133.6 fps
ffdshow: 125.6 fps
LAV Filters: 129.4 fps

480p, 8-bit, 1830 kbps
======================
DiAVC: 390.4 fps
CoreAVC: 340.6 fps
ffdshow: 309.9 fps
LAV Filters: 335.0 fps


It's sad to see CoreCodec fall this low. What used to be cutting-edge software continues its trend into obsolescence. I mean, even I would be embarrassed at releasing a supposedly "high-performance" software that's 30% slower than a free offering. Claims for improved 8-bit performance are also unable to be verified, as CoreAVC 3.0 scores no higher than 2.5.5 (not shown in data, see previous).

What's more interesting is how far libavcodec development has come. Nevcairiel's optimized LAV Filters now lead CoreAVC in 10-bit decoding by as much as CoreAVC 1.0 lead the earliest versions of libavcodec. Another victory for open source software. No wonder CoreCodec has to try gouging its ever-dwindling customer base for repeated "upgrade" fees.

[Kurtnoise]

@Stephen : could you post/link the samples you use for your benchmark please ?

[SSH4]

hmm, cuda and dxva not work on CoreAVC 3.0?

oops no cuda/dxva on 10bit ?

[BetaBoy]

Stephan.... Please take the drama else where.

[Mixer73]

No wonder CoreCodec has to try gouging its ever-dwindling customer base for repeated "upgrade" fees.

You know what... I complained when Core announced that 3.0 would be a new license and not an upgrade on 2.0... Now they have offered a $3 discount for 2.0 owners, against a license that is what $12.95?

Can we really complain about such low priced software? I dunno that we can, really.

[Tanuki]

@BetaBoy
Can you elaborate on the Zoom Player problem (since I seem to have one myself) ?

[SSH4]

can anyone tell me is CUDA and DXVA decoding work on 10bit streams or CoreAVC can decode 10bit only in CPU mode?

[Barlow]

can anyone tell me is CUDA and DXVA decoding work on 10bit streams or CoreAVC can decode 10bit only in CPU mode?

I'm not sure about CUDA, but DXVA won't decode 10bit on any card yet.

[kerimcem]

my graphics card Ati HD 2600 PRO (UVD)+ 7300 gt (old card)

CoreAVC 2.5.5 DXVA works perfectly

CoreAVC 2.6.0 DXVA not working
CoreAVC 2.6.1 DXVA not working
CoreAVC 3.0.0 DXVA not working

[nevcairiel]

can anyone tell me is CUDA and DXVA decoding work on 10bit streams or CoreAVC can decode 10bit only in CPU mode?

Both CUDA and DXVA use the hardware decoder on your GPU, and that one is limited to 8-bit.

[CiNcH]

Having criticized CoreCodec for the way they do business a lot in the past (and I am not alone, I have never seen anyone getting more heat than they do), I can also give credit where it is due.

Version 2.6.1 is finally usable within the DVBViewer (not perfect though, and I am not talking about DXVA) and the eventualities in a streaming environment where decoders have to deal with fast channel hopping, random access, on-the-fly format changes, interlaced content a.s.o.

All my reports have successfully been processed (except for DXVA of course). Finally proper vector-adaptive deinterlacing when using NV12 is possible. I consider this being a much more critical task than hardware decoding.

Maybe it is better that DXVA is not supported within the DVBViewer as of yet. Who knows what would have happened if format changed on-the-fly or one would have switched between 720p and 1080i channels without the DVBViewer rebuilding the graph...

Looking back some years, it also took MPEG-2 decoder developers some time to embrace all the eventualities in a streaming environment. CyberLink has come a long way and this may be the reason why they still rock in this area (even with DXVA). I am pretty sure that others will arrive there too one day.

[Stephen R. Savage]

@Stephen : could you post/link the samples you use for your benchmark please ?

Stephan.... Please take the drama else where.

@Kurtnoise: I will try to make them available later today.

@BetaBoy: This is not the first time I've shown clear evidence of failings in CoreAVC. Each time you have summarily dismissed them as "drama" and have consistently failed to improve your software in any meaningful manner. The fact that you refuse to acknowledge shortcomings reflects poorly on both your company and on you personally. In fact, I am not the only user to have noticed that CoreAVC no longer lives up to the standard it once set.

To those in this thread: CoreCodec thrives off of uninformed users. Please don't be such a person. Every usage case that CoreAVC might have had is now supplanted by free software.

CPU Decoding: LAV Filters
CUDA (NVIDIA): LAV CUVID Decoder
DXVA (Intel/AMD): MPC-HC, ffdshow, Windows 7, all sorts of things

Let's not forget all the things CoreCodec promised but failed to deliver:

GPU Encoding: lol
Decoding 1080p on Intel Pentium 4: lol
MKV DVD-style menus: lol
Full support for High Profile: wait, what was that about weighted prediction?
GPU Decoding: on NVIDIA only, AMD and Intel users are stuck with useless DXVA

Edit:
@Mixer73: $12.95 is infinitely more than $0, and hence you are being infinitely ripped off.

@hajj_3: I don't know, extrapolating from my tests, and estimating that a 1.73 GHz Core Solo is 40% as fast as my 2.00 GHz Core 2 Duo, 3200 kbps 720p still decodes at over 50 fps with LAV, more than enough for viewing in a basic renderer like EVR (esp. w/ D3D Fullscreen).

Also, in case anybody is wondering, the free software I am mentioning is LAV Filters/LAV CUVID. I am not shilling for DiAVC, and I personally don't recommend anybody buy it unless you want to use neuron2tools for some reason.

[hajj_3]

well atleast they are getting pretty quick at fixing bugs, they have fixed the majority of bugs in 2.6.0 in a matter of days which is pretty impressive. Judging by reports it seems there are a ton of bugs in 3.0 so i'm sure it will be months until that is stable. Its better than nothing though, i can play 3200 bitrate 720p on a single core 1.73ghz core solo, haven't tried diavc as only the 64bit is free and the cpu is only 32bit.

[squid_80]

Come now Stephen, without the sample clips as evidence to back up your findings your comparison is useless and your statements have absolutely no merit. For all we know you specifically chose clips to make CoreAVC look bad or even worse, outright fabricated the results. At the very least, allow someone else to post their own comparisons (using an i5-661, null renderer, same filter versions/testing setup).

Let's try a monster clip that most people are familiar with:
Life in the Garden (http://www.youtube.com/watch?v=N0m1XmvBey8), 4096x2304, null renderer
==============================
CoreAVC: 109.1267 fps
FFDShow: 93.1857 fps
LAV Filters: 83.2946 fps

I noticed you didn't test any interlaced material. Should we believe this was on oversight on your behalf?
premiere-paff.ts (http://www.mediafire.com/?onyymjatwjq), 1080i, null renderer
==============================
CoreAVC: 95.5605 fps
LAV Filters: 74.6953 fps
FFDShow: 67.0859 fps

Now you can consider yourself informed. Although I wonder, since you already had such a poor opinion of CoreCodec/CoreAVC, what prompted you to purchase the 3.0 upgrade?

[CruNcher]

Come now Stephen, without the sample clips as evidence to back up your findings your comparison is useless and your statements have absolutely no merit. For all we know you specifically chose clips to make CoreAVC look bad or even worse, outright fabricated the results. At the very least, allow someone else to post their own comparisons (using an i5-661, null renderer, same filter versions/testing setup).

Let's try a monster clip that most people are familiar with:
Life in the Garden (http://www.youtube.com/watch?v=N0m1XmvBey8), 4096x2304, null renderer
==============================
CoreAVC: 109.1267 fps
FFDShow: 93.1857 fps
LAV Filters: 83.2946 fps

I noticed you didn't test any interlaced material. Should we believe this was on oversight on your behalf?
premiere-paff.ts (http://www.mediafire.com/?onyymjatwjq), 1080i, null renderer
==============================
CoreAVC: 95.5605 fps
LAV Filters: 74.6953 fps
FFDShow: 67.0859 fps

Now you can consider yourself informed. Although I wonder, since you already had such a poor opinion of CoreCodec/CoreAVC, what prompted you to purchase the 3.0 upgrade?

Something was wrong sorry (new results later) :(

[wanezhiling]

CoreAVC 3.0.......

Believe it or not , CPU Usage is still very high when dxva on.

[cyberbeing]

AMD X2 4800+ (939) @ 2.64Ghz
WinXP SP3 x86
Haali Media Splitter 1.11.96.14

Here are a few GraphStudio 10bit h264 tests with P010 vs YV12 (dithered) on CoreAVC 3.0.0 with NULL output:

Update: Added LAV Video 0.35 results, now that nevcairiel posted a fixed build.

33.9615 FPS NULL CoreAVC 3.0.0 YV12
33.0268 FPS NULL CoreAVC 3.0.0 P010 (2.8% slower)
34.0204 FPS NULL FFDSHOW r3978 YV12
37.9940 FPS NULL LAV Video 0.35 YV12
37.4290 FPS NULL LAV Video 0.35 P010

37.7804 FPS NULL CoreAVC 3.0.0 YV12
36.5628 FPS NULL CoreAVC 3.0.0 P010 (3.3% slower)
38.5740 FPS NULL FFDSHOW r3978 YV12
42.5697 FPS NULL LAV Video 0.35 YV12
41.7282 FPS NULL LAV Video 0.35 P010

43.3645 FPS NULL CoreAVC 3.0.0 YV12
41.6692 FPS NULL CoreAVC 3.0.0 P010 (4% slower)
42.6866 FPS NULL FFDSHOW r3978 YV12
47.8580 FPS NULL LAV Video 0.35 YV12
47.0682 FPS NULL LAV Video 0.35 P010

122.3882 FPS NULL CoreAVC 3.0.0 YV12
116.3716 FPS NULL CoreAVC 3.0.0 P010 (5.2% slower)
116.4711 FPS NULL FFDSHOW r3978 YV12
131.6452 FPS NULL LAV Video 0.35 YV12
128.0310 FPS NULL LAV Video 0.35 P010

Note: I didn't list them, but CoreAVC P016 results near-identical to P010 results.
__________

Here are the DXVAChecker 10bit h264 benchmarks I did with VMR9 yesterday (a bit messy):

Decoder: CoreAVC Video Decoder | Average FPS: 34.171 | Min/Max FPS: Min: 23 Max: 43 | Playback CPU Usage (%): Avg: 71 Max: 100
Decoder: ffdshow Video Decoder | Average FPS: 33.946 | Min/Max FPS: Min: 25 Max: 43 | Playback CPU Usage (%): Avg: 71 Max: 92
Decoder: LAV Video Decoder |Average FPS: 37.764 | Min/Max FPS: Min: 26 Max: 50 | Playback CPU Usage (%): Avg: 63 Max: 84

Decoder: CoreAVC Video Decoder | Average FPS: 38.281 | Min/Max FPS: Min: 30 Max: 55 | Playback CPU Usage (%): Avg: 63 Max: 80
Decoder: ffdshow Video Decoder | Average FPS: 38.685 | Min/Max FPS: Min: 32 Max: 49 | Playback CPU Usage (%): Avg: 62 Max: 75
Decoder: LAV Video Decoder | Average FPS: 42.336 | Min/Max FPS: Min: 33 Max: 54 | Playback CPU Usage (%): Avg: 55 Max: 68

Decoder: CoreAVC Video Decoder | Average FPS: 43.683 | Min/Max FPS: Min: 35 Max: 50 | Playback CPU Usage (%): Avg: 54 Max: 66
Decoder: ffdshow Video Decoder | Average FPS: 42.413 | Min/Max FPS: Min: 38 Max: 46 | Playback CPU Usage (%): Avg: 55 Max: 64
Decoder: LAV Video Decoder | Average FPS: 47.837 | Min/Max FPS: Min: 42 Max: 52 | Playback CPU Usage (%): Avg: 48 Max: 55

Decoder: CoreAVC Video Decoder | Average FPS: 84.311 | Min/Max FPS: Min: 70 Max: 107
Decoder: ffdshow Video Decoder | Average FPS: 87.385 | Min/Max FPS: Min: 74 Max: 111

Decoder: CoreAVC Video Decoder | Average FPS: 118.340 | Min/Max FPS: Min: 85 Max: 139
Decoder: ffdshow Video Decoder | Average FPS: 113.697 | Min/Max FPS: Min: 87 Max: 128

Decoder: CoreAVC Video Decoder | Average FPS: 45.284 | Min/Max FPS: Min: 37 Max: 62
Decoder: ffdshow Video Decoder | Average FPS: 41.258 | Min/Max FPS: Min: 36 Max: 54

Playback CPU usage = non-benchmark normal speed VMR9 playback in DXVAChecker

CoreAVC 3.0.0 was released late last night, so I went to sleep without doing Playback CPU usage for all of them, but you should be able to see the trend. CoreAVC 3.0.0 struggles with sudden high-complexity/high-bitrate fluxuations in the stream, making it not so good for older CPUs like my AMD X2 which risk falling below real-time. The test I listed on top is very representative of the problem I'm seeing. CoreAVC hits 100% CPU usage with a hard to decode section during normal playback and falls below real-time when benched, while FFDSHow doesn't go above 92% CPU usage and stays slightly above real-time when benched.

Update: LAV Video 0.35 results are surprisingly faster than both CoreAVC 3.0.0 and FFDShow.
Update: It looks like LAV Video 0.35 also has a P010 overhead, but it's half that of CoreAVC 3.0.0, so it seems there is room for improvement.

[TheFluff]

I've been seeing several reports of CoreAVC 3.0 exhibiting decoding errors with some 10-bit clips, as well.

Sample file (http://x264.fushizen.eu/encodan/10bit/railgun_op1_10bit.mp4)
The errors should be obvious, but here's a screenshot (http://vfrmaniac.fushizen.eu/OtherStuff/CoreAVC3.0_damages_railgun_op1_10bit.mp4.png) as well. The file works correctly when decoded with libavcodec, but I haven't tested any other decoders.

[cyberbeing]

Tested a few things and found another sample with similar corruption to what TheFluff posted:

Sample (http://www.mediafire.com/?bkdqlxuwmrxjfbx) | Screenshot (http://img696.imageshack.us/img696/7283/coreavc30corruption.png)

Edit: And another... I guess I should actually be watching things instead of benching, since the corruption problem must be semi-widespread

Sample2 (http://www.mediafire.com/?9830yforq4yc647) | Screenshot2 (http://img14.imageshack.us/img14/6517/coreavc30corruption2.png)

[mandarinka]

I noticed similar jumps in 10bit decoding cpu load with ffdshow /libavcodec in general/ when testing on an Athlon XP.
Maybe the decoders only have codepaths for cpus with better SSE performance. (Athlon XP would need MMX asembly since it lacks SSE compeltely, maybe some functions in ffh264 aren't SIMDed in MMX, in libavcodec; as for coreAVC, maybe it doesn't take the slowness of SSE2 on K8 into account?)

BTW, anyone tested on non-sse2 cpu?

[sneaker_ger]

Athlon XP would need MMX asembly since it lacks SSE compeltely

That is not true, Athlon XP has SSE(1).

[nevcairiel]

Did it occur to you that the Athlon XP is maybe just slow in general? :)

I can only speak for myself, but i will not waste time writing the code that i wrote in SSE2 already again in MMX, for some CPU thats around 10 years old. :D

[BetaBoy]

We are tracking a few annoying 10bit related bugs. Ones that stand out are the ones that affect Anime (of all things) and a few specific CPU's types.

[TheRyuu]

We are tracking a few annoying 10bit related bugs. Ones that stand out are the ones that affect Anime (of all things) and a few specific CPU's types.

Why does the content matter?

BTW, anyone tested on non-sse2 cpu?

No, just no.
Why should decade old hardware matter?

[eddman]

GPU Decoding: on NVIDIA only, AMD and Intel users are stuck with useless DXVA


You don't even know what you're talking about, and you expect everyone to take you seriously!

Coreavc is NOT a GPU decoder. It uses CUDA, only to access the built-in video decoder (Purevideo). It works almost like DXVA.

[BetaBoy]

Why does the content matter?
It doesn't It was meant to point out the Anime crowd being early adopters. RE: Hi10

[TheRyuu]

It doesn't It was meant to point out the Anime crowd being early adopters. RE: Hi10

And why exactly should that matter?

It's typical usage, you're watching a 10bit encoded video. Surely that's something that quality control should catch... It's not some obscure bug that takes some really weird set of steps to reproduce. From what I'm hearing basically every 10bit video is broken so it shouldn't really be all that hard to reproduce.