CoreCodec/H.264 Codec "CoreAVC"

[mkanet]

Thanks for asking. This alone would give me reason to upgrade.

PS: My weird FF/REW issue (mentioned above) is fixed. All I had to do was change to acceleration to disable on CoreAVC, then set it back to Cuda. I also upgraded my LAV splitter from version .29 to .30 (but seriously doubt that would make a difference).

-MKANET

We have several groups working on DXVA from several fronts, as with 2.x you will continue to see 3.0 refine DXVA 1/2 support with each 3.0 release. However 3.0 combines all of their efforts. It will become more apparent on whats been done after 3.0 is out.

We have reports of the 'green' issue and if I am not mistaken it has been fixed. I just sent a PM asking to confirm this.

[CruNcher]

Dan could you please check this
http://forum.doom9.org/showthread.php?t=162021

[BetaBoy]

CruNcher.... I have the guys looking into it.

[CruNcher]

Hehe i could fix the issues also with CoreAVCs DXVA, it's interesting if PTEs are to low DXVA (needs a lot of PTEs) cant be used with High resolutions anymore so for users using the /3GB switch you need to carefully balance it out with /USERVA= (User/kernel pools) you can take this into your help system for crazy XP users, using /3GB alone can cause DXVA problems (and most probably you need to manually adjust it for best Results in Video Acceleration/and Application Memory Efficiency above 2 GB for 32bit) ;)

[Nick [D]vB]

Sorry to go off-topic but have we got an ETA for CoreMVC yet? Any news on CUDA support for it? I just read something on AnandTech that gave me an idea, ATI seem to have worked out a way to partially accelerate MVC decoding on older UVD2.2 hardware (some Fusion APUs and the rebranded HD5750 -> HD6750s cards etc) Somehow they are treating the left stream as AVC and accellerating it with DXVA, then doing the right stream in shaders / software. This approach might allow for some acceleration on older nvidia cards (VP2/A), could it work for CoreMVC?

http://www.anandtech.com/show/4479/amd-a83850-an-htpc-perspective/6

http://forums.anandtech.com/showpost.php?p=31940090&postcount=17

[BetaBoy]

We have finished CoreMVC 3D's 'CORE', OMF (Open Media Format), directshow work and changes to the Haali Splitter to add support for MVC (and some minor splitter fixes). Also please see Peters post on OMF as its related to our initial CoreMVC 3D release: http://forum.doom9.org/showthread.php?t=156051

(Beta testers just got a new build this morning which adds Haali's new splitter as we are not using the MPC splitters Peter created for his Stereoscopic Player)

However we will are on hold for the next 2/3 weeks till we complete the changes for CoreAVC 3.0... 10-bit output options, ASM work, DXVA 1/2, deinterlacing issue, DXVA fallback, etc. We are planning however to release CoreMVC soon after CoreAVC 3.0 is out.

I'll have the guys look into the anandtech articles, thanx!

[Nick [D]vB]

Cool, I look forward to the CoreMVC release then! I had always hoped that any card with dual-stream H.264 support would be able to decode MVC in hardware with a few driver updates, at least the AVC part, but it seems to be "all or nothing". I suppose that sort of partial MVC acceleration would have to be engineered at driver level, or eveyone would be doing it right? Neither AMD or Nvidia have any real incentive to do it, if they want to sell new cards, except for in special cases like Fusion / rebrands.

I realise it's too late to add any major features to this version but it would be great if you could look into the idea for the future, maybe you could achieve something similar using CUDA? That would be another great USP for CoreCodec. I have been keeping an eye on that OMF thread but most of it goes straight over my head! lol Just out if interest, would it be possible to use the new splitter to send the left "AVC like" stream to a standard AVC codec (using DXVA) and the right MVC delta stream to CoreMVC? I suppose that would need some sort of custom renderer though?

Anyway, thanks for the update.

:)

[madshi]

We have finished CoreMVC 3D's 'CORE', OMF (Open Media Format)
We're still discussing the final OMF spec, though. Do you mean just the pin connection types Peter is currently using? They're not based on OMF yet, he has recently stated.

[BetaBoy]

We're still discussing the final OMF spec, though. Do you mean just the pin connection types Peter is currently using? They're not based on OMF yet, he has recently stated.

Peter will comment more on it.

[BetaBoy]

CoreAVC deinterlacing issue resolved.... we think. Still more testing to do but it looks like adding more checks has worked.

[nussman]

:thanks:

What do you think about an open Beta-Test for customers?
So that all showstopper-bugs can be fixed once and forever before the next release?

[clsid]

I don't use CoreAVC, so I don't know if the current version still has this bug, but has the thumbnailing crash been solved yet? That bug has been present for years.

[BetaBoy]

It was an issue with Haali's splitter and not CoreAVC. Haali disabled thumbnails a while back as he was tired of trying to work around the many shell bugs still present in Win 7.

[clsid]

I am not talking about Haali's shell extension. I am talking about thumbnailing with Microsoft's shell extension.

[BetaBoy]

Just added NVIDIA Cuda and DXVA directshow fallback to software when high bit is detected in CoreAVC 3.0.

[Mixer73]

I guess I'm not alone in recieving the following:

We are down to our last 48 hours to be able to get an upgrade to CoreAVC 3.0 for $7.95 with a purchase of CoreAVC 2.x now, before our price goes back to $12.95.

This is the cheapest way to get CoreAVC 3.0, as we will not be offering upgrades for this milestone to our current users.

CoreAVC 3.0 is the culmination of over 2 years of work and brings many new features:

- Full DXVA 1 / DXVA 2 support
- DXVA Fallback
- AVC 10-bit decoding support
- 4:4:4 profile support (in a later 3.x release)
- Additional hardware support (more info the 3.0 press release)

I added the bold for emphasis.

Dan, is this correct? Will owners of 2.0 not even be offered an upgrade to 3.0, and have to buy again?

I'm someone who has defended you on here, but honestly I'm struggling to find a real reason to use CoreAVC these days, and if I am not misunderstanding, and this is your intention, then you've definitely lost me.

[Maccara]

I added the bold for emphasis.


They worded it really ...badly.

I don't appreciate, as a customer, receiving an ultimatum...

[BetaBoy]

As stated we will continue to release 2.x with the reported issues (but not sell 2.x any longer once 3.0 has been released). So the choice to upgrade for the new features in 3.0 is up to the end user for their needs.

As always we are grateful for everyone's continued support.

[desta]

As stated we will continue to release 2.x with the reported issues (but not sell 2.x any longer once 3.0 has been released). So the choice to upgrade for the new features in 3.0 is up to the end user for their needs.

As always we are grateful for everyone's continued support.
Hardly! I paid for a product which never worked properly, which I never received any support for, despite requesting numerous times (and let's face it, you never tried) and now I'm being told that if I want the new version I've basically got to pay (again) a discounted price for the version I've already got. Genius.

[BetaBoy]

desta... While I understand what you are saying, as noted we 'will' still continue to release 2.x for the users that purchased it to address the reports we have. This means you will continue to get those 2.x updates as a part of your 2.x purchase and as stated a few pages back, we plan on releasing a new 2.x release soon after 3.0 is out.

Also for users that have recently purchased 2.x in the past 60 days, they get teh upgrade to 3.0 as a part of the purchase and will be the first ones notified on its availability.

[Mixer73]

As stated we will continue to release 2.x with the reported issues (but not sell 2.x any longer once 3.0 has been released). So the choice to upgrade for the new features in 3.0 is up to the end user for their needs.

Dan, please clarify that 2.0 owners cannot buy 3.0 at a cheaper price, and in fact must purchase 3.0 outright. This is how I have read your email.

[Ice =A=]

Is it so hard to understand?!?
You can get 3.0 cheaper for one more day by buying the 2.x version - AGAIN... :)

[Ice =A=]

@BetaBoy:

Are there any plans to implement advanced features into CoreAVC like motion compensation (computing pictures between pictures for more fluid movements)?
That (apart from nearly everything else) would truly be a unique feature!

And by the way: Are there any plans to release CorePlayer for Android (not just the Codec as SDK)?!?
I still renenber the old one for Windows Mobile, that just great!

Thanks!

[dead_screem]

Dan, please clarify that 2.0 owners cannot buy 3.0 at a cheaper price, and in fact must purchase 3.0 outright. This is how I have read your email.

He already did when I asked this a few pages back. http://forum.doom9.org/showpost.php?p=1514426&postcount=6422

If you own 2.x there will be no 2.x->3.0 upgrade discount at all. you need to re-buy. The good news is that after 3.0 is released they will still release bugfixes for 2.x version so it won't just go unsupported/deprecated like 1.x did.

[Audionut]

we plan on releasing a new 2.x release soon after 3.0 is out.

Unfortunately, corecodecs definition of "soon", differs from the english definition.

Just incase you guys are losing something in the translation, here you go. (http://dictionary.reference.com/browse/soon)

[Mixer73]

If you own 2.x there will be no 2.x->3.0 upgrade discount at all. you need to re-buy. The good news is that after 3.0 is released they will still release bugfixes for 2.x version so it won't just go unsupported/deprecated like 1.x did.

Thanks, thought personally I found CoreAVC a necessary requirement on a Vista or XP system, with Win7 I personally think there are other alternatives I'll pursue, I can't understand a company that doesn't first want to look after its installed userbase.

Anyway my last comment on the topic.

[Virtual_ManPL]

Is this bug finally fixed in version 3.0 ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600

[Abradoks]

Is this bug finally fixed in version 3.0 ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600
Man, that bug has been reported (http://forum.doom9.org/showthread.php?p=1367251#post1367251) and described (http://forum.doom9.org/showthread.php?p=1390804#post1390804) in details only 18 months ago, so you should be patient and shouldn't ask for fix again before January 2012. Don't get it wrong: you are ignored not because BetaBoy doesn't care, but because CoreCodec high qualified engineers have to save the world before they can get to that single-line-fix bug.

[dead_screem]

Is this bug finally fixed in version 3.0 ?
http://forum.doom9.org/showthread.php?p=1390600#post1390600

Looks like CoreAVC is overriding the aspect set by the splitter with whatever it detects, which is fine, but it then sets it wrong in the output in _both_ cases.

CoreAVC+haali
output pin from haali splitter. aspect is set corectly as 853:480
Filter : Haali Media Splitter - CLSID : {55DA30FC-F16B-49FC-BAA5-AE59FC65F82D}

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Input

- Connection media type:

Video: MPEG4 Video (H264) 720x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 171

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 39
dwProfile: 0x00000064
dwLevel: 0x0000001f
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 24
biCompression: avc1
biSizeImage: 0
biXPelsPerMeter: 720
biYPelsPerMeter: 853
biClrUsed: 0
biClrImportant: 0

CoreAVC+haali
output pin from CoreAVC. CoreAVC changes 853:480 display aspect to a completely ridiculous 14557:8192, which somehow gets changed to 71:40, either by the player or renderer (not sure). which gives an 852:480 display which is one pixel off on the X, should be 853.
Filter : CoreAVC Video Decoder - CLSID : {09571A4B-F1FE-4C60-9760-DE6D310C7C31}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: NV12 1024x480 (14557:8192) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 14557
dwPictAspectRatioY: 8192
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: NV12
biSizeImage: 737280
biXPelsPerMeter: 8192
biYPelsPerMeter: 9705
biClrUsed: 0
biClrImportant: 0

CoreAVC+gabest
output pin of gabest splitter. aspect set correctly as 853:480.
Filter : sample.mkv - CLSID : {0A68C3B5-9164-4A54-AFAF-995B2FF0E0D4}

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Input

- Connection media type:

Video: MPEG4 Video (H264) 720x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 166

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 34
dwProfile: 0x00000064
dwLevel: 0x0000001f
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 24
biCompression: AVC1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

CoreAVC+gabest
output pin of CoreAVC. CoreAVC is now changing the 853:480 aspect to 3:2, which is a 1:1 display so no aspect correction.
Filter : CoreAVC Video Decoder - CLSID : {09571A4B-F1FE-4C60-9760-DE6D310C7C31}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: NV12 1024x480 (3:2) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 720
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: NV12
biSizeImage: 737280
biXPelsPerMeter: 1
biYPelsPerMeter: 1
biClrUsed: 0
biClrImportant: 0

FFMPEG + haali
output pin of haali. 853:480 aspect
Filter : Haali Media Splitter - CLSID : {55DA30FC-F16B-49FC-BAA5-AE59FC65F82D}

- Connected to:

CLSID: {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}
Filter: MPC Video Decoder
Pin: Video

- Connection media type:

Video: MPEG4 Video (H264) 720x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 171

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 39
dwProfile: 0x00000064
dwLevel: 0x0000001f
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 24
biCompression: avc1
biSizeImage: 0
biXPelsPerMeter: 720
biYPelsPerMeter: 853
biClrUsed: 0
biClrImportant: 0

FFMPEG + haali
output pin of ffmpeg. 853:480 aspect still correct
Filter : MPC Video Decoder - CLSID : {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: YV12 1024x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 737280
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

FFMPEG + gabest
output pin of gabest. 853:480 aspect
Filter : sample.mkv - CLSID : {0A68C3B5-9164-4A54-AFAF-995B2FF0E0D4}

- Connected to:

CLSID: {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}
Filter: MPC Video Decoder
Pin: Video

- Connection media type:

Video: MPEG4 Video (H264) 720x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 166

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 34
dwProfile: 0x00000064
dwLevel: 0x0000001f
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 1
biBitCount: 24
biCompression: AVC1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

ouput of ffmpeg. 853:480 aspect still correct
Filter : MPC Video Decoder - CLSID : {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: YV12 1024x480 (853:480) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 480
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 737280
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

[BetaBoy]

On Aspect Ratio.... We have commented here several times, but let me address the post.

"CoreAVC doesn't respect AR when it's specified only in MKV header, but not in the stream."
What should take priority? The container? The header? What about all those broken MKV files that are out there?

"CoreAVC changes 853:480 display aspect to a completely ridiculous 14557:8192, which somehow gets changed to 71:40, either by the player or renderer (not sure). which gives an 852:480 display which is one pixel off on the X, should be 853."
Add it up... 853:480 and 14557:8192 are practically the same. The conversion to 71:40 is what is broken, and is causing the 'off by one' error.

[clsid]

For those who want Hi10P support right now, the latest versions of ffdshow, LAV Video, and MadVR all have support for decoding it.

[nevcairiel]

What should take priority? The container? The header? What about all those broken MKV files that are out there?

Since you ship by default with Haali anyway, which overwrites the stream AR with the container AR - i guess go with that?

For MKVs, its usually better to trust the container. Other formats might not have a container AR, like MPEG-TS. For MPEG-TS TV recordings its actually quite common to change mid-stream (between content and ads) which would of course only work if you use the stream value.

Adding an option to configure the behaviour doesn't sound too bad to me.

[BetaBoy]

Adding an option to configure the behaviour doesn't sound too bad to me.

Agreed.

[dead_screem]

"CoreAVC changes 853:480 display aspect to a completely ridiculous 14557:8192, which somehow gets changed to 71:40, either by the player or renderer (not sure). which gives an 852:480 display which is one pixel off on the X, should be 853."
Add it up... 853:480 and 14557:8192 are practically the same. The conversion to 71:40 is what is broken, and is causing the 'off by one' error.which begs begs the question, what is causing the conversion to 71:40?

And practically the same is not the same. 14557 / 8192 = 1.7769775390625 853 / 480 = 1.7770833333333 (repeating) while 14557:8192 should also give an 853x480 resolution the aspect should always be expressed in the lowest form. which is 853:480 in this case. The question is, is 14557:8192 what was actually in the avc bitstream or is CoreAVC coming up with this high value on its own? with gabest splitter and CoreAVC with that file, CoreAVC sets 3:2 aspect, was 3:2 what was actually set in the bitstream? ???

If Haali is actually modifying the AVC bitstream on the fly based on the container, there needs to be an option to disable that. In addition, there should also be an option in CoreAVC to enable/disable reading of the AR from the bitstream (and with it disabled just passthrough the AR from the splitter).


and another example of the off by one error.
but with a h.264 TS
output pin of gabest mpeg splitter gabest correctly sets 16:9 from the container (or its cheating and reading it from the bitstream, because there is no aspect in TS from what i hear?)
Filter : file.ts - CLSID : {1365BE7A-C86A-473C-9A41-C0A6E82C9FA3}

- Connected to:

CLSID: {09571A4B-F1FE-4C60-9760-DE6D310C7C31}
Filter: CoreAVC Video Decoder
Pin: Input

- Connection media type:

Video: MPEG4 Video (H264) 1440x1080 (16:9) 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 187

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333666

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 55
dwProfile: 0x0000004d
dwLevel: 0x00000028
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 1440
biHeight: 1080
biPlanes: 0
biBitCount: 0
biCompression: AVC1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

output of CoreAVC, it sets a weird 14563:8192 instead of 16:9. this somehow results in a off by one 1919:1080 final display...
Filter : CoreAVC Video Decoder - CLSID : {09571A4B-F1FE-4C60-9760-DE6D310C7C31}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Renderer 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: NV12 2048x1080 (14563:8192) 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3317760
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(1440,1080)
rcTarget: (0,0)-(1440,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333666

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000025
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 14563
dwPictAspectRatioY: 8192
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 2048
biHeight: -1080
biPlanes: 1
biBitCount: 12
biCompression: NV12
biSizeImage: 3317760
biXPelsPerMeter: 4096
biYPelsPerMeter: 5461
biClrUsed: 0
biClrImportant: 0

[leeperry]

BTW, I've got a wattmeter but I'm kinda lazy...anyone's ever compared the actual power consumption between CoreAVC CUDA and plain CPU decoding? I've just received my yearly energy bill, and it's substantially smaller than the year before http://forum.slysoft.com/images/smilies/agreed.gif

All I see in this thread is naysayers threadcrapping pretty much every page, but this would be useful information for a change...maybe I've missed it, though :o

[CruNcher]

BTW, I've got a wattmeter but I'm kinda lazy...anyone's ever compared the actual power consumption between CoreAVC CUDA and plain CPU decoding? I've just received my yearly energy bill, and it's substantially smaller than the year before http://forum.slysoft.com/images/smilies/agreed.gif

All I see in this thread is naysayers threadcrapping pretty much every page, but this would be useful information for a change...maybe I've missed it, though :o

you would have to compare CoreAVC Cuda vs DXVA vs Software DXVA should in theory save the most energy though if you go from this standpoint you could even save more energy with a ARM or MIPS Decoding setup and abond the PC ;)

the cheapest craziest thing currently is the Apple TV 2 for 99 bucks you get a complete XBMC player though using tricks to get 1080p->720p playback with scaling (though with crazy energy performance) ;) http://www.youtube.com/watch?v=wJ26L4nTy4s

Or if you adventurous a Pandaboard their you would get 1080p native without tricks @ low power ;)

With such a thing you would save much more money then with anything you do on your IBM PC either with CUDA,DXVA or any Software Decoder ;)

Though Tegra 3 will be the craziest of all finally Nvidia is going to bring all the Power of their Desktop Decoder to the Mobile space and go even beyond http://cdn.static.viddler.com/flash/as3/simple-publisher.swf?key=6dbeeef0 (after the Tegra 2 vs Intel CE Atom disaster on the Boxee Box (heavy playback limitations of their SOC no weighted prediction low bitrate ect)) :D

A good Decoder IP core these days needs no more then 500mw for full 1080p AVC decoding :)

Tegra 3 stuff and Sonys Vita are the most interesting upcoming things :)

[namaiki]

If/Since CoreAVC 2.x won't support decoding of Hi10P/10-bit video, would it be possible for you to please do a maintenance release for 2.x so that it automatically won't be used when a 10-bit video is played?

[mandarinka]

That would indeed be great.

[mkanet]

Sorry if this has been brought up before. I'm curious how the latest CoreAVC CUDA compareS to the latest LAV CUVID CUDA. It looks like LAV CUVID has a lot more features; including a nice surprise... VC1 decoding; which makes sense if you need your decoder for bluray playback.

[ney2x]

^
LAV CUVID = Free to use but expect to have some bugs/problems. Regular updates.
CoreAVC = You need to pay. Updates annually.

[mkanet]

Yeah, I already found that out. I couldn't get the LAV video decoder to connect to any video renderers. I first thought I was doing something wrong, but it looks like it's just a problem with the decoder (at least on my system; which works perfectly with CoreAVC CUDA).

^
LAV CUVID = Free to use but expect to have some bugs/problems. Regular updates.
CoreAVC = You need to pay. Updates annually.

[BetaBoy]

A heads up. We are preparing to release final builds of CoreAVC 3.0 to beta testers after tomorrow.

[hajj_3]

any chance of a changelog?

[BetaBoy]

Ill post the changelog once all the new changes are verified by the larger pool of beta testers.

Also pls note for 2.x users it will be a few weeks for us to back port some of the changes/fixes we made for 3.0... but as stated we do plan a follow-up 2.6 release.

[BetaBoy]

If/Since CoreAVC 2.x won't support decoding of Hi10P/10-bit video, would it be possible for you to please do a maintenance release for 2.x so that it automatically won't be used when a 10-bit video is played?
I threw it at the devs to think about how to handle.

[TheShadowRunner]

BetaBoy, will decoding hi10p contents benefit from the current acceleration methods (CUDA, DXVA..) in CoraAVC 3.0, or will it be 100% software only?
I can imagine DXVA is a no go, but I wonder about CUDA..
Thanks for the info.

[BetaBoy]

Ill comment once 3.0 is out, but you're not far off.

[TheShadowRunner]

Thanks for the fast reply. The wait starts now ;)

[mandarinka]

What conversion method does CoreAVC use to convert 10bit to 8bit yv12 in software?

Madshi reported earlier that the method used by x264 and ffdshow/lavvideo/mplayer/etc (everything using swscale for the job) is somewhat wrong and possibly disagrees with Microsoft's specification. Some details in this thread: http://forum.doom9.org/showthread.php?p=1517620#post1517620

Will CoreAVC mimic FFDshow&friends' method, or will it use something like what Madshi suggests (and is using in madvr I assume)?

[nevcairiel]

What that thread was about was really conversion from 8bit to 10bit (for encoding), not the other way around.

For 10 to 8, there really is only one proper way to do it, and that is dithering, with saturation/clipping.