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

Guest · 8th January 2014, 00:40

Quote:

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 · 9th January 2014, 10:55

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

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

Quote:

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!

Quote:

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 · 9th January 2014, 13:50

Thanks. No threat to DGSource() then.

WBL · 19th January 2014, 12:04

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 · 19th January 2014, 17:29

Quote:

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 · 16th February 2014, 19:57

Code:

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 · 16th February 2014, 20:41

Quote:

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:

Quote:

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

Thanks!

pistacho · 18th February 2014, 09:39

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 · 18th February 2014, 15:21

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 · 19th February 2014, 19:14

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 · 19th February 2014, 21:27

Quote:

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 :

Quote:

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 · 20th February 2014, 04:10

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 · 20th February 2014, 05:21

Quote:

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

Quote:

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 · 20th February 2014, 05:41

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 · 1st March 2014, 12:46

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 · 4th October 2014, 15:56

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 · 13th October 2014, 09:34

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

pistacho · 13th October 2014, 19:43

Quote:

Originally Posted by Nico8583

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

Nope!

Nico8583 · 14th October 2014, 07:38

Quote:

Originally Posted by pistacho

Nope!

Ok, thanks

Nico8583 · 23rd October 2014, 12:33

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 !

16th February 2014, 19:57	#26 \| Link
pistacho Registered User Join Date: Feb 2010 Location: Spain Posts: 549	Test version Code: 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 __________________ KODI 19 Matrix HDR Windows API BDtoAVCHD - One Click Blu-Ray to BD5/BD9/BD25/MKV MVCsource – MVC 3D Avisynth Source Plugin MVCenc – MVC 3D Encoder Last edited by pistacho; 16th February 2014 at 20:05.

18th February 2014, 09:39	#28 \| Link
pistacho Registered User Join Date: Feb 2010 Location: Spain Posts: 549	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 __________________ KODI 19 Matrix HDR Windows API BDtoAVCHD - One Click Blu-Ray to BD5/BD9/BD25/MKV MVCsource – MVC 3D Avisynth Source Plugin MVCenc – MVC 3D Encoder Last edited by pistacho; 1st March 2014 at 12:54. Reason: 700 fps benchmark link

20th February 2014, 05:41	#34 \| Link
Thalyn Registered User Join Date: Dec 2011 Posts: 129	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. Last edited by Thalyn; 20th February 2014 at 12:51.*

1st March 2014, 12:46	#35 \| Link
pistacho Registered User Join Date: Feb 2010 Location: Spain Posts: 549	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... __________________ KODI 19 Matrix HDR Windows API BDtoAVCHD - One Click Blu-Ray to BD5/BD9/BD25/MKV MVCsource – MVC 3D Avisynth Source Plugin MVCenc – MVC 3D Encoder

4th October 2014, 15:56	#36 \| Link
pistacho Registered User Join Date: Feb 2010 Location: Spain Posts: 549	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... __________________ KODI 19 Matrix HDR Windows API BDtoAVCHD - One Click Blu-Ray to BD5/BD9/BD25/MKV MVCsource – MVC 3D Avisynth Source Plugin MVCenc – MVC 3D Encoder

9th January 2014, 13:50	#23 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	Thanks. No threat to DGSource() then.

19th January 2014, 12:04	#24 \| Link
WBL Registered User Join Date: May 2005 Posts: 17	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

18th February 2014, 15:21	#29 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	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?

19th February 2014, 19:14	#30 \| Link
Thalyn Registered User Join Date: Dec 2011 Posts: 129	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?

20th February 2014, 04:10	#32 \| Link
Thalyn Registered User Join Date: Dec 2011 Posts: 129	There's no way, that I know of, to force software mode through MVCSource. At least it hasn't been documented if it exists.

13th October 2014, 09:34	#37 \| Link
Nico8583 Registered User Join Date: Jan 2010 Location: France Posts: 851	Hi, Does the new Intel Media SDK 2014 R2 resolve the bug from Pacific Rim ? Thanks !

23rd October 2014, 12:33	#40 \| Link
Nico8583 Registered User Join Date: Jan 2010 Location: France Posts: 851	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 !