CoreCodec/H.264 Codec "CoreAVC"

[pankov]

More likely is he's tired of answering the same questions/criticism 5000 times in the same thread.

He of course loves if you find a technical problem.....however none have come up in this thread in quite some time.

Here is one problem that isn't address till now. I'm still hoping it'll be soon since I've opened a ticket in my Core account ... though it's more than a couple of weeks now and I haven't received any feedback from them :(

[ChronoCross]

Here is one problem that isn't address till now. I'm still hoping it'll be soon since I've opened a ticket in my Core account ... though it's more than a couple of weeks now and I haven't received any feedback from them :(


Care to share what the problem is?

[pankov]

oooh,
I forgot the link
http://forum.doom9.org/showthread.php?p=1329406#post1329406

[pankov]

today I tried using the AVS HD 709 test patterns (http://www.avsforum.com/avs-vb/showthread.php?t=948496) to quickly re-calibrate my projector and I found that CoreAVC doesn't recognize the correct Input/Output levels. Both FFDShow and MPC Video Decoder show the flashing black (17-25) and white (230-234) lines in "Brightness & Contrast.mp4". In CoreAVC I have to manually set the input to "PC" or output "to TV". When they are set to "Auto"/"Auto" none of the lines are flashing. If it was for all videos it wouldn't be such a problem but sadly this happens only to a few, one of which is this calibration pattern.
Am I doing something wrong or is there a bug in CoraAVC's level detection algorithm?

[BetaBoy]

If we've learned anything about BetaBoy, it's that he has learned to ignore any piece of criticism that doesn't paint his software in the best possible way, and call it off topic, trolling, etc. :devil:
I've been staying away from obvious troll postings and instead concentrating on what matters for our customers.

We are working on CoreAVC 2.1 at the moment with many enhanced features I've discussed here and some I have not.

[BetaBoy]

Here is one problem that isn't address till now. I'm still hoping it'll be soon since I've opened a ticket in my Core account ... though it's more than a couple of weeks now and I haven't received any feedback from them :(

PM me with the ticket # and I'll get the team on it here this morning to see what the hold up is.

[BetaBoy]

today I tried using the AVS HD 709 test patterns (http://www.avsforum.com/avs-vb/showthread.php?t=948496) to quickly re-calibrate my projector and I found that CoreAVC doesn't recognize the correct Input/Output levels. Both FFDShow and MPC Video Decoder show the flashing black (17-25) and white (230-234) lines in "Brightness & Contrast.mp4". In CoreAVC I have to manually set the input to "PC" or output "to TV". When they are set to "Auto"/"Auto" none of the lines are flashing. If it was for all videos it wouldn't be such a problem but sadly this happens only to a few, one of which is this calibration pattern.
Am I doing something wrong or is there a bug in CoraAVC's level detection algorithm?
We are looking into it...

[squid_80]

today I tried using the AVS HD 709 test patterns (http://www.avsforum.com/avs-vb/showthread.php?t=948496) to quickly re-calibrate my projector and I found that CoreAVC doesn't recognize the correct Input/Output levels. Both FFDShow and MPC Video Decoder show the flashing black (17-25) and white (230-234) lines in "Brightness & Contrast.mp4". In CoreAVC I have to manually set the input to "PC" or output "to TV". When they are set to "Auto"/"Auto" none of the lines are flashing. If it was for all videos it wouldn't be such a problem but sadly this happens only to a few, one of which is this calibration pattern.
Am I doing something wrong or is there a bug in CoraAVC's level detection algorithm?

The fullrange flag isn't set, so setting Input levels to Auto will use TV. If the Output levels is set to Auto, it will use PC levels for VMR9 or else TV levels. Sounds like you're using VMR9 and your video driver assumes TV levels are being used.

[hajj_3]

What features can you confirm for us for v2.1?

[pankov]

PM me with the ticket # and I'll get the team on it here this morning to see what the hold up is.
I've already done this on couple of days ago (19th February 2010, 21:49)

[pankov]

The fullrange flag isn't set, so setting Input levels to Auto will use TV. If the Output levels is set to Auto, it will use PC levels for VMR9 or else TV levels. Sounds like you're using VMR9 and your video driver assumes TV levels are being used.
Well, I tried other renderers and it seems you are correct. The strange thing is that FFDShow and MPC's video decoder recognize the correct levels with all renders and don't clip blacks/whites even with VMR9 - they show the same picture with all renderers.

[Cyber-Mav]

What features can you confirm for us for v2.1?

id like to know how much it will cost to upgrade from 2.0 to 2.1 :confused:

[hajj_3]

i think updates are free except for major numbers eg v1.0, 2.0 etc.

[BetaBoy]

correct...

[BetaBoy]

What features can you confirm for us for v2.1?

- Full DXVA Support
- Low latency Option
- Various bug fixes and speed enhancements

We are working on the report of a subtitles issue atm as well.

[ajp_anton]

- Full DXVA SupportMeaning ATI support?
- Low latency OptionAt what cost?

[Disabled]

- Full DXVA Support
Does it mean you can use DXVA to reencode Videos? Ie DXVA decodes the video and pipes it to another program? Like this guy is suggesting:
http://forum.doom9.org/showthread.php?p=1375061#post1375061

[BetaBoy]

Well to define Full = Anything but old cards that don't support bitstream mode.

[Keiyakusha]

Well to define Full = Anything but old cards that don't support bitstream mode.

So If I understand right, the answer is "yes", it will be possible to do whatever you want with decoded frames, the whole thing won't be limited to direct decoder-renderer connection like with all currently available solutions?

[BetaBoy]

To early to comment more on DXVA atm as we are just now testing Alpha builds.

As far as the low latency option... it is mostly for very specialized use cases (CCTV, IPTV, etc.) when speed is very important.
----
When a stream is properly muxed into a MP4 format, it has the advantage of storing the NALU lengths at the beginning of each frame. When the Byte stream format is used instead, the size of the NALU can only be determined when the next startcode is seen... this adds one frame of latency, plus the existing one frame delay.

Additionally you will need to use FORMAT_MPEG2Video for the input connection format type, with dwFlags set to the length of the size field (commonly 2 or 4 bytes) and the sps and pps NALUs should be passed in dwSequenceHeader. Also note that you should not use MEDIASUBTYPE_MAINCONECPT_H264 ({0x8D2D71CB, 0x243F, 0x45E3, 0xB2, 0xD8, 0x5F, 0xD7, 0x96, 0x7E, 0xC0, 0x9B}) for the subtype, as it is not meant for this format. Use one of the other regular H264 subtypes made by using either "avc1" or "h264" as the fourcc.

All of the above will be in the "CoreAVC Guide" and in the filter properties box.

[CiNcH]

As far as the low latency option... it is mostly for very specialized use cases (CCTV, IPTV, etc.) when speed is very important.
----
When a stream is properly muxed into a MP4 format, it has the advantage of storing the NALU lengths at the beginning of each frame. When the Byte stream format is used instead, the size of the NALU can only be determined when the next startcode is seen... this adds one frame of latency, plus the existing one frame delay.

So were are talking about 20-40ms faster zapping or what?

[Stephen R. Savage]

Are there any plans to include a 64-bit version of avss.dll? It is the only file from HMS that has no 64-bit equivalent.

[BetaBoy]

I've asked Haali to comment.

[Snowknight26]

Hope you also ask him to comment on his broken splitter. D:

[Gleb Egorych]

BetaBoy, so no improvements in interlaced content support?

[jj666]

We now have two "world's fastest H264 software decoders" according to webpages - which one is now the fastest?

Cheers,

-jj-

[Disabled]

It depends on the hardware you have. The other one was faster in some tests, others had CoreAVC run faster on their computer. I guess the tendency is, that CoreAVC performs better on older hardware while the other one performs faster on newer ones. CoreAVC is much more stable and feature complete and has no hardware tied activation scheme. The other one is still under heavy development, meaning there are some speed boosts to expect and features are promised to be added too. Theres always the free third option and the open source fourth, so if you can, wait for further development of both codecs.

[lych_necross]

I've got a question about CoreAVC 2.0 being used with ffdshow. I have configured CoreAVC to prefer CUDA acceleration and when I watch h.264 movies, I sometimes like to use ffdshow's raw video filter alter the movie in realtime. My question is, if I use CoreAVC (w/CUDA enabled) and ffdshow together, will CoreAVC revert to software mode like DXVA decoders do when used with ffdshow?

[roozhou]

will CoreAVC revert to software mode like DXVA decoders do when used with ffdshow?
No, CUDA is not DXVA. The frame will be fetched back to main memory no matter what you connect the decoder to.

[me7]

I've got a question about CoreAVC 2.0 being used with ffdshow. I have configured CoreAVC to prefer CUDA acceleration and when I watch h.264 movies, I sometimes like to use ffdshow's raw video filter alter the movie in realtime. My question is, if I use CoreAVC (w/CUDA enabled) and ffdshow together, will CoreAVC revert to software mode like DXVA decoders do when used with ffdshow?

I do exactly this and it works. As roozhou said each frame is copied back to RAM and can be altered by any filter you like.

[lych_necross]

Thanks roozhou and me7. That's what I thought, but I wanted to be sure. How is DXVA support going to change things? Lets say I have the latest and greatest Geforce card from Nvidia. Is the new CoreAVC going to prefer CUDA or DXVA? Using both at the same time is impossible I'm assuming.

[Keiyakusha]

It doesn't really matters since the same chip will be used as for CUDA. If cuda is fine for you now, then there will be no improvements for you.

By the way the only point for DXVA in CoreAVC I see is... if there will be some custom renderer and we will be able to retrieve decoded frames then Ati users will be happy. Otherwise this is waste of time IMHO... There is already DXVA in MPC-HC and ffdshow and its free.

[lych_necross]

It never occurred to me that the same chip is used for both. Hopefully, when the next update of coreavc comes out there will be a new haali splitter (unless Haali sees his shadow, then we'll have to wait six more months ;)

[me7]

Thanks roozhou and me7. That's what I thought, but I wanted to be sure. How is DXVA support going to change things? Lets say I have the latest and greatest Geforce card from Nvidia. Is the new CoreAVC going to prefer CUDA or DXVA? Using both at the same time is impossible I'm assuming.

The DXVA option could be slightly faster since the frames don't need to be copied to RAM while CUDA has the advantage of being compatible with other filters.

[clsid]

Is there a way for us to motivate Haali to fix some of the remaining bugs in his excellent splitter? Perhaps he could add a donation page to his website? Or the Matroska foundation could do it, and forward the revenue to Mike.

I could help send a lot of traffic to such a donation page, if that would result in further improvement of the splitter.

BetaBoy, are there still plans to open an official bugtracker for HMS and CoreAVC?

[Keiyakusha]

It will be also good to see in HMS support for compliant AC3 in mp4.

[Midzuki]

It will be also good to see in HMS support for compliant AC3 in mp4.

Besides AC3: DTS and VC-1.

[Jeff Flowerday]

Is there a way for us to motivate Haali to fix some of the remaining bugs in his excellent splitter? Perhaps he could add a donation page to his website? Or the Matroska foundation could do it, and forward the revenue to Mike.

I could help send a lot of traffic to such a donation page, if that would result in further improvement of the splitter.

BetaBoy, are there still plans to open an official bugtracker for HMS and CoreAVC?

+1, I'd be up for donating!

I'd even be up up to purchasing a splitter that was maintained with regular updates.

[BetaBoy]

We do share the source for HMS. But Haali has been resistant to outside devel other then us here at CoreCodec. Haali has a full time job and his splitter and third party work takes a back seat to his time availability. I'll ping him more on it.

On a CoreAVC bug tracker... we do have our internal wiki that we keep going but atm 2.0 has very little known bugs and those that are known have already been fixed for our upcoming 2.1 release.

[lych_necross]

Is there a way for us to motivate Haali to fix some of the remaining bugs in his excellent splitter? Perhaps he could add a donation page to his website? Or the Matroska foundation could do it, and forward the revenue to Mike.

You could try kidnapping his dog and holding it for ransom :devil:

Seriously, maybe Corecodec could buy haali's splitter outright and handover development to another person/team (someone who is more approachable and willing to work with others).

[hajj_3]

or they could buy it and make it open source:)

[ExSport]

Does it mean you can use DXVA to reencode Videos? Ie DXVA decodes the video and pipes it to another program? Like this guy is suggesting:
http://forum.doom9.org/showthread.php?p=1375061#post1375061
If it will be possible to use DXVA for decoding part in encoding process, like in Sherpya MEncoder, I suppose every will benefit from this, not only CoreCodec in sale ratings :)
And also new "benefit" in comparison with DiAVC: http://forum.doom9.org/showthread.php?p=1379225#post1379225 (Sherpya post and codec matrix supported in MEncoder right now)
I like free market, it leads to better products for end user so good luck FFDSHOW, DiAVC and Corecodec. Keep up good work all!!! Sorry for OT.

[leeperry]

You could try kidnapping his dog and holding it for ransom :devil:

Seriously, maybe Corecodec could buy haali's splitter outright and handover development to another person/team (someone who is more approachable and willing to work with others).
he's always idling on the MPC-HC IRC channel, bribe him :p

[dimitrik]

There is already DXVA in MPC-HC and ffdshow and its free.

OT: I know about DXVA in MPC-HC, but my understanding is ffdshow is a pure software decoder. Are you sure it can support DXVA?

EDIT: Checked, no it can't and won't. See this post here. (http://forum.doom9.org/showthread.php?p=1145712#post1145712)

Franky if it did there would be no reason whatsoever to use coreavc or other commercial decoders. As it is, they have at least that advantage, especially when hardware acceleration exists.

[nm]

OT: I know about DXVA in MPC-HC, but my understanding is ffdshow is a pure software decoder. Are you sure it can support DXVA?

EDIT: Checked, no it can't and won't. See this post here. (http://forum.doom9.org/showthread.php?p=1145712#post1145712)

That's old information. ffdshow tryouts (http://ffdshow-tryout.sourceforge.net/) SVN has DXVA support, including subtitle renderering in any DirectShow media player. Search the development thread (http://forum.doom9.org/showthread.php?t=120465) for more information.

[weasel_]

OT: I know about DXVA in MPC-HC, but my understanding is ffdshow is a pure software decoder. Are you sure it can support DXVA?

EDIT: Checked, no it can't and won't. See this post here. (http://forum.doom9.org/showthread.php?p=1145712#post1145712)


you check to old info ...

now it can ...

read ffdshow tryout project topic

[popper]

and OC theres the beta http://www.splitted-desktop.com/~gbeauchesne/xvba-video/ for AMD HD cards on linux use now OC,
its not clear if Core will or can make use of this (limited right now) UVD codebase patches etc in some way on linux for AMD HD cards HW assisted AVC decode!

Overview:
XvBA backend for VA API supporting the following codecs:

MPEG-4 AVC (H.264)
Windows Media Video 9 Advanced (VC-1 Advanced profile)
Requirements

This version requires AMD fglrx driver version >= 8.66. In particular, you'd need either fglrx 8.66.x (Catalyst 9.10) or fglrx 8.68.2 (9.12-HotFix)....

http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/
these patches add VA API support to FFmpeg and MPlayer.

HW video decode capabilities depend on the actual VA API implementation. Besides, from an MPlayer perspective, only full-offload (VLD) of the video is supported for the following codecs:....

http://www.splitted-desktop.com/~gbeauchesne/libva/
These patches extend VA API with data needed for VDPAU and XvBA backends. Other changes include packaging improvements.

http://www.phoronix.com/forums/showthread.php?p=113271#post113271
AMD's UVD2-based XvBA Finally Does Something On Linux

it might be werth helping out and asking questions on freenode #radeon too If your a developer looking to help make something usable for AMD/ATI end users there any time soon as he and several in house ATI/AMD devs hand out there.

[nitrous]

For some reason when I'm playing H264 movies on KMPlayer + CoreAVC, the picture randomly freezes, but the audio keeps running. The solution is going 5 seconds back, then it plays normally. What's the issue?


Edit: Nevermind this. Fixed it (I think) by changing video renderer from EVR to VMR9.

[BetaBoy]

CoreAVC 2.1 devel update... DVXA 1 done... working on finishing up DXVA 2 atm.

[BetaBoy]

On a side note we are also working on finalizing our CoreASP (DivX) directshow filter (and OEM SDK) for a QA release internally... the initial public release will be afterwards. No CUDA on the initial release, but it is planned.