CoreCodec/H.264 Codec "CoreAVC"

[rica]

Aren't CoreAVC and CoreMVC two different products, with the latter still to be released (as a standalone product)? :confused:

http://forum.doom9.org/showpost.php?p=1535817&postcount=6889

Please checkout changelog:

http://corecodec.com/products/coreavc/changelog

- ADD: Support for MVC 3D videos

[Keiyakusha]

Please checkout changelog:

http://corecodec.com/products/coreavc/changelog

I only see "SDK: Initial support for MVC (CoreMVC) integration" which means you're not getting MVC in CoreAVC.
"ADD" is just for haali splitter. So after all you can't watch MVC with CoreAVC

[LoRd_MuldeR]

I only see "SDK: Initial support for MVC (CoreMVC) integration"

Yup. It means that they have added MVC support to their SDK (Software Development Kit), which other companies can license for their own products.

Still "CoreAVC" and "CoreMVC" are two separate stand-alone products. And only the latter will support MVC.

Also the MVC support that has been added to Haali's Splitter means that you will be able to use Haali's Splitter in conjunction with CoreMVC, once the latter is released. Nothing more.

(Please correct me if I'm wrong...)

[rica]

I only see "SDK: Initial support for MVC (CoreMVC) integration" which means you're not getting MVC in CoreAVC.
"ADD" is just for haali splitter. So after all you can't watch MVC with CoreAVC

I understand with "add", you can watch MVC with Haali?

[Keiyakusha]

I understand with "add", you can watch MVC with Haali?
Well in theory yes, but of course if you also have MVC decoder that can work with it. I don't have such decoders so have no idea if haali really works as advertised.
EDIT: oh, BTW, I was just told that MVC stream is backward compatible with AVC so someone probably tried that already and can tell better if haali really works

[rica]

Then i spend money for nothing.

[madshi]

Well, I think it was pretty clear that CoreMVC would be a separate product. You gotta inform yourself before making a purchase... ;)

[rica]

Well, I think it was pretty clear that CoreMVC would be a separate product. You gotta inform yourself before making a purchase... ;)

I'm lucky; at least the cost of purchasing unless informed was just 12 USD :o

[BetaBoy]

Rica... PM me ill issue you a refund.

As stated CoreMVC is a separate product, but at its core it uses CoreAVC. Technically we already addd support for Haali's splitter for MVC streams with the 3.0 release but we are adding support for the MS directshow MVC spec before we release CoreMVC.

[rica]

Rica... PM me ill issue you a refund.

As stated CoreMVC is a separate product, but at its core it uses CoreAVC. Technically we already addd support for Haali's splitter for MVC streams with the 3.0 release but we are adding support for the MS directshow MVC spec before we release CoreMVC.

Thanks a lot betaboy but this is my fault and i don't need any refund. And i'm happy with my new toy :)

But i wouldn't object to any discount ticket when you released Core MVC :)

[n3w813]

The 520 is too slow for anything. It can't even properly do full quality deinterlacing, be it with EVR or anything else.

I have a GT520 and it can decode 1080p60 Blurays without issues with Lav Video w/CUVID and MadVR. :) I've never tried interlaced content though. :p

[Thunderbolt8]

how many 1080p60 BDs are actually out there?

[nevcairiel]

how many 1080p60 BDs are actually out there?

None, its not a valid format for Blu-ray.
You can get 1080i60 or 720p60, but not 1080p60.

[kirakami]

i have CoreAVC 3.0.1 installed
Can CoreAVC alone Output P010 without using madVR??? have anyone tried.
i m using MPC-HC.

[XRyche]

i have CoreAVC 3.0.1 installed
Can CoreAVC alone Output P010 without using madVR??? have anyone tried.
i m using MPC-HC.

CoreAVC 3.01 can handle P010 but......MadVR is the only renderer that can output P010 atm. If you use haali, any flavor EVR, Overlay, any flavor VMR, etc.... it outputs in 8 bit format. To my understanding (which admittedly is very limited) it all gets displayed on your monitor as 8 bit anyways (dithered or not). I could be wrong though so if someone more knowledgeable could set me straight I'd appreciate it.
Oh MPC-HC tester builds for internal renderer fixes http://forum.doom9.org/showthread.php?t=161047
can surface display 32 bit but it uses shaders to do this and can be very unstable. That said, personally I like it.

[sneaker_ger]

MadVR is the only renderer that can output P010 atm.

IIRC, though madVR accepts P010 input, it can not output 10 bit.

[XRyche]

IIRC, though madVR accepts P010 input, it can not output 10 bit.

It does output 10 bit on the surface but your monitor can't.

[sneaker_ger]

Those are only for its internal processing, I think. Final output is always dithered down to 8 bit max.

[pankov]

It does output 10 bit on the surface but your monitor can't.
I think you are wrong.
madVR always outputs 8bit. When it get's 10bit input it dithers it down to 8bit

[madshi]

AFAIK madVR is the only renderer which *accepts* P010 (unless JanWillems has changed VMR/EVR accordingly). The whole madVR processing chain is 16bit+, so full use of P010 is made. However, final output is currently always dithered down to 8bit, but the dithering makes sure that most of the high bitdepth information is still intact, so the 8bit output is not really a problem. 10bit output is eventually planned for a future version. FWIW, the best solution for image quality is to have the dithering done as the last step in the processing chain. So having madVR do it is better than to have CoreAVC do it.

[SEt]

CoreAVC works just fine with P010 and P016 without MadVR - for example with my renderer (it's private one). So, I think there is no problems in CoreAVC's implementation if that is what you are concerned about.
But if you want P010 for "higher quality" with MPC-HC - don't bother, you won't see the difference between decent renderer fed with 8 and 10 bit data.

[XRyche]

Well...I'm glad that I put that qualifier to my answer. Thanks for setting me straight madshi and company :) .

[LoRd_MuldeR]

Rule #6 post and follow-up's have been removed. Discussion about "pirated" software is not allowed.

[Thunderbolt8]

does coreavc actually use frame-based multi-threading? or only multi-threading based on slices?

if frame-based multi-threading, is there any limitation regarding the number of threads which can be used for decoding?

[LoRd_MuldeR]

CoreAVC does not need slices in the H.264 stream to do multi-threaded decoding:
http://img832.imageshack.us/img832/9826/coreavcperf.png

(It scales up to at least 4 threads, as you can see. I don't have a machine with even more cores)

[kirakami]

Which Nvidia Graphic cards can actually output P010/P016?
Are there even monitor's available yet that can show
10-bit color space without dithering to 8-bit?
Not dithered to 8-bit by monitor before hit the display
even if card can output 10-bit

[Paladin77]

I enjoyed this product. Although I did switch to better free alternatives which provide better performance especially with my 10 bit anime titles. Still it does a great job!

As for 10 bit dithering. So far madVR is unmatched due to what madshi explained. Dithering occurs at final step of processing.

[The Seeker]

Is there a list somewhere detailing CoreAVC's supported ATI GPUs?

Edit: Never mind, mine is supported.

[06_taro]

The latest mmg recognizes ttf font as "application/x-font-ttf" as default MIME type.
Haali(v1.11.288.0) fails to load this type of embedded font, it only load "application/x-truetype-font" fonts, which are detected as default MIME type in old versions of mmg.
Other splitter like LAV/AV/Gabest (All latest, older versions like Gabest before svn r3802 are not included) can load "application/x-font-ttf" fonts.

Forgive me if Haali's issues are not supposed to be here.

[cyberbeing]

The latest mmg recognizes ttf font as "application/x-font-ttf" as default MIME type.
Haali(v1.11.288.0) fails to load this type of embedded font, it only load "application/x-truetype-font" fonts, which are detected as default MIME type in old versions of mmg.
In mmg 5.1.0, OTF fonts are now identified as application/vnd.ms-opentype instead of application/x-truetype-font as well, so I'd assume they are also affected?

[benus]

It seems that the new version of CoreAVC is gonna be released on Monday:

http://twitter.com/corecodec

[LoRd_MuldeR]

It says that the work on finalizing v3.1 begins on Monday. Not that this work will be completed on Monday...

[BetaBoy]

On Monday we will begin working on putting together the various projects we have been working on for CoreAVC 3.1.

[cyberbeing]

Will an updated Haali Splitter which fixes the unsupported MIME type font loading issues be included with v3.1 or sometime after?

[madshi]

Bug report:

It seems that CoreAVC does not set the "IMediaSample2::GetProperties" flag "AM_VIDEO_FLAG_REPEAT_FIELD". This is an important piece of information which is needed to reliably detect a 3:2 pulldown pattern for IVTC algorithms. Without this flag, soft-telecined content will look like 2:2 while hard-telecined content will look like 3:2.

[wanezhiling]

Here's a sample (http://uploadingit.com/file/bvjftldv095pahat/no%20dxva.avi), cuda ok, but dxva failed...


Another sample (http://uploadingit.com/file/erzothack7ksfyk3/1%20(1)-001%20(1)-001%20(1)-001.mkv):there's lots of skipped frame with dxva or cuda mode...

[vivan]

This site is down.
http://2.firepic.org/2/images/2011-12/11/rhmeo1mqltdm.png
UPD: now it's up, but it says that file not found. And that their service is broken.

[BetaBoy]

Madshi.... can you supply an example for us to look at?

[madshi]

Sure, try this one:

http://madshi.net/repeatFirstField.evo

If you look at the h264 bitstream, you'll find the following pic_struct variations:

3: top field, bottom field
4: bottom field, top field
5: top field, bottom field, top field
6: bottom field, top field, bottom field

For these pic_struct variations, CoreAVC should output the following flags via IMediaSample2.Get/SetProperties:

3: AM_VIDEO_FLAG_FIELD1FIRST
4: 0
5: AM_VIDEO_FLAG_REPEAT_FIELD | AM_VIDEO_FLAG_FIELD1FIRST
6: AM_VIDEO_FLAG_REPEAT_FIELD

Thanks!

[wanezhiling]

This site is down.
http://2.firepic.org/2/images/2011-12/11/rhmeo1mqltdm.png
UPD: now it's up, but it says that file not found. And that their service is broken.

cuda ok, but dxva failed (http://www.mediafire.com/?4yk1pi21wd0tbuv)...

lots of skipped frame with dxva or cuda mode... (http://www.mediafire.com/?wykw88vi5p8nqi5)

[BetaBoy]

madshi... can you explain this a little more. If "hard telecine" is used there are no flags in the source so we have no idea what to set, and for "soft telecine" streams coreavc ignores the flags so the original rate is used.

[madshi]

madshi... can you explain this a little more. If "hard telecine" is used there are no flags in the source so we have no idea what to set, and for "soft telecine" streams coreavc ignores the flags so the original rate is used.
There's nothing you can do about hard telecine. But for soft telecine you should pass the flags downstream. You don't need to do anything with the flags yourself, just set them in the properties of the IMediaSample2 you output. That's really all you need to do, should be very easy to do, and there should be no negative side effects at all.

You may wonder why this might be useful. After all if you simply ignore soft-telecine, we get perfect progressive output, right? Well, that's true for HD DVD and Blu-Ray. But some countries are now broadcasting in h264, and we can't expect the broadcast to always stick to soft-telecine. The broadcasts might switch between soft-telecine and hard-telecine in the middle of the stream. I don't have a sample for that, but it happens very often with MPEG2 broadcasts (plenty of samples for that) so I would expect this to eventually happen with h264 broadcasts, too. In order to properly IVTC such streams, it is very useful to know which frames are hard-telecined and which are soft-telecined and how they are soft-telecined. That's why it would be useful if CoreAVC could pass the soft-telecine flags downstream.

I'm working on an IVTC algorithm for madVR, and it's working pretty well for MPEG2 broadcasts, even if there are mixed hard-telecined and soft-telecined sections, as long as the MPEG2 decoder outputs the proper soft-telecine flags. So this is why I'm now asking you for this, too, just to make sure that IVTC will work well for h264 broadcasts with mixed hard-telecined and soft-telecined frames, too.

[mp3dom]

Well, that's true for HD DVD and Blu-Ray. But some countries are now broadcasting in h264, and we can't expect the broadcast to always stick to soft-telecine.

It happens with Bluray too... especially on trailers that are edited at 60i for 'broadcast' purpose but gets a mixture of hard and soft pulldown encode while on disk.

[madshi]

It happens with Bluray too... especially on trailers that are edited at 60i for 'broadcast' purpose but gets a mixture of hard and soft pulldown encode while on disk.
Didn't know that. Do you happen to have a sample?

[mp3dom]

I don't have a sample here with me but it can be created. A lot of bd encoders have a built-in IVTC so they can encode both soft and hard pulldown (soft when they catch the pattern and hard when they're unable to detect it).
It can happens with 1080i contents but also with 480i (always referred to AVC encode)

[madshi]

Would it be easy for you to create such a sample? It would be quite useful for testing purposes. If you can do this, maybe you can pick a sample with a lot of movement in it, so that it's easy to see whether IVTC succeeded or not?

[mp3dom]

Here: http://www.mediafire.com/?s9wr6ljdrl3ew9a
Both 1080i60 and 480i60 (don't know if there are flag differences).
There are 2 segments in each file, first segment is hard pulldown, second is soft.

[madshi]

Here: http://www.mediafire.com/?s9wr6ljdrl3ew9a
Both 1080i60 and 480i60 (don't know if there are flag differences).
There are 2 segments in each file, first segment is hard pulldown, second is soft.
Thank you!! :)

I can confirm that with these test samples, my (work-in-progress) IVTC algorithm reliably detects a 3:2 cadence in the hard-telecine section with both CoreAVC and LAV Video Decoder. When the soft-telecine section begins, with CoreAVC my IVTC algorithm detects a cadence break and detects a new 2:2 cadence for the 2nd half of the samples. When using the LAV Video Decoder, the cadence stays unbroken at 3:2 for the full runtime of both samples, because LAV Video Decoder forwards the soft-telecine flags to madVR. The SD and HD samples behave identically.

[mp3dom]

Glad it helps :) The samples are bd-compliant, so it's the way an hypothetical bluray could look.

[kieranrk]

I don't have a sample for that, but it happens very often with MPEG2 broadcasts (plenty of samples for that) so I would expect this to eventually happen with h264 broadcasts, too. In order to properly IVTC such streams, it is very useful to know which frames are hard-telecined and which are soft-telecined and how they are soft-telecined. That's why it would be useful if CoreAVC could pass the soft-telecine flags downstream.


Generally speaking, you don't set your encoders to do pulldown detection if you're sending captions because it has bad hardware support. This applies to AVC broadcasts as well so I think this issue will be quite rare.