CoreCodec/H.264 Codec "CoreAVC"

[Frank K Abbott]

The major bug I see is when seeking through mkv files. It is a problem that needs to be fixed. Seeking properly with open GOPs requires the decoder to go back an extra GOP. Also I have a small feature request. Can you add a width/height black border setting in pixels somewhere? When I stream to my tv it cuts off a bit from the sides and i have to end up zooming out a little bit through MPC-HC's zoom feature. unfortunately that zoom has big increments and i never get the picture perfectly showing. ffdshow has a pixel-based border setting which works out perfectly.

[Keiyakusha]

Can you add a width/height black border setting in pixels somewhere? When I stream to my tv it cuts off a bit from the sides and i have to end up zooming out a little bit through MPC-HC's zoom feature. unfortunately that zoom has big increments and i never get the picture perfectly showing. ffdshow has a pixel-based border setting which works out perfectly.
Why not put ffdshow postprocessor after coreavc and do any kind of processing you want? Way better than anything you can expect from single decoder.

[ChronoCross]

and answering with a statement rather then answering what bugs we have not addressed and or replied too helps who? As far as releases... We think we have been good in the quality of the last few 1.9.x and 2.0 releases and making them as bug free as possible. I attribute that to 1) Our devs doing QA, 2) The amazing job the beta test group does 3) Sites like here at D9 and, 4) The feedback we get from our OEM customers... and to that... you are right, if there were any major bugs in 2.0 as it stands right now we would be aware of it, and we are not.

Addressing complaints involves fixing them and providing that fix to your client base, responding with "noted" or "this is not a showstopper" doesn't constitute it being addressed. If it's fixed internally it means nothing if one has to wait 6 months to a year for a major release fix.

One of the issues that comes directly to mind (without me wasting time going through this thread) is seeking in CoreAVC takes 3-5 seconds while ffdshow, and Divx seeking is instant. If the other two weren't instant I would say it's my computer.

[Frank K Abbott]

Why not put ffdshow postprocessor after coreavc and do any kind of processing you want? Way better than anything you can expect from single decoder.

Wouldn't that mean that ffdshow would re-process the output coming from CoreAVC? My setup right now is MPC-HC, Haali Renderer, [CoreAVC auto in levels, auto out levels, output RGB32 (rest unchecked)], [ffdshow set to HQ YV12 -> RGB32, TV levels in, Computer levels out]. So it would be like RGB32 coming from CoreAVC being reprocessed to RGB32 again with ffdshow and with level conversions based on the tv in/comp out settings?

One of the issues that comes directly to mind (without me wasting time going through this thread) is seeking in CoreAVC takes 3-5 seconds while ffdshow, and Divx seeking is instant. If the other two weren't instant I would say it's my computer.

I have the same exact issue with CoreAVC. I think two people and more saynig the same exact thing without any agenda for their own product advertisement constitutes a problem with the decoder and not with the users or their computers.

[Keiyakusha]

Frank K Abbott
re-process? the only "processing" by CoreAVC is a converting to RGB. Turn that off by outputting yv12 and ffdshow will do conversion if you need RGB. Also ffdshow's conversion can give higher quality, depending on settings.
EDIT: well if you only need to add borders, you can leave RGB output in CoreAVC. Thats up to you.

[Frank K Abbott]

Frank K Abbott
re-process? the only "processing" by CoreAVC is a converting to RGB. Turn that off by outputting yv12 and ffdshow will do conversion if you need RGB. Also ffdshow's conversion can give higher quality, depending on settings.
EDIT: well if you only need to add borders, you can leave RGB output in CoreAVC. Thats up to you.

How do I adjust the filter chain in order to have CoreAVC decoding and ffdshow just post processing as you have said?

[Keiyakusha]

Add raw filter to MPC-HC external filters, set merit to preferred if it doesn't loaded, and configure as you like. It should be set to process colorspace that came from CoreAVC. Postprocessor (raw filter) now has separate settings from ffdshow decoder.
Adding to external filters is needed because due to some bug MPC-HC doesn't wants to load any filters between decoder and renderer. At least on Win7.

[Frank K Abbott]

Wow, I absolutely love this! Now I can post-process everything with AviSynth on-the-fly :D Thanks so much!

[BetaBoy]

I have the same exact issue with CoreAVC.
We are looking into what we can do to work around any open GOP.... but as even Haali just noted to me "how do you detect an open gop in the first place".

[squid_80]

Which splitter is being used by the people seeing corruption after seeking?

[kemuri-_9]

You can get it right for the vast majority of cases by saying it is open if the first frame in display order is a B frame.

that logic fails for open gop streams generated by x264.

[hajj_3]

What filetypes and codecs will Coreplayer for Android be able to play? Will it be powerful enough to play 720p via HDMI out with the 1GHZ snapdragon cpu's ?

[CruNcher]

Hehe on the Cortex A8 with Neon i guess possible though don't expect extreme profile support and bitrates for example 30 fps Realtime playback :D

[hajj_3]

i was hoping 3000 bitrate x264 1280x720 L4.1 might play on a snapdragon 1ghz cpu, would be cool to play 720p tv/movies on your tv from your phone, alot less power required compared to a laptop and silent.

[CruNcher]

Hajj_3 sure these solutions already exist (via HDMI out 1080p HP L4.1 Low Power no problem, as MIPS and ARM solutions with special Decoding IP) though not in Phone factors yet, will still take some time before they come to market and also what you can see currently they will be again limited according to rumors for example about the Nvidia Tegra2 and it's based Boxxe box (might disappoint many) also Omap4 in general seems to be limited.

[hajj_3]

yeah i know there's standalone devices that can play them like WD HD media player etc was just hoping that the snapdragon cpu's might be powerful enough to handle 720p. There's 1.2/1.3ghz dual core snapdragons coming in a few months too.

[Guest]

that logic fails for open gop streams generated by x264. They are not really open. I revised and extended my remark here:

http://forum.doom9.org/showthread.php?p=1416044#post1416044

[Frank K Abbott]

@ Keiyakusha
I just want to make sure I'm doing this right. I have CoreAVC set to output only YV12 and ffdshow set to output only RGB32 with high quality conversion and dithering enabled. ffdshow input levels are standard and output is computer. However I don't understand what CoreAVC is doing with the "Input Levels", "Output Levels", and "Input colorspace (set to auto)" if ffdshow is already doing those conversions and settings. Does CoreAVC only decode the stream and send it to ffdshow as is with no levels conversions or colorspace changes? I just want to make sure that CoreAVC isn't sending out video that is already "processed" in these terms and then ffdshow is reprocessing the levels through the RGB conversion section.

[Keiyakusha]

However I don't understand what CoreAVC is doing with the "Input Levels", "Output Levels", and "Input colorspace (set to auto)"
If you outputting yv12, with this settings CoreAVC should do nothing. Output should be "auto" too. The result should be the same as when you set input and output levels to TV in coreAVC, since DVDs, BDs etc. uses TV levels.

[p0w3rh0u5e]

Madshi.... No that is CoreMVC... And something you'll likely see later this year. On 10bit.... It's been discussed and once we get past DXVA, we will go there.
Thats great. :)

And while we're talking about future plans, i want to make a wish. As a future owner of one of those RED cameras, i would like to see something like CoreRED.

They offer a SDK and there is already a vdub-input-plugin, but being able to play those RED-files directly in MPC-HC & co would be great.

[Guest]

Seeking properly with open GOPs requires the decoder to go back an extra GOP. I should also mention that seeking requires that the required SPS and PPS be available. One needs some heuristics to find and inject them on a seek.

[Frank K Abbott]

If you outputting yv12, with this settings CoreAVC should do nothing. Output should be "auto" too. The result should be the same as when you set input and output levels to TV in coreAVC, since DVDs, BDs etc. uses TV levels.

Exactly what I was hoping for. BTW HQ YV12 -> RGB32 and dithering makes a beautiful output. The conversion is so much more superior to CoreAVC. :D It's awesome. Thanks again! :)

[cyberbeing]

Trying to playback one of the new 4K Youtube videos (4096x2304 x264) with CoreAVC 2.0 (software mode, CUDA disabled) produces a black screen with all renderers. FFDshow plays them just fine, so it seems CoreAVC's 4K support is broken. Since this is a somewhat major bug, I assume it will be fixed in CoreAVC 2.1?

[squid_80]

I should also mention that seeking requires that the required SPS and PPS be available. One needs some heuristics to find and inject them on a seek.

CoreAVC is a decoder, not a splitter. It cannot seek, its job is to decode what it is given (which is why I am asking what splitter people are using because gabest's splitter treats I frames as IDR frames).

[Galnospoke]

Trying to playback one of the new 4K Youtube videos (4096x2304 x264) with CoreAVC 2.0 (software mode, CUDA disabled) produces a black screen with all renderers. FFDshow plays them just fine, so it seems CoreAVC's 4K support is broken. Since this is a somewhat major bug, I assume it will be fixed in CoreAVC 2.1?


Confirm. The same problem.

[Frank K Abbott]

Trying to playback one of the new 4K Youtube videos (4096x2304 x264) with CoreAVC 2.0 (software mode, CUDA disabled) produces a black screen with all renderers. FFDshow plays them just fine, so it seems CoreAVC's 4K support is broken. Since this is a somewhat major bug, I assume it will be fixed in CoreAVC 2.1?

I can confirm the same.

@ squid_80

I don't know about others but I'm using Haali Media Splitter for nearly everything except for m2ts files. I use MPC-HC's "MPEG PS/TS/PVA" splitter for that so that I can properly see the audio/subtitle/video stream types and switch between them. Haali's Media Splitter has some issues with that.

[BetaBoy]

Thx for the reports... We are looking into the YT 4k problem.

[BetaBoy]

Can anyone post 'legal' examples that breaks 4k support in CoreAVC?

[lnatan25]

This is one of the 4K videos:
http://www.mediafire.com/?ugnenwm00mzfxum

It is taken from here:
http://www.youtube.com/watch?v=N0m1XmvBey8

[Stockpile]

Using Inatan25's download link, I was able to produce the same bug as mentioned previousley. A whole black screen, actually WMP doesn't even wanna play it.

[THX-UltraII]

I don't know about others but I'm using Haali Media Splitter for nearly everything except for m2ts files. I use MPC-HC's "MPEG PS/TS/PVA" splitter for that so that I can properly see the audio/subtitle/video stream types and switch between them. Haali's Media Splitter has some issues with that.


I ve also noticed that Haali has a problem with subtitles with .m2ts files. I ve uninstalled Haali and only checked MPEG PS/TS/PVA in the internal filters of MPC-HC. Everything seems to work fine this way. What are the benefits of using Haali instead of the internal MPEG PS filter in MPC-HC?

[rahzel]

I think there's issues again with the newer versions of x264. I'm experiencing the same glitchy video that v1.9.5.0 had with newer versions of x264 with v2.0 recently. It's not as severe as it was with 1.9.5.0, it happens sometimes when I skip forward and sometimes when a video is played a second time without closing (I use MPC HC).

[hajj_3]

any eta on the new version of coreavc betaboy?

[BetaBoy]

We are trying to finish up on DXVA1 DXVA2 to stay focused... but we have addressed some of the issues reported here on D9 for 2.1 as well. TBD on the release date.

[Cyber-Mav]

dxva1 is older hardware like nvidia 6800?

[Mangix]

DXVA1 = DXVA on Windows XP
DXVA2 = DXVA on Vista and up

[hajj_3]

no news?

[JohnnyFu]

Patience young padawan. I bet they are already preparing for the Christmas edition. Aren't you Betaboy?

[BetaBoy]

JF... I love your continued persistence at interjecting OT wisdom ;-)

hajj_3... we are continuing to work on DXVA2 atm no ETA.

[STaRGaZeR]

I bet they are already preparing for the Christmas edition

Yeah, 2011 :D

[ChronoCross]

Yeah, 2011 :D

Post here on Doom9 indicate the next release of CoreAVC with DXVA and DXVA2 has been in QC/Final dev since may. So your statement probably isn't too far off.

[hajj_3]

if DXVA2 is taking so long wouldn't it be better to include that in the version after the upcoming release as its been over 9 months since coreavc 2.0 was released. Thats why we don't wait for 9 months for new firefox releases, its better to have more frequent releases.

[STaRGaZeR]

Maybe they'll release a new version in Christmas 2011 without DXVA2, and the one with DXVA2 in Christmas 2012.

DXVA2, version 2.2, 2012. Sounds good to me :p

[JohnnyFu]

Now... look what I've done. Sorry Betaboy :)

@hajj_3
9 months? It's more like 5 years since GPU support was announced for the first time :)

[me7]

if DXVA2 is taking so long wouldn't it be better to include that in the version after the upcoming release as its been over 9 months since coreavc 2.0 was released. Thats why we don't wait for 9 months for new firefox releases, its better to have more frequent releases.

Firefox is open source and has new nightly builds each day, that's a completely different beast.

[hajj_3]

my analogy wasn't to compare the applications or that its closed source its that features are often dropped in order to make deadlines of a new firefox version every few months, thats what CoreAVC needs to do. Much better to release more frequently with a few new features and bug fixes each time.

[dwrbudr]

IMHO they are more focused on the mobile market right now.

[oddball]

CoreAVC is sorely in need of VC1 support. Heck even ffdshow supports VC1 in DXVA and that's freeware.

[me7]

Yes, a software that is called CoreAVC definitely needs VC-1 decoding :rolleyes:

There are real issues at hand, like the buggy decoding of open-gop AVC.

[Audionut]

Patience young padawan.

Patience is something that doesn't last forever.

http://img409.imageshack.us/img409/6393/coreplayer.png