CoreCodec/H.264 Codec "CoreAVC"

[qyqgpower]

Let me say again that ffdshow have no problems with any of them except System Default, Old Renderer and VMR7 (windowed), resulting in no deinterlacing.
The topic is kinda OT, but I'll still post here.
The previous build of ffdshow (080903) works perfectly with NV12 output and interlaced flag, giving nice HW deinterlace in EVR & VMR9.
But recent, even latest build(081017) would always give wrong field order to renderer. Not only EVR & VMR9, even haali renderer(which CoreAVC could correctly work with) couldn't render the decoded interlaced frame from ffdshow (081017) correctly.

If I replace the libavcodec.dll from 080903 with 081017, the field order issue will occur. Something must be faultily modified in recent libavcodec.dll

[STaRGaZeR]

I'm using albain's lastest betas for the new audio codecs, and it's version of libav gives either deinterlacing or no deinterlacing, but always the good field order. But that's out of the question here. The fact is that both CoreAVC and ffdshow are doing something wrong with hardware deinterlacing, some renderers are at fault but not all of them and there are problems even with those that don't have issues by themselves. That's why we are here reporting bugs, to make CoreAVC a better codec and a justified purchase. Let's hope the CoreAVC guys will look at our reports.

[clsid]

Nothing is faulty in ffdshow. It has no way of knowing what field order is correct. It simply assumes an order. The current code assumes different order as before. This order is incorrect for your files, but will be correct for other files. From what I have been told the field order may differ per country.

If you can provide some information about what field order is most common that I can perhaps adjust ffdshow's behavior.

[STaRGaZeR]

The code present in albain's betas has no problems assuming field order with all my files, don't know about your builds. qyqgpower, you can test the same build I'm using (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2224_20081017_dbt_new_audio_codecs.exe?modtime=1224232861&big_mirror=0) and see if for you the order is fine too. Also, what criteria is ffdshow using for assuming one or another, and why has been changed?

However, if MediaInfo for example can determine what field order is used, ffdshow should be able too?

[qyqgpower]

Thank you for the info, clsid. As you said "It simply assumes an order", I've tested more MBAFF files with different build of ffdshow, CoreAVC 1.8.5 and Cyberlink. Renderer is EVR.
for TFF:
080903 ffdshow=TFF
081017 ffdshow=BFF < incorrect
CoreAVC=BFF < incorrect (with Haali Renderer=TFF)
Cyberlink=TFF

for BFF:
080903 ffdshow=TFF < incorrect
081017 ffdshow=BFF
CoreAVC=BFF
Cyberlink=BFF

for faultily mastered BFF(SHOULD BE output as BFF and jump back and forth)
080903 ffdshow=TFF < incorrect
081017 ffdshow=BFF
CoreAVC=BFF
Cyberlink=BFF

So the result is:
080903 ffdshow always assumes TFF.
recent ffdshow always assumes BFF.
CoreAVC always assumes BFF when connecting to EVR, but giving correct order to Haali Renderer.
Cyberlink could correctly detect the field order.

So, the detection of field order in MBAFF may be actually possible.
BFF is mostly common for PAL, and TFF for NTSC, but BFF could also be used in NTSC.
Both field order is commonly used around the world, so the best option is "Auto Detection". If it can't be done now, a possible work around would be an option to select output field order.

[qyqgpower]

The code present in albain's betas has no problems assuming field order with all my files, don't know about your builds. qyqgpower, you can test the same build I'm using (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2224_20081017_dbt_new_audio_codecs.exe?modtime=1224232861&big_mirror=0) and see if for you the order is fine too. Also, what criteria is ffdshow using for assuming one or another, and why has been changed?

However, if MediaInfo for example can determine what field order is used, ffdshow should be able too?
Yes I'm using ffdshow from sourceforge, both albain's build and xxl's build.

MediaInfo can't tell the actually field order for MBAFF H264.

[STaRGaZeR]

MediaInfo can't tell the actually field order for MBAFF H264.

Indeed, my bad. I was looking at some non MBAFF TFF NTSC files.

[clsid]

If you kindly ask Haruhiko, maybe he is willing to implement an option to configure which field order should be assumed.

[hubblec4]

hi

@ BetaBoy

Is there a development at the CoreAAC decoder (CoreAAC.ax)

I miss the 7.1channel decode for playback.


hubble

[BetaBoy]

OT... but ok.... We have had our CoreAAC decoder (directshow filter) done for well over a year now, but we have slowly been adding more profiles SBR, PS, etc. to the core. We have a bit more of coding to do on it and then QA before we sign off on it as a stand alone product like CoreAVC.

[Quark.Fusion]

This stream is correctly decodes with ffdshow, but CoreAVC produces some garbage on screen — is that decoder bug or error in stream?

http://www.savefile.com/files/1833602
http://www.fileqube.com/shared/vIRND131162

CoreAVC 1.8.5 — similar results.

[LoRd_MuldeR]

Is it intentional that the CoreAVC Decoder v1.8.5 setup installed a pretty old version of Haali Renderer on my system? :confused:

(I was confused because the "Show OSD" and "Luma Range" options were missing all of a sudden ^^)


[EDIT]

A quick hash compare showed that the HaaliMkx.exe included in the CoreAVC installer equals version 2007-01-31 of Haali Media Splitter.

[lych_necross]

Nothing is faulty in ffdshow. It has no way of knowing what field order is correct. It simply assumes an order. The current code assumes different order as before. This order is incorrect for your files, but will be correct for other files. From what I have been told the field order may differ per country.

If you can provide some information about what field order is most common that I can perhaps adjust ffdshow's behavior.

Can't you just use AssumeTFF() or AssumeBFF() in the Avisynth portion of ffdshow to correct field order problems? If not, why not include an option that forces either top or bottom field first in ffdshow?

[BetaBoy]

Is it intentional that the CoreAVC Decoder v1.8.5 setup installed a pretty old version of Haali Renderer on my system? :confused:

(I was confused because the "Show OSD" and "Luma Range" options were missing all of a sudden ^^)


[EDIT]

A quick hash compare showed that the HaaliMkx.exe included in the CoreAVC installer equals version 2007-01-31 of Haali Media Splitter.

Were looking into it.... thx for the report.

[KornX]

@betaboy...

would it be possible to raise the max resolution to a far higher level?

like quadHD?

and what is the max framerate?

My testclip won't run (but with other codecs)
50fps 3840x2160


KornX

[fleon]

Hi I have xp x64 and coreavc 1.8.5 and I'm using media player classic home cinema x64 and eventhought I have configured coreavc to be the preferred decoder and to display the tray icon that doesnt happen inestead the ffdshow x64 tray icon appear eventhought the h264 decoding in ffdshow x64 is disabled, i tried re registering coreavc but nothing..

[LoRd_MuldeR]

MPC-x64 will work with x64 filters only! But I don't think there's a x64 version of CoreAVC yet. Also there is no reason to use MPC-x64, because MPC-x86 will run on 64-Bit Windows just fine.
Usually you'll even get better performance with the x86 version, because the x64 filters available presently are far less optimized than the x86 ones...

[fleon]

I didnt knew that, so I will use ffdshow x86, mpc hc x86 inestead and keep using coreavc thanks

[LoRd_MuldeR]

I didnt knew that, so I will use ffdshow x86, mpc hc x86 inestead and keep using coreavc thanks

On 64-Bit Windows you can run x86 and x64 processes at same time. However x86 and x64 code can not be mixed in the same process!
That means: A x86 executable cannot load any x64 DLL's and also a x64 executable cannot load any x86 DLL's.

In theory x64 code should run faster than x86 code, because it has got more and wider registers available.
But in practice optimized assembler code, as used by all applications that are developed for high performance, is only available for x86, not for x64.
That's why x86 code often runs faster than x64 code. At least that's the situation for Windows at the time being.

If I remember correctly, x64 support was announced to be added to CoreAVC at a later time...

[clsid]

Well, libavcodec in ffdshow x64 is now also compiled with GCC, so it has all the optimizations that the x86 version has. In the past, before MinGW64 was around, we used MSVC for compiling 64bit libavcodec, and that resulted in bad performance. So performance is not much of an argument anymore, but stability is. The 64-bit builds of ffdshow are not as stable as the x86 builds.

[LoRd_MuldeR]

Well, libavcodec in ffdshow x64 is now also compiled with GCC, so it has all the optimizations that the x86 version has. In the past, before MinGW64 was around, we used MSVC for compiling 64bit libavcodec, and that resulted in bad performance. So performance is not much of an argument anymore, but stability is. The 64-bit builds of ffdshow are not as stable as the x86 builds.

Does your libavcodec compiled by MinGW64 include any of the optimized assembler code?

As far as I know you must disable all "hand optimized" assembler code on x64 Windows, unless you want to modify it specifically for x64 Windows.
That's because x64 Windows has some obscurities that x64 Linux doesn't have (keyword: "calling convention").
And it's also the reason why x264 can be built for 64-Bit Linux, but not for 64-Bit Windows (except you disable all the nice assembler optimizations).

[clsid]

Yes, all the assembly stuff is included.

[LoRd_MuldeR]

Yes, all the assembly stuff is included.

Wow :D

Then there is hope to get x264 fully working on MinGW64 one day? ;)

[Dark Shikari]

Most of lavc's assembly is using GCC inline syntax, not yasm/nasm, and so doesn't have the same calling convention issues.

[LoRd_MuldeR]

Most of lavc's assembly is using GCC inline syntax, not yasm/nasm, and so doesn't have the same calling convention issues.

I see. Why decided the x264 developers to use yasm/nasm instead of GCC inline syntax?
MSVC compatibility isn't really an argument, because most of the Assembler must be disabled for MSVC anyway...

[squid_80]

I see. Why decided the x264 developers to use yasm/nasm instead of GCC inline syntax?Probably because it's only compatible with GCC...
MSVC compatibility isn't really an argument, because most of the Assembler must be disabled for MSVC anyway...
Not sure why you think x264 can't be built with asm by MSVC (there was the stack alignment thing but that's not an issue if you know what you're doing).

[LoRd_MuldeR]

Not sure why you think x264 can't be built with asm by MSVC (there was the stack alignment thing but that's not an issue if you know what you're doing).

Well, there definitely is a problem with MSVC and stack alignment that makes various ASM functions in x264 crash. I think it's the SSE functions that are affected.
Currently x264 has a workaround for MSVC and will disable all the problematic ASM code when built by MSVC. But the build will be significant slower than a GCC build.
So in fact you are bound to GCC, if you want to have a build that has all the nice ASM speed-optimizations. And who doesn't ???

That in mind, using the GCC inline syntax would not be a big drawback. You'd need to disable all ASM code for MSV, instead of a significant part of it. So?
But there would be a big benefit: Thanks to MinGW64 you would be able to get a fully working x64 build of x264 for Windows with all ASM enabled and a huge speed-up.
If I remember correctly, it was stated that a x64 Linux build of x264 runs ~20% faster than a x86 Windows build at the moment.

I guess the biggest problem would be to convert all ASM code from nasm/yasm syntax to GCC inline syntax. Far too much work, if possible at all...

[Guest]

if possible at all... It's statements like that that show you have an agenda and are not a seeker after truth.

[Dark Shikari]

Probably because it's only compatible with GCC...No, because GCC Inline syntax is unbelievably awful to code in, especially for very complex functions, due to its ugly syntax and weak macro capabilities.

[squid_80]

Well, there definitely is a problem with MSVC and stack alignment that makes various ASM functions in x264 crash. I think it's the SSE functions that are affected.
Currently x264 has a workaround for MSVC and will disable all the problematic ASM code when built by MSVC. But the build will be significant slower than a GCC build.
So in fact you are bound to GCC, if you want to have a build that has all the nice ASM speed-optimizations. And who doesn't ???Like I said, it's fixable if you know what you're doing (i.e. how function calls work at a low level). If you're someone who just chucks code into compilers without understanding it, yeah you're stuck with GCC. :P

That in mind, using the GCC inline syntax would not be a big drawback. You'd need to disable all ASM code for MSV, instead of a significant part of it. So?
But there would be a big benefit: Thanks to MinGW64 you would be able to get a fully working x64 build of x264 for Windows with all ASM enabled and a huge speed-up.
If I remember correctly, it was stated that a x64 Linux build of x264 runs ~20% faster than a x86 Windows build at the moment.So you propose rewriting all the asm to (ugly and general PITA to work with, thank you) gcc inline syntax, just to get win64 working? It would be far easier to fix the existing asm to work with win64 (which does use a 16-byte aligned stack btw).
MS b0rked the ABI for win64 from the start, then decided it wasn't bad enough and b0rked it some more after XP64 RC1*. x264-64 for windows will never see the same speed increases over x264-32 as the linux version.

(* - Ever have trouble finding a win64 device driver? Imagine you write drivers for a living; MS comes and says we've got a new OS coming, here's the specs if you want to make a new driver for it. So you write a new driver using their specs, then BAM! Right before the OS is released, the specs change and your new driver is now broken. Would you rewrite it again, or just say screw MS and their new OS and bin the whole thing?)

[Quark.Fusion]

IMHO 64-bit is future, so earlier or later you will face the need to make x64-compatible build. The choice is to wait when "OS" will be released or do it during its development. And of course the last worsest choice is to be lazy and not doing it at this time.

[dukey]

I've got a problem with coreavc
It basically won't play some h264 videos (with mkv container) unless i load it, stop the video in direct show and play it again. Then it will start playing.

I am using my own renderer, currently it only supports the RGB24 colour space.

I am running my graph like this

CoInitialize(NULL);

if(FAILED(CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER,IID_IGraphBuilder, (void **)&iGraphBuilder))) {
printf("creating filter graph failed\n");
return E_FAIL;
}

oglRenderer = new OpenglRenderer(NULL, &hr);
oglRenderer->setupOpengl(hwnd,hglrc,hdc);

if (FAILED(hr) || !oglRenderer) {
delete oglRenderer;
printf("Could not create texture renderer object! hr=0x%x", hr);
return E_FAIL;
}

// Get a pointer to the IBaseFilter on the TextureRenderer, add it to graph
iRenderer = oglRenderer;

if (FAILED(hr = iGraphBuilder->AddFilter(iRenderer, L"OpenglRenderer"))) {
printf("Could not add renderer filter to graph! hr=0x%x", hr);
return hr;
}

iGraphBuilder->RenderFile(fileName,NULL);

if(FAILED(hr = iGraphBuilder->QueryInterface(IID_IMediaControl, (void**)&iMediaControl))) {
printf("could not get iMediaControl interface\n");
return hr;
}

if(FAILED(hr = iGraphBuilder->QueryInterface(IID_IMediaSeeking, (void **)&iMediaSeeking))) {
printf("could not get mediaseeking interface\n");
return hr;
}

if(FAILED(hr = iGraphBuilder->QueryInterface(IID_IMediaPosition, (void **)&iMediaPosition))) {
printf("could not get iMediaPosition interface\n");
return hr;
}

if(FAILED(hr = iGraphBuilder->QueryInterface(IID_IMediaEventEx, (void **)&iMediaEvent))) {
printf("could not get iMediaEvent interface\n");
return hr;
}

iMediaEvent->SetNotifyWindow((OAHWND)hwnd, WM_USER, 0);
iMediaEvent->SetNotifyFlags(0); // turn on notifications

Then i run it like this
iMediaControl->Run();

Only with *some* videos, and CoreAVC it appears to do nothing. No sound plays, no video, nothing gets sent to the renderer. I check the state of the graph and it claims the graph is running. With FFDshow and libavc it works perfectly. Maybe there is a bug somewhere? I am using the latest version of Haali's media splitter.

[dukey]

This problem is definitely to do with CoreAVC and not my program. I set the output type in coreavc to RGB24

now
http://img338.imageshack.us/img338/1545/heroesdshowxx0.jpg

When i try to run it.
http://img368.imageshack.us/img368/2597/errorlm5.png

Strangely, after this error has come up and I try to run the graph again, it works. When I use a different h264 decoder, it works ! no problems ie ffdshow.

[squid_80]

What's the format type of CoreAVC's output pin before and after the error message?

[dukey]

I think CoreAVC's 24bit output must be broken, it doesn't seem to want to output rgb24 at all, only RGB32
when i force the output type as RGB32 it works like a champ
maybe i'll try and make my renderer support that as a work around

[me7]

A small noob question: Do the output formats provide different performances? If yes, which one is the fastest?

[LoRd_MuldeR]

A small noob question: Do the output formats provide different performances? If yes, which one is the fastest?

YV12 should be the fastest, because that's the "native" format. Hence using YV12 output will prevent any color-space conversion.

Of course the YV12 to RGB conversion needs to be done at a later time then, e.g. in the renderer...

[me7]

YV12 should be the fastest, because that's the "native" format. Hence using YV12 output will prevent any color-space conversion.

Of course the YV12 to RGB conversion needs to be done at a later time then, e.g. in the renderer...

Is one of these two methods known to be faster?
MPC offers three renderers with subtitle compatibility (VMR7 (renderless), VMR9 (renderless) and EVR Custom preset), is one of them "better/faster" than the others?

I'm currently trying to turn my HDMI equipped laptop into a mobile HD-machine and want to squeeze every last bit of performance out of it ;)

[LoRd_MuldeR]

This depends on how the renderer is implemented. In the worst case the renderer will do it in software, in the best case the renderer will use the GPU to do it.
Also if you feed YV12 into the VMR7/VMR9/EVR renderers you often get wrong levels. However there is a shader available in MPC to fix the "levels" problem...

[clsid]

You don't need a renderer with subtitle compatibility. If you use VSFilter for subtitles, you can use any renderer you want. Overlay Mixer has the lowest CPU usage and also does not suffer from luminance levels issues.

[me7]

All right, I'll try YV12 with Overlay Mixer. Thanks to both of you.

[squid_80]

I think CoreAVC's 24bit output must be broken, it doesn't seem to want to output rgb24 at all, only RGB32If the connecting filter won't accept RGB24, obviously CoreAVC won't output it. But it should offer it, which is why I asked what the output format is before and after you see the error message. Also check with the pin disconnected, it should offer 4 types of RGB24 (VideoInfoHeader/VideoInfoHeader2 and Bottom-Up/Top-Down).
There really shouldn't be any need to force a particular colorspace at all, if your renderer only supports RGB24 then that is what it should request from CoreAVC. If it is accepting whatever formats are offered to it then it's broken.

[dukey]

I cant even get the RGB output types to work in graph edit with vrm7/9 without errors, so I don't think it's going to work in my program (without errors).

So just gonna have to stick to use ffdshow and libavcodec for now.

[dukey]

I found out what was causing my problem
in the mkv splitter force 25fps was set, causing random behaviour downstream, problems solved now :)

[fleon]

Overlay Mixer has the lowest CPU usage and also does not suffer from luminance levels issues.

I was reading that this discussion and since I have been using VMR9 and your argument is valid, I changed it to overlay mixer but then I noticed that the video was too dark, and I thought that it must be because of my monitor I'm using a Samsung Syncmaster 732n plus I tried to calibrate the colors and everything but I'm still not sure about it, how can I get the true colors?

[dukey]

tell the decoder to output RGB24 or RGB32
the thing with VRM7/9 is when they are given YUV or however its packed
they will use the scale 0-255, instead of 16-239 or whatever it is. So all blacks, instead of being black will end up brighter.

[fleon]

According to avisynth by using info() my video is YUV12 because of what clsid said i want to keep using overlay mixer, but as I said the problem is that my monitor(Samsung Syncmaster 732n plus) doesnt seems to be well calibrated so keeping all that how can I calibrate my monitor to show the true colors

[clsid]

Why do you think your monitor is the cause? Your graphics driver settings are more likely the cause. Those often have settings that mess with colors.

[fleon]

Why do you think your monitor is the cause? Your graphics driver settings are more likely the cause. Those often have settings that mess with colors.

You are right that is also a posibility, but I dont think I can discard the monitor thing, since I changed some settings like constrast and brightness maybe it was just the graphic driver but now maybe is also the monitor, for what is worth I have an ati x1650 pro with the 8.10 drivers x64, I have windows xp x64

[LeMoi]

When switching from a segment to another in a multi-segment mkv file, x264 video disappears (using latest Haali Media Splitter)