CoreCodec/H.264 Codec "CoreAVC"

[BetaBoy]

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]

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 :D

[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...

[guada 2]

Sorry Beteboy,

It is similar.
The problem persists.

[BetaBoy]

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]

as soon as it supports cabac i try it ;)

[Sharktooth]

as soon as it supports cabac i try it ;)
it does: http://forum.doom9.org/showthread.php?p=754347#post754347

[CruNcher]

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]

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]

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]

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]

I'm upgrading my 400Mhz PPC with the latest TCPMP.

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

[Sirber]

110% with new codec :D :D :D

great work!!!

[Sirber]

Any clue why bench I ahve all frames while in real playback I have dropped frames? It's unfair :(

[DeathTheSheep]

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]

ok... fair enough :)

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

[DeathTheSheep]

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]

have you already a directshow-decoder?

[BetaBoy]

@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]

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]

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]

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]

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]

You mean Dr.DivX OSS with that ?
Yes, that's the correct name.

[CruNcher]

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]

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]

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]

Thanks. The problem was caused by a buffering problem with high bitrate files dropping reference frames (there were also some audio gaps)

[CruNcher]

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]

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]

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]

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]

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.

[Sharktooth]

Any news on Weighted prediction front?:)

[CruNcher]

hehe sharktooth that's supported allready

version 0.71e (avc plugin only):
-some fixes
-weighted prediction support

we are at 0.71g allready but therefore no changelog is existing right now seems to had some speed optimations :)

@BetaBoy
that sounds cool but i hope going into Directshow and outside of TCPMP will not hurt the performance that much :(

[BetaBoy]

CruNcher... thats the goal... the TCPMP decoders are written at such a low level that in theory they should be at least 20% or more effecient then a comparable decoder. I am guessing this is why Toff wanted to diff other decoders.

[Lobuz]

It's wonderfull decoder ... but I have a little problem with maximizing CPU usage. Tested with Aplle trailers at WInXP and even in benchmark mode there is max around 60-70% CPU usage. My hardware is a little old: Newer AthlonXP 2400+ running on old Asus A7V at 1.5 GHz with 100MHz bus + 512MB of 133Mhz RAM on GForce2Pro64 . Is my hardware causing some bottleneck problem for TCPMP optimisations? Anyway it would be nice to know in what kind of video output TCPMP is working (WMV7-9 etc.) and color space (YV12 - YUY2 ) for better graphics card setting (YUY2 for my card).

Regards
Lobuz

[PicardGK]

There were no changes other that avc optimizing in 0.71g

In general the player is not really tuned for win32/x86 yet. Example some color space transformations maybe slow like hell.

Anyway it would be nice to know in what kind of video output TCPMP is working (WMV7-9 etc.)
You mean VMR7 / VMR9? Neither. The player is not DirectShow based, it uses simple DirectDraw overlays for output.

and color space (YV12 - YUY2 ) for better graphics card setting (YUY2 for my card).
It will try to use planar YUV formats first, like YV12, IYUV, I420. If that fails it will try the packed ones like YUY2. But I just checked and the planar->packed transformation in the player is handled by a slow fallback function currently with x86. This may cost speed, but didn't explain lower cpu usage.

One explanation I can think of is vsync. If you don't see tearing this means the ddraw overlay driver uses vsync. Try benchmarking the movie with selecting options/video/null in menu.

[Lobuz]

It will try to use planar YUV formats first, like YV12, IYUV, I420. If that fails it will try the packed ones like YUY2. But I just checked and the planar->packed transformation in the player is handled by a slow fallback function currently with x86. This may cost speed, but didn't explain lower cpu usage.
That would be useful to choose YUV formats like in ffdshow config. My graphics card isn't good with YV12 .. some hroma/luma shift and it propably does some conversion from yv12 color space.

One explanation I can think of is vsync. If you don't see tearing this means the ddraw overlay driver uses vsync. Try benchmarking the movie with selecting options/video/null in menu.
With null video set it uses 100% CPU and gets in benchmark of V 1080p 120% speed.

Regards
Lobuz

ps. Are there any chances of mpeg2 in ts HDTV support witch such fast decompression speed?

[unmei]

Yeah, i got the same "problem" here, i didn't even see that it wasn't using all of the CPU, i just noticed that a Xvid, a 450kbit AVC and a 2400kbit AVC all had exactly 60.09Hz in benchmark - highly unlikely (my assumption is either the GPU or the TFT itself (on DVI) locked the overlay memory to only allow writing at that certain freq max, which is the monitors refresh rate). Anyway with the NULL decoder speeds are amazing.

[bond]

first of all wow! this decoder really blows away!
i guess i can for the first time decode D1 res avc + he-aac in realtime on my 866mhz pentium3 :)

here my speed results for
x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop-5_WBP_cabac:
coreavc-tcpmp: 90.32fps
ateme: 50.62fps
ffmpeg-mplayer: 49.91fps
ffmpeg-ffdshow: 44.98fps
ffmpeg-tcpmp: 38.58fps

i guess the values speak for themselves, coreavc-tcpmp is ~80% faster than the second fastest decoder, ateme!!!

the tcpmp values are derived via the tcpmp benchmark option together with "null video".
with directdraw video i still get 36.92fps

as i see it the now used avc features not supported by coreavc are:
- custom quant matrices
- lossless
- interlacing
i hope at least the first two will be supported too

another interesting thing i saw was that ffmpeg avc decoding via tcpmp is clearly more slower than when decoding with ffmpeg via ffdshow or mplayer. i guess thats because tcpmp itself is not that fast?

Thanks. The problem was caused by a buffering problem with high bitrate files dropping reference frames (there were also some audio gaps)i am wondering when does tcpmp drop frames? and is it possible to disable this, so i know for sure that tcpmp plays my videos in realtime without dropping frames

[Revgen]

This decoder (V. 71g) may be fast for some videos (The Greatest Game) but it's slow with my x264 encoded Beavis and Butthead video.

FFDshow and VLC player play this video fine.

If BetaBoy or Picard would like to take a look at it just send me a PM with your e-mail and I can send it to you via www.yousendit.com

[bond]

make sure you have avc.plg in your folder, otherwise the player will use ffmpeg for decoding, and thats slow

[Revgen]

The avc.plg is in my folder.

Or else The Greatest Game.mp4 video would play slow.

[kurt]

great player! But a question the developers:

what about AR-signaling (SAR in mp4 / DAR in matroska)? will this be implemented in the future?

[Birdy1]

This is amazing. I benchmarked a trailer of the movie Serenity. Before I couldn't play it at all.

player: tcpmp.win32.0.71g.zip
plugin: avc.win32.0.71g.zip

Serenity movie trailer serenity_1080p.mov

without avc and aac plugin (no sound) 53%
with avc and aac plug in 171%

P4 3GHz
ATI Radeon 9600 Pro

[BetaBoy]

Revgen and others.... if you have the FFMPEG plug-in installed and the AVC plug-in installed and are trying to play a video with our unsupported AVC features
- interlacing
- custom quantizer matrices
- lossless coding

Playback will the default to the FFMPEG plugin. This is the likely reason it is playing slow. Try another AVC video with the supported features and let us know the results.

[Revgen]

Okay, here are the details again.


1) My Beavis and Butthead video doesn't use any of these above features. So it shouldn't be the problem.

2) My video plays well with FFDShow and VLC player. The FFMPEG plugin shouldn't be the problem.

3) My video plays slow using TCPMP 0.71G combined with AVC plugin 0.71G. It also plays slow when the AVC Plugin IS NOT in the folder.

4) I can upload and send a link to my video through www.yousendit.com if you're interested.

[CruNcher]

Revgen what does the Media Info show after you load the file ?

[Revgen]

Revgen what does the Media Info show after you load the file ?

URL: H:\BEAVIS_BUTTHEAD_VOL_1\VIDEO_TS\Beavis and Butthead Vol 1 Disk 1.mkv
Format: Matroska File (MKV,MKA)
Duration: 1:47:40.960
Filesize: 715821 KB


Video: AVC aka H.264
Codec: CoreCodec AVC
Video Size: 720x480
Frame Rate: 23.976
Language: eng


Audio: AC-3
Codec: LibA52 (AC-3)
Format: 48000 Hz Stereo
Data Bit Rate: 224 kbit/s
Language: und


Played: 0
Frames Dropped: 0
Played FPS: 23.976

[Hyper Shinchan]

Really amzaing this plugin!!! I'll make extended tests later, but I'm really impressed!
Sugoiii!!!

[DeathTheSheep]

In having some MKV problems here as well. I think its the same one, actually; an MKV file of mine benches near 400% despite dropping many frames during playback.
AVI works just fine, though.

[travisbell]

Can't wait to see this DirectShow filter you are teasing us with... should be very, very interesting...

[BetaBoy]

ok... you have been warned!!! This is a pre-pre-pre-alpha directshow version of CoreAVC.... bond has tested it and it needs alot of work still ;-)

<bond> ffdshow: 47.16
<bond> ateme: 50.62
<bond> coreavc: 73.33 ;)
<bond> that is with a stream that has pretty much everything enabled

CoreCodec AVC DirectShow Video Decoder

ALPHA VERSION FOR TESTING PURPOSE ONLY

Changelog:
==========

Version 0.0.0.1 Alpha :
Use a very high merit in this alpha release, don't install it if you
don't want to use it.
Should support anamorphic from Matroska (native mode) and MP4 files.
Limitations :
- Only output to YV12 and I420
- No dynamic output mediatype change
- No flushing for buffered frame at end of file
- Linked with some unecessary code from TCPMP
- no cqm, lossless or interlacing support


There are way too many issues to even bother posting about... but hey, I did say it was a pre-pre-pre alpha build... so with that.... Have fun.

Download here: http://cc.serveftp.org:8884/CoreAVC20060102.7z

[falcon2000eg]

thanx i just tried it and loved it keep the good work.

[Revgen]

Beavis and Butthead plays great with this one. Good Job! :thanks:

The Greatest Game trailer (1920x1080) also plays great.


Your pre pre pre alpha build has earned a right to graduate! :)

[Sirber]

On my 3000+ (running in low power mode, RealAnime is not encoding :D)

On 640x480 with (x264 + AAC+v2 = MKV), in overlay mode

FFDShow: ~50% CPU
CoreAVC: ~38% CPU
MPlayer: ~30% CPU

[CruNcher]

yep it's like Bond said blasting 40% faster then any of the other Decoders :)

[sillKotscha]

blasting 40% faster then any of the other Decoders :)

first time I can watch these trailers...

sample H264 High Profil

KingKong (http://multimediacom.free.fr/Download/x264HP_KingKong_720p_1500.mp4)
1280*720*25
1500 Kbps

Harry potter IV (http://multimediacom.free.fr/Download/x264HP_HPIV_720p_1250.mp4)
1280*720*25
1250 Kbps

IceAge (http://multimediacom.free.fr/Download/x264HP_IceAge_720p_1250.mp4)
1280*720*25
1250 Kbps

really flawless with my system...

http://tinypic.com/jkvlzn.png
http://tinypic.com/jkvn1l.png
http://tinypic.com/jkvm6h.png

[bond]

<bond> ffdshow: 47.16
<bond> ateme: 50.62
<bond> coreavc: 73.33note that with the tcpmp i get on the same stream a decoding speed of 90fps, so its even a lot faster than coreavc dshow

edit:
so on this sample (720x288_B3-Ref_Ref5_p4x4-i8x8_loop-5_wbp_cabac_770kbps) with my pentium3 866mhz cpu
- coreavc-dshow is ~45% faster than ateme
- coreavc-tcpmp is ~75% faster than ateme

ateme _was_ the fastest decoder till now (and not publically available). compared to the available other fast decoders (libavcodec, moonlight) the speed increase is obviously even bigger

so this decoder really rocks! great job! :)

[PicardGK]

4) I can upload and send a link to my video through www.yousendit.com if you're interested.

Please upload it, if there is a little chance it will make faster finding problem. In next few days I will be still busy with some other stuff I need to finish, but I will get back to coreavc after that (cqm support is coming also).

[bond]

cqm support is coming alsouhm, actually it seems the 0.0.0.1 version of coreavc already handles cqm!
did this happen automagically? :D

no lossless and interlacing tough

[Revgen]

Please upload it, if there is a little chance it will make faster finding problem. In next few days I will be still busy with some other stuff I need to finish, but I will get back to coreavc after that (cqm support is coming also).

Uploaded the file and the link has been sent to your e-mail address.

[Sirber]

http://picard.exceed.hu/tcpmp/test/ is dead :(

[BetaBoy]

yeah.... there is an outage in the host country.

[Wedgedkc]

Huge thanks for this, I can now watch the the fountain teaser and other hd trailers in 720p on my athlon xp 1800+. Amazing!

[Sirber]

Bug: Can't use CoreAVC DShow from AVISynth. Takes 100% CPU and timeout.

[CruNcher]

Bug: Can't use CoreAVC DShow from AVISynth. Takes 100% CPU and timeout.


Known problem is being worked on actually it will load it but it takes very long ;)

[Sirber]

AVISynth timeout :) so it will never load... NEVER!!! :D

[bond]

my issues till now with coreavc:
- loading via directshowsource() doesnt work
- helix vfw yuv codecs cant handle the yv12 output of coreavc (but can handle ffdshow's yv12)
- after seeking in very rare cases the audio takes some seconds till its played again

[MatMaul]

:eek: :eek:

with a x264 high profile source (688*368), I obtain on my processor (pentium M Dothan 1,73 ghz) :

CoreAVC : 163.5 fps
ffdshow-20051230-icc-sse2 by issa : 104,1 fps (fastest build on this processor)
TCPMP : 172 fps
mplayer2005.11.23.P4 by celtic_druid : 106,7 fps

with a x264 high profile HD source (1280*720) :

CoreAVC : 69,5 fps
ffdshow-20051230-icc-sse2 by issa : 44,3 fps
TCPMP : 77 fps
mplayer2005.11.23.P4 by celtic_druid : 46,4 fps

Really good job !! Thanks a lot !!
I can now decode HD 720p trailer without dropped frames !

[Sirber]

What about mplayer?

[Revgen]

If anybody wants an easy way to register/unregister .dll, .ax, or other types of files I recommend RegDrop (http://www.addisonsw.com/revsqu.htm) . Just put the regdrop.exe onto your desktop and drag whatever file you want to register over the regdrop.exe icon and it will register the file for you. Drag that same file over the icon again to unregister it.

Works well with the CoreAVC decoder.

[MatMaul]

with this build of mplayer (http://www.aziendeassociate.it/cd//mplayer/mplayer2005.11.23.P4.7z) and this command line :
mplayer "file.mkv" -vo null -benchmark
I obtain 106,7 fps

PS : I edited my last post with a test on a hd source

[[Toff]]

I've uploaded a new version :
http://coreavc.corecodec.org/CoreAVC20060104.7z

Changelog :
Version 0.0.0.2 Alpha (20060104) :
Fixed some compatibility problems (AVI Decompressor, AviSynth, ...)
Project cleanup (smaller size)

[CruNcher]

Yep works great thx toff good work :)

[AlexW]

Hi, could one of the CoreAVC devs please have a look at this clip?: http://mirror05.x264.nl/Alex_W/force.php?file=./clips/b0rked.mp4

The problem seems to occur when the 8x8 transform is used on direct blocks in B-frames.

[Sirber]

It seems I have dropped frames with the player (0.71g). Seems to drop on low motion, so it could be the same problrm as AlexW.

[dbzgundam]

That's odd... Still no mention of CQM, yet the above posted CoreAVC can handle all my CQM encoded videos. ;)

[omion]

Wow. VERY nice.

ffdshow:
880 CABAC = 23.88 fps
720 CABAC = 32.40
720 CAVLC = 46.07

CoreAVC 0.0.0.2:
880 CABAC = 38.14
720 CABAC = 49.16
720 CAVLC = 63.67

60% faster than ffdshow at 1600x880. Very impressive! Keep up the great work!

The only quibble I have with it is that it doesn't seem to work with MPC's "VMR9 (renderless)" setting. It keeps using some sort of overlay.

[lexor]

@omion: what's up with 1600x880? what footage do you have in such a weired resolution?

[omion]

Heh. I knew somebody would ask that. The source is actually a 1920x1080 HDTV capture. I rescaled it to be 1600 wide because that's the width of my monitor. The height just came out to 880.

[futurex]

that it doesn't seem to work with MPC's "VMR9 (renderless)" setting. It keeps using some sort of overlay

i noticed that too

[[)370|\|470!2]

Is there any way of adjusting brightness/contrast?

[rozemab]

Is there any way of adjusting brightness/contrast?

options | settings | select page

You will find the sliding controls there.

[[)370|\|470!2]

options | settings | select page

You will find the sliding controls there.

..huh?


http://img228.imageshack.us/img228/5056/coreavc9ee.jpg

[Sirber]

Wasn't he talking about TCPMP?

[Sirber]

I made a test with RealAnime 4 using my new "Low Complexity" profiles and with x264 and vorbis I get 156% realtime. It seems though to have problem playing bframes in realtime though.

320x240 @ 12 FPS
1-pass CQ 36

[Caroliano]

A little n00b question: to where I shoud copy the CoreAVCDecoder.ax file to? It is the directshow filter, isn't?

[[)370|\|470!2]

A little n00b question: to where I shoud copy the CoreAVCDecoder.ax file to? It is the directshow filter, isn't?

Copy it anywhere u like, then run regsvr32.exe CoreAVCDecoder.ax

[[)370|\|470!2]

Wasn't he talking about TCPMP?


Hmm, yea, seems so..:|

[TEB]

with this build of mplayer (http://www.aziendeassociate.it/cd//mplayer/mplayer2005.11.23.P4.7z) and this command line :
mplayer "file.mkv" -vo null -benchmark
I obtain 106,7 fps

PS : I edited my last post with a test on a hd source

I tested on Saggitares x264HP_IceAge_720p_1250.mp4 on that mplayer build and TCPMP build (-nosound as default)

Mplayer w/directshow as -vo 36fps -vo null 63fps
TCMP/AVC w/directshow as -vo 77fps -vo null 97fps

URL \x264HP_IceAge_720p_1250.mp4
Size 12923107
Platform Windows
OS Version 5.01
Clock speed 3590 Mhz
Video output DirectDraw 1280x1024 32bits Lookup
Video zoom 1280x720 -> 1280x720


My comment: Man this is impressive :) Keep up the good work and keep the builds coming!
Btw do u support mpeg2-ts demuxing and decoding in hd and sd?
I see that u dont use HT or Multicore/smp, is this planned to be implemented?

[rozemab]

yes, I was referencing the player, not the directshow filter.

[Caroliano]

My rounded results in a 1.7GH celeron with an 640x352 High profile Noir opening:

file -> ffdshow -> chegepuga: ~40fps
file -> coreavc -> chegepuga: ~65fps
file -> coreavc -> ffdshow -> chegepuga: ~58fps

The last is because I cant plug the coreavc into Video Render directly. If I try that the FFDShow apears automaticaly between them. Even though can conect it directly to chegepuga... maybe a compatibility bug?

[bond]

The last is because I cant plug the coreavc into Video Render directly. If I try that the FFDShow apears automaticaly between them. Even though can conect it directly to chegepuga... maybe a compatibility bug?coreavc doesnt make a colorspace conversion, so it only outputs yv12. afaik old video renderer doesnt like yv12 input. try vmr7

[Caroliano]

coreavc doesnt make a colorspace conversion, so it only outputs yv12. afaik old video renderer doesnt like yv12 input. try vmr7
I'm not familiar with Graphedit yet. It shoud be in graph -> insert filters, but where? In directshow tree? Other tree? It has exactly this name?

[bond]

I'm not familiar with Graphedit yet. It shoud be in graph -> insert filters, but where? In directshow tree? Other tree? It has exactly this name?in the mpc options you can enforce what renderer you want to use

[MatMaul]

I have edited my fps for ffdshow because there are wrong (I used a YV12->RGB conversion...)

now the values are good and it appears ffdshow=mplayer ( normal :D , they use the same library for decode...)

[Caroliano]

I tried VRM7 windowed in MPC but this way apear a lot of blocking and some artifacts in motion. With renderless is the same thing, plus that I cant see anything in fullscreen (very strange artifacts). I'm using ffdshow for an directshowsource() encode right now, this can be the problem, I don't know.

Also, it don't afect graphedit. I'm doing anything wrong?

[GhengisKhan]

This decoder is awesome - have it running from a USB drive and it almost allows me to play Apple Trailers in 1080p.

Great work Picard!

GhengisKhan

Edit. P.S. Picard do you think you could get 1080p to play perfectly for me (1.6Ghz Intel Centrino proc.)
P.P.S. Any updates about the encoder or other development... Picard... Betaboy...anyone?
P.P.P.S. How's soon can we expect a full decoder (all features implemented)?

Thanks, you guys are great!

[MatMaul]

Edit. P.S. Picard do you think you could get 1080p to play perfectly for me (1.6Ghz Intel Centrino proc.)

I can decode 1080p films with my pentium m @1,73ghz (about 35 fps)

[GhengisKhan]

Yeah, that's what I meant by saying it wasn't quite perfect yet. It's almost like I can reach it. It was like this in 720p before in Quicktime on my 1.6Ghz -almost there, but still dropping some frames. I'm sure by the time the new release comes out (the one Betaboy is probably demoing at CES), I will be able to watch 1080p trailers from www.apple.com/trailers perfectly (my brother wants to buy that new Panasonic HD camera which records in 1080p HD so this is really important to me - so I can watch what he records).

GhengisKhan

P.S. It takes too long to be allowed to post - I couldn't post when all the good stuff was being talked about... and I'm leaving (skiing) the day after I'm allowed... this sucks (Picard do me a favor and hold off on the release wait about 5 days - then release a big sucker. Just for me? Just kidding, it would be nice though... I'm so addicted to TCPMP...)

[CruNcher]

Panasonic HD camera which records in 1080p HD


Hmm but im sure it won't record in H.264, so for the raw stuff you should have no problems watching it on your specs with a fast Mpeg-2 Decoder with DXVA support.

@picard
im not sure but it seems to be the same decoding bug that AlexW experienced http://forum.doom9.org/showpost.php?p=762293&postcount=94
in this sample http://rapidshare.de/files/10498977/coreavc_decoding_prob.mp4.html

when useing (bframes 2)
--analyse all --8x8dct <- i have not such Decoding problems but when useing
--analyse p8x8,b8x8,i4x4,i8x8 --8x8dct the problems as the sample shows occour

[Selur]

Ok, seems like I'm doing something wrong, I downloaded tcpmp.win32.0.71g.zip (from http://picard.exceed.hu/tcpmp/test/) and ice_age_2-tlrD_h1080p.mov (from http://www.apple.com/trailers/fox/ice_age_2/hd/), remuxed ice_age_2-tlrD_h1080p.mov into ice_age_2-tlrD_h1080p.mp4 using Quicktime 7pro.
Then I unziped tcpmp.win32.0.71g.zip, started player.exe, ignored the message about the aac audio decoder, opened the mp4 file and tried to play it. => 100% CPU usage and a no way watchable (to slow, skipping frames) playback. Playback works fine in TCMP using ffdshow for Audio&Video decoding, no problem watching the mp4 smoothly. (70-99% CPU usage, would be a bit less if I would use ffdshow to convert the aac stream on the fly to ac3)

Shouldn't this work? Am I doing something wrong?

Cu Selur

Ps.: running WinXpro 32bit with newest updates, 2GB RAM, Athlon 64bit 3500+, display resolution: 1920x1200.

[bond]

selur, you need to get avc.plg, which is available together with the aac.plg in an extra package on the page

[Selur]

Ah, okay, thx.
Just tested the directshowdecoder. :)
CPU usage dropped to 46-75%, nice. :D

Thx, bond worked fine, CPU usage even dropped another 5%. ;)

Cu Selur

Ps.: Nice work CoreCoded-Team :D

[JoeBG]

selur, you need to get avc.plg, which is available together with the aac.plg in an extra package on the page

@ Selur

You got it? :D

[Selur]

yup, that's why I inserted 'Thx, bond worked fine, CPU usage even dropped another 5%.' :D

[cjei]

I hope CoreAVC can have these color conversion options :
ColorMatrix("Rec.709->Rec.601")
ColorMatrix("Rec.601->Rec.709")
ColorYUV(levels="TV->PC")

Because vmr7&9 seems to need PC scale YUV
and overlay needs Rec.709 for HD.

[falcon2000eg]

Is there any way of adjusting brightness/contrast?

yes i hope that (in the dshow decodr i mean) to quit using ffdshow.

[[Toff]]

yes i hope that (in the dshow decodr i mean) to quit using ffdshow.

Graphic cards already have settings for that, why would you want to have settings in each video decoder ? That mean that each time you install a new decoder, you have to tweak its settings. If you want to have 2 or more configurations, for example for day and night, you need to change again all the settings in all the video decoders.

[[)370|\|470!2]

']Graphic cards already have settings for that, why would you want to have settings in each video decoder ? That mean that each time you install a new decoder, you have to tweak its settings. If you want to have 2 or more configurations, for example for day and night, you need to change again all the settings in all the video decoders.

It's not always help to brighten the picture, especially when color conversion applied. Darken details are still unwatchable.

[[Toff]]

It's not always help to brighten the picture, especially when color conversion applied. Darken details are still unwatchable.

How would that be different with decoder level brigthness settings ?

[[)370|\|470!2]

']How would that be different with decoder level brigthness settings ?


Hmm, just thought, that applying brightness before rendering on more deeper level is more effective...

[bobololo]

I did a quick test using TheGreatestGame_HD_AVC.mp4 trailer (1920x1080p) available from nerodigital.com and timeCodec from Haali. I'm running an AMD X2 4400+ @ 2420 MHz.

Nero: 52.3 fps
CoreAVC: 45.3 fps
Ateme: 30.6 fps

As you can see CoreAVC shows really good performance it's only beaten by nero decoder which exploits both cores of my CPU while others don't.

[bond]

I did a quick test using TheGreatestGame_HD_AVC.mp4 trailer (1920x1080p) available from nerodigital.com and timeCodec from Haali. I'm running an AMD X2 4400+ @ 2420 MHz.

Nero: 52.3 fps
CoreAVC: 45.3 fps
Ateme: 30.6 fps

As you can see CoreAVC shows really good performance it's only beaten by nero decoder which exploits both cores of my CPU while others don't.well bobololo left some of his values away:
the values he posted are for plain decoding (eg via avisynth). for playback (via directshow) the display fps shown by haalis tool are important and these are in bobololo's setup:

CoreAVC: 45.1 fps
Nero: 36.1 fps
Ateme: 30.6 fps

as you can see coreavc is faster than nero for playback, even altough nero is multithreaded and coreavc isnt, so i wouldnt say nero is able to beat it at all

[videomixer9]

Athlon XP 3000+, 1 GB Dualchannel DDR333 RAM, TheGreatestGame_HD_AVC.mp4, Haali timeCodec

ffdshow 04 Jan 2006
User: 173s, kernel: 0s, total: 174s, real: 180s, fps: 21.1, dfps: 20.3
CoreAVC:
User: 107s, kernel: 0s, total: 107s, real: 111s, fps: 34.1, dfps: 32.8

Plays fine and in sync with CoreAVC and stutters otherwise, I guess I say byebye to ffdshow, too bad I cannot use quicktime decoder in timeCodec as I'm sure that one would be by far slower, tried with an apple trailer that stutters around totally in Quicktime Player and test result was this, besides the totally fluent playback in the player (x-men_3-pre_teaser_h1080p.mov):
User: 42s, kernel: 0s, total: 42s, real: 48s, fps: 55.7, dfps: 49.4
Apple ever going to update their crappy decoders? I got lots of ppl that think their PC is not ready for HDTV stuff because of the bad performance of Quicktime ...

Hope CoreAVC will be improved and regularly released soon!

[SeeMoreDigital]

What a fabulous little MPEG-4 AVC decoder....

With it I've been able to play some 1280x720 samples quite perfectly, samples that previously stuttered ;)


Great work guys.... once AR signalling detection is included, it will be a brilliant little MPEG-4 AVC decoder :)


Cheers

[bobololo]

well bobololo left some of his values away:
the values he posted are for plain decoding (eg via avisynth). for playback (via directshow) the display fps shown by haalis tool are important and these are in bobololo's setup:

CoreAVC: 45.1 fps
Nero: 36.1 fps
Ateme: 30.6 fps

as you can see coreavc is faster than nero for playback, even altough nero is multithreaded and coreavc isnt, so i wouldnt say nero is able to beat it at all

LOL that's really funny to see how strong you're defending OSS things (is CoreAVC OSS btw ?) against evil commercial things ;). That even brings you to post mis-leading information without rigorously checking them !

To come back to the topic, our main interest here is to compare the raw performance of the decoders no matter what there is around (dshow, displaying, rendering, etc.). And this raw performance is indicated by the fps entry from timeCodec as Haali explained to you. I provided the figures corresponding to it in my post above.

The display fps (dfps) gives the actual framerate of the whole display graph if I understand correct and therefore it includes many things like parsing, rendering, output color conversion, displaying, etc. that are to my opinion out of the previous scope.

I don't know the reason why the dfps is quite lower with nero decoder, but it's rather abnormal since I used the null renderer in which case the fps should be close to the dfps (as it's verified with other decoders btw). I have the feeling that for some reasons, an unknown additional filter had been added in nero's case and drastically slowed down the display graph given its poor result. Whatever the cause, it doesn't change the raw performance figures showing that nero is faster than CoreAVC and there is no discussion possible here (unless there are some issues in the way timeCodec does its job).

And as a conclusion to my 2 cents' comment :), I would suggest you to spend your energy bitching CoreAVC devs to exploit MT optimization to definitively bring it far ahead from others decoders instead of trying to arrange actual facts that don't please your taste ;). That would be much more useful for the development progress !

[fight2win]

hi,
i have done some avc encodes using megui x264, high profile with jvt turned on, so will core avc decoder be able to play them?

[bond]

LOL that's really funny to see how strong you're defending OSS things (is CoreAVC OSS btw ?) against evil commercial things ;). That even brings you to post mis-leading information without rigorously checking them !coreavc is not oss, as i see it its indeed a "commercial" solution, given away for free tough (till now)

i simply posted the info you left away, i see nothing wrong with that

To come back to the topic, our main interest here is to compare the raw performance of the decoders no matter what there is around (dshow, displaying, rendering, etc.). And this raw performance is indicated by the fps entry from timeCodec as Haali explained to you. I provided the figures corresponding to it in my post above."our" interest is not what you described here, as its not your job to decide what our main interest is.

imho the main interest is how nero and coreavc perform during playback, as currently avc decoders are as good as always used for playback
if nero does some wierd colorspace conversion or something else during playback which slows it down, it still makes it slower than coreavc during playback

therefore the dfps value is interesting and shows that during playback coreavc is faster than nero
you should have at least provided us that info

[Sagittaire]

Bond use simple core CPU
bobololo use dual core CPU

perhaps simple SMTP optimisation for Nero Decoder ... ???

[lexor]

Bond use simple core CPU
bobololo use dual core CPU

perhaps simple SMTP optimisation for Nero Decoder ... ???
that's not what's happening above, from my understanding of what bobololo did, is that he just measured performance of pure decoding (without playback) to raw of each decoder. bond posted bobololo's figures but with playback component added in, I think the number bond posted are also from bobololo's test not bond's own, just bobololo didn't post those since he compared the raw perfomace.

As you can see both ateme and coreavc didn't take a performance hit (barely a dent in decimal part) when you add the playback component in (since they are both single threaded, just like dsfilters and players) whereas nero took a nose dive since its multi-threaded performance was negated by necessity to wait for the single threaded dsfilters and players.

I think the result of the comparison that bobololo made is that it doesn't matter if one step is multi-threaded, you gotta get all software in your playback chain multi-threaded, or you don't get benefit. Thanks for that bobo :) makes me feel better about not having dual core just yet.

[Doom9]

well, since there's such a significant difference between pure decoding and the whole playback stream, that would warrant some investigation on which filter uses how much CPU time so see if there's a bottleneck somewhere, if there's a filter that may be unable to cope with the amount of data the decoder feeds it and starts to choke. Comparing the CPU usage in both scenarios might also be interesting.. are both cores really being maxed out in the DShow scenario? If not but they are in the pure decoding scenario, that would be a strong indicator that one of the additional filters used by dshow playback causes a slowdown.

And as far as QT goes.. perhaps Apple will learn by the year 3000 but I wouldn't expect anything before that. They may make good video editing software but encoding and decoding video is another story entirely.

[CruNcher]

bobololo use dual core CPU


I think he uses a P4 Hyperthreading Cpu no Dual Core, anyway
all of you here entirely forget what CoreAVC is about and that it's still in early Development and from that result it shows here in that state as a ST Decoder against an MT Version of Neros Decoder i would call that allready much better low level optimized and in ST Mode it looks completly different, because that's what Picard optimized CoreAVC initialy for (showcased on CES @ the Sandisk and HP booth) Single Core Mobile Devices and now with the first Dual Core Mobile Devices and Multimedia CE Devices showing up im sure Picard gonna enhance it even further also in that direction and it really seems to be a Dshow bottleneck like lexor said that the Nero filter can render faster in MT mode but can't display it out as fast. But anyway in my eyes that doesn't make Neros Decoder better even if it could provide the same speed for the output :P

Before Picard goes on optimizing it for Dual Core i think it's more important to fix the for now last known Decoding bug inside it. That would be http://forum.doom9.org/showpost.php?p=762293&postcount=94

[lexor]

I think he uses a P4 Hyperthreading Cpu no Dual Core, anyway

I'm running an AMD X2 4400+ @ 2420 MHz.
how did you get P4 out of that? :cool:

[videomixer9]

I'm quite amazed the difference between X2 4400+ and XP 3000+ is only ~11fps with CoreAVC, guess the 4400+ is only given with both cores fully used ... so far the test seem to be kinda unfair and I'd wonder how it'll turn out once CoreAVC does multithreading ... if Nero would equally spread the load on the two cores the amount of fps bobololo reached isn't that impressive really ... it'd mean that Nero only got 26,15 fps out of each core, that's less fps than CoreAVC managed on my single core XP 3000+. Considering the overclocking from 2200mhz to 2420mhz this is a real bad performance imo.

[Doom9]

it really seems to be a Dshow bottleneck like lexor said that the Nero filter can render faster in MT mode but can't display it out as fast.That's not correct. There's decoding, and then there's filters after it.. it really needs to come down to analyzing the filter and what percentage of CPU they use (in relation to the complete available CPU power). Assuming everything before the decoder filters is the same, and further assuming that there's just the renderer after the decoder, the renderer might be doing something screwed up. Since when it comes to raw decoding power, the Nero decoder appears to be the fastest, and it no longer is when there's a renderer in the picture, wouldn't it be reasonable to suspect the renderer as a bottleneck, and that much of a bottleneck that it actually punishes fast decoders?

[videomixer9]

null renderer is shit, vmr7 has better dfps on my system :)
(at least with fps this low, on mpeg4 decoding with over 300fps it cannot keep up, still quite mysterious)

[CruNcher]

@lexor
oops yeah i oversaw that last time i spoke with him about the results of the Nero filter he was on a P4 HT ;)

[bobololo]

Whatever the cause, it doesn't change the raw performance figures showing that nero is faster than CoreAVC and there is no discussion possible here (unless there are some issues in the way timeCodec does its job).

Thanks to Haali's help, we finally sorted out what was happening. Due to the way timeCodec is measuring the decoding time, it doesn't account all running threads which cause the incorrect fps measurement with nero decoder since is multithreaded. According to Haali, dfps when using null renderer is close enough to the actual decoding fps (less than 1% error when using long enough clip). So finally, I redid my bench and the results are summarized as follow :

CoreAVC: 48.6 fps
Nero: 39.6 fps
Ateme: 33.6 fps
ffdshow: 30.7 fps

On my AMD X2 @ 2420 MHz (I recently upgraded my hardware from a P4/HT @ 3 GHz) which means that if there isn't any further measurement mistake, CoreAVC outperforms any decoders around even without exploiting MT. It's just impressive, and we'll have some hard work to catch up ;) !

update: added ffdshow's result

[PicardGK]

Actually I'am not at CES, but busy with Symbian porting of TCPMP.

I found the decoding bug (bframe + 8x8dct) and the problem with mkv under TCPMP. But as I understand the CoreAVC ddshow filter was not effected by this mkv timing problem.

I will compile a new TCPMP build tomorrow.

Multithreaded decoding, x86-64bit build are on my todo list, the problem is time and I have to prioritize. Probably adding some mmx color space transformation support will be the first (which will also help TCPMP with other codecs)

CQM support was added a while back. The second version of ddshow filter already has it, but TCPMP binaries not yet.

[lexor]

sorry pickard, someone at corecodec forums said you were at CES, and the bit about coreAVC I admit I just made up :) the original poster with mkv problem did say he was using TCPMP getting the problem (so do I) so I'm going to grab that new version asap when released :)

[Ice =A=]

Seems to be very fast indeed. But you should describe a little more clearly what to download and how to "install" the plugin, that's what kept me from testing it the last few days...
Then again, measured by this forum's standards I'm quite a noob... :)

[SeeMoreDigital]

CoreAVC outperforms any decoders around even without exploiting MT. It's just impressive, and we'll have some hard work to catch up ;) !Thanks for your confirmation bobololo. It's very gracious of you ;)

[kurt]

just noticed version 0.71h is up :)

version 0.71h
+aspect ratio support for mkv files
+avc cqm support
-mkv avc timing fix
-avc bug fixes
http://picard.exceed.hu/tcpmp/test/

download is very slow - so i made a mirror (http://home.arcor.de/mutterstadt/)
(hope this is ok?)

[bond]

just noticed version 0.71h is up :)anamorphic resize with mp4 in tcpmp works fine now too

[Sirber]

Did the 8x8 dct on bframes bug resolved?

[PicardGK]

Did the 8x8 dct on bframes bug resolved?
It should be. It's up to Toff to build a new dshow filter.

[Sirber]

Still the same problem with TCPMP 0.71h: bframes are dropped completly.

[bond]

Still the same problem with TCPMP 0.71h: bframes are dropped completly.sure you placed the new avc.plg into the tcpmp folder?
my avc mp4 streams with b-frames are played very nicely on my pentium3 866mhz

[PicardGK]

Still the same problem with TCPMP 0.71h: bframes are dropped completly.
Is this with mkv files? Does file/media info dialog show the dropped frames? Does this sample also drop frames? http://rapidshare.de/files/10655776/test-002.mkv.html

Make sure both the player and avc files are updated. Check version in about for 0.71h and check media info for CoreAVC video codec.

[Sirber]

duh!

I only upadted the player lol

works #1 now :D

[thetrueavatar]

Oops I forgot to update tpcmp. Now both tcpmp and plugins are up to date and it works fine with my mkv. Great job and keep going.

[SeeMoreDigital]

I'm getting a bit confused...

What's the latest direct-show encoder? The one I currently have installed is CoreAVCDecoder.ax v0.0.0.2 Alpha (2006-01-04).


Cheers

[travisbell]

I'm getting a bit confused...

What's the latest direct-show encoder? The one I currently have installed is CoreAVCDecoder.ax v0.0.0.2 Alpha (2006-01-04).


Cheers

I believe that is still the most updated. Only the Core player and plugin were just updated.

[nurbs]

I have some performance issues with TCPMP. I have 2 PCs, one with a 2 GHz Athlon XP and one with a 1.8 GHz Athlon 64.
I tested a 1080p trailer from Apple.

video not displayed; audio deactivated
Athlon XP: 180%
Athlon 64: 245%

video direct draw; audio wave out
Athlon XP: 120%
Athlon 64: 65% ;choosing GDI does improve this by ~ 5%

The trailer actually plays fine on the Athlon 64 as long as I keep the default window size, but when I go fullscreen the framerate drops and its not watchable any more.

[PicardGK]

Is the updated timeCodec.exe somewhere available?
How did you guys benchmark Nero7 filter when it only works in Showtime?

[PicardGK]

Athlon 64: 65% ;choosing GDI does improve this by ~ 5%
My guess the ddraw overlay mode didn't kick in or it couldn't use yv12 format. The fallback mode is kind of useless (unoptimized) at the moment. Fullscreen slowing down, means the player uses (fallback) software scaling.

[kurt]

I don't know if this is the right time to ask, but are there any plans to implement spdif output for AC3/dts/HE-AAC?
that would be great for all receiver owners :)

[asdfsauce]

I'm a little confused. Does the latest corecodec dshow filter do h.264? And if so, where can I get it?

[kurt]

I'm a little confused. Does the latest corecodec dshow filter do h.264? And if so, where can I get it?
yes it does, look here for download: http://forum.doom9.org/showthread.php?p=762244#post762244

[thetrueavatar]

Since it's coreAVCdecoder there is a lot of chance that it does :p

[asdfsauce]

Thanks kurt,

Very nice decoder, cut my CPU usage in half with MPC.

[[Toff]]

New DirectShow filter build up :
http://coreavc.corecodec.org/CoreAVC20060109.7z

Changelog :
Version 0.0.0.3 Alpha (20060109) :
CQM support
Fix for 8x8dct
Flush buffered frame
Support for X264 and x264 FOURCCs
Now use MERIT_NORMAL

[travisbell]

Awesome! Just gave it a try and love it. .mkv's seem to working properly with 0.0.0.3.

Keep up the good work guys!

[ChronoReverse]

Works and is fast. This wins.


I'm not sure how the Aspect signaling things work but an clip in mp4 resized itself automatically (like it should) in Zoomplayer when I tried playing it using 0.0.0.2 (and 0.0.0.3). So does this already support it or is this something about the container that Haali's splitter handles instead?

[foxyshadis]

I know this is a little off-topic, but since I want to switch off ffdshow to use this for a while, is there a way I can run the output through avisynth without creating a new script with directshowsource(file) for every file? If not I'll find a way around it with batch files or scripts, but it'd be cooler if it did. ;)

[SeeMoreDigital]

I'm not sure how the Aspect signaling things work but an clip in mp4 resized itself automatically (like it should) in Zoomplayer when I tried playing it using 0.0.0.2 (and 0.0.0.3). So does this already support it or is this something about the container that Haali's splitter handles instead?AR signalling detection does not appear to be working in either .AVI or .MP4 for me :(

[ChronoReverse]

No idea why it works for me and not you =(

I have the latest Haali Splitter installed and played the .mp4 (video only) clip using Zoomplayer Standard 4.51 using Derived Aspect setting.

The .mp4 file is a 640x432 video with the pixel set to 6:5 in megui. Zoomplayer automatically resizes to 768x432 (in VMR9 Windowed... VMR9 Windowless seems to have a bug with it) with both FFDSHOW and CoreAVC.

Of course, I'm probably not understanding how it works...


confirmed: it only works with CoreAVC + haali splitter. gabest splitter failed for mp4....

Ah, there it is. I'm using Haali's Splitter.

[kurt]

AR signalling detection does not appear to be working in either .AVI or .MP4 for me :(
confirmed: it only works with CoreAVC + haali splitter. gabest splitter failed for mp4....
TCPMP works fine btw :)

testfile (http://home.arcor.de/evil.bert/test/hq%20slowest.cqm.sar.mp4)

[bond]

anamorphic resize doesnt work here with coreavc with either haali or gabests mp4 splitter with vmr7 and vmr9
haali works with overlay mixer (1 and 2) and the old video renderer, but gabest doesnt

[ChronoReverse]

anamorphic resize doesnt work here with coreavc with either haali or gabests mp4 splitter with vmr7 and vmr9
haali works with overlay mixer (1 and 2) and the old video renderer, but gabest doesnt


Okay... now I need to figure out what I did to make it work on my end with VMR9 Windowed.

[wata]

anyone using matrox g400 32mb (latest driver)
can't play any 720p trailers from apple using directdraw, 50% drop frames
if switch to gdi, playable but with a few drop frames
i am using amd64 3500+ with asus a8v deluxe board
i saw people using axthonxp and play 1080i no problem, does this have to do with the old videocard i am having, any setting to fix.

the same trailer clip can be play using either nero or ffdshow filter with mpc.

[ChronoReverse]

If you're using VMR modes, it's almost certainly it since those modes require a fast enough video card that can handle the resolutions you're playing at.

[wata]

i am using the latest tcmp player with the latest avc plugin to play

[ChronoReverse]

Not sure then since I haven't used that player.


Bug report (I think).

Media Player Classic 6.4.8.7
Video clip is Vorbis + AVC + .ass softsubs inside .mkv using AR signaling.

When using CoreAVC Aspect Ratio is automatically corrected in MPC, but the softsubs will not show up.

As soon as I switch back to ffdshow, Aspect Ratio is no longer automatically corrected but the softsubs do show up.

Incidentally, in Zoomplayer, the Aspect Ratio is corrected regardless of whether I use CoreAVC or ffdshow.

Hmm, none of the VMR9 features in MPC seem to work with CoreAVC. Does CoreAVC do something that doesn't jive with VMR9 renderless?

[kurt]

anyone using matrox g400 32mb (latest driver)
can't play any 720p trailers from apple using directdraw, 50% drop frames
if switch to gdi, playable but with a few drop frames
i am using amd64 3500+ with asus a8v deluxe board
i saw people using axthonxp and play 1080i no problem, does this have to do with the old videocard i am having, any setting to fix.

the same trailer clip can be play using either nero or ffdshow filter with mpc.
I also have this videocard - but in my secondary pc (PIII, 1ghz, 256 MB RAM)...

full anamporphic x264 dvdrips (704x432) are able to play smoothly up to ~2000kbps with AC3 sound in mkv container with this decoder :) (need to do some more tests with even higher bitrates)

Did you try mplayer for comparison? (have a look here (http://forum.doom9.org/showthread.php?p=727638#post727638) to setup mplayer)
The hdtv trailers (720p) I didn't check out yet (could do this only at the weekend) but in my case I guess the cpu/low RAM is the limited factor ...

[dzy]

Hmm, none of the VMR9 features in MPC seem to work with CoreAVC. Does CoreAVC do something that doesn't jive with VMR9 renderless?

VMR9 doesn't accept the two output formats CoreAVC supports now. Colorspace convertion might cause a severe performance impact though.

[videomixer9]

For me it works just fine ... using DirectX 9 Dec 2005, GeForce FX 5600 and 83.10 Forceware with MPC and 0.0.0.3 DShow CoreAVC and Haali, both Overlay and VMR9 ... anamorphic encodes also play fine incl. softsubs (both vsfilter and mpc internal one).

[SeeMoreDigital]

For me it works just fine ... using DirectX 9 Dec 2005, GeForce FX 5600 and 83.10 Forceware with MPC and 0.0.0.3 DShow CoreAVC and Haali, both Overlay and VMR9 ... anamorphic encodes also play fine incl. softsubs (both vsfilter and mpc internal one).Hmmmm!

Somewhere along the line Haali's filters must be interpreting the "streams" AR signalling data and sending it along to the media player, because without Haali I can't get AR signalling to work at all in MPC or (shock horror) WMP10.


Cheers

[bond]

basically the nero mp4 parser was the one which introduced the way how avc mp4 parsing is done now in as good as all mp4 parsers (haali, gabest, elecard...), so its in a way the benchmark

coreavc shows the same behaviour with the nero parser as with gabest here, which tells me coreavc doesnt read out the anamorphic resize correctly it gets from the parsers (they attach the SPS/PPS storing the ar info)
propably haali does something additional/different which makes coreavc work

but still, this means coreavc has incomplete anamorphic resize support with mp4

[SeeMoreDigital]

....but still, this means coreavc has incomplete anamorphic resize support with mp4Agreed ;)

[BetaBoy]

picard noted it is on Toff to add it to the DS filter as the decoder now can pass the AR info parsed from video stream.

[Ice =A=]

@ChronoReverse:
Could you tell me how to use CoreAVC in MPC? Thanks!

[ChronoReverse]

Um, I'm presuming you mean how to install the CoreAVCDecoder.ax? MPC uses dshow filters just like many other players do.

In WinXP:

regsvr32 <pathto>\CoreAVCDecoder.ax

You may have to open the ffdshow settings and turn off h.264 decoding (stop it from using libavcodec).

[lexor]

ooh and Pickard (or anyone from Core team or anyone else for that matter) is there a way to make seek slider appear in full screen? it's kinda weired now having to minimize to seek.

[Ice =A=]

@ChronoReverse: Thanks for your help, I mixed up the direct-show decoder with that tcpmp plugin. To be honest, I still don't quite understand it, but I don't have to know everything... :)

[ChronoReverse]

VMR9 doesn't accept the two output formats CoreAVC supports now. Colorspace convertion might cause a severe performance impact though.

I'm not sure if this has been asked yet, but what are the two formats that CoreAVC uses?

And which are the ones that VMR9 supports?

Check that, is it YUY2 and RGB?

[videomixer9]

VMR9 Renderless in MPC seems to have YUY2 enforced, windowed always used YV12 with videos also using it if I didn't convert to RGB manually.

VMR9 is btw. b0rked for me since some time already, fullscreen stutters around or it stutters if I put another window on top of MPC, with any video driver and decoder ... dunno what's so great about VMR9 anyways, just keep using Overlay, works great and bugfree ... I only remember a post that CoreAVC supports only YV12 ... did I overread another format being supported now?

[ChronoReverse]

VMR9 Renderless in MPC seems to have YUY2 enforced, windowed always used YV12 with videos also using it if I didn't convert to RGB manually.

VMR9 is btw. b0rked for me since some time already, fullscreen stutters around or it stutters if I put another window on top of MPC, with any video driver and decoder ... dunno what's so great about VMR9 anyways, just keep using Overlay, works great and bugfree ... I only remember a post that CoreAVC supports only YV12 ... did I overread another format being supported now?


Does it now?


As for VMR9 being borked, it works fine for me. I generally use it in MPC for the prettier softsubs (the only reason I use MPC). In ZP, I turn it on for the VMR9 style colour controls.

[videomixer9]

Oh well it my VMR9 works but not using Direct3D, if you render with Direct3D it fails with stuttering around ... as to SeeMoreDigital ... maybe try another ASP decoder, if the decoder somehow enforces this, not like there not enough MPEG4 SP/ASP decoders ... (oh well seems many more answered before me, quite much activity currently here!)

As Toff already mentioned I too dislike the concept of those huge all incl. packs like ffdshow as it's basically killing the dshow concept ... I like to have each for it's own ... especially as you can get the best for anything then easily without having to carry around the bloat of other ffdshow stuff e.g. like I never needed all those filters in ffdshow and some things like the vorbis decoder was always buggy.

[[Toff]]

I'm not sure if this has been asked yet, but what are the two formats that CoreAVC uses?

And which are the ones that VMR9 supports?

Check that, is it YUY2 and RGB?

CoreAVC currently output YV12 or I420 which are 12 bits planar format (Y,U,V plane are separated and not interlaced like YUY2 for example).

VMR9 support is probably dependant of the hardware you use. For example here it support YV12 without problem (Radeon 9600 pro).

I mostly use just the old Overlay Mixer myself.

[videomixer9]

I think not supporting YV12 for a video renderer would be quite dumb as almost any material is encoded in YV12 ...

[[Toff]]

About AR handling, I'v only tried Haali splitter so it's very possible to be buggy with other splitters. I will try Gabest's splitter.

[ChronoReverse]

']CoreAVC currently output YV12 or I420 which are 12 bits planar format (Y,U,V plane are separated and not interlaced like YUY2 for example).

VMR9 support is probably dependant of the hardware you use. For example here it support YV12 without problem (Radeon 9600 pro).

I mostly use just the old Overlay Mixer myself.


Well looking at the Graph information output in Zoomplayer, both ffdshow and coreAVC outputs to yv12 and works fine in VMR9 (i.e., the VMR9 colour controls work).


It seems like with MPC, it somehow renders not using VMR9 though...

[videomixer9]

Btw. I noticed a quite funny thing, while the aspect ratio is mostly correct with actual playback, te thumbnails created via haali for video with AVC are wrong in aspect ratio ... with other codecs this works fine in any container, thumbnails are all stretched to max size. I dunno how thumbnails are generated, but as I understand it create a graph for the requested frame and shows this, with ffdshow widescreen movies had fitting aspect ratio thumbnails, with CoreAVC not ... odd.

[SoleBastard]

Wow, this decoder just rocks:

I tried it on my Tungsten T5 (Intel Xscale 420MHz) with a personal encode using the following encoding settings:

Nero Recode 'Max definition' (b-frames, CABAC, the works)
576x328
25fps
80kbps HE-AAC
around 600kbps video bitrate

...And it *almost* runs smoothly! With 'Disable AVC deblocking filter' it runs with acceptable speed (stillf frame-dropping but in sync) at full screen! This is just amazing :D. I hope if I'd use LC-AAC and 480*xxx I can get smooth playback on my T5...

Thank you for this kick ass decoder 8)

/edit

benchmark info (disabled avc-deblocking filter):
Average speed: 60.55%
Benchmark FPS: 15.14

Ah well, I guess it looks better then the cold hard numbers tell. Can't spoil the fun for me though ;-)

[videomixer9]

well as long as anybody knows what is meant, it's just that 4CC is understood by much more ppl then those who'll know instantly what subtype will describe ...

Except that tool like hypersnap are imo useless you cannot capture overlays really, no matter which tool you're using. What you see in your shoot is the video you opened and it moves as the overlay position is set to your player coordinates, but the color supposed to be the placeholder for the video also works in screenshots of it, thus overlay video is also placed into any areas that have the same overlay colorcode.

Btw. usually in the filter list overlay mixer or videomixing renderer 7 should appear listed, my filterlist only looks like yours if ancient rendering is used. Oh well whatever, maybe something to do with the standard thing.

[sillKotscha]

you cannot capture overlays really, no matter which tool you're using.

hmm, look above at SMDs screencapture_image...

What you see in your shoot is the video you opened and it moves as the overlay position is set to your player coordinates, but the color supposed to be the placeholder for the video also works in screenshots of it, thus overlay video is also placed into any areas that have the same overlay colorcode.

I know, I know... it's just the fact that I thought hypersnap might do well in that respect

Btw. usually in the filter list overlay mixer or videomixing renderer 7 should appear listed

it does, if another renderer is used instead of the standard one :)

Oh well whatever, maybe something to do with the standard thing.

see above...

[videomixer9]

whenever I use standard vmr9 pops up even though vmr7 and overlay mixer work fine ...

[ChronoReverse]

hmm, look above at SMDs screencapture_image...

He's probably using a VMR mode in which case screenshots work just fine (and another reason I use VMR).

[AVmaniac]

I did a reencode on the X-Men3-HD-Trailer with megui-x264-awesome-setting
[1920x816@2048kbps]
When using ffdshow for the decoding i had a 99% CPU load on my Athlon64-3400+So754 Machine ...
Since i use the CoreAVC-DS-Filter i've an average load of 65% for the same video ...

simlpy GREAT !!!
You folks at CoreCodec really did a great job !!!! THX !!!!! and please go on !!!

[Sharktooth]

This thing is getting faster and faster... :D
Keep up the good work guys

[FFWD]

Hi BetaBoy,

I have an iPaq rx3715 Windows Mobile 2003SE pocket pc. I installed these components on my iPaq File Store;

tcpmp.setup.0.71h.exe
ac3.setup.0.71h.exe
ffmpeg.setup.0.71h.exe
avc.setup.0.71h.exe
tcpmp_aac_plugin.windows_mobile.0.66.zip

However, when I try to play back an H.264/AVC file, I get an "avc decoder not found" error. If I remove the "avc.setup.0.71h.exe" plug-in, I can play back the file (with ffmpeg plug-in), but I only see a new frame each 5 seconds :-/

The .mp4 file was made with MeGUi and the x264 codec. I used the MeGui HQ Slowest preset.

[bob0r]

What about a splitter and decoder in 1?

Once CoreAVCDecoder.ax is "finished" and ready to ship with the x264 installer, it would be great to run a splitter at the same time, as then we have a complete package.

I will still host the alternative splitters and decoders, but its just a thought on how to further take over the world.

[grouik]

Very Nice Decoder i can now play 720p AVC trailer on a simple 2400+ with sdram, 1080p need a little more power it was playaing at 22 fps as well

Good Job and Thanks a lot

What about a "corevc1" ? (joke)

[3ngel]

Many compliments for the AVC ds filter, this filter was something really miss :cool:

You may ask for a CoreASP
This would be another SO GREAT thing to have :), as now ASP is the most difficult coding to read correctly (atm only Nero itself and 3ivx decode it correctly, ffdshow has a little brightness problem (and moreover i hate ffdshow :))).

[GhengisKhan]

Hahaha! I love you Picard! Unbelievable! My 1.6Ghz Intel Centrino Proc. now can decode 1080p perfectly! Actually, the benchmark said 117.83% average speed (that's with one IE page open - it couldn't even decode it that well before)!

This is all using TCPMP Win32. I couldn't get it to work properly using the Directshow filter in WMP10. But, playing in TCPMP is enough for me now!

Thanks again Picard - and all the other devs helping :thanks: ,

GhengisKhan :cool:

P.S. I am considering "switching" (that means dual booting) to Mac (Intel Macs of course). Can anyone tell me about how the development is going that arena? I'm assuming it won't be that big of a deal - but, I can't be sure. Thanks again.

P.P.S. why don't I get audio in WMP10 (playing 1080p V is for Vendetta Trailer 2) and why does it skip so many frames? I thought the Directshow filter wasn't supposed to be that much slower...

[tomos]

just found out about this tonight, worked a treat - thanks all and keep up the good work :)

[[Toff]]

New build up :
http://coreavc.corecodec.org/CoreAVC20060113.7z

Version 0.0.0.4 Alpha (20060113) :
Support for VSSH FOURCC
Support for YUY2 output
Force anamorphic flag on renderer

You can thank Haali for this release ;-)

(I haven't look at this .ts sample yet)

[chichazor]

¿Can anybody make a simple setup for the directshow version?

[ChronoReverse]

Cool, I'll test this out as soon as I get home.


@chichazor

I have a few batch files to do it but frankly, just use Regdrop (http://www.addisonsw.com/revsqu.htm). Drag the ax to the executable to register it and drag it with shift held down to unregister.

[Scoty]

this Codec is very great. with MPC i can run it but how can i use with WMP 9 or 10 ?

[loni_blues]

And for lossless support?

[ChronoReverse]

']New build up :
http://coreavc.corecodec.org/CoreAVC20060113.7z

Version 0.0.0.4 Alpha (20060113) :
Support for VSSH FOURCC
Support for YUY2 output
Force anamorphic flag on renderer

You can thank Haali for this release ;-)


Haali gets a cookie. VMR9 Renderless mode is working perfectly in Media Player Classic now. I'm getting my automatic aspect ratio and my softsubs.

[Pookie]

You CoreAVC guys deserve medals for this big leap in playback functionality, and I mean BIG !

Thank you very, very much :)

[LigH]

']Support for YUY2 output
...
You can thank Haali for this release ;-)
Yes - thank you [Toff], thank you Haali. YUY2 output will help my old and crappy GeForce2 a little.

[hippoth]

@BetaBoy

A new TCMP-version (NOT TCPMP) is coming soon (I hope so). What can we expect in relation to AVC support? Is it similar to TCPMP?

[SeeMoreDigital]

Hmmm.

I'm still unable to get anamorphiclly signalled MPEG-4 AVC streams within AVI to auto AR in Media Player Classic or WMP10. And it's no-go with MPEG-4 AVC streams within MP4 in Media Player Classic too!

When tested on my other WinXP boot, the same encodes work fine with Haali's splitter!


Cheers

[sillKotscha]

Hmmm.

I'm still unable to get anamorphiclly signalled MPEG-4 AVC streams within AVI to auto AR in Media Player Classic or WMP10. And it's no-go with MPEG-4 AVC streams within MP4 in Media Player Classic too!

at first I've experienced the same beahviour with your posteted clip - but than I've reinstalled latest Haali Media Splitter and wOOt :)

what about http://tcpmp.corecodec.org/tcpmpx/index.htm ?

I can't see anything 'cause FireFox does need a plugin and I'm to dumb to install the required one...

[bond]

basically the nero mp4 parser was the one which introduced the way how avc mp4 parsing is done now in as good as all mp4 parsers (haali, gabest, elecard...), so its in a way the benchmark

coreavc shows the same behaviour with the nero parser as with gabest here, which tells me coreavc doesnt read out the anamorphic resize correctly it gets from the parsers (they attach the SPS/PPS storing the ar info)
propably haali does something additional/different which makes coreavc work

but still, this means coreavc has incomplete anamorphic resize support with mp4still the case with 0.0.0.4

anamorphic resize works with haali's mp4 parser, but not with nero's (and all the other mp4 parsers acting the same way as nero, like gabest, elecard...)

therefore i think haali does something different than all the others making coreavc not resize and therefore the support in coreavc is, unfortunately, still incomplete

[SeeMoreDigital]

....therefore i think haali does something different than all the others making coreavc not resize and therefore the support in coreavc is, unfortunately, still incompleteAgreed....

I cross-checked to see if Media Player Classic's own internal MP4 parser was working okay by playing some anamorphic MPEG-1 and MPEG-2 in MP4 streams (muxed using YAMB/MP4box) and they work perfectly ;)


Cheers

[bond]

'] Support for YUY2 outputthx to this i can now connect to vmr9 without the need for the avi decompressor doing the colorspace conversion

some random speed comparison between yv12 and yuy2 output:

yv12: 72.32fps
yuy2: 67.47fps (-7%)

edit:
is the colorspace conversion done in coreavc lossless?

[3ngel]

New build up :
http://coreavc.corecodec.org/CoreAVC20060113.7z

Version 0.0.0.4 Alpha (20060113) :
Support for VSSH FOURCC
Support for YUY2 output
Force anamorphic flag on renderer

It works absolutely great on my side! Great!

One question, how can i know what colorspace is used during the decoding? I use MPC. Is there a way to force the output colorspace to RGB? You can add the option in the control panel of DirectShow filter to decide the output color space?

[videomixer9]

Isn't there a way to make GPU do all the colorspace conversions via directx or something? I still wonder why this things cannot be easily done via simple interfaces to the graphics adapter. Imo VMR9 should've been made that way though, connect with anything and convert via hardware to anything else ... but now I'd think filters could fix this up at least maybe ...

[Koti]

']New build up :

Version 0.0.0.4 Alpha (20060113) :


Thx Haali , Toff , Picard , CoreCodec

[SeeMoreDigital]

Isn't there a way to make GPU do all the colorspace conversions via directx or something? I still wonder why this things cannot be easily done via simple interfaces to the graphics adapter. Imo VMR9 should've been made that way though, connect with anything and convert via hardware to anything else ... but now I'd think filters could fix this up at least maybe ...Agreed....

I wonder, would it be possible to place some "user settings" that can be accessed and adjusted via the filters "Properties" widow: -

http://img486.imageshack.us/img486/9890/coreavcsettings7cp.png


Cheers

[[)370|\|470!2]

']New build up :
http://coreavc.corecodec.org/CoreAVC20060113.7z

Version 0.0.0.4 Alpha (20060113) :
Support for VSSH FOURCC
Support for YUY2 output
Force anamorphic flag on renderer

Just great! With an YUY2 it's now possible to mess around with
saturation/brightness/contrast. Thx Core team. Keep up teh
good work. ;)

[foxyshadis]

GPUs doing colorspace conversions is what causes so many problems with YUV levels being incorrectly converted to RGB for output, and why the big flamewar over ffdshow and/or vmr9 sucking erupted. Still, it's worth investigating if you need the speed and can find a colorspace it doesn't trash.

[Revgen]

I personally have trouble with VMR9/VMR7 whever I use FFDShow or CoreAVC. I pretty much stick to Ol' Fashioned Hardware Overlay.

[Isochroma]

Thank you CoreCodec team for your awesome work! Unfortuantely, my GeForce FX5200 (and MX400) don't do either YUY2 or YV12 colorspace conversions right - the result looks really ugly - faded, washed out colors.

When you get time, it would be really great to add RGB24 output to your decode filter, thanks!

[molinacabaleiro]

mpc 6481 + ffdshow = 40% cpu
tcpmp + ffmpeg = 20% cpu

not bad, but ogg vorbis volume goes down quite a bit compared to radlight decoder

what do i do with CoreAVC.ax so mpc will recognize it?
when i uninstall ffdshow it resorts to nero for x264 playback :(

[bond]

mpc 6481 + ffdshow = 40% cpu
tcpmp + ffmpeg = 20% cpunice, but this has nothing to do with coreavc

not bad, but ogg vorbis volume goes down quite a bit compared to radlight decodernot nice, but this has nothing to do with coreavc :D

what do i do with CoreAVC.ax so mpc will recognize it?
when i uninstall ffdshow it resorts to nero for x264 playback :( register it ;)

[3ngel]

When you get time, it would be really great to add RGB24 output to your decode filter, thanks! Or even RGB32, choosable from a control panel inside the filter.

[Ice =A=]

Version 0.0.0.4 Alpha (20060113) works very well in my case. Plays all 1080-videos smoothly on an Athlon 3500+ (at least with mpc in overlay mode). Good work! :)

[breez]

Thank you CoreCodec team for your awesome work! Unfortuantely, my GeForce FX5200 (and MX400) don't do either YUY2 or YV12 colorspace conversions right - the result looks really ugly - faded, washed out colors.

Well actually the conversion is done just right, but there is a difference with video and PC levels. In video levels reference black is at 16 and reference white at 235 (0 and 255 in PC levels).

It is problematic for mixed use PCs. One either calibrates display for video or PC levels, but not for both. One can also expand the 16-235 range to 0-255 to use with a display calibrated to PC levels. This of course isn't a lossless operation (banding may occur when done at low precision). You can do the expanding with ffdshow 'levels' or only allowing RGB32 output colorspace (with HQ YV12 to RGB32 checked to get reduced banding). And at least on ATI cards the overlay mode does the expanding for you (with 10-bit precision, less banding than with 8-bit). Try overlay for starters.

[BetaBoy]

bond... should we make this a sticky now?

[SeeMoreDigital]

bond... should we make this a sticky now?Well... I agree ;)

[Sharktooth]

agreed ;)

[[)370|\|470!2]

Thumbs up! ;)

[Sirber]

I'm against!

Nothing to see, move along ;)

Why not adding it to the AVC sticky in the decoder section?

[edit]

Ha! like the "ateme beta encoder" :)

I agree then :D

[GhengisKhan]

Making this thread a sticky must be the best idea I've seen in this thread yet!

Go for it :D !

GhengisKhan :cool: