MVCsource v3.0.0 – 3D MVC/AVC/VC-1/MPEG2 Avisynth Source Plugin (Intel Quick Sync)

[Guest]

Originally Posted by pistacho

Coming soon also 2D video supported => VC1, AVC, MPEG2 decoder...

With robust frame accuracy, correct pulldown handling, etc.? What supported input container formats? Output to AVCHD only? Avisynth source filter? Inquiring minds want to know.

[pistacho]

The idea is to keep it as simple and fast as possible.

Decoding 2D VC-1, AVC, MPEG2 is just an added bonus.

Originally Posted by neuron2

With robust frame accuracy

Since no seek is allowed, the frame served is always the next. But yes, it is robust!

Originally Posted by neuron2

What supported input container formats? Output to AVCHD only?

Input only elementary streams and the ouput is raw YV12 (is only a decoder)

[Guest]

Thanks. No threat to DGSource() then.

[WBL]

tried to load a MVC file created by Panasonic Z10000 - I get an error 'Invalid or not supported stream header' - but the MVC file from this 3D camcorder is correct and valid (e.g can be loaded without problem in Sony Vegas Pro)

greetings
Werner

[pistacho]

Originally Posted by WBL

tried to load a MVC file created by Panasonic Z10000 - I get an error 'Invalid or not supported stream header' - but the MVC file from this 3D camcorder is correct and valid (e.g can be loaded without problem in Sony Vegas Pro)

greetings
Werner

Hi,

As we have commented in the other thread, only elementary streams are allowed as input.

I guess the camcorder produces .ts or .m2ts container.

[pistacho]

v2.1.1 (test version)

- Updated to Intel Media SDK 2014.
- Load libmfxsw32.dll from same folder as MVCsource.dll (no system path required)
- Some code optimizations and speed improvements.
- Workaround to fix corrupted frames in some streams (e.g. Pacific Rim – root cause seems Intel Media SDK bug)

=> MVCsource_v2.1.1.rar

More info about "Intel Media SDK bug" here:
http://forum.doom9.org/showthread.ph...68#post1668668

[Guest]

Originally Posted by pistacho

Load libmfxsw32.dll from same folder as MVCsource.dll (no system path required)

Since you have followed my lead on this feature, may I please know what you did for this:

Workaround to fix corrupted frames in some streams (e.g. Pacific Rim – root cause seems Intel Media SDK bug)

Thanks!

[pistacho]

The key is the version of sample_decode.exe that uses ssifSource v4.1 (by slavanap).

But not for the changes introduced by slavanap but the version is earlier than that are based all other decoders (FRIM, DGMVC and mine).

The workaround therefore is to use Intel Media SDK 2013 instead of 2013 R2 and use the sample code in this release. Unfortunately the Intel sample code (all versions) is plenty of bugs and poorly optimized (apparently done by interns) but this is another issue. Anyway, once compiled, the fix is still maintained using libmfxsw32.dll from SDK 2013 R2 or even SDK 2014.

But as I said in another thread, this is not a real solution because the bug is still there and can only be solved entirely by Intel.

As for the sample code "sample_decode.exe", I try to avoid everything possible for the reasons I mentioned (I made a complete refactory) and that is why my plugin (for now) is that it consumes less RAM/CPU and has a much larger throughput that others.

I've got ~700 fps on HW in the latest test version

[Guest]

Thanks, that's very interesting, especially claims of 700fps decoding! Would you be willing to share any of the architectural changes that led to that?

[Thalyn]

Hmm... I grabbed 2.1.1 and tried to run the Pacific Rim fragments through it, but I got the same errors as before. Is that perhaps a bad upload (ie the wrong file), or is it that I'm using hardware decoding (as I suspect) that's causing the problem?

[Nico8583]

Originally Posted by Thalyn

Hmm... I grabbed 2.1.1 and tried to run the Pacific Rim fragments through it, but I got the same errors as before. Is that perhaps a bad upload (ie the wrong file), or is it that I'm using hardware decoding (as I suspect) that's causing the problem?

pistacho said bug is still present in HW mode :

At the moment, I do not know the exact conditions that have to give, but I found a way that seems to solve the problem in SW mode. It is a "workaround" because I do not think it can be a long-term solution and the bug is still present in HW mode.

Have you tried to force SW (if it's possible) ?

[Thalyn]

There's no way, that I know of, to force software mode through MVCSource. At least it hasn't been documented if it exists.

[allanlee]

Originally Posted by Thalyn

There's no way, that I know of, to force software mode through MVCSource. At least it hasn't been documented if it exists.

It's mentioned here

Since MVCsource has not an explicit param. to force hw/sw decode, to ensure SW is used and workaround fix is "active" you can rename temporally Intel Quick Sync driver location e.g.:

C:\Program Files\Intel\Media SDK to C:\Program Files\Intel\_Media SDK_

[Thalyn]

Well, I'll just sit in the corner and be silent. Feel free to provide a dunce cap.

*ed: It's still not right. It doesn't glitch, but the same scenes are still missing frames in the same place. In the Pac1 short clip there should be additional frames between 71 and 72 - roughly 45 of them judging by when the scene blanks at the end. This puts the audio significantly out of sync (almost 2 seconds). I haven't studied Pac2 closely but I imagine it's much the same again.

Demonstration time:
CoreAVC (via DirectShowMVCSource)
Intel Media (via MVCSource)

Both streams are produced via MKVMerge, set to split out frames 95,000 to 95,499, with the only difference being the video source. Yes, I realise they're both only 472 frames and not 500 but that's MKVMerge's doing - at least it's consistent. The only other variation is in the x264 settings used but that has no relevance.

[pistacho]

I have not gone back to spend more time on this matter. But I'm beginning to suspect that the problem could simply be the source (bad source).

In any case, the workaround is based on which has reported that ssifSource4.1 solved the problem. The MVCsource workaround produces the same output as ssifSource4.1.

Therefore, if it turns out that this version of the MVCsource not fix the issue, ssifSource4.1 either.

But we are talking that this is a fault in a single scene of a single Blu-Ray. It seems logical that if there really it’s an Intel decoder bug, should affect more sources...

[pistacho]

Version 2.2.1 (10/04/2014)

• Updated to Intel Media SDK 2014 R2.
• Some decoder throughput improvements (both HW and SW decoding).

BENCHMARK:

Quick Sync decoding




Software decoding




For more deatails see first post...

[Nico8583]

Hi,
Does the new Intel Media SDK 2014 R2 resolve the bug from Pacific Rim ?
Thanks !

[pistacho]

Originally Posted by Nico8583

Hi,
Does the new Intel Media SDK 2014 R2 resolve the bug from Pacific Rim ?
Thanks !

Nope!

[Nico8583]

Originally Posted by pistacho

Nope!

Ok, thanks

[Nico8583]

Hi, another question : have you tried your plugin with a new Intel CPU and last Intel Media SDK ? It seems there are bugs with new Intel CPU and hardware acceleration, for example with Intel Haswell Refesh (Core I5 4590S), if we use the lastest Intel Media SDK. We don't know if it's a problem with our decoder or with Intel DLL.
Thanks !