CoreCodec/H.264 Codec "CoreAVC"

[Isochroma]

Yes, the XviD directshow filter has a very good output colorspace selector; this would be great to have in CoreAVC!

[Scoty]

please People help me. i can not use the CoreAVC in MPC and WPM 10. which settings in MPC and WPM 10 i need ?

[calinb]

Originally Posted by breez

Well actually the conversion is done just right, but there is a difference with video and PC levels. In video levels reference black is at 16 and reference white at 235 (0 and 255 in PC levels).

It is problematic for mixed use PCs. One either calibrates display for video or PC levels, but not for both. One can also expand the 16-235 range to 0-255 to use with a display calibrated to PC levels. This of course isn't a lossless operation (banding may occur when done at low precision).

The other problem with expanding levels from the video to pc range is levels outside the "permitted" video level range sometimes occur--the so called "blacker than black levels." They will be clipped in the expansion. When using the video range, it's still possible to properly adjust your display to render them (supported by some monitor/TV calibration DVDs), whereas they are simply lost when expanded to the PC range.

[dk75]

Originally Posted by Scoty

please People help me. i can not use the CoreAVC in MPC and WPM 10. which settings in MPC and WPM 10 i need ?

regsvr32 /s CoreAVCDecoder.ax

And you shouldn't uninstall ffdshow.
You should change decoding option in codec settings: "H.264" to "disabled" and "RAW" to "supported all".
With this, you could do color space conversion with ffdshow for CoreAVC decoded stream.

[Zero1]

The speed is remarkable, excellent job. This will help bring H.264 to many more people now

Such a shame it won't become a part of FFDShow(/libavcodec). Let's just hope they are able to speed up also. We already have the best ASP decoder

[sillKotscha]

Originally Posted by SeeMoreDigital

I wonder, would it be possible to place some "user settings" that can be accessed and adjusted via the filters "Properties" widow: -

Cheers

at least some kind of infos... would it be possible to show the profile that was used for the encode?? like ffdshow does via osd (bframes, gmc, etc.)

that would be very nice

btw, enjoy the nice sunday

[bond]

ok before this non-avc related discussion evolves too much, note that this thread is about coreavc, the _AVC_ decoder

if you want to discuss different things, like mpeg-2, .ts, streaming or whatever start new threads where they belong plz

[lexor]

Originally Posted by bond

ok before this non-avc related discussion evolves too much, note that this thread is about coreavc, the _AVC_ decoder

if you want to discuss different things, like mpeg-2, .ts, streaming or whatever start new threads where they belong plz

it is? I thought it was about TCMPM which reached mature stage and just got coreAVC, I thought decoder discussion was just a bonus based on BetaBoy's first post.

[bond]

guys, betaboy started an own thread for tcpmp in the software player forum (where it belongs):
http://forum.doom9.org/showthread.php?t=103199

post there your non-coreavc issues

[PicardGK]

I'am checking rgb32/24 mmx transformation. It will cost speed for sure (like ffdshow). Alone the bytes written to memory is almost 3 times as many. Benchmark performance with Null output will suffer more because of lower memory latency which doesn't really hide the mmx transformation.

Why people use rgb32 for video playback? I heard some Nvidia card has crappy yuv colorspace transformation, but I'am not sure why.

Does all VMR9 driver support YUY2 input? I also have the brightness problem in this scenario, but it can be adjusted by the decoder (like ColorYUV(levels="TV->PC")), although I'am not sure how much quality loss there is because of the 8bit channel resolution.

[bond]

Originally Posted by PicardGK

Why people use rgb32 for video playback? I heard some Nvidia card has crappy yuv colorspace transformation, but I'am not sure why.

well i used to notice jerky playback in rare cases with my old nvidia tnt2 pro with yv12, that happened with gabest's realvideo dshow stuff iirc
especially i noticed jerkyness with yv12 anamorphic resize (with asp)
this would speak for that the old tnt2 has problems with yv12

than there is the thing that anamorphic resize works in mplayer, tough i am not sure it really uses yv12 (altough it says so)
tcpmp also works fine it seems (does it output yv12?)
so this might indicate that there are simply some issues with the dshow filters i used (ffdshow for asp) and yv12 works fine on the tnt2

than there is that mf once told me that these cards have problems with yv12 overlay but i wasnt able to find any info about this anywhere in the web, so i am not sure about this

also after i upgraded to win2000 i dont seem to get these issues that clearly anymore (eg yv12 anamorphic resize with coreavc seems to work fine)
the thing is the jerks are hardly spotable, so its hard to say whether there are problems or not, especially if you are testing with avc on a pentium3 866mhz pc you never know if lack of cpu kicks in

so all in all my tnt2 is an old card and i still cant say for sure if it has problems or not

Does all VMR9 driver support YUY2 input?

on my tnt2 vmr9 only wants to directly connect to coreavc if it outputs yuy2. when coreavc outputted yuy2 only it force a colorspace converter in between

I also have the brightness problem in this scenario, but it can be adjusted by the decoder (like ColorYUV(levels="TV->PC")), although I'am not sure how much quality loss there is because of the 8bit channel resolution.

if you add something that means quality loss make sure to add an option for the user to en- or disable it plz

[PicardGK]

Originally Posted by bond

tcpmp also works fine it seems (does it output yv12?)

YV12 is the deafult if the DirectDraw overlay supports it. But I will add some options in settings dialog to be able to override.

Originally Posted by bond

on my tnt2 vmr9 only wants to directly connect to coreavc if it outputs yuy2. when coreavc outputted yuy2 only it force a colorspace converter in between

I guess the second part was about YV12. My Radeon 9600 doesn't support YV12 either with VMR9. I guess because it's planar.

Originally Posted by bond

if you add something that means quality loss make sure to add an option for the user to en- or disable it plz

Of course. Btw the only problem with TV->PC yuv level transformation that scaling [16..235] to [0..255] means the result will have some gaps, but I guess it's not visible. But it may cost little performance, so everything is optional.

[videomixer9]

I think many ppl want to convert the ranges as you can clearly see any encoding glitch in VMR9 with YV12 video. I have lots of encodes that look fine in overlay but you'll see how crappy they really are in VMR9. Besides it's kinda awkward seeing a grey tone instead of black even though this is the correct way of displaying it. Where this doesn't matter should be HTPCs or if you use VMR9 on your TV screen otherwise, of course.

Imo the problem clearly is that there's no hardware accelerated colorspace conversion available as part of VMR9 and imo MS should fix this.

Besides the bonus of being able to have lots of accelerated videos running at the same, I don't see much bonus in using VMR9 (excl. all uses for videos in games). If you got an graphics adapter with bad hardware resizer you'll prolly lack the power to correct this via software anyways, seeing that high quality lanczos resizing or even hq bicubic resizing takes lots of power in realtime.

Whatever, VMR9 sounds cool and is new, thus many ppl will keep using it and some might actually gain quality with it, but sure not those with old pcs and graphics cards that have broken support for things like YV12, and those sure aren't the new top modells of nvidia and ati ...

[3ngel]

Why people use rgb32 for video playback?

Because doing YUY2->RGB32 conversion in software avoid possibile bad conversion, and any visualization problem you can imagine cause of the grafic card hardware routine.
Doing in software a good conversion (with a good routine) you are sure to send to the GPU the raw video stream (already converted in the color space used by the GPU that is RGB) and so the GPU has only to send to video without any other operation. And so there are no problems at all (and a maximum quality visualization).

[PicardGK]

Originally Posted by cjei

I hope CoreAVC can have these color conversion options :
ColorMatrix("Rec.709->Rec.601")
ColorMatrix("Rec.601->Rec.709")
ColorYUV(levels="TV->PC")

Because vmr7&9 seems to need PC scale YUV
and overlay needs Rec.709 for HD.

I checked and AVC does have a way to signal input yuv levels and whether it's BT601 or BT709. So by default the decoder will use this info (example all Apple 1080p trailers us BT709, but 720p and lower are BT601). Not sure if there is a need to be able to override it. On the other hand the output properties should be optional, because I don't know any way to detect them.

At the moment BT601 vs BT709 transformation will only work with RGB output. (btw maybe it's just me, I see almost no different on my LCD monitor between this modes...)

Originally Posted by videomixer9

I think many ppl want to convert the ranges as you can clearly see any encoding glitch in VMR9 with YV12 video.

Sure. It will be supported (optional). This an output property.
Btw I don't understand why would VMR9 look good on TV? This would mean the gray on monitor looks black on TV, which means an old overlay black would be more black or something.

Originally Posted by videomixer9

Imo the problem clearly is that there's no hardware accelerated colorspace conversion available as part of VMR9 and imo MS should fix this.

You mean whem CoreAVC outputs YUY2 to VMR9, it's transformed by the video driver software and not pixelshader or something? This would mean there is not much perfomance loss if CoreAVC would do the transformtion (with correct yuv level and colormatrix usage).

[Inventive Software]

Guys, I'm impressed! For the first time I can play 720x576@25 AVC content on my Celeron 800. You should have an award! This stuff is revolutionary, no joke.

As yet, I haven't tried ASP content with all the bells and whistles, but that time will come soon!

[CruNcher]

This stuff is revolutionary, no joke.

It isn't really, it shows that good clean low level coding can be very powerfull but sadly alot of developers today go more in the direction of .Net and stuff loseing all this knowledge

[breez]

Originally Posted by PicardGK

Btw I don't understand why would VMR9 look good on TV? This would mean the gray on monitor looks black on TV, which means an old overlay black would be more black or something.

Old overlay with a TV would look bad as supposedly gray colors would be black (and white when dealing with light gray).

[BetaBoy]

mmx color transformation code has been added to SVN for TCPMP and also to the CoreAVC filter.. it's up to Toff to listen to the proposals from you 'SMD' to add the about dialog controls so the user has more options.

[videomixer9]

Originally Posted by PicardGK

You mean whem CoreAVC outputs YUY2 to VMR9, it's transformed by the video driver software and not pixelshader or something? This would mean there is not much perfomance loss if CoreAVC would do the transformtion (with correct yuv level and colormatrix usage).

Actually I thought that MS could implement VMR9 to accept almost anything and give video drivers the chance to pass over colorspace conversion to the graphics hardware, all I know is that MS currently delivers this odd colorspace conversion filter that's not really brilliant. Or can VMR9 do conversions via PixelShaders or sth. similar already without the player, or are there any shaderscripts you can e.g. use with MPC to do conversions e.g. to RGB?

Oh well seeing how skillful CoreAVC is done I guess you'd do something nice for this thing too, maybe better than fake hardware acceleration we all know

As to TV it seems funky as classic overlay and VMR9 look almost perfectly the same here. Dunno what nvidias drivers or hardware do there ...