Log in

View Full Version : CoreCodec/H.264 Codec "CoreAVC"


Pages : [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144

BetaBoy
18th December 2005, 23:14
CoreAVC is known in the industry as being the standard for playback of high quality H.264 video. CoreAVC allows you to directly offload video decoding with either NVIDIA CUDA. ATI with Microsoft's DirectX Video Acceleration (DXVA) interface for any Windows XP, Vista, or Windows 7 PC.

More info here: http://corecodec.com/products/coreavc .

CoreAVC™ 3.0.x Professional Edition Decoder
* Supports Windows 7
* 32/64 bit support
* 8/9/10 bit support
* DXVA 1/2 Compatible
* NVIDIA CUDA GPU support
* NVIDIA DXVA GPU support
* ATI GPU support (DXVA)
* Intel Media SDK support
* ARM NEON support
* Netlogic/RMI MAE GPU support
* Supports unlimited CPU Cores
* 8100x8100 Resolution support
* Low Latency support
* Uses Directshow for MKV
* Includes the Haali Media Splitter
* Full Interlaced support

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

----

CoreCodec / CoreAVC H.264 Decoder
Configuration Properties Guide
*** UPDATED FOR v3.0 ***


INPUT FORMATS
This controls which DirectShow Media Types the CoreAVC video decoder accepts on input. Uncheck this 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 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.

9/10 Bit (checkbox) - check to enable

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.
RGB32 - 8 bits per channel RGB format with an extra padding byte.
RGB24 - 8 bits per channel RGB format.
RGB16 (565) - RGB format with 6 bits per green sample and 5 bits each for red and blue samples.
RGB15 (555) - 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
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 specifies how interlaced material is handled by the CoreAVC 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.
Aggressive - in addition to SEI messages and POC numbers, assume the source is interlaced if any interlaced coding tools are used (MBAFF, PAFF)

DEBLOCKING
This controls how the deblocking step of H.264 specification is executed by the CoreAVC 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. This setting has no effect when hardware acceleration is in use.

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.

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.

Not Checked - do not crop video.
Checked - when input video is exactly 1088 pixels high, crop 8 pixels off the bottom.

PREFERRED DECODER
Overrides any other AVC directshow video decoders, and uses CoreAVC instead.
Not checked - does not change system merit.
Checked - enables the highest merit on the PC. This option is recommended to be on.

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

Not checked - does not change VMR settings.
Checked - 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.

USE TRAY ICON
This determines if an icon will be shown in the system tray when the CoreAVC 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 the means for playback is restarted or the computer itself is restarted.

Not checked - does not show the tray icon.
Checked - enables the tray icon while media is playing.

LOW LATENCY
This causes frames to be decoded synchronously, reducing the time between when a compressed frame is received and when the corresponding decoded frame is output.

Not checked - use asynchronous decoding, improves CPU utilization.
Checked - use synchronous decoding, less than optimal CPU utilization.

Low Latency Technical: When a stream is properly muxed into a MP4 format, it has the advantage of storing the NALU lengths at the beginning of each frame. When the Byte stream format is used instead, the size of the NALU can only be determined when the next startcode is seen, this adds one frame of latency, plus the existing one frame delay.

Additionally you will need to use FORMAT_MPEG2Video for the input connection format type, with dwFlags set to the length of the size field (commonly 2 or 4 bytes) and the sps and pps NALUs should be passed in dwSequenceHeader. Also note that you should not use MEDIASUBTYPE_MAINCONECPT_H264 ({0x8D2D71CB, 0x243F, 0x45E3, 0xB2, 0xD8, 0x5F, 0xD7, 0x96, 0x7E, 0xC0, 0x9B}) for the subtype, as it is not meant for this format. Use one of the other regular H264 subtypes made by using either "avc1" or "h264" as the fourcc.

ACCELERATION
This sets the preferred method of hardware acceleration for decoding H.264 streams. Changes to this option will not take effect until playback is restarted.

CUDA - Use a compatible NVIDIA graphics card if the stream is encoded using compatible features.
DXVA - Use an ATI or NVIDIA DXVA1/DXVA2 compatible graphics card if the stream is encoded using compatible features with a renderer filter connected.
NONE - Use software decoding only.

TRAY ICON STATES
When the "Use Tray Icon" option is enabled, the tray icon indicates whether or not hardware acceleration (GPU) is active in CoreAVC.

Blue - CUDA or DXVA is not active or in use.
Green - CUDA acceleration is active and in use.
Red - DXVA acceleration is active and 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.
Note: Picture levels cannot be adjusted when DXVA hardware acceleration is in use.

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


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


Also... as a reference here are the install flag options for Haali's splitter:
Haali Media Splitter supports the following command line options:
/S - silent install without any UI
/MKVONLY - register only Matroska components
/AVI=[yes|no] - register AVI support
/MP4=[yes|no] - register MP4 support
/OGG=[yes|no] - register OGG/OGM support
/TS=[yes|no] - register MPEG TS support
/PS=[yes|no] - register MPEG PS support
/WMP=[yes|no] - register WMP to play in Windows 7


Also when reporting issues, please include the following:
People, how about providing detailed bug reports? Simply saying that it's not working or it's slow for me won't really help. It should be something like this:

1. Description: Explain the problem throughly and provide video sample if possible, if not then at least provide screenshots
2. OS:
3. CPU:
4. GPU:
5. Video Driver Version#:
6. Player and Version#:
7. Renderer:
8. Splitter and Version#:
9. Codec Version:
10. Output:
11. Acceleration (DXVA/CUDA):
12. Other info that might help.

Sirber
18th December 2005, 23:16
Sweet!

What is it's speed compared to FFMPEG?

BetaBoy
18th December 2005, 23:21
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
19th December 2005, 00:33
at 320x240@12FPS, I can barely decode it on my 400MHz xScale using FFMPEG. I will test this ASAP :D

BetaBoy
19th December 2005, 00:53
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
19th December 2005, 13:05
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
19th December 2005, 13:24
I just spoke to the Devels 'CoreAVC' is officially born.... next is the 'CoreAVC Encoder'

Sirber
19th December 2005, 13:27
Encoder for pocket pc? ;)

BetaBoy
19th December 2005, 13:47
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
19th December 2005, 14:47
Great news, BetaBoy.

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

BetaBoy
19th December 2005, 16:34
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
20th December 2005, 02:13
Your plans for that AVC encoder, include what. All new stuff that x264 codec have?

BetaBoy
20th December 2005, 12:09
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
20th December 2005, 15:15
wow, that was fast :)
are you going to implement the full specs (all profiles and levels)? and why is it closed source?

BetaBoy
20th December 2005, 16:13
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
20th December 2005, 16:28
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
20th December 2005, 16:40
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
20th December 2005, 19:03
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
20th December 2005, 19:30
@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
20th December 2005, 20:04
guada 2... your running the windows TCPMP?

if not LMK...

guada 2
20th December 2005, 20:42
Sorry Beteboy,

It is similar.
The problem persists.

BetaBoy
21st December 2005, 00:11
Sorry Beteboy,

It is similar.
The problem persists.
OK... i'll look into it....

Here is v0.71d:
http://picard.exceed.hu/tcpmp/test/tcpmp.win32.0.71d.zip

and it now includes:
- AVC weighted prediction support

CruNcher
21st December 2005, 04:35
as soon as it supports cabac i try it ;)

Sharktooth
21st December 2005, 04:43
as soon as it supports cabac i try it ;)
it does: http://forum.doom9.org/showthread.php?p=754347#post754347

CruNcher
21st December 2005, 06:02
ups sorry , yeah wow this thing is fast damnit nice work Betaboy really nice playback of that 1920x1080p sample is not easy but TCPMP + CoreAVC do it perfect looking forward for a Directshow Filter and implementation into mplayer and VLC would be also nice but i see you don't want to open it for now what a pitty :) Like you have another Skal on your team now hehe this Picard guy really knows low level coding it seems. Skals Decoder should be as fast as this :D If the Encoder gets the same optimization cure as the decoder my my alot have to watch out and CoreAVC Encoder could be in the future on the 1 place here on Doom9 i wish it CoreCodec so much that this becomes reallity :)

@BetaBoy
something is strange with the ffmpeg.plg it's very slow compared to CoreAVC rendering to slow compared with a recent ffdshow build hmm seems you useing a very outdated ffmpeg with libavcodec here ?

superdump
21st December 2005, 06:48
I look forward to trying CoreAVC when binaries are available for dshow use. *Looks at Toff* :) And it will be nice to have another AVC codec on the scene. By the sounds of the the quality of the decoder is very good so... Thanks for the news Betaboy and good luck with the programming for this little lot. :)

BetaBoy
21st December 2005, 07:19
http://picard.exceed.hu/tcpmp/test/avc.win32.0.71e.zip

Plugin 'only' for TCPMP for Windows... with the new AVC weighted prediction support

DeathTheSheep
21st December 2005, 18:19
So now it supports everything except lossless, CQM, and interlaced stuff (x264 doesn't do interlaced encoding anyway)! It's very fast, and it's optimized for the PocketPC, so it performs even better there relative to the PC.
Sony's PSP AVC decoder, shabby as it is, is falling behind rapidly, as is Nero's PocketPC AVC decoder, it seems...
The age of true handheld AVC-HP has arrived with a BOOM thanks to Picard, BetaBoy, and the TCPMP team!

Sirber
22nd December 2005, 03:10
I'm upgrading my 400Mhz PPC with the latest TCPMP.

currently decoding x264 (Q35) + vorbis (8kbps) = 65% realtime with FFMPEG

Sirber
22nd December 2005, 03:58
110% with new codec :D :D :D

great work!!!

Sirber
22nd December 2005, 04:17
Any clue why bench I ahve all frames while in real playback I have dropped frames? It's unfair :(

DeathTheSheep
22nd December 2005, 04:20
Well, AVC is a format in which certain scenes of the video requre more processing power than others--more complex in certain areas than in others.

While benchmarking, the 110% you achieve is an average. As such, it is very inconsistent throughout the video stream--some places in the video may decode at 250% while others lag at 75%. In realtime playback, you notice the more complex places with frame drops.

Sirber
22nd December 2005, 04:36
ok... fair enough :)

Also it might be my PPC, but I cannot playback from SD card :( It jam after few seconds.

DeathTheSheep
22nd December 2005, 16:58
Oh? Try freeing some ram, giving it to mostly program memory, and/or adjust the player's buffer size in the settings-> player menu.

If the problem keeps up, try uninstalling some 3rd-party programs, removing the SD card, and doing a soft-reset (keeps your data). Then try it again ;)

HQ-LQ
22nd December 2005, 17:28
have you already a directshow-decoder?

BetaBoy
22nd December 2005, 18:13
@BetaBoy
something is strange with the ffmpeg.plg it's very slow compared to CoreAVC rendering to slow compared with a recent ffdshow build hmm seems you useing a very outdated ffmpeg with libavcodec here ?

It is from source coode from about 3 months ago.... However even with the changes that thay have made it would not make a diff with the current code.

This is why we made the choice to do a decoder/encoder from scratch and expand our business model to include AVC as we were going to license it anyway for TCPMP and our licensees.

have you already a directshow-decoder?
Toff is working on it now and we hope to have it out as soon as possible.

Scarpad
22nd December 2005, 18:38
I've been waiting to get AVC support. I have an Axim X30 624mhz PPC, anyone using it with this hand help. I primarily want to use the files I create for my Ipod Video on the PPC. The files are only 320x240 at 768kbps

PicardGK
22nd December 2005, 22:57
Like you have another Skal on your team now hehe this Picard guy really knows low level coding it seems.
We are both demoscene trained :D
Heaven 7 (http://pouet.net/prod.php?which=5)

something is strange with the ffmpeg.plg it's very slow compared to CoreAVC rendering to slow compared with a recent ffdshow build hmm seems you useing a very outdated ffmpeg with libavcodec here ?
That plugin is not meant for real life usage. I'am building it with Visual Studio without any gcc inline assembly (mmx/sse). Maybe I will have look at the DivX version of ffmpeg where the assembly stuff is separated to libavdsp.

nm
22nd December 2005, 23:26
We are both demoscene trained :D
Heaven 7 (http://pouet.net/prod.php?which=5)
Still my favourite 64k intro :), though I haven't followed the scene much lately.
Nice work you're doing here too.

CruNcher
22nd December 2005, 23:36
yeah picard i got your exceed background very impressive nice to see you working on multimedia solutions , and yes heaven 7 is also 1 of my favs hehe :)


Maybe I will have look at the DivX version of ffmpeg where the assembly stuff is separated to libavdsp.


You mean Dr.DivX OSS with that ?

PicardGK
23rd December 2005, 12:51
You mean Dr.DivX OSS with that ?
Yes, that's the correct name.

CruNcher
24th December 2005, 21:22
i found decoding probs
those decoding errors seem to occur only with the Directdraw output with GDI their are no problems visible useing blitting instead of overlay with directdraw the problems are also gone strange.

Picard is deblocking 100% supported ???

PicardGK
25th December 2005, 14:49
Picard is deblocking 100% supported ???
Yes. It should be.

If GDI mode shows it correctly it seems a problem with my DirectDraw overlay handling. What does media info dialog tell about the video size (maybe odd pixels, but in theory it shouldn't be a problem)? Can you send a sample with problem? picard[at]demoscene[dot].hu

CruNcher
25th December 2005, 17:28
try this http://rapidshare.de/files/9787718/The-Island_HD-Trailer-High_Profile-x264-nodeblocking.mp4.html
you gonna find a bug in CoreAVC with this Clip

Merry Christmas

PicardGK
27th December 2005, 07:42
Thanks. The problem was caused by a buffering problem with high bitrate files dropping reference frames (there were also some audio gaps)

CruNcher
29th December 2005, 00:04
In the case of DirectDraw overlay mode the full sized YUV color space frames are transfered to the video card memory and it's downscaled by video card during displaying.

But the null vs directdraw speed difference is larger as mine. Do you have a 8x AGP video card? Or maybe it does vsync even in benchmark mode. Do you seen tearing during benchmark? (I do with my Radeon 9600)

Sorry for being offtopic. For further CoreAVC discussion: http://forum.doom9.org/showthread.php?t=104277

ps: ops. I forget to update the version number in the player to 0.71g


Jep better to continue here hehe no no tearing visible got a Radeon 9800 pro 8x Agp yes running @ 8 AGP on ULI M1695+M1567 ASrock Dual Sata-II Catalyst 5.13

you still have no changelog for the CoreAVC 0.71g version on your site is this intentional ?

easyfab
29th December 2005, 13:33
Thanks Picard and all corecodec Team :) .
Now I can play HD 1080p AVC files on my XP2500 :)

I'm impressed that your (assembly?) optimizations gives so better speed improvement

You prove that we not absolutely need new generation PC each new codec generation ( same for games or softwares ).

Scarpad
30th December 2005, 20:00
0.71 D works well on my Axim 30 H, of course there's a price to be paid for AVC decoding, it eats Battery life.

Pomyk
30th December 2005, 21:14
I have a problem with normal playback - it skips frames when file has b-frames. In benchmark it plays smoothly and I get over 300%. I'm using win32.0.71g version.

BetaBoy
31st December 2005, 01:48
Got word Toff is finishing up work on the CoreAVC directshow decoder filter and doing speed comparisons now to other filters that are available. I'll get the status for everyone... but I am counting on this for CES to demo for everyone.

That aside.... On sunday I want to demo H.264 in our new TCPMP 'CoreXtension Web browser Plug-in'.... the first version will be only for IE. But dont worry FireFox will be right behind it.... ill post a link then.