Quote:
|
Originally Posted by Egh
Exactly. Easiest way to check is filters submenu, of course. So revise the abovementioned bugs and see if those were caused when Haali renderer was on  |
I checked again now, Haali renderer is present with the strange behavior (with or without ffdshow in the chain, WMV9 file).
edit: It is worth noting, that there was only a small rise in CPU usage with 640x480 XVID and DivX videos when doing fullscreen resize (decoded by ffdshow). But then with a 640x480 H.264 video (decoded with CoreAVC, ffdshow not in the chain) the CPU was at 100% again.
Quote:
|
Not that fast. YUY2 is practically same as YV12 Converting to RGB is another matter, of course. In YV12 and YUY2 luma is same, only chroma planes differ, and since it's only a factor of two (YUY2 has twice as much "color pixels" compared with YV12, in notation: 4:2:2 and 4:2:0 respectively), conversion YV12->YUY2 is pretty straightforward. Some additional CPU is spent to rearrange luma/color info though, but that should be rather fast (planar/interleaved conversion).
|
Yes, there wasn't much difference in CPU usage with YV12 and YUY2 ffdshow (or HQ RGB32 for that matter). Just ffdshow handling raw video though takes 20% eventhough it is doing nothing (YV12 output)! Comparison made with VMR9.
No ffdshow, but just WMV9 decoder and Haali (no resize) gives me ~same 20% higher CPU usage, obviously WMV decoder doing the colorspace conversion (with bad chroma upsampling even! tsk, tsk) so that Haali renderer can accept it.