Log in

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


Pages : [1] 2

pistacho
31st December 2013, 10:55
As part of BDtoAVCHD (http://forum.doom9.org/showthread.php?t=154957) software I developed this plug-in for optimize Blu-Ray 3D to SBS/TAB conversions. Is based on Intel Media SDK 2021 R1 and can be used on all systems (SW acceleration) or on Intel Graphics systems (HW acceleration - Intel Quick Sync). Can decode elementary AVC/MVC both streams combined in the same file or in separated files.

Now I opened this thread so it's can be used for more purposes/applications in addition to original usage.

Current version can also decode 2D HEVC/AVC/VC-1/MPEG2 streams (included UHD 10 bit color for HEVC).


REQUIREMENTS


Windows 10/8.1/8/7 (32 or 64-bit)
AviSynth 2.6.0 (32-bit) or AviSynth+ (32/64-bit)



DOWNLOAD


BDtoAVCHD_v3.1.9.msi (https://www.connecta2000.com/download/BDtoAVCHD_v3.1.9.msi) (44.61 MB)



LIMITATIONS

No seek supported. Only strictly linear decoding is allowed.



CHANGELOG

Version 3.0.3 (06/03/2022)

- Updated compiler to Visual Studio 2022.


Version 3.0.0 (06/11/2021)

- Updated to Intel Media SDK 2021 R1.


Version 2.9.8 (01/02/2021)

- Updated to Intel Media SDK 2020 R1.


Version 2.9.2 (01/24/2020)

- Updated to Intel Media SDK 2019 R1 (API 1.28).
- Updated compiler to Visual Studio 2019.


Version 2.8.6 (03/19/2019)

- Updated to Intel Media SDK 2018 R2.1 (API 1.27).
- Updated compiler to Visual Studio 2017 with Update 9.


Version 2.8.0 (05/12/2018)

- Can also decode HEVC (only in HW mode).
- Updated AviSynth header to support AviSynth+.
- New 64-bit version.
- Added deep color support (10bit) for HEVC decoding (requires AviSynth+).
- Optimized code using SSE2, SSSE3 and AVX2 instructions.
- Updated to Intel Media SDK 2018 R1 (API 1.26).
- Updated compiler to Visual Studio 2017 with Update 6.


Version 2.7.2 (07/19/2017)

- Updated to Intel Media SDK 2017 R1 (API 1.23).
- Updated compiler to Visual Studio 2017.


Version 2.6.4 (10/26/2016)

- Updated compiler to Visual Studio 2015 Update 3.


Version 2.5.8 (07/27/2016)

- Fixed: with some sources hangs using HW mode and recent Intel Graphics Drivers.


Version 2.5.7 (06/28/2016)

- Updated to Intel Media SDK 2016 R2 (API 1.19).


Version 2.5.6 (05/09/2016)

- Fixed: MPEG2 decoding using SW mode.
- Simplified memory allocation scheme.


Version 2.5.1 (11/27/2015)

- Updated to Intel Media SDK 2016 (API 1.17).


Version 2.5.0 (11/12/2015)

- Updated to Intel Media SDK 2015 Update 2.1 (API 1.16).


Version 2.4.6 (09/21/2015)

- Fixed: with parameter output_format = -2 R/L views order gets inverted after minute 45.
- Upgraded to Visual Studio 2015.


Version 2.4.5 (08/17/2015)

- Updated to Intel Media SDK 2015 Update 2 (API 1.15).


Version 2.4.3 (06/13/2015)

- Updated with Avisynth headers v6, due this, older Avisynth versions (2.5.8) are no longer compatible ***is now required Avisynth v2.6.0***.


Version 2.4.0 (03/20/2015)

- Updated to Intel Media SDK 2015 Update 1 (no functional changes).


Version 2.2.4 (11/20/2014)

- Upgraded to Visual Studio 2013 (no functional changes).


Version 2.2.3 (11/07/2014)

- Fixed all Pacific Rim 3D decoding issues (SW mode and HW mode).
- Full compatible with latest Intel HD Graphics driver's series.
- Slightly reduced CPU usage and memory usage (CPU usage downs from 12% to 8% in benchmarks: AVSMeter, HW mode,
latest Intel drivers).


Version 2.2.2 (10/25/2014)

- Fixed: Possible image corruption (artifacts on MVC view) using Quick Sync acceleration and latest Intel
Graphics drivers 15.33.xx.39xx


Version 2.2.1 (10/04/2014)

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


Version 2.1.3 (03/16/2014)

- Better strategy for detection HW API LEVEL supported by system and chose SW on not supported systems.


Version 2.1.2 (02/26/2014)

- 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)


Version 2.0.0 (01/10/2014)

- Also 2D video decoding (AVC, VC-1, MPEG2)


Version 1.9.5 (12/28/2013)

- HW acceleration on Intel HD Graphics systems (Intel Quick Sync Video)


Version 1.9.2 (10/19/2013)

- Support of AVC/MVC on separated input streams.


Version 1.9.0 (08/25/2013)

- First release.
- Decoding of AVC/MVC combined streams only.



PARAMETERS


MVCsource("X:\path_to_AVC.h264", "X:\path_to_MVC.h264", number_of_frames, output_format)

number_of_frames: number of frames that contains .h264 files

output_format:

0 : AVC frames only
1 : MVC frames only
2 : interleaved AVC-MVC frames (AVC odd)
-2 : interleaved MVC-AVC frames (AVC even)


Notes:


If number_of_frames specified is lower that actual number of frames in .h264 file, output is trimmed. Also if is greater additional black frames are inserted to complete requested number of frames.
Output is already YV12 color format, please do not insert ConvertToYV12() in scripts.
Correct framerate is taken from stream, please do not insert AssumeFPS() in scripts.
In interleaved left-right direct outputs frame rate is doubled (2x). It's not a bug! That's the functionality that is intended.
From version 2.0.0 it's also possible to specify a 2D elementary stream (AVC/VC-1/MPEG2) in the first parameter. In this case must leave the empty second parameter "" and output_format = 0.
NEW: from version 2.8.0 can also decode 2D HEVC elementary stream (only using HW mode).



USAGE EXAMPLES

Simplest script (returns interleaved AVC-MVC frames)

LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

MVCsource("X:\path_to_AVC.h264", "X:\path_to_MVC.h264", 178055, 2)


Same on combined AVC + MVC file

LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

MVCsource("X:\path_to_MVCCombined.h264", "", 178055, 2)


Half SBS conversion (AVC = left eye)

LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

Interleaved = MVCsource("X:\path_to_AVC.h264", "X:\path_to_MVC.h264", 178055, 2)

Right = SelectOdd(Interleaved)
Left = SelectEven(Interleaved)

return StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))


Half SBS conversion (AVC = right eye)

LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

Interleaved = MVCsource("X:\path_to_AVC.h264", "X:\path_to_MVC.h264", 178055, -2)

Right = SelectOdd(Interleaved)
Left = SelectEven(Interleaved)

return StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))


Half TAB conversion (AVC = left eye)

LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

Interleaved = MVCsource("X:\path_to_AVC.h264", "X:\path_to_MVC.h264", 178055, 2)

Right = SelectOdd(Interleaved)
Left = SelectEven(Interleaved)

return StackVertical(VerticalReduceBy2(Left), VerticalReduceBy2(Right))


Half TAB conversion (AVC = right eye)

LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

Interleaved = MVCsource("X:\path_to_AVC.h264", "X:\path_to_MVC.h264", 178055, -2)

Right = SelectOdd(Interleaved)
Left = SelectEven(Interleaved)

return StackVertical(VerticalReduceBy2(Left), VerticalReduceBy2(Right))


only AVC view

LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

MVCsource("X:\path_to_AVC.h264", "X:\path_to_MVC.h264", 178055, 0)


only MVC view

LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

MVCsource("X:\path_to_AVC.h264", "X:\path_to_MVC.h264", 178055, 1)


2D decoder (HEVC/AVC/VC-1/MPEG2)

LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource.dll")

MVCsource("X:\path_to_2D_stream.vc1/mpv/h264/hevc", "", 178055, 0)


BENCHMARK (updated to version 2.8.0)

HW decoding on Intel HD Graphics 630 (Kaby Lake) and simplest script (no resize and no stack, only decoding)

http://www.connecta2000.com/imagenes/MVCsource_HW.png


SW decoding on Intel i7-7700k and simplest script (no resize and no stack, only decoding)

http://www.connecta2000.com/imagenes/MVCsource_SW.png

r0lZ
31st December 2013, 13:12
Useless as long as it's not a standalone filter. Especially because BDtoAVCHD is adware, and can't be promoted by free programs, for obvious reasons. But thanks anyway.

pistacho
31st December 2013, 13:26
http://www.download3k.com/Antivirus-Report-BDtoAVCHD.html
http://www.soft82.com/antivirus-report/download/windows/bdtoavchd_2/

r0lZ
31st December 2013, 13:40
I haven't said that it is a virus. By definition, it is an adware, since it is ad-supported. You must understand that you cannot earn money (with ads or any other method) by forcing the creators of free tools to promote your program, and, even more important, by forcing the owners of the free tools developed by others to install your program.

Give us the possibility to include the avisynth plugin alone with our program, and we will be happy to credit you, and we will add a link to your program, for those that may be interested. But it is unacceptable to force the users of our tools to install your program anyway, especially because it's an adware.

Of course, any programmer is free to accept your conditions, but I doubdt you'll find one here at D9.

Nico8583
31st December 2013, 14:39
Before to go to an (another) useless discussion, could you explain me where is your interest to force users to install your soft instead of simply credit you and add a link to your soft ?

If I install your soft, I'll never launch it -> no ad-banner to display -> no gain for you :confused:

pistacho
31st December 2013, 15:07
I haven't said that it is a virus. By definition, it is an adware, since it is ad-supported. You must understand that you cannot earn money (with ads or any other method) by forcing the creators of free tools to promote your program, and, even more important, by forcing the owners of the free tools developed by others to install your program.

Give us the possibility to include the avisynth plugin alone with our program, and we will be happy to credit you, and we will add a link to your program, for those that may be interested. But it is unacceptable to force the users of our tools to install your program anyway, especially because it's an adware.

Of course, any programmer is free to accept your conditions, but I doubdt you'll find one here at D9.


I do not impose anything. I just offer an alternative...

Do not you think that people can decide for itself among the options currently available?

e.g.:

1. Comercial program that costs a lot of $
2. Free application that redistributes a commercial codec in a dude way and has plenty of bugs, decoding glitches and washed colors.
3. Ad-supported software that offers good quality decoding / good speed / free of know bugs and is free to use (costs $0).
4. ...

Sorry for this off topic.

pistacho
31st December 2013, 15:09
Before to go to an (another) useless discussion, could you explain me where is your interest to force users to install your soft instead of simply credit you and add a link to your soft ?

If I install your soft, I'll never launch it -> no ad-banner to display -> no gain for you :confused:


At heart I'm a good person :D :D

Groucho2004
31st December 2013, 15:35
Some observations:

The software installs and runs fine on XPSP3 (W7 was specified as a min. req.)
I noticed that the app stays in memory after cancelling a job and closing. Nasty.
The application writes temporary files to the C: drive and not to the directory pointed to by the "TEMP" environment variable. "C:\Temp" and also "C:\AVCHD" are hardcoded :eek:. Unbelievable.

Nico8583
31st December 2013, 15:58
At heart I'm a good person :D :D
And so ? :rolleyes:

Wilbert
31st December 2013, 16:24
@Nico8583 and others, stop it. Your point is clear.

pistacho
31st December 2013, 17:45
The software installs and runs fine on XPSP3 (W7 was specified as a min. req.)


W7 min req. are only for MVCsource.dll. But for 2D conversions and rest of BDtoAVCHD functionality XPSP3 are sufficient (+UDF driver for read BD structure)

Some observations:
I noticed that the app stays in memory after cancelling a job and closing. Nasty.


I have been astounded! :eek: Can you elaborate more this?


The application writes temporary files to the C: drive and not to the directory pointed to by the "TEMP" environment variable. "C:\Temp" and also "C:\AVCHD" are hardcoded :eek:. Unbelievable.


"C:\TEMP" and "C:\AVCHD" are default ones for on a fresh install. You can change this in menu -> Options -> Settings. Also output folder can be edited per job.

EDIT:
http://www.connecta2000.com/imagenes/BDtoAVCHD-settings.png


p.s. Your AVSMeter are useful to me in order to benchmark my decoder plugin! :) Cool!

Groucho2004
31st December 2013, 20:51
I have been astounded! :eek: Can you elaborate more this?
Actually, one only has to start and exit the program. After that, I can't start it again, it complains that there is already an instance running. Funnily, this adds yet another instance.
In order to start it again I have to kill all these instances in Task Manager.
So, not so "free of known bugs" as you claimed (which is a ridiculous statement anyway).

By the way, since your application is completely dependent on great and free tools like x264, FFMS2, BDSup2Sub, eac3to, MatroskaSplitter, mkvtoolnix, tsmuxer, etc., are you planning to give some of the money that you make with your Adware to the developers of these programs?

pistacho
31st December 2013, 21:30
Are you running in exotic configuration like Virtual Machine + Windows XP + Firewall to block internet access?

May be auto-update function (to notification new versions of software) causes this comportment if you block access and closes program too early.

Anyway "no know bugs" is referring to MVCSource.dll not whole BDtoAVCHD but I investigate it this issue any way :)

Happy New Year!!!

Sparktank
31st December 2013, 22:24
This is quite interesting. Definitely going to explore this in the new year (-8 GMT time for me).

A stand-alone port in the future would be great for those who already have most of the components installed.

I always worry that installers will reset/alter existing settings/registry.
Or even to different versions.
For eac3to, I have in separate location with registered Arcsoft decoders so I tend to avoid bundled software as I don't want to copy and register more than once.
Also for BDSup2Sub, there is also BDSup2Sub++ that I tend to use quite a bit but is not a Java-based application (QT-based).

I'll give it a go after I setup my system to be ready for changes and some heavy testing.

pistacho
1st January 2014, 21:21
For eac3to, I have in separate location with registered Arcsoft decoders so I tend to avoid bundled software as I don't want to copy and register more than once.


Don't worry, the program can use Arcsoft DTS decoder (if already installed) but does not touch it or change its configuration.


I'll give it a go after I setup my system to be ready for changes and some heavy testing.


I will like to hear your feedback. :)


SIDE NOTE: this thread is for MVCsource plugin specific questions, for BDtoAVCHD general questions better here:
http://forum.doom9.org/showthread.php?t=154957

pistacho
1st January 2014, 21:22
Updated first post with BENCHMARK

Groucho2004
5th January 2014, 13:48
Anyway "no know bugs" is referring to MVCSource.dll not whole BDtoAVCHD
I can't ignore the bugs of the whole application since you force users to install it.

"C:\TEMP" and "C:\AVCHD" are default ones for on a fresh install. You can change this in menu -> Options -> Settings. Also output folder can be edited per job.

It's still hardcoded in the executable and the program tries to create these directories at the first launch.
Hardcoding a path this way is one of the most moronic things a developer can do and clearly reveals the skill level.

Guest
5th January 2014, 16:34
Hardcoding a path this way is one of the most moronic things a developer can do and clearly reveals the skill level. Treading on rule 4 territory here. Please remain civil when stating your opinion. Thank you.

SamKook
7th January 2014, 19:17
As someone who once had no C drive for a while, I can tell you it's certainly not a good idea to use it as default.

pistacho
8th January 2014, 00:37
If this is the only trouble that you have found, I am more than satisfied...

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

Guest
8th January 2014, 00:40
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.

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

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
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
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 (http://www.connecta2000.com/download/MVCsource_v2.1.1.rar)

More info about "Intel Media SDK bug" here:
http://forum.doom9.org/showthread.php?p=1668668#post1668668

Guest
16th February 2014, 20:41
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
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 (http://forum.doom9.org/showthread.php?p=1671283#post1671283) 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
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
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
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 (http://forum.doom9.org/showthread.php?p=1668668#post1668668)


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) (https://mega.co.nz/#!w0lWAYwT!GFSGIKUu0-QJl_VIsUwL6wf7AO272rUUbrHHulvcQ30)
Intel Media (via MVCSource) (https://mega.co.nz/#!V9FWmAyB!EXRB97SBIbv5O11_3wDX2n5T1-YvhSfwcwfTifIj2AI)

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

http://112.imagebam.com/download/uRlK-cgCCnddmGCrA5FTOA/35554/355532609/MVCsource-HW.png


Software decoding

http://112.imagebam.com/download/rnDJ3gLhNI93aryLP9zZIQ/35554/355532608/MVCsource-SW.png


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
Hi,
Does the new Intel Media SDK 2014 R2 resolve the bug from Pacific Rim ?
Thanks !

Nope! :(

Nico8583
14th October 2014, 07:38
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 !

pistacho
25th October 2014, 11:07
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 !

Hi,

I not tested with new hardware but currently are testing with latest Intel HD Graphics drivers and I found a new bug: image corruption (artifacts) on MVC view only. Also I test new driver with old "libmfxhw32.dll" (from old drivers) and corruption are gone.

Seems that culprit of bug is new "libmfxhw32.dll" included with new drivers. Also seems that important changes exists due different file sizes: version 5.14.7.25 (new) has 7.93 MB and old 16.7 MB!

Fortunately I have found a way to fix it and the next version of MVCsource be compatible with the new drivers :)

Also I have seen the new version consumes less CPU in benchmarks (from 12% downs to 8-5%) in general seems that new drivers has less preprocessing overhead but are more "sensitive" in terms of little variation of input format (are less "robust").

I have also done a new test with Pacific Rim and surprising has gone well! (no glitches or audio out of sync) but still do not know if it's due to the new drivers or the changes I've introduced latest in MVCsource. I need do more tests...

Nico8583
25th October 2014, 11:45
Thanks for your response.
If anyone on this thread with a new Intel CPU can post a feedback it could be perfect ;)
Very well for Pacific Rim ;) have you tried without HW acceleration ? I would like to know if it works with SW decode.
Thanks !

pistacho
25th October 2014, 18:48
have you tried without HW acceleration ? I would like to know if it works with SW decode.
Thanks !

Confirmed: Pacific Rim now decodes OK on HW using latest Intel Graphics drivers + latest MVCsource v2.2.2

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24329&lang=spa&ProdId=3712

Unfortunately, SW decoding has the same problems as before (no glitch but some frames missing -> audio out of sync)

EDIT (Only for clarification PR issues):
- Old Intel drivers + New MVCsouce = Bad decoding
- New Intel drivers + Old MVCsource = Bad decoding
- New Intel drivers + New MVCsource = OK
- SW decoding + New MVCsource = Bad decoding

pistacho
25th October 2014, 18:54
Version 2.2.2 (10/25/2014)


Fixed: Possible image corruption (artifacts on MVC view) using Quick Sync acceleration and latest Intel Graphics drivers 15.33.xx.39xx

Nico8583
26th October 2014, 10:29
Thanks for explanation. So the only way to encode Pacific Rim correctly is to get an Intel CPU with HW acceleration, but mine is an AMD :(

Nico8583
26th October 2014, 15:41
Could you explain "the way to fix it", how and why is it necessary to fix ? Also is it necessary to change plugin source code when Intel update SDK or functions/calls are identical and replace with new dll is sufficient ? Thanks !

pistacho
7th November 2014, 10:41
Good news for Pacific Rim maniacs: ;)

Version 2.2.3 (11/07/2014)

- Fixed all Pacific Rim 3D decoding issues (SW mode and HW mode).
- Full compatible with latest Intel HD Graphics driver’s series.
- Slightly reduced CPU usage and memory usage (CPU usage downs from 12% to 8% in benchmarks: AVSMeter, HW mode, latest Intel drivers).

Release in progress...

EDIT: Done!

pistacho
20th November 2014, 11:23
Version 2.2.4 (11/20/2014)

- Upgraded to Visual Studio 2013 (no functional changes).

Updated benchmark on first post.

Nico8583
23rd November 2014, 15:53
Could you explain us the solution for Pacific Rim ? It could be important for FRIM or DGMVCSource...
Thanks !

frank
18th January 2015, 23:41
Simple use latest Intel gfx drivers and libmfxsw32.dll (2014/09/14) from Intel INDE2015 / Media SDK 2015.

Pistacho, it is not a fine way to ignore questions at Doom9's forum.