CoreCodec/H.264 Codec "CoreAVC" [Archive] - Page 118

Virtual_ManPL

23rd May 2010, 13:44

Squid has already stated that your streams are invalid.
Maybe, but MPC-HC and DiAVC decoders didn't show any signs of this, like I said many times before...
So implanting some better error handling will be good (like not better) also like getting faster and faster with each release :)

And how about my first bug ? It's not about invalid streams, but ignoring any AR set in the container by CoreAVC decoder like I can see...
http://forum.doom9.org/showthread.php?p=1390600#post1390600

Keiyakusha

23rd May 2010, 16:10

And how about my first bug ? It's not about invalid streams, but ignoring any AR set in the container by CoreAVC decoder like I can see...
http://forum.doom9.org/showthread.php?p=1390600#post1390600

Your sample doesn't have SAR info on stream level (which is wrong since in current example it absolutely should be there), only info on container level is present. It seems more like bug/missing feature in gabest splitter.
Stream that have SAR on stream level plays nice.
As for divx, I believe there is a switch that makes it read aspect ratio from container, but imho decoder really should pay attention to the stream only. So if this is the case, this is not a bug in CoreAVC but more likely you asking for some extra functionality.

Also I believe MPC-HC devs planning to replace splitters with something else from ffmpeg project so "tomorrow" everything can be different again...

squid_80

24th May 2010, 03:18

Maybe, but MPC-HC and DiAVC decoders didn't show any signs of this, like I said many times before...
Yes they do.

Audionut

24th May 2010, 08:43

well that and with us working with Google on WebM has taken away our focus a bit.

So we'll also wait even longer for coreplayer mobile 2. It's a shame that his is becoming duke nukem forever.

This is the app that symbian S60 V5 phones desperately needs.

Virtual_ManPL

24th May 2010, 10:34

@ Keiyakusha - are you sure ? in MediaInfo I can see ratio (16:9) and even second one (3:2)
but odd, I tested many codecs like MPC-HC, DivX, CyberLink, ArcSoft, Elecard, Nero and only CoreAVC shows signs of this (as far I remember)

If its not CoreAVC bug than sorry...
And will be very nive when this feature will be also in CoreAVC

Yes they do.
No, they dont :p
At last on my side, like you can see on screenshots...

Keiyakusha

24th May 2010, 13:54

MediaInfo I can see ratio (16:9) and even second one (3:2)

I checked the stream itself, but if mediainfo shows that, it just confirms what I say. "Second one" is a stream level info. Since SAR is absent 720/480 = 3/2. And this is what used with gabest splitter. Normally you shouldn't see "original display aspect ratio" field. If stream meant to be anamorphic, it should be encoded as anamorphic - with appropriate SAR values.
Actually some workaround may be nice feature, I just say you shouldn't blame decoder for current behavior. Note that decoder by itself doesn't do scaling. This info forwarded to player. Isn't the splitter is the one, who should work with container-level info?

By the way. How it works with another splitters (other than haali and gabest)?

Abradoks

24th May 2010, 21:21

I just say you shouldn't blame decoder for current behavior.
Why not to blame decoder, if it overwrites correct dwPictAspectRatioX/Y values even when SAR information is not present in stream? Oh, and even if splitter workarounds this bug by writing biXPelsPerMeter/biYPelsPerMeter, CoreAVC will still change all these parameters to something weirdly calculated (like 7219/3072 and 2048/2625 instead of 1128/480 and 110/141).
BTW, divx decoder has an option to choose which AR to prefer, bitstream or container.

madshi

1st June 2010, 07:17

Since the first 3D Blu-Ray is out now, let me ask:

Do you plan to add support for 3D (h264 MVC) decoding?

asarian

4th June 2010, 01:29

I'm back to letting libavcodec (ffdshow) do the H264 decoding. First I got all sorts of nasty artifacts; and today the RipBot264 process froze up when using CoreAVC 2.0 (repeated attempts). It's unusable this way; sorry.

BetaBoy

4th June 2010, 07:12

asarian... Please provide more detail to what you are referring to when you say RipBot264 froze? You have a sample or profile details to what you encoded? Also, we have no reports of such issues.

asarian

4th June 2010, 13:34

asarian... Please provide more detail to what you are referring to when you say RipBot264 froze? You have a sample or profile details to what you encoded? Also, we have no reports of such issues.

Well, the RipBot264 process would freeze after a few seconds into the encoding (re-encoding a H264 anime to add subs). x264 itself would keep running, but the RipBot264 shell just stops responding, time and again (after killing everything and starting it up again). The moment I set ffdshow to let H264 decoding be handled by libavcodec again, RipBot264 kept running normally. And I have the latest ffdshow and haali media splitter.

My guess is, that it's CUDA related somehow. Not really sure how, as just running a preview avs script (which naturally also uses CoreAVC) seems to work just fine. After the current encoding job finishes, I'll do some more tests.

pankov

4th June 2010, 22:10

Betaboy,
are you intentionally ignoring my question/bug report?
It's kind of rude to answer other problems and skip mine 4 times ... and 3 PMs too
:(

Stockpile

7th June 2010, 09:24

Dan, has it fixed the 'crashing windows with explorer thumbnail integration' bug?Yes, that's fixed.

Not here tho. Perhaps it's because I'm on a 64-bit Vista.

EDIT: clsid's post below shows a similar registry entry to what I used to make Windows Explorer show try thumbnails on *.m2ts files.

clsid

7th June 2010, 11:51

If 'fixing' the thumbnail crash simply means removing Haali's shell extension, then it definitely has not been fixed. Thumbnails can be generated through Microsoft's shell extension as well. At least v2.0 still crashes with that afaik. Also when using a different splitter.

Here is an example of using MS shell extension:Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.flv\ShellEx\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}]
@="{c5a40261-cd64-4ccf-84cb-c394da41d590}"

Stockpile

7th June 2010, 11:57

I may also add that XnView crashes when trying to create thumbnails of videos decoded by CoreAVC, as well as Pinnacle Studio 12 keeps refreshing the browsing feature, in order to create thumbnails of the videos. Related to Xnview, I contacted them and Pierre said he might send me a test version to see where the problem (I hope we can find a reason to the crashes then).

Other than that, nice codec it's definitely worth the money in my opinion.

Mixer73

7th June 2010, 23:20

If 'fixing' the thumbnail crash simply means removing Haali's shell extension, then it definitely has not been fixed. Thumbnails can be generated through Microsoft's shell extension as well. At least v2.0 still crashes with that afaik. Also when using a different splitter.

This is reason enough alone I just refuse to have Haali splitter in my system, and remux all MKV back to MP4. Just a joke something so old can be around for so long.

Stockpile

8th June 2010, 08:57

After testing several XnView exes, Pierre could conclude from the XnView console window, that the crash was because of the codec crashing. I might be able to pull more information out of him, I just need to hear if that's needed then. =)

EDIT: XnView (and probably other software as well) uses IMediaDet::GetBitmapBits to get a frame from each video. Perhaps AVC CoreCodec doesn't support that?

goofee

14th June 2010, 11:22

Does a upgrade offer still exist from 1.9.5 to 2.0? I don't have any account on this new portal though, how do i proceed? I tried PM'ing betaboy and emailing support but no go. Any tips?

hajj_3

21st June 2010, 07:37

what kind of support will you be adding for VP8 if any?

BetaBoy

21st June 2010, 16:18

Betaboy,
are you intentionally ignoring my question/bug report?
:(
Not at all... I think we have addressed your report.

BetaBoy

21st June 2010, 16:21

If 'fixing' the thumbnail crash simply means removing Haali's shell extension, then it definitely has not been fixed. Thumbnails can be generated through Microsoft's shell extension as well. At least v2.0 still crashes with that afaik. Also when using a different splitter.

Here is an example of using MS shell extension:

We are looking into it some more. Thx for the report.

BetaBoy

21st June 2010, 16:42

what kind of support will you be adding for VP8 if any?

Not to get OT... but we are going to be releasing a CoreVP8 at a later date as an alternative directshow filter to the current WebM Project's filter.

On a related note... We have added WebM support into CorePlayer 2.0 as well as migrated to our official code for Matroska 2.0 via the 'core' parser library with the updated libMatroska2 and libEBML2.

But on deck atm is us releasing CoreAAC 2.0 as a directshow filter. We are in final QA for it now.

Keiyakusha

21st June 2010, 16:45

Did I miss something? CoreAAC2.0? Is it any faster than faad, ffmpeg? (I don't need any comparisons, your word it enough for me atm.)
Multichannel, LC, HE support all is there?
What about Cuda-based aac decoder? not possible/not worth the trouble?

BetaBoy

21st June 2010, 16:59

Did I miss something? CoreAAC2.0? Is it any faster than faad, ffmpeg? (I don't need any compartions, your word it enough for me atm.)
Multichannel, LC, HE support all is there?
What about Cuda-based aac decoder? not possible/not worth the trouble?
CoreAAC 2.0 is what we have been using in CorePlayer 1.x and is written by us from scratch compared to our open source 1.x version that was based on faad2. The initial directshow filter will support 32/64bit, 2 channel and SBR+PS = LC / Main Profiles (ie; LC-AAC, HE-AAC and HE-AAC v2).

CUDA is planned (yes its worth it) but we wanted to get the initial release out to fix any potential bugs before moving on. Is there is a performance improvement over FFmpeg? Simply put, yes... but like I have said for CoreAVC, that's for you all to tell us.

Additionally CoreAAC has many more options available for our OEM licensee's that also includes support for AAC features like: LOAS/LATM Container, ARM NEON support and like our other decoders, supports all modern operating systems and CPU's.

OT off.

Stockpile

21st June 2010, 20:21

Sounds good, perhaps worth to test out when I get the time. How advanced will the decoder be when it comes to user-controlled options?

Cyber-Mav

21st June 2010, 22:25

will coreaac be a replacement for ac3filter?

21st June 2010, 22:44

will coreaac be a replacement for ac3filter?

AAC is not AC-3 (Dolby Digital)

pankov

22nd June 2010, 16:47

Not at all... I think we have addressed your report.
What does this mean? That you've found the problem and you've already fixed it or that you don't see a problem and there is nothing you can do about it?
If it's the first, which I hope, when should I expect the fix?

me7

26th June 2010, 17:08

Guest

26th June 2010, 17:27

Seeking properly with open GOPs requires the decoder to go back an extra GOP. I don't know if CoreAVC has implemented that. Can you post a sample so that I can check if something else is going on?

me7

26th June 2010, 17:36

Sure: http://www.mediafire.com/?sharekey=811bbb2860d2a452e62ea590dc5e5dbb77213321e971ea7aea4ac78345cbe4ce
I was able to reproduce the error in that sample by seeking back and forth.

Guest

26th June 2010, 17:43

Thanks. Seeking is fine with that sample in DGDecNV, so it appears that CoreAVC did not implement the "back by one GOP" move when decoding open GOP streams (or did not do it correctly).

They could also skip leading B frames instead of using the "back by one GOP" move if accurate random access is not a requirement.

CruNcher

26th June 2010, 20:11

I think there is a problem with open-gop, committed to x264 a few days ago. Sometimes after seeking, the picture looks like this:

http://img685.imageshack.us/img685/9421/error1ju.png (http://img685.imageshack.us/i/error1ju.png/)

http://img34.imageshack.us/img34/2615/error2e.png (http://img34.imageshack.us/i/error2e.png/)

http://img404.imageshack.us/img404/737/error3y.png (http://img404.imageshack.us/i/error3y.png/)

Skipping a few seconds back and rewatching the same scene is fine though, seems to be related to seeking. Happens with and without CUDA.
Encoded with "--open-gop display".

Doesn't happen with DivX Demuxer and your sample, i guess it's more a Haali splitter issue.
Ok it does happen though it seems to be a very random problem, doesn't happen on every seek.
It definitely doesn't happen with DivX H.264 Decoder so indeed it seems to be as neuron2 said that Decoder issue :)

bob0r

30th June 2010, 11:51

LOL CoreAVC has this error for so long... (or in this case maybe haali) The same happens with BBC-HD. it always recovers and video is there to watch :p

ChronoCross

3rd July 2010, 04:24

I've pretty much given up on all CoreCodec projects.

CoreAVC was great when it came out, but with updates/bug fixes taking 7 or more months it becomes less and less competitive as open-sourced decoders performance are rapidly increasing with each passing week.

CorePlayer 2 has been worked on for over 2 years now with the initial forum announcement stating this in August 2009. Now at nearly a year since that post CorePlayer 2 is no closer to being available.

CoreASP - 2 or 3 years since it was announced. Treading on Duke Nukem Forever Territory.

CoreAAC - announced around a year ago, got it's forum placeholder yesterday which means it's 1-2 years away from release.

This may seem harsh but I've always been a stanch supporter of CoreCodec and it's been nothing but disappointment for awhile now and the last 20 pages of this thread is supporting evidence of that fact.

fenomeno83

5th July 2010, 22:24

ChronoCross

5th July 2010, 23:45

can you say what decoder that in your opinion works better than coreavc for h264?because I didn't find them

DivX, DiAVC, libavcodec are all contenders who either come close or surpass CoreAVC in common situations.

libavcodec has the most bugfixes for problematic streams. I haven't really tested multi-threaded as I have a single core machine.

Audionut

6th July 2010, 09:52

CoreAAC - announced around a year ago, got it's forum placeholder yesterday which means it's 1-2 years away from release.

Funny you say that.

Hello,

***** , we want to thank you for your past purchase of CoreAVC 2.0.0 .
Since you are a valued customer we are now offering you the ability to be one of the first to purchase the long awaited release of our CoreAAC Audio Decoder. The CoreAAC Directshow Plug-in for Windows Media Player is the culmination of over 2 years of work and fully supports AAC on any 32/64bit Windows OS.

We would like to pass on a $2.00 off discount code below ($5.95 purchase price). This discount code can be given to friends, family or maybe you just need CoreAAC 2.0 for another computer.

Discount code: *****
Purchase here: https://customers.corecodec.com/cart.php?a=add&pid=8

You can share and use the code above as many times as needed until August 30th, 2010.

Thank you.

Regards,

Dan Marlin
CEO/CoreCodec, Inc.
http://corecodec.com
http://twitter.com/corecodec

Lets hope that this is the start of many releases overdue.
I for one, am desperately waiting for coreplayer 2 for symbian.

BetaBoy

6th July 2010, 10:11

This may seem harsh but I've always been a stanch supporter of CoreCodec and it's been nothing but disappointment for awhile now and the last 20 pages of this thread is supporting evidence of that fact.

- We have been listening to the feedback here while we are working on DXVA support for CoreAVC 2.1, and have been reviewing the feedback/bug reports being posted.... we may not respond here to every D9 post but we do read what is being said and thank those for all the great feedback.

- While that is going on we just released CoreAAC 2.0 tonight, see: http://forum.corecodec.com/viewtopic.php?f=30&t=3908&p=14872#p14872

- CoreASP 2.0 is under 'reconstruction' as we felt it was best to rework the code some more (since its like 3 codec code bases in one... and I am sure of you code junkies know what I mean about ASP)... this also includes ARM NEON (for our SDK Licensees).

- CorePlayer 2.0 is still a work in progress, but we are getting closer everyday now with just a few bullet points to go before we release it... including Android.

BetaBoy

6th July 2010, 10:24

LOL CoreAVC has this error for so long... (or in this case maybe haali) The same happens with BBC-HD. it always recovers and video is there to watch :p
Is this really an error? filters are not meant to seek backwards, as they only decode what they're given.

To be more precise... As far as "back by one GOP".... we can't "go back by one GOP" because the filter can't seek, it just receives data... ie; it shouldn't be showing frames until it is sure they're not incomplete.

Audionut

6th July 2010, 10:46

- While that is going on we just released CoreAAC 2.0 tonight.

We have officially launched CoreAAC 2.0 for you to purchase

http://forum.corecodec.com/viewtopic.php?f=30&t=3908

ChronoCross

7th July 2010, 02:46

Funny you say that.

Lets hope that this is the start of many releases overdue.
I for one, am desperately waiting for coreplayer 2 for symbian.

Indeed, pretty funny indeed. I've been waiting for CorePlayer 2 for Windows and Linux for quite some time now.

- We have been listening to the feedback here while we are working on DXVA support for CoreAVC 2.1, and have been reviewing the feedback/bug reports being posted.... we may not respond here to every D9 post but we do read what is being said and thank those for all the great feedback.

Just do a quarterly release for product updates. You don't even have to respond on any forums. All any of us care about is results, but 6-12 month release cycles don't exactly inspire confidence.

- While that is going on we just released CoreAAC 2.0 tonight, see: http://forum.corecodec.com/viewtopic.php?f=30&t=3908&p=14872#p14872

Interesting timing.

- CoreASP 2.0 is under 'reconstruction' as we felt it was best to rework the code some more (since its like 3 codec code bases in one... and I am sure of you code junkies know what I mean about ASP)... this also includes ARM NEON (for our SDK Licensees).

Duke Nukem Forever has been redeveloped 3 or 4 times. I got a good laugh when I read this one. Thanks.

- CorePlayer 2.0 is still a work in progress, but we are getting closer everyday now with just a few bullet points to go before we release it... including Android.

Non-vague release date?

madshi

7th July 2010, 09:23

@BetaBoy, two questions:

(1) Will CoreAVC get support for h264 MVC (3D) decoding?
(2) Will CoreAVC get support for h264 High 10 Profile (10bit) decoding?

Thanks!

BetaBoy

7th July 2010, 12:35

CC..... Is D9 the reason you state we 'don't reply'? We do our best to reply although your not likely going to see a reply on every forum to every post.... But we do our best.

CorePlayer on Linux is a challenge for distributions as many of you may know. Many of our OEM customers have been using it on Linux for years now... But this is a controlled distribution and much easier for us to manage. We have discussed a public release for a while.... Let's see what we can do about it in CP2.

Madshi.... No that is CoreMVC... And something you'll likely see later this year. On 10bit.... It's been discussed and once we get past DXVA, we will go there.

madshi

7th July 2010, 15:09

Madshi.... No that is CoreMVC... And something you'll likely see later this year. On 10bit.... It's been discussed and once we get past DXVA, we will go there.
Good to hear, thanks. For 10bit, which FOURCC are you planning to use? If I may suggest, the FOURCC values on this page seem like good choices:

http://msdn.microsoft.com/en-us/library/bb970578%28VS.85%29.aspx#fourcc_codes

There are also FOURCC values for 4:2:2 and 4:4:4 listed there, in case you plan to support native 4:2:2 and 4:4:4 h264 streams, too. In any case it would be great, if you could offer an option with which your decoder always outputs the *native* format without any conversion. So basically for 8bit 4:2:0 you would use YV12 or NV12, for 10bit 4:2:0 you would switch to FOURCC P010, and for 10bit 4:2:2 you would automatically use P210 etc. That would be the ideal solution.

ChronoCross

7th July 2010, 17:19

CC..... Is D9 the reason you state we 'don't reply'? We do our best to reply although your not likely going to see a reply on every forum to every post.... But we do our best.

As I stated in my last reply I could care less about replies on any forum.....I'm more concerned when it takes six months to a year for any bugfixes on a product. I simply used doom9's 20-40 pages of bug/product discussion since your last release as an example of why you should release bugfix versions more often.

BetaBoy

7th July 2010, 23:28

As I stated in my last reply I could care less about replies on any forum.....I'm more concerned when it takes six months to a year for any bugfixes on a product. I simply used doom9's 20-40 pages of bug/product discussion since your last release as an example of why you should release bugfix versions more often.

What bugs are outstanding in CoreAVC 2.0 in the last 20-40 pages that we have not addressed??? If anything was a show stopper we would have released a new version, but as I've stated we have taken this time to concentrate on the 5+ flavors of DXVA 1/2 done as it is no small undertaking, and is one of the major features we wanted to get into it now before we move that code over to working on adding higher AVC profile support and then MVC.

BetaBoy

7th July 2010, 23:37

Good to hear, thanks. For 10bit, which FOURCC are you planning to use? If I may suggest, the FOURCC values on this page seem like good choices:

http://msdn.microsoft.com/en-us/library/bb970578%28VS.85%29.aspx#fourcc_codes

There are also FOURCC values for 4:2:2 and 4:4:4 listed there, in case you plan to support native 4:2:2 and 4:4:4 h264 streams, too. In any case it would be great, if you could offer an option with which your decoder always outputs the *native* format without any conversion. So basically for 8bit 4:2:0 you would use YV12 or NV12, for 10bit 4:2:0 you would switch to FOURCC P010, and for 10bit 4:2:2 you would automatically use P210 etc. That would be the ideal solution.

Noted... Thx for the input.

ChronoCross

8th July 2010, 00:36

What bugs are outstanding in CoreAVC 2.0 in the last 20-40 pages that we have not addressed??? If anything was a show stopper we would have released a new version, but as I've stated we have taken this time to concentrate on the 5+ flavors of DXVA 1/2 done as it is no small undertaking, and is one of the major features we wanted to get into it now before we move that code over to working on adding higher AVC profile support and then MVC.

I wonder if you would say this to one of your corporate clients if they were complaining about these "non-showstoppers".

Anyway I'm tired of trying to convince you that you shouldn't release only major revisions once a year and that smaller minor bug fix releases would be helpful to customer satisfaction.

I've decided as a result of your reply to never purchase or recommend your products to anyone ever again. I know you won't find losing a single persons business all that harmful but oh well.

BetaBoy

8th July 2010, 03:10

and answering with a statement rather then answering what bugs we have not addressed and or replied too helps who? As far as releases... We think we have been good in the quality of the last few 1.9.x and 2.0 releases and making them as bug free as possible. I attribute that to 1) Our devs doing QA, 2) The amazing job the beta test group does 3) Sites like here at D9 and, 4) The feedback we get from our OEM customers... and to that... you are right, if there were any major bugs in 2.0 as it stands right now we would be aware of it, and we are not.