How does CoreAVC 3.0 compare to LAV Video, ffdshow-mt, mpc filters, etc?

[Gaius]

Since this just came out, I figured I'd start a thread so people can discuss how it compares to our homegrown decoding solutions.

[Blight]

Compare on what level?

LAV shares a lot of code with ffmpeg and so does ffdshow.
There is also the LAV video decoder that uses NVIDIA hardware, which is also shared by CoreAVC (their "CUDA" decoder option).
CoreAVC 3 supports the new Intel Sandybridge decoding engine, but there's a thread here for a new ffdshow build with the same hardware support.
The Intel developer working on the ffdshow code will also help get it working in the LAV Video decoder soon enough.

In today's world, unless you're running on a low-power device, the decoding power is not as important as broad compatibility with other filters/system components.
As the Zoom Player developer I can tell you that the biggest headaches with decoders is that they are either incompatible with other filters or they even break things in the graph creation process.

Right now, I would say that the LAV Filters are moving the fastest in the right direction.
Mainly because nevcairiel is staying on top of bug reports and compatibility testing.

If you're on a laptop, depending on the hardware, CoreAVC may be the way to go.

[CruNcher]

Though Blight the Level that CoreAVC 3.0 supports is DXVA2 i think if i understood Betaboy right (didn't tried it yet) FFdshow-quicksync only supports the Direct API way yet (lower Performance, though more versatile to use and less error prone).

[clsid]

CoreAVC is a waste of your money. The free alternatives are very good, sometimes even better.

[CruNcher]

Depends heavily on your use case though for normal consumer you right absolutely, also if you go in the Direction of MVC support then it would look different again also for normal consumer :)

[nevcairiel]

CoreAVC will not support MVC, thats a completely different decoder which you need to buy again. :p

[Stephen R. Savage]

It's hard to say anything in particular about CoreAVC 3.0 when the current tests show that it contains several bugs that result in incorrect decoding.

That said, in tests I have posted to the CoreAVC thread, which other users including cyber-mav and CruNcher have posted results agreeing with, the performance difference between CoreAVC and LAV in software decoding mode is negligible. The only disputed cases are some edge-examples including a 4k video that CoreCodec employees cited. Additionally, in 8-bit (since 10-bit is broken, we can't say anything about it), CoreAVC 3.0 is not significantly faster than CoreAVC 2.5/2.6.

Regarding GPU acceleration, users have reported using LAV CUDA by nevcairiel on NVIDIA without issue, and DXVA support has been in MPC-HC for many years now.

Unless CoreCodec comes out with some dramatic performance improvements (unlikely) or additional format support (also unlikely, see comment r.e. CoreMVC), there's nearly no reason to purchase CoreAVC.

Regardless, we'll have to wait until CoreCodec fixes the 10-bit decoding bug before we can make any claim about it. My intuition is that the bug is not performance-related, in which case several users including cyber-mav and myself have confirmed CoreAVC being 30% slower than LAV Video on 10-bit encoded content.

P.S. Higher performance --> lower CPU usage --> lower power consumption

[CruNcher]

Generally Lav Video (0.34) is also slower with Interlaced Bitstreams mostly DVB there CoreAVC 3.0 kills it everytime (it's funny though that especialy those user group had so much problems with it) ;)

[Blight]

Cruncher:
MVC is a subset of H.264, it's only a matter of time before support is added.
It's really that there's barely any (home-grown) content for it. Only now you see a few scattered devices capable of capturing this format.
Not to mention that most 3D TV devices suck.

With regards to DXVA2, the Intel SDK uses DXVA internally, so it's basically the same thing as CoreAVC. They may not return the image back into the system memory, in which case they may be faster, but they lose certain features.
I'm still hoping Eric will find a way to make the memory transfers faster. Either that or get the Intel driver team to add a function to lock the Virtual GPU memory and then grab the RAW data directly, which would be A LOT faster.

[kieranrk]

Adding MVC to libavcodec isn't that hard. Demuxing probably is harder.

[nevcairiel]

Adding MVC to libavcodec isn't that hard. Demuxing probably is harder.

The way CoreMVC expects the MVC streams, demuxing really isn't all that hard (it accepts two streams, the reference H264 and the MVC stream). It itself does then take care of synchronizing the two streams to match them for decoding.

If you want the demuxer to interleave the streams for you, now thats probably harder.

Once CoreMVC is available, i'll see about adding demuxing support for BD MVC to LAV Splitter. Its only not done because i'm lacking any way to test it.