Free H.264 MVC 3D Encoder

[jdobbs]

Is anyone else having problems with the FRIMSource() in v1.26?

I get an error if I try to use it, but it works fine if I just replace it with the DLL from v1.25.

[r0lZ]

That's right. It doesn't work with the latest libmfxsw32.dll (v7.15.10.28, 28/10/2015). The plugin crashes without any error message.
I have not tried it with an older libmfxsw32.dll, but the previous version of FRIMSource.dll works fine with the latest Intel library.

[videofan3d]

Originally Posted by r0lZ

That's right. It doesn't work with the latest libmfxsw32.dll (v7.15.10.28, 28/10/2015). The plugin crashes without any error message.
I have not tried it with an older libmfxsw32.dll, but the previous version of FRIMSource.dll works fine with the latest Intel library.

Show me the script and conditions to reproduce, I'll check this...

[r0lZ]

You can download this sample I did to test the black frames bug of DGMVCSource. Just comment out the 2 lines related to DGMVCSource and uncomment the two lines for FRIMSource, and change the path to the DLL.

But IMO you don't need it. AFAIK, the crash happens with any MVC decoding.

I've used the two DLLs from FRIM_x86_version_1.26.zip, but the same bug happens with the Intel lib directly downloaded from their site. I have not tested the 64-bit version of FRIMSource.

[videofan3d]

Originally Posted by r0lZ

You can download this sample I did to test the black frames bug of DGMVCSource. Just comment out the 2 lines related to DGMVCSource and uncomment the two lines for FRIMSource, and change the path to the DLL.

But IMO you don't need it. AFAIK, the crash happens with any MVC decoding.

I've used the two DLLs from FRIM_x86_version_1.26.zip, but the same bug happens with the Intel lib directly downloaded from their site. I have not tested the 64-bit version of FRIMSource.

This is strange...
I used sample files which you provided, and played it using the script:

LoadPlugin("c:\Prj\IntelMedia\_exe\Win32\Release_v1.26\FRIMSource.dll")
FRIMSource(codec="mvc", filename="c:\a\sample.264", filename_dep="c:\a\sample.mvc", num_frames=100, cache=2, platform="sw", log_file="c:\a\Z.log", layout="sbs")

without any issue!

I used fresh installation of Avisynth 2.6.0 downloaded from videohelp.com.
And Intel library libmfxsw32.dll is file version 7.15.10.28, API 1.17 (this is written into file Z.log).

No crash occurred to me....
(and the same for layout "tab" or "alt")

[jdobbs]

It crashes on every source I try. I'll send you an example.

[jdobbs]

@videofan3d

I've sent you a PM with a link to test files that cause it to crash on my computer. My test was with AVISYNTH 2.58... but it should do the same with 2.60.

[videofan3d]

Originally Posted by jdobbs

@videofan3d

I've sent you a PM with a link to test files that cause it to crash on my computer. My test was with AVISYNTH 2.58... but it should do the same with 2.60.

Tested on Windows 7.

LoadPlugin("c:\a\frimsource1.26.dll")
FRIMSource(codec="h264",filename="00000.m2ts",container="ts",platform="sw",num_frames=4427,cache=24,log_file="c:\a\Z.log")

Tested with both libraries libmfxsw32.dll:
version 7.15.10.28, as well as 6.14.11.28

Avisynth 2.6.0
(cksum avisynth.dll is
3665143647 401920 C:\Windows\System32\avisynth.dll
3665143647 401920 C:\Windows\SysWOW64\avisynth.dll

Again, no problem on my setup.
- attached is screen from MPC-HC version 1.7.8.61 which I have installed.

[jdobbs]

All I can tell you is that it fails. Not sometimes, but every time on every source I try with the new dll. If I switch to v1.25 (even when using the newer libmfxsw.dll) it works every time. This is true not just with MPC, but with X264 or anything else that tries to use the AVS.

I'm not sure what else to tell you -- but if switching fixes it, it is very obviously the version. If it were the configuration, hardware, or some other variable it would fail with both.

It's not a big deal, as I can just use the older dll -- I just wanted to report it.

[Edit] Hope you don't mind that I removed the attachment after I looked at it... it was really big and made the thread hard to read

[videofan3d]

Originally Posted by jdobbs

All I can tell you is that it fails. Not sometimes, but every time on every source I try with the new dll. If I switch to v1.25 (even when using the newer libmfxsw.dll) it works every time. This is true not just with MPC, but with X264 or anything else that tries to use the AVS.

I'm not sure what else to tell you -- but if switching fixes it, it is very obviously the version. If it were the configuration, hardware, or some other variable it would fail with both.

It's not a big deal, as I can just use the older dll -- I just wanted to report it.

[Edit] Hope you don't mind that I removed the attachment after I looked at it... it was really big and made the thread hard to read

Version 1.25 and 1.26 differ only a little ("alt" option), and in compilation with Intel Media 2016 libraries.
Avisynth 2.6.0 also brought some changes in calling "AVS_linkage" vector, which I incorporated in version 1.26.

If you will add FRIMSource (..., log_file="whatever_path_file.log"), then you will see in .log where is the libmfxswNN.dll called from.

I re-tested it now quickly also on Windows 8.1 (64-bit) - no problem.
And also with FRIMSource64.dll (opening .avs with MPC_HC x64 via AviSynth+). Both again without obstacles.
Hard to say what is wrong until I reproduce the problem...

[jdobbs]

Originally Posted by videofan3d

Version 1.25 and 1.26 differ only a little ("alt" option), and in compilation with Intel Media 2016 libraries.
Avisynth 2.6.0 also brought some changes in calling "AVS_linkage" vector, which I incorporated in version 1.26.

If you will add FRIMSource (..., log_file="whatever_path_file.log"), then you will see in .log where is the libmfxswNN.dll called from.

I re-tested it now quickly also on Windows 8.1 (64-bit) - no problem.
And also with FRIMSource64.dll (opening .avs with MPC_HC x64 via AviSynth+). Both again without obstacles.
Hard to say what is wrong until I reproduce the problem...

I just tested it with AVISYNTH 2.6 and it works. As I'd mentioned, previous tests were using AVISYNTH 2.58. So the change you made using the AVS_linkage vector apparently makes if incompatible with earlier versions of AVISYNTH.

BD Rebuilder supports downward compatibility with earlier versions of AVISYNTH (2.5), so unfortunately I won't be able to update the installation package to include the v1.26 FrimSource dll.

[videofan3d]

Originally Posted by jdobbs

I just tested it with AVISYNTH 2.6 and it works. As I'd mentioned, previous tests were using AVISYNTH 2.58. So the change you made using the AVS_linkage vector apparently makes if incompatible with earlier versions of AVISYNTH.

BD Rebuilder supports downward compatibility with earlier versions of AVISYNTH (2.5), so unfortunately I won't be able to update the installation package to include the v1.26 FrimSource dll.

Good - so we found the root. Thanks!

Avisynth 2.6.0 is stable - so for time-being I'll leave it.
Later I'll check if it can be easily fixed...

[Eseninzhiv]

can someone make a video on YouTube?
how to install in system, the entire procedure
and re-encode a small piece of 3D (SSIF file demux into streams through tsMuxeR)
with the last AVISYNTH 2.6 and Intel_Media_SDK_2016
preferably on 64-bit windows
thanks in advance!

PS: video made
Sef Thank you!

[Thalyn]

Small, quick observation, Videofan3d: it seems your AVISynth plugin won't work in the absence of hardware decoding acceleration.

For stability reasons (which I later determined to be heat-related) I disabled my on-die GPU (HD4600) and just went with my stand-alone GPU. FRIMSource flat out refused to work, kicking back the error "Cannot initialize Intel Media SKD session." Out of curiosity I re-enabled the on-die GPU and set the Platform to be SW - same error. Worked fine in HW mode, however (forced or allowed to detect it).

[jdobbs]

Try leaving your GPU on but enabling sw encoding.

[Thalyn]

I've only ever used software encoding (x264). It's the decoding which is giving issues when attempting to use software mode instead of hardware, whether the on-die GPU is active or not.

[jdobbs]

You missed the point. You can individually enable sw encoding and decoding... so the point is that the encoder or decoder may see your (Intel) processor and assume you have hw acceleration available. By manually forcing sw, you 1) Don't have to disable your GPU 2) May avoid issues. What I was suggesting was that it may be possible that the failure was due to the fact that the GPU was disabled but the software (Intel's dll) was still trying to use it.

I use software encoding/decoding all the time with a non-Intel (AMD) CPU, and it works fine.

[Thalyn]

I guess it could be the presence of an Intel CPU giving it issues. I'm perhaps the only person, anywhere, using SW decoding on an Intel CPU with an appropriate GPU. But I have tried forcing software (platform = "SW"). I mention as much. It gives the same error as when the hardware is not available.

Incidentally, having the GPU enabled on its own is not sufficient to get HW decoding. Not for now, at least - headless mode isn't available through the Media SDK. It requires a screen also be active, though that screen doesn't necessarily need to physically exist.

[l33tmeatwad]

Any plans to port the AviSynth plugin to VapourSynth?

[BlackSharkfr]

Hello,
I'm using this program for the first time.
I bought a Sony BDP S4500 BluRay player with 3D capability, the player has no problem with AVC side by side 3D (squashed) clips, but it cannot play side by side (full ratio) 3840x1080 clips I am used to manipulate on my computer.
So I decided to try using FRIM to convert these side by side AVC clips into MVC.
I has some difficulties, but in the end I managed to make it work. However, I am very surprised by how different the image quality looks depending on which software/hardware i use to play the files.

I had a lot of difficulties feeding FrimEncode from my usual mkv clips. The file I used as source for this test is a 5 minute clip with 3840x1080 resolution 24fps side-by-side AVC made with x264 at about 10-15 Mbps average bitrate.
I wanted to use avisynth scripts to open the mkv files directly, but for some reason I couldn't get DirectShowSource to open them, I did manage to open them with FFmpegSource but for some reason I do not understand, I couldn't feed this script to FrimEncode.
When I used : -i input.avs -sbs 2 -w width -h height, the program stops at 0 frames (it creates empty output files)
When I used : -i input.avs -avi -sbs 2, the program gives me codec error. ( I did try to add converttoYV12() but it makes no difference)
I haven't used avisynth in a very very long time, it's probably an obscure problem on my side and I'm not that interested in using avisynth at the time. (I don't use it for anything else at the moment)

So I used a different feeding system : I extracted the h264 elementary streams using mkvextract gui, and used FrimDecode to open the elementary stream into a pipe using the -o \\.\pipe\filename.yuv trick.
I then reopen that pipe in FrimEncode with a difference command prompt, and finally managed to get it working.
The first time I did, I used the following parameters : -i \\.\pipe\filename.yuv -sbs 2 -w 1920 -h 1080 -o:mvc base.h264 dependent.h264 -vbr 10000
It went quite fast even though FrimEncode says it was using software mode : almost real time (I have an Intel Ivy Bridge i5-3570K, but the IGP is off : i use an AMD gaming graphics card)

I then muxed the base and dependent stream with TSmuxer into a m2ts container (along with the audio from the original clip).
I opened the file into my usual 2D video player (MPC HC) to check the picture quality of the base view : I was shocked at how awful the picture looked.
The initial fade in from black of the video has a large amount of small black artefacts across the picture (like if the fade in is delayed by one or two frames in these blocks), then during the clip I could see obvious blocking issues, especially backgrounds where there should be smooth gradients, if the camera is panning the blocking in these gradients moves randomly and attracts the eye towards the defect.

I then learned about the quality setting (-u value) which defaults to 4 (medium) if not specified.
So I tried again with : -i \\.\pipe\filename.yuv -sbs 2 -w 1920 -h 1080 -o:mvc base.h264 dependent.h264 -vbr 10000 -u 1
It went much more slowly (about 5-10 fps on average) but the end result looked much better.
The "-u 1" file has way less visible blocking artefacts, but they're not really gone. It's not clean like x264 AVC.

I then tried playback in stereoscopic player (3dtv.at) to see the dependent stream and got even more surprises.
The base view looks just like in MPC HC, the dependent view has about an equivalent amount of blocking artefacts as the base view, but the dependent view also has some bright green blobs appearing temporarily on the top edge of the picture wherever there is movement in the adjacent lower parts of the picture (typically : across the entire top of the picture during pans or when just in the part above a character's head when they move)
The "-u 4" file shows a lot more artefacts than the "-u 1" file, the occurrence in the "-u 1" file is very rare but it does have it too.

But then the big surprise was when I loaded these files in the Sony BDP-S4500 BluRay player.
The m2ts file successfully loads across the network, 3D is automatically detected and used, and the picture looks completely clean.
Fade ins and outs are clean, background gradients are smooth, the dependent view looks perfectly normal, no green blobs, with both the "-u 4" file and the "-u 1" file. I am stunned !
It's like if the software players had forgotten to do the deblocking pass but the Sony player didn't or something. I cannot explain the difference in behaviour.

Did I forget something ? Did I miss a parameter ?