CoreCodec/H.264 Codec "CoreAVC" [Archive] - Page 86

BetaBoy

2nd January 2009, 02:02

@LoRd_MuldeR... More robust? We would diff from that opinion. Adding higher non-spec compliant MV's in any decoder comes at the cost of CPU cycles, ie; speed.
@Atak_Snajpera... are resolutions higher then 1080p within the AVC spec?
@laserfan... what are you using to encode these videos? I would like to contact them about their problem.

While it was about 100+ pages back... we have added 'some' out of spec MV support to CoreAVC, but stopped short at the point where it began to effect speed.

LoRd_MuldeR

2nd January 2009, 02:11

@LoRd_MuldeR... More robust? We would diff from that opinion. Adding higher non-spec compliant MV's in any decoder comes at the cost of CPU cycles, ie; speed.

So obviously it's a trad-off. And the CoreAVC team decided to give performance (speed) a higher priority than robustness against (slightly) broken streams.

However if a significant number of original Blu-Ray discs contain out-of-spec MV's, then it may be a good idea to be prepared for that case.

Strictly limiting your decoder to the specs won't help your users as long as the big studios keep on violating these specs. And I don't expect the studios to change their behavior.

After all speed isn't everything. Nasty artifacts may be much more annoying than a reasonable speed drop...

@Atak_Snajpera... are resolutions higher then 1080p within the AVC spec?

The specs for Level 4.0/4.1 of H.264:
* Max. number of macroblocks per seconds: 245760
* Max. picture size in macroblocks: 8192
* Examples: 1920x1080 @ 30.1 fps, 2048x1024 @ 30.0 fps

The specs for Level 4.2 of H.264:
* Max. number of macroblocks per seconds: 522240
* Max. picture size in macroblocks: 8704
* Examples: 1920x1080 @ 64.0 fps, 2048x1080 @ 60.0 fps

The specs for Level 5.0 of H.264:
* Max. number of macroblocks per seconds: 589824
* Max. picture size in macroblocks: 22080
* Examples: 1920x1080 @ 72.3 fps , 2560x1920 @ 30.7 fps

The specs for Level 5.1 of H.264:
* Max. number of macroblocks per seconds: 983040
* Max. picture size in macroblocks: 36864
* Examples: 1920x1080 @ 120.5 fps, 4096x2048 @ 30.0

Source:
http://de.wikipedia.org/wiki/H.264#Level

BetaBoy

2nd January 2009, 02:22

So obviously it's a trad-off. And the CoreAVC team decided to give performance (speed) a higher priority than robustness against (slightly) broken streams.

However if a significant number of original Blu-Ray discs contain out-of-spec MV's, then it may be a good idea to be prepared for that case.

Strictly limiting your decoder to the specs won't help your users as long as the big studios keep on violating the specs. And I don't expect the studios to change their behavior.

After all speed isn't everything. Nasty artifacts may be much more annoying than a speed (minor) speed drop...

I have already been in direct contact with 2 studios that produced the titles mentioned in this thread 6+ months ago and they both stated that they are aware of the problem and are addressing the mastering issue.

Otherwise we beg to disagree to add non-compliance as being robust.

vwpassion

2nd January 2009, 02:24

So obviously it's a trad-off. And the CoreAVC team decided to give performance (speed) a higher priority than robustness against (slightly) broken streams.

However if a significant number of original Blu-Ray discs contain out-of-spec MV's, then it may be a good idea to be prepared for that case.

Strictly limiting your decoder to the specs won't help your users as long as the big studios keep on violating the specs. And I don't expect the studios to change their behavior.

After all speed isn't everything. Nasty artifacts may be much more annoying than a speed (minor) speed drop...

I agree. Nasty artefacts (check screenshots a few posts earlier) are a biggern concern to me than speed. In fact, I'm now preferring ffdshow's video decoder over coreavc due to this.

I've encountered these artefacts on several blurays already, thats whats the biggest concern to me. If it was a one-time thing, I'd be less worried. But with new studios popping up on the bluray market, I can foresee more of these out-of-spec MV's appearing on a number of blurays yet to come.

LoRd_MuldeR

2nd January 2009, 02:38

I have already been in direct contact with 2 studios that produced the titles mentioned in this thread 6+ months ago and they both stated that they are aware of the problem and are addressing the mastering issue.

Well, that is a step to the right direction but won't fix existing discs. But still users that own these discs would like to play them.

Can you bring a disc back to shop because it contains "none-standard-compliant MV's" and get a new "fixed" copy, although the discs will play back properly on almost any Blu-Ray player?

Sorry, I doubt it. The guys at shop won't even understand what the problem is ;)

Otherwise we beg to disagree to add non-compliance as being robust.

Fact is: Blu-Ray discs with out-of-spec MV's exist and it seems they aren't that rare. CoreAVC won't decode these discs properly, no matter whose mistake that is.

The customers will decided whether this is a reason to buy CoreAVC or to go for another decoding solution ...

Sharktooth

2nd January 2009, 02:58

standards are made for a reason. if a studio produces a non standards compliant disc then it's their fault and ppl should avoid buying those products.

LoRd_MuldeR

2nd January 2009, 03:14

standards are made for a reason. if a studio produce a non standards compliant disc then it's their fault and ppl should avoid buying those products.

Ideally yes. But realty often looks different. Companies define their own "de-facto" standards :rolleyes:

If your favorite movie was available on Blu-Ray disc and you really want to have it, but you also knew that the release contains none-standard-compliant MV's, what would you do?

1. Buy it anyway and use another decoder that can handle the problem (e.g. ffdshow).

2. Refuse to buy the disc and miss that movie in your collection, just because of some mastering bug (one that can be worked around quite easily)

I think most people would rather use a different decoder than not being able to watch their favorite Blu-Ray movies.

But after all CoreCodec has to decide what's best for their (potential) customers...

laserfan

2nd January 2009, 03:29

standards are made for a reason. if a studio produce a non standards compliant disc then it's their fault and ppl should avoid buying those products.You can't be serious--someone is going to evaluate & ID non-std discs, and ppl are going to seek-out and find this definitive list (worldwide, for all variants) and make buying decisions accordingly? Never in the real world! :confused:

BetaBoy

2nd January 2009, 05:15

@LoRd_MuldeR...

- A MV work around other then what we have done already as you say is not as easy as you state it to be, and would take a considerable amount of work.

- Dark Shikari himself said about 100+ pages ago that it would take studios 6+ months for his x264 fix for make MV spec compliant to float its way just through the various distros and we consider the current state on non-spec MV's going on a downward trend.

- on resolution... that's a 'me bad' as I misinterpreted the question.

LoRd_MuldeR

2nd January 2009, 05:21

- A MV work around other then what we have done already as you say is not as easy as you state it to be, and would take a considerable amount of work.

What I meant is that there is an easy workaround for the user, if CoreAVC shows artifacts for none-compliant streams:
Download and install ffdshow ;)

So my point was that customers rather go for another decoder than avoiding none-compliant discs, since we must assume they already bought the disc for hard money.

- on resolution... that's a 'me bad' as I misinterpreted the question.

So are there any plans to enable CoreAVC for higher resolutions anytime soon?

From what I know the H.264 specs only limit the resolution through levels. And in level 5.1 you can have 4096x2048 at 30.0 fps.

squid_80

2nd January 2009, 06:23

So are there any plans to enable CoreAVC for higher resolutions anytime soon?
Currently CoreAVC handles up to 2048x2048; besides Crowdrun, does anyone have any proper streams (i.e. that they haven't encoded themselves for testing) that exceed these limits?

Ice =A=

2nd January 2009, 13:12

I also think you should NOT sacrifice speed for non-compliant encodings!
After all, you have to draw a line somwhere.

You could include an option to switch on a less rigid codec interpretation with lower speed somewhere in the options menu, but I think that would not be worth the extra money and work!

clsid

2nd January 2009, 14:14

Dark Shikari

2nd January 2009, 14:42

I also think you should NOT sacrifice speed for non-compliant encodings!Given the way CoreAVC handles MVs, "fixing" decoding of non-compliant streams would in fact speed up, not slow down, encoding ;)

Guest

2nd January 2009, 16:00

BTW, in addition to ffdshow, the Nvida VP2 decoder plays this stream correctly, as do the DirectShow decoders from several software players that I have installed. Core is out on their own here. I don't believe the claim that it would be difficult to fix it or that speed would suffer dramatically.

blubberbirne

2nd January 2009, 16:10

BTW, in addition to ffdshow, the Nvida VP2 decoder plays this stream correctly,

*hm* ffdshow has DXVA support now?

BetaBoy

2nd January 2009, 16:10

Isn't the solution simple? Implement the MV related functions twice. The current implementation, and a slower one that works with out-of-spec MVs. Add an option to the GUI called "Support out-of-spec motion vectors" with a tooltip like "Warning: this will reduce decoding performance". During initialization, just set the appropriate function pointer in the code based on the option. Users can then choose between speed and compatibility with non-standard video streams.

Result: All your customers are happy.

Correct and we talked about this xx# of pages ago and its something I am throwing around internally here again as we go into 1.9.x and 2.0... this would include a pop-under with a similar warning to what you stated but from the tray icon which would then lead them to an option to change support for for larger MV's.

Guest

2nd January 2009, 16:28

*hm* ffdshow has DXVA support now? No, DGAVCDecNV has VP2 support. :)

blubberbirne

2nd January 2009, 19:44

ah ok, i think i was confused :D

RealNC

4th January 2009, 00:06

I hope you guys will support OpenCL instead of CUDA when NV and ATI drivers introduce support for it so that CoreAVC can make use of both ATI and NV :)

CiNcH

4th January 2009, 16:11

I hope you guys will support OpenCL instead of CUDA
There is nothing similar to the CUDA Video API for accessing the PureVideo engine within OpenCL. OpenCL could just replace the CUDA API which uses the shader ALU's for generic computation.

RealNC

5th January 2009, 00:03

There is nothing similar to the CUDA Video API for accessing the PureVideo engine within OpenCL. OpenCL could just replace the CUDA API which uses the shader ALU's for generic computation.

Yes. Doesn't that mean you can run the decoder in-GPU with OCL? That also means that every video will be playable, regardless of it's encoding settings.

tetsuox

5th January 2009, 00:25

Yes. Doesn't that mean you can run the decoder in-GPU with OCL? That also means that every video will be playable, regardless of it's encoding settings.

The PureVideo engine is virtually the same across all 8xxx+ GPU's with minor difference in clock speed (save the lowest end models which use VP3), which leads to similar decoding performance.

Shader clock speeds however are different, not to mention the number of shaders of the various models, which leads me to assume that decoding performance via OpenCL can vary from 900MHz (lowest end 8xxx series) to 1836MHz (GF9800 GTX+). Number of shaders also range from 16 to 240 from the latest and greatest that nvidia has to offer.

5th January 2009, 11:59

Yes. Doesn't that mean you can run the decoder in-GPU with OCL?
You can, but first you'll need to program such a decoder and that is a huge task. For CUDA, NVIDIA provides access to their hardware decoder which means that most of the hard work has already been done.

CruNcher

5th January 2009, 12:32

You can, but first you'll need to program such a decoder and that is a huge task. For CUDA, NVIDIA provides access to their hardware decoder which means that most of the hard work has already been done.

Why do you want to have Decoders written in CUDA for the supported formats it is more efficient then anything else it is like a SAP :) a CUDA based Decoder wouldn't be that Energy Efficient show me HD Video Decoding @ under 1W in CUDA (the shader part of the GPU) :). It would be interesting for other non supported formats like Dirac or VPx :)
And i know many will say it isn't 1W and yes + idle energy it isn't, though you have to face reality and that is GPUs will be everywhere they already in many systems used for Enhancing the GUI Experience of the OS, though for Video Decoding/Encoding in the future Consumers gonna see a nice move to currently 50k like DSP/FPGA solutions that gonna do the Transcoding/Decoding on the fly for the Consumers alike (for a much lower Price) :). In those regards Nvidia and Ati have 1 big + they are here already it's easier for the PC manufacture to get only 1 Card that does it all then 1 GFX card + DSP and Nvidia and Ati currently provide that (Ati/Amd going 1 step already into future Research trying to bring everything into 1 chip) solution at least for the Decoding part, for sure we gonna see progress on the Encoding/Transcoding part from Nvidia and Ati as well :)

Though the problem is only of temporal Nature for Consumers currently, next Generation of Video nobody needs to care anymore about resolution, decoding complexity, Mobile or Desktop Devices will handle it the same way without much heavier Power consumption for Decoding and so also Transcoding will slowly become just a ugly remembering of the Past Digital century :). Future Generations gonna just lough if you tell them "Hey we had to change the complexity of the Video to be able to use it on our Mobile Devices".

5th January 2009, 13:35

Why do you want to have Decoders written in CUDA
If you are replying to me, I don't. I was arguing the same thing as you, CiNcH and tetsuox: using dedicated hardware decoders for H.264, VC-1 and MPEG-2 decoding is currently much more feasible than developing new decoders from scratch with any general purpose GPU language.

RealNC

5th January 2009, 21:05

Hmm, what about Stream SDK then? (AMD/ATI's equivalent to CUDA). It would be sad to have GPU accelerated CoreAVC only for NVidia :(

TheShadowRunner

5th January 2009, 21:43

Just making sure... adding a filter between decoder and renderer wouldn't break CUDA offload, would it?
(i'm thinking how Vsfilter currently breaks dxva..)
Later,

TSR

CruNcher

6th January 2009, 00:39

It shouldn't break it also it is independent of the Renderer as it uses Nvidias Hardware Decoding Engine directly the same way Donald does it and you should also be able to leverage from most of the bugfixes in the NVCuvid Ecosystem :)

TheShadowRunner

6th January 2009, 01:17

thanks for your confirmation didn't catch the joke about donald though

6th January 2009, 01:35

No joke there, CruNcher was talking about Donald Graft's (aka neuron2) DGAVCDecNV.

Guest

6th January 2009, 01:36

I didn't get the joke either. :)

TheShadowRunner

6th January 2009, 01:55

haha sorry neuron ;)
Good news about VSFilter not breaking anything, CUDA sounds like it's the best of both worlds.

BetaBoy

7th January 2009, 16:30

Ok.. I've been getting some email on this so... now that DivX 7 out I can respond more publicly. We will be releasing some official comparisons of DivX 7 Vs CoreAVC by the end of the week at http://compare.coreavc.com/ (dead link atm) and yes we will also be including ffdshow-mt in the comparison chart and full specs on the test environments and we will show separate NVIDIA CUDA results.

Also if anyone is at CES you can PM me and we can give you some times on where we will be if you want to see some of the various projects we are doing.... We will also be showing CorePlayer Mobile for the iPhone/Touch.

Also NVIDIA has told us that CoreAVC 'CUDA Enabled' Professional Edition will be showcased at the NVIDIA booth, so go swing by there to check it out in action.

clsid

7th January 2009, 19:06

Wouldn't such a comparison be biased? Because I noticed that benchmarks from others show that CoreAVC performs better for some samples, while DivX performs better with other samples. If either one publishes a comparison, then they will obviously pick those samples that make their decoder look better.

Dark Shikari

7th January 2009, 19:09

JohnnyFu

7th January 2009, 20:17

When it comes to reviews on big tech websites, these websites usually compare the most common media files for their readers. Blu-Ray, HD-Streams, Apple Trailer for instance.
Hopefully CoreAVC can perform well on that stuff. Btw, almost every website I read reported about DivX 7 these days. This is something I miss for CoreAVC, there is alot of work for the marketing guys :)

BetaBoy, I just dropped you a PM.

BetaBoy

7th January 2009, 20:20

DS... thx for the samples and we will use them... clsid... yes and no... but we will be as open to the conditions and we will adjust it accordingly based on everyone's feedback like DS has just done. We are not trying to bash anyone at all, we just want to get through the facts (from our perspective of coarse) that others are putting out there so consumers can make the choice that meets their needs.

LoRd_MuldeR

7th January 2009, 20:22

Btw, almost every website I read reported about DivX 7 these days.

Crazy that so many sites report about DivX 7, which basically is the DivX 6.8.5 Codec with a new logo :rolleyes:

(...and a slightly improved, but still useless DivX Converter)

leeperry

7th January 2009, 21:11

Crazy that so many sites report about DivX 7, which basically is the DivX 6.8.5 Codec with a new logo :rolleyes:

(...and a slightly improved, but still useless DivX Converter)
well it includes Remoulade, which is just as fast as CoreAVC.....and freeware.

I've posted benchmarks here :
http://forum.doom9.org/showpost.php?p=1232971&postcount=13

and it has a "low latency" option that seems to help a lot jitter-wise in Haali's Renderer when using crazy AVS scripts in ffdshow :o

LoRd_MuldeR

7th January 2009, 21:20

well it includes Remoulade, which is just as fast as CoreAVC.....and freeware.

That's really the only reason to check out DivX 7. And even that only if you don't own CoreAVC and if you aren't satisfied with ffdshow-MT.

BetaBoy

8th January 2009, 00:31

leeperry.... that's a misleading statement on DivX7, it maybe as you state with some content and with 'your' configuration but for others as reported in this thread and in other threads it is not. That's why we feel the compare site is important, to inform. If they truly did beat us I would be the first one jumping at chance to showcase CoreAVC 2.0 @ the NVIDIA booth while we are here at CES.

Cyber-Mav

8th January 2009, 00:39

betaboy you believe that coreavc 2.0 will be a lot faster on cpu decoding than current 1.8.5 version? how much more speed is there left to gain?

Dark Shikari

8th January 2009, 00:42

betaboy you believe that coreavc 2.0 will be a lot faster on cpu decoding than current 1.8.5 version? how much more speed is there left to gain?A lot. Current CoreAVC doesn't use SSE at all.

tetsuo55

8th January 2009, 00:51

A lot. Current CoreAVC doesn't use SSE at all.

Maybe SSE4.1 will help even more, not sure of its completely interesting for h264 decoding, and AVE should speed things up even more..

Here is an article on SSE4.1 in a video environment
http://www.virtualdub.org/blog/pivot/entry.php?id=199

Cyber-Mav

8th January 2009, 01:00

A lot. Current CoreAVC doesn't use SSE at all.

huh?? i thought it used sse2???

damn any guesstimates on how much % increase in speed can be seen with SSE being used?

Dark Shikari

8th January 2009, 01:03

Maybe SSE4.1 will help even more, not sure of its completely interesting for h264 decoding, and AVE should speed things up even more..

Here is an article on SSE4.1 in a video environment
http://www.virtualdub.org/blog/pivot/entry.php?id=199I have yet to imagine any possible use of SSE4 for decoding, though maybe there might be something creative with pblend or pinsrd.

It will be used for some upcoming x264 optimizations, but those are only encoder-side.huh?? i thought it used sse2???

damn any guesstimates on how much % increase in speed can be seen with SSE being used?A lot. This by the way is the reason why CoreAVC has such a huge advantage on older CPUs--on newer ones, competing encoders making heavy use of SSE close the performance gap, but on older CPUs where SSE isn't available or isn't very fast, CoreAVC has a large advantage.

IgorC

8th January 2009, 03:00

If I remember correctly most of x264's algos obtained 15-30% perfomance gain when gone from MMX to SSE/SSE2/SSE3....
But I'm not sure about CoreAVC as it is a decoder not encoder.

Sagekilla

8th January 2009, 03:16

You also have to realize the decoder isn't doing stuff like RD or any other optimization of file size vs quality ;) In that case, speeding up a function that's commonly used on both encoding and decoding could provide two different results. On encoding, it may only improve your speed 5 - 10%, while on decoding it might speed up by 30%* instead.

* Note: Just used some numbers to give an idea of comparison, don't take this as actual word for % speedup you'll get.