CoreCodec/H.264 Codec "CoreAVC"

[betaking]

Coreavc 2.6 did not work with mpc-hc x64, no video output. Tried internal , haali and LAV splitter, both the same. But other h264 decoder and 2.5.5 works fine.

YES coreavc 2.6 can not Connection some mpc-hc internal standalone and LAV splitter,but use 2.5.5 no problem!:confused:

[Fadeout]

What remains is a DXVA bug with DVBViewer...

There's also the problem I reported in my previous post (stutters or video freeze in DXVA on specific videos), that was there already in 2.5.5 and will probably be there in 3 too.

[CiNcH]

We reviewed the cause of the DXVA/CUDA problem in the DVBViewer team in more detail now and came to the conclusion that it is a CoreAVC restriction. Taking actions inside the DVBSource filter would only be a workaround which may have bad side effects in a streaming environment. The DVBSource perfectly adheres to the MSDN H.264 streaming rules.

[devil-strike]

We reviewed the cause of the DXVA/CUDA problem in the DVBViewer team in more detail now and came to the conclusion that it is a CoreAVC restriction. Taking actions inside the DVBSource filter would only be a workaround which may have bad side effects in a streaming environment. The DVBSource perfectly adheres to the MSDN H.264 streaming rules.


Hmm whene using dvbviewer it wont work, like some say's here.

But here its goes back to microsoft codec, and ignore coreavc completly, whene i go back to old version of coreavc it works.

[CiNcH]

But here its goes back to microsoft codec, and ignore coreavc completly
Hmm, did you disable certain media subtypes or color spaces within the CoreAVC settings?

[BetaBoy]

The DVBSource perfectly adheres to the MSDN H.264 streaming rules.

CiNcH as we pointed out in email which you seem to now want to post to the public rather then continue our emails discussions (which is fine by us).

The SPS and PPS are normally sent as part of the AVC/H264 connection info. Is it mandatory? No but it is describe as the preferred method.

See: https://msdn.microsoft.com/en-us/library/dd757808(v=vs.85).aspx

DVBSource does NOT perform anything like the description on the MSDN page as the normal way to send SPS/PPS via the connection info is by using the dwSequenceHeader field of the MPEG2VIDEOINFO struct.

As stated, for local files this is fine but for live streams its not the proper behavior since the SPS/PPS may not be immediately available. RE: If there's a channel change, the connections need to be torn down and reconnected.

Our determination is that DVBSource doesn't do what it should and because it doesn't, CoreAVC can't be sure DXVA will work so it doesn't use it.

Breaking the proper methodology in DVBSource to save on perceived delays for end users when changing channels is not right, as decoding can't be start until the sps+pps are received anyway.

[devil-strike]

Hmm, did you disable certain media subtypes or color spaces within the CoreAVC settings?

No is on auto, like i said in 2.5 is working after install 2.6 is not working with same settings.

[CiNcH]

DVBSource does NOT perform anything like the description on the MSDN page as the normal way to send SPS/PPS via the connection info is by using the dwSequenceHeader field of the MPEG2VIDEOINFO struct.
In case of MEDIASUBTYPE_H264 a format block does not have to be appended. In this case there simply is no MPEG2VIDEOINFO.

Breaking the proper methodology in DVBSource to save on perceived delays for end users when changing channels is not right, as decoding can't be start until the sps+pps are received anyway.
But it will most likely happen that the splitter will wait for SPS/PPS and then the decoder waits again as it does not expect the SPS/PPS to be appended to the connection info as the MSDN states that you do not have to expect one in case of MEDIASUBTYPE_H264. This may result in >5s channel switching delays depending on the SPS/PPS frequency. SPS/PPS are pretty rare. We won't implement a workaround with such side effects to satisfy CoreAVC.

[BetaBoy]

As stated its not mandatory... and we will not use DXVA without it given the mixed live/local environments.

[nevcairiel]

I agree with CiNcH, the MSDN clearly states that H264 with Startcodes does not require a SPS/PPS block in the media type. It actually doesn't even list the possibility (or how to do it) for H264 with start codes.
It also does not name a preferred method.

DVBSource functions perfectly within the parameters as defined by the MSDN.

To quote the MSDN:
When the bitstream contains start codes, any of the format types listed here is sufficient, because the decoder does not require any additional information to parse the stream. The bitstream already contains all of the information needed by the decoder, and the start codes enable the decoder to locate the start of each NALU.

I don't understand why CoreAVC doesn't just wait for the SPS/PPS, and then decides if DXVA should be used or not. Like you said, a SPS/PPS is needed before decoding can start anyway, so the choice which decoder to use can easily be postponed until then.

[CiNcH]

OK, so DXVA/CUDA won't be supported when using DVBSource together with CoreAVC. You guys told me via mail already that you are also not going to take further actions for the time being. I am fine with that. The reason why I made this public is because both sides won't do anything about it. I just wanted both, CoreAVC and DVBViewer users, to know about this restriction (leaving out the details) and our point of view. It was not meant to insult you. If you have another opinion or understand things differently, you can of course also state it (which you did) and I am fine with that too. We do not have to be of same opinion ;) . I am not using CoreAVC anyway. The only thing I am concerned with is customer/user satisfaction and that is why I went into all this debugging. (OK you can now hand me the medal of honor for special service ;) )

If people want to use CoreAVC within the DVBViewer they can still do so for content that does not make use of the DVBSource filter (obviously not for DVB) or simply give up on DXVA/CUDA.

[MOS-Marauder]

"If you want to use CoreAVC within the DVBViewer you can still do so for content that does not make use of the DVBSource filter. " ....


Witch makes it allmost unusable. I guess the same behaviour will be in CoreAVC 3.0.. so .. WHY should i buy this ?

For me.. i got CoreAVC for use @DVBViewer. Not its no longer possible..guess what?


Chris

[BetaBoy]

I don't understandNobody is in the wrong here... they do it one we, we another. But don't misunderstand us, we want DVBViewer w/DXVA to work and we are discussing on how best to handle it.

[BetaBoy]

We are releasing CoreAVC 2.6.1


CoreAVC H.264 Video Codec - Version 2.6.1.0 (20110906)
- FIX: Installer uses 32-bit filter for post-install configuration
- FIX: SPS/PPS identification regression
- CHG: DXVA increase max buffers
- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
- FIX: Better recovery point handling, reduces artifacts for poorly cut streams

Emails are about to be sent now. It will take a few hours for them all to go out.

[nussman]

Betaboy ... you want to stop the discussion right now? :eek:
At a point were we are very close to make CoreAVC useable?


I don't understand why CoreAVC doesn't just wait for the SPS/PPS, and then decides if DXVA should be used or not. Like you said, a SPS/PPS is needed before decoding can start anyway, so the choice which decoder to use can easily be postponed until then.

Thats the point i dont understand too.
Could you explain it?

[CiNcH]

- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
Can you get into detail here too? We actually want to fix it inside the splitter. DVBSource also suffered from bad field order with hardware deinterlacing inside the renderer when using CoreAVC.

[squid_80]

But it will most likely happen that the splitter will wait for SPS/PPS and then the decoder waits again as it does not expect the SPS/PPS to be appended to the connection info as the MSDN states that you do not have to expect one in case of MEDIASUBTYPE_H264. This may result in >5s channel switching delays depending on the SPS/PPS frequency.
That's just silly. If the decoder expects SPS/PPS to be part of the connection info why would it then ignore it? If a filter doesn't know how to read the SPS/PPS data from the connection info, you could also prepend it to the first sample - thus preventing the decoder from discarding any NALUs due to them referencing non-present/inactive SPS/PPS (which would actually reduce the "perceived" latency rather than increase it).
OK, so DXVA/CUDA won't be supported when using DVBSource together with CoreAVC.
CUDA isn't affected at all, I don't know where you're getting that information from.
I don't understand why CoreAVC doesn't just wait for the SPS/PPS, and then decides if DXVA should be used or not. Like you said, a SPS/PPS is needed before decoding can start anyway, so the choice which decoder to use can easily be postponed until then.
It can't be postponed - the renderer handles DXVA decoding and must be configured during pin connection. This happens before any samples are sent between the splitter and CoreAVC.For me.. i got CoreAVC for use @DVBViewer. Not its no longer possible..guess what?It works just fine, but won't use DXVA with DVBSource. Could be worse - try using MPC's decoder with DVBSource and see what happens.
Can you get into detail here too? We actually want to fix it inside the splitter. DVBSource also suffered from bad field order with hardware deinterlacing inside the renderer when using CoreAVC. Given that your splitter sends chunks of elementary stream, it would be virtually impossible to fix it there - you need to send a whole frame per sample with correct start and end times set. For unknown durations or end times, MS says it is allowable to set the end time to start time + 1, but it has been discovered that their renderers don't like this very much.

[CiNcH]

If the decoder expects SPS/PPS to be part of the connection info why would it then ignore it?
Hmm, seems my English is not good enough to explain myself properly... Sorry for that.

In case of MEDIASUBTYPE_H264 the decoder may not expect SPS/PPS to be part of the connection info as it is not really defined for H.264 with start codes. And also due to the fact that the format may have changed already, the decoder may be better off using the most recent info from the stream. So we end up waiting for SPS/PPS twice.

CUDA isn't affected at all, I don't know where you're getting that information from.
I was referring to user MOS-Marauder. But he of course was referring to the general issue within 2.6 where SPS/PPS was not properly read at stream time which is now fixed in 2.6.1. So CUDA may work then. Sorry for that.

It can't be postponed - the renderer handles DXVA decoding and must be configured during pin connection. This happens before any samples are sent between the splitter and CoreAVC.
So let us all just be happy that some other DXVA decoders are able to handle this case.

[hajj_3]

will CoreAVC 3.0 still be released today? Do you have a changelog for it yet?

p.s you should put changelogs for each version on your website.

thanks.

[CruNcher]

Dan do you also plan on implementing Intel (SB and newer) and AMD (APU,UVDx) Native API Hardware support @ the side of Nvcuvid or do you propose for Performance reasons DXVA for those 2 platforms :) ?

[dansus]

2.6.1

Emails are about to be sent now. It will take a few hours for them all to go out.

Is the download live? Still says 2.6 on the page.

[MOS-Marauder]

I was referring to user MOS-Marauder. But he of course was referring to the general issue within 2.6 where SPS/PPS was not properly read at stream time which is now fixed in 2.6.1. So CUDA may work then. Sorry for that..

Yep i tested yesterday 2.6.0 resulting in Black Screen with Audio.

Chris

[TOM_SK]

Is the download live? Still says 2.6 on the page.

Add me to the list, too (invoice number 33689).

[MOS-Marauder]

Add me to the list, too (invoice number 33689).

Well give them some Time... some Hrs more or less doesnt count...


Chris

Edit: ok some hrs later.. still no 2.6.1 @Account(s)

[BetaBoy]

Is the download live? Still says 2.6 on the page.

As we were releasing 2.6.1 we found a DXVA1 bug and pulled it from the portal. We finished compiling a new one and are signing it... releasing it will be next.

Then on to the CoreAVC 3.0 launch.

[BetaBoy]

Dan do you also plan on implementing Intel (SB and newer) and AMD (APU,UVDx) Native API Hardware support @ the side of Nvcuvid or do you propose for Performance reasons DXVA for those 2 platforms :) ?
I can comment more on our Intel efforts after we release CoreAVC 3.0 in a few hours.

[MOS-Marauder]

As we were releasing 2.6.1 we found a DXVA1 bug and pulled it from the portal. We finished compiling a new one and are signing it... releasing it will be next.

Then on to the CoreAVC 3.0 launch.

Ok, thx for Info.

Chris

[BetaBoy]

will CoreAVC 3.0 still be released today? Do you have a changelog for it yet?

p.s you should put changelogs for each version on your website.

thanks.
We post each changelog from each release, see:
http://corecodec.com/products/coreavc/changelog

[hajj_3]

ahh, there it is, silly me!

[Tanuki]

thanks god there are some alternative to CoreAVC, because I have been blocked with the buggy 2.6 for 3 days (with no possibility to downgrade to 2.5.5 since the license key isn't archived anywhere in my client area)...
I REALLY hope the Hi10P support won't be a disappointment.

[TheShadowRunner]

I REALLY hope the Hi10P support won't be a disappointment.

Don't we all ;)

[BetaBoy]

backing up.... gonna release 2.6.1 next... then take down 2.x purchasing in preparation for the CoreAVC 3.0 launch.

[hajj_3]

isn't it better to use new version numbers instead of silent updates as those people who downloaded the buggier versions of 2.6.0.0 and 2.6.0.1 may not be aware new versions are available. I'd name it 2.6.0.2 if i were you.

[BetaBoy]

CoreAVC 2.6.1.0 released on our customer portal. https://customers.corecodec.com

To upgrade to 2.6.1 (or any product) click 'My Products' and then click the product you purchased. At the top you will see an upgrade notification link, click through it and the updated product will then be in your account.

CoreAVC H.264 Video Codec - Version 2.6.1.0 (20110906)
- FIX: Installer uses 32-bit filter for post-install configuration
- FIX: SPS/PPS identification regression
- CHG: DXVA increase max buffers
- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
- FIX: Better recovery point handling, reduces artifacts for poorly cut streams

[TOM_SK]

coreavc 2.6.1.0 released on our customer portal. https://customers.corecodec.com

Thanks!

[BetaBoy]

Any feedback related to DVBViewer/DVBSource and third party splitters would be appreciated as this was the primary focus of this release. As noted in previous posts DXVA will not work with DVBViewer/DVBSource till we sort out the SPS issue (same goes for CoreAVC 3.0).

[nussman]

CoreAVC 2.6.1:

dvbviewer:
seems to work fine in software mode
no dxva as expected .... :mad:

deinterlacing:
Seems to work properly now with dvbviewer sourcefilter and mpc-hc splitter

installer:
64bit errormessage is gone


Not so bad at all.
Please take your time and think about the SPS/PPS issue!

[BetaBoy]

nussman... awesome... thx for the fast feedback!

[dansus]

Any feedback related to DVBViewer/DVBSource and third party splitters would be appreciated as this was the primary focus of this release. As noted in previous posts DXVA will not work with DVBViewer/DVBSource till we sort out the SPS issue (same goes for CoreAVC 3.0).

I can watch BBCHD now and globe is green, good enough for me.

[mkanet]

I totally didn't expect this (since I didnt notice anyone else report this issue), but the problem with 2.6.0 went away where a few of my videos would have this weird repetitive 1-sec video loop over and over again on certain parts of the video (for example a person's head nodding up and down or arm flapping back and forth). I can also confirm that the install error went away.

Both issues are fixed for me.

Thanks for all your hard work,
MKANET

[Chumbo]

Some feedback on 2.6.x. The hardware deinterlacing is working great. The 30fps media files from Hauppauge HD-PV4 1212 now play nice and smooth in both DXVA and None with Hardware deinterlacing (I use MPC-HC). Single field and Bob are better than they were but still unwatchable by the way.

[BetaBoy]

green = DXVA... nice.

We are tracking 3 potential issues... not show stoppers but we are working with the reporters on the issues.

- Haali .MP4 bug where the container is not supported (for some users)
- Interleave MP4 videos (might be field order related)
- ZoomPlayer having issues as well

[Fadeout]

The problem I had in the previous version is still there: with some videos and DXVA (ATI, no matter the driver version and tested across different videocards models) the video freezes (the player is responsive and the audio goes on, but the image completely freezes, including the stats graph). CoreAVC CPU decoding works fine, DXVA in the internal MPC works fine. Only CoreAVC DXVA freezes. If I enable V-synch or frame correction the video doesn't freeze but I still get unusual stutters here and there (that aren't there with MPC internal DXVA).

So this is an issue specific to CoreAVC DXVA implementation.

Can't post a sample because it's an anime. If you want to look up the specific file, it's this:
[Commie] Tiger & Bunny - 01 [39E1E59A].mkv

One freeze happens at 00.44, and also usually happens 3-4 seconds before a different chapter in the file. The stutters instead happen every few seconds.


This was also partially fixed in 2.6.1 in the sense that now the video doesn't freeze/stop anymore.

The problem that is left is that there are still stutters here and there, it seems especially on some scenes change. MPC-HC DXVA is instead always smooth.

[cyberbeing]

Haali .MP4 bug where the container is not supported (for some users)
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.

[BetaBoy]

CoreAVC 3.0 is a major milestone for us here at CoreCodec and adds features like 9/10 bit support, Full DXVA 2, DXVA 1, GMA support, DXVA fallback, Intel Media SDK support, New Assembly 'Core', etc.

What's new in CoreAVC 3.0?
CoreAVC H.264 Video Codec - Version 3.0.0.0 (20110906)
- ADD: 9 bit support
- ADD: 10 bit support
- ADD: DXVA fallback to software
- ADD: Intel Media SDK Support (DXVA2)
- ADD: Intel GMA Support (DXVA2)
- ADD: 10 bit output format (P010)
- ADD: 16 bit output format (P016)
- ADD: Directshow dithering when filter output is downsampled
- ADD: Improved DXVA handling for interlaced streams
- ADD: Colorspace conversion from 10 bit formats to 8 bit formats
- ADD: DXVA 2 Long slice support
- ADD: Initial 4:4:4 integration (No decode support yet)
- ADD: New assembly engine
- ADD: New assembly IDCT
- ADD: New assembly motion compensation
- ADD: New assembly inter-prediction
- ADD: New assembly weighted prediction
- ADD: New assembly 9-bit
- ADD: New assembly 10-bit
- ADD: Improved assembly 8 bit performance
- CHG: Use container AR when there is no stream AR
- FIX: Improved Frame order handling
- FIX: Hardware deinterlacing field order
- CHG: DXVA increase max buffers
- CHG: Sanitize sample stop times for buggy splitters, for hardware deinterlacing compatibility
- FIX: Better recovery point handling, reduces artifacts for poorly cut streams
- SDK: Updated xcode support for iOS and OS X
- SDK: Improved APIs
- SDK: Fix: Missing APIs
- SDK: Initial support for MVC (CoreMVC) integration

Haali Media Splitter - Version 1.11.233.7 (20110830)
- FIX: Various DTS Audio bugs
- ADD: Improved DTS support
- ADD: Support for MVC 3D videos


For current 2.x customers, if you have purchased CoreAVC within the past 60 days, you will automatically get 3.0 as a part of the purchase.

CoreAVC 3.0 can be purchased here:
https://customers.corecodec.com/cart.php

[BetaBoy]

Customers who purchased CoreAVC 2.x (not a 1.x upgrade) in the past 60 days get the update first.

After the emails are sent we will make it available for purchase.

[BetaBoy]

Also a heads up... although it did not make it into 3.0 before we went 'gold', we have also added:
- 4:4:4 profile support
- Intel AVX support (SandyBridge / IvyBridge)

You will likely see those in one of the next updates starting with 4:4:4 first.

[cyberbeing]

CoreAVC 3.0 software decoding has an extremely massive memory leak when used with madVR and MPC-HC. Every time a video is opened or re-loaded without closing the player, memory usage increases by the initial amount... For a 10bit 1080p video this means ~+250MB for every video you open until you are out of memory.

[BetaBoy]

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

[BetaBoy]

We have taken down 2.x purchasing.... about to push 3.0 live for everyone.