CoreCodec/H.264 Codec "CoreAVC"

[BetaBoy]

CoreCodec is proud to present CoreAVC our AVC/H.264 decoder that had originally been created for the CorePlayer Platform( see: www.coreplayer.com ) but because of early testing we found that it was the most 'processor efficient' H.264 decoder available and decided to port it to the directshow framework. We are now adding it to our CoreCodec Suite of directshow codecs and are making it our flagship codec for Consumers and third party licensees.

More info here: http://www.coreavc.com .

Here are the CoreAVC Decoder 'Editions':

CoreAVC™ Standard Edition Decoder
As of 1.9.5 it is now 'End of Life' and not sold any longer.


CoreAVC™ Professional Edition Decoder
- H.264 Baseline, Main, High profile support
- Interlaced support (PAFF and MBAFF)
- Lossless 4:2:0 support
- SMP (multi-core CPU) support (limit 4)
- GPU support (NVIDIA CUDA)


Q: What NVIDIA CUDA enabled hardware is supported by CoreAVC Professional?
A: NVIDIA GeForce GTX 260/280, 9800, 9600, 9500, 8800 GT, 8700, 8600, 8500, 8400, Tesla S1070/C1060, Quadro FX 3700, Quadro FX 3600M, Quadro FX 1700/FX 570/ NVS 320M/FX 1600M/FX 570M/FX 370/NVS 290/NVS 140M/NVS 135M/FX 360M/NVS 130M and higher.

----

CoreCodec / CoreAVC H.264 Decoder Configuration Properties Guide *** UPDATED FOR v1.9.5 ***

Input Formats
This setting controls which DirectShow Media Types the decoder accepts on input. Uncheck only if you are troubleshooting problems with CoreAVC incorrectly decoding some variant of H.264, or want to use another decoder for it.
avc1 / AVC1 - Accept streams with avc1 / AVC1 FourCCs.
h264 / H264 - Accept streams with h264 / H264 FourCCs.
x264 / X264 - Accept streams with x264 / X264 FourCCs.
VSSH - Accept streams with VSSH FourCC.
Mainconcept H.264 - Accept H.264 streams from the Mainconcept splitter.
ArcSoft H.264 - Accept H.264 streams from the ArcSoft splitter.

Output Formats
This setting determines the preferred output color space. The decoder tries each enabled format in order from top to bottom until it is accepted by the Video Renderer filter.
- YV12: YUV 4:2:0 planar format.
- I420: YUV 4:2:0 planar format with chroma planes in reverse order.
- NV12: YUV 4:2:0 with interleaved chroma samples.
- YUY2: YUV 4:2:2 packed format.
- UYVY: YUV 4:2:2 packed format with different sample ordering.
- RGB24: 8 bits per channel RGB format.
- RGB32: 8 bits per channel RGB format with an extra padding byte.
- RGB16: RGB format with 6 bits per green sample and 5 bits each for red and blue samples.
- RGB15: 5 bits per channel RGB format.
- Up Arrow: Increases the priority of the selected format by moving it towards to the top.
- Down Arrow: Decreases the priority of the selected format by moving it towards the bottom.

Input Levels
- TV (16-235) - always assume the stream uses TV levels.
- PC (0-255) - always assume the stream uses PC levels.
- Auto detect - use the full range flag in the stream to determine Luminance range.
- Output levels, this also affects conversion to RGB color space when it is done by the decoder.

Output levels
- TV (16-235) - assume the Video Renderer expects TV levels.
- PC (0-255) - assume the Video Renderer expects PC levels.
- Auto detect - use PC levels when VMR is used as a Video Renderer, and TV levels for all others.

Input Colorspace
BT.601 - use BT.601 colorspace coefficients when converting to RGB.
BT.709 - use BT.709 colorspace coefficients when converting to RGB.
Auto detect - use the colormatrix flag in the stream to determine the colorspace coefficients.

Deinterlacing
This setting specifies how interlaced material is handled by the decoder.

- None (Weave) - Each output frame contains two fields, flagged as progressive.
- Single Field - Each output frame contains one field. Only one frame is produced for each field pair.
- Bob - Each output frame contains one field. Two frames are produced for each field pair.
- Hardware - Each output frame contains two fields, flagged as interlaced to allow the video renderer to perform deinterlacing.

Deblocking
This setting controls how the deblocking step of H.264 specification is executed by the decoder. Deblocking is a complex process that consumes significant processing resources. If your machine is not fast enough, you might want to turn off deblocking for some frames, but it will degrade visual quality.

- Standard deblocking - do deblocking exactly as specified by H.264.
- Skip when safe - skip deblocking step when decoding B-frames.
- Skip always - does not perform any deblocking.

Aggressive deinterlacing
This option determines how the decoder detects interlacing in source stream.

- Off: use only picture timing SEI and POC numbers to detect interlaced video. Unfortunately not all encoders properly flag material as interlaced.
- On: in addition to SEI and POC, assumes source is interlaced if any interlaced coding tools are used in encoding the frame (MBAFF, PAFF).

Crop 1088 to 1080
H.264 encoded video size is always a multiple of 16, and sequences that are 1080 pixels high are encoded as 1088 padded at the bottom. Also H.264 specifications provides a set of cropping parameters to signal that parts of the encoded picture are not important and should not be displayed. Some H.264 encoders fail to specify cropping parameters when encoding 1080 video.

- Off: do not crop video.
- On: when input video is exactly 1088 pixels high, crop 8 pixels off the bottom.

Force VMR AR correction
This option can be used if you are working with the decoder outside the normal player environment.

- Off: does not change VMR settings.
- On: instructs VMR filter to maintain aspect ratio of the video that it displays. Normally this AR correction is the responsibility of a video player. This option should normally be off.

Preferred Decoder
Overrides any AVC directshow decoders, and uses CoreAVC instead.
- Off: does not change system merit.
- On: enables the highest merit on the PC. This option is recommended to be on.

Use Tray Icon
This option determines if an icon will be shown in the system tray when the decoder is in use. The tray icon can be used to access the configuration settings while media is playing. Changes to this option may not take effect until playback is restarted.

- Off: does not show the tray icon.
- On: enables the tray icon while media is playing.

Prefer CUDA acceleration
If this option is on the decoder will attempt to accelerate H.264 decoding by utilising your graphics card. This option is only available if you have a NVIDIA CUDA compatible video card and driver installed. Not all streams can be decoded using hardware acceleration. Changes to this option may not take effect until playback is restarted.

- Off: do not attempt to use CUDA video decoding.
- On: use CUDA video decoding if the current input video is compatible.

CUDA Tray Icon States
When both the 'Use tray Icon' and 'Prefer CUDA acceleration' options are enabled, the tray icon will show the current state if CUDA being used or not.

- Blue: CUDA not in use.
- Green: CUDA in use.

Picture Levels
Picture level slider adjustments can be made in ‘real time’ so you see the effects of the changes as you make them. Once the adjustments are made, ensure that you press ‘Apply’ to save changes or they will be lost.

- Brightness: Adjusts the overall brightness level.
- Contrast: Adjusts the difference between light and dark areas.
- Saturation: Adjusts the vibrancy of colours.
- Restore Defaults: Reset all picture level adjustments. It is not necessary to click Apply after this option.


OEM Licensing
OEM/ODM/Third party developers looking to license or evaluate the CoreAVC SDK for iPhone/Touch, Android, CE, CE Embedded, Windows Mobile, Windows, OS X, Linux, and DSP's can contact me dmarlin@corecodec.com or our OEM Licensing Department at licensing@corecodec.com for pricing, SDK, Promotional and or reference material.

[Sirber]

Sweet!

What is it's speed compared to FFMPEG?

[BetaBoy]

Sirber... from my tests... 75% faster... but this is on my PPC and Palm... Windows, well... read the thread... its a great start... and we have very big plans for CoreAVC.

[Sirber]

at 320x240@12FPS, I can barely decode it on my 400MHz xScale using FFMPEG. I will test this ASAP

[BetaBoy]

You'll probally need some specifically encoded AVC files to test properly.. Picard added 8x8 transform on Friday and b-frames (consecutive b-frames, b-frames referencing...) should work in theory, but he noted there are some bugs left.

Devel will slow on this as we are working on Skins and Symbian for TCPMP at the moment... and are preping for CES (we have 30+ companies demo'ing TCPMP).

[DarkZell666]

Wow, that is definitely a good news !

Been waiting for that for quite a long time now, nice to hear of such an initiative !

Keep up the good work

[BetaBoy]

I just spoke to the Devels 'CoreAVC' is officially born.... next is the 'CoreAVC Encoder'

[Sirber]

Encoder for pocket pc?

[BetaBoy]

Sirber.... no a full blown 'CoreAVC H.264 Encoder'... there is plan with a few of our devels... one envolves our Dr Doom Media Encoder aka DDME. But some of the devels have noted that they did not want another encoder 'program'... we may just adopt Dr DivX 2.0 and mod it to our needs...

[Kostarum Rex Persia]

Great news, BetaBoy.

About encoding quality, anything to say, perhaps, or it's too early, yet.

[BetaBoy]

Kostarum Rex Persia... yeah way too early... its on the roadmap but you are looking at Late Feb. early March at the earliest when I bring on about 6 more paid developers @ CoreCodec to help.

[Kostarum Rex Persia]

Your plans for that AVC encoder, include what. All new stuff that x264 codec have?

[BetaBoy]

to be honest Kostarum Rex Persia..... We plan on a full blown feature rich and licensable encode and decoder for CoreAVC @ CoreCodec @ http://www.coreavc.com

BTW... we just added CABAC - http://picard.exceed.hu/tcpmp/test/

[Sharktooth]

wow, that was fast
are you going to implement the full specs (all profiles and levels)? and why is it closed source?

[BetaBoy]

Sharktooth... its to be determined still on if we keep it closed source or not. Reasoning is this... with TCPMP we have had 'alleged' thefts of our GPL source code and decoders that are in third party hardware/software. We have worked hard over the past three years to get were we are at now with CoreCodec/TCPMP and are going to take baby steps in protecting ANY of our projects IP.

Why invest our time to get our source code ripped off and that those doing the ripping do not comply with the GPL when we release it that way? Pretty sad since we also state that we own 100% of the code as well and offer a closed source alternative license to it, and they still OPT to steal it.

So with that being said... we are taking the cautious steps first with CoreAVC and yes, we have larger plans with our encoder like you had asked... we do plan on supporting ALL profiles and levels.

Now to get bond a directshow filter.... ;-)

[Sharktooth]

I understand your point. It's not the first time and it's not an isolated case.
However closing the source will help protecting from code stealing but will potentially kill the codec development at some time in its existence.

[BetaBoy]

Well... for the most part yeah. Killing devel in it will not happen as we at CoreCodec are hiring about a dozen plus developers over the next few weeks to work on the various projects we have going on. Including:
- TCPMP
- CoreAVC, CoreMP4, CoreAAC (new version)
- CoreTheque
- Websites

But we can protect what we have... and when the unfortunate few that have chosen to steal the GPL code have been announced they will wish they had not gone the route that they did not only from a community perspective. But as the actual products they sell suffer from the theft as well... I leave the rest to the lawyers.

[ShAQ]

Hi BetaBoy.

Thanks for sharing this with us. I will take a closer look at the codec when I have a little bit more freetime. Feedback will come - soon oder later.

[guada 2]

@BetaBoy

I have a problem.
Look at this:

" ActiveSync not found in this computer. Setup cannot continue and will now exit ".

An idea please.

[BetaBoy]

guada 2... your running the windows TCPMP?

if not LMK...