Free H.264 MVC 3D Encoder

[TankTreads]

Is there any way for FRIM Transcode to crop? The CLI output hints that crop is a feature but I can't find the arguments.

[videofan3d]

I was wondering how many of you still use FRIM Tools?
Is it still worth to update it with Intel Media SDK 2017?

Will you do me a favor and fill short survey ?
Thanks in advance...

[jdobbs]

Originally Posted by videofan3d

I was wondering how many of you still use FRIM Tools?
Is it still worth to update it with Intel Media SDK 2017?

Will you do me a favor and fill short survey ?
Thanks in advance...

BD Rebuilder uses it. So that means that anyone using BD-RB for 3D sources still use it.

[r0lZ]

Same thing for BD3D2MK3D (and FRIMsource).

[videofan3d]

Originally Posted by TankTreads

Is there any way for FRIM Transcode to crop? The CLI output hints that crop is a feature but I can't find the arguments.

Cropping in FRIMTranscode is not implemented in version 1.26 yet, only resizing.

I will add to next release, so you will be able to crop (and optionally resize) widescreen movies, e.g. to 1920x808 without letter box black-bars.

[videofan3d]

Technical release with few changes:

FRIM all - build with Intel Media SDK 2017 R1

FRIMTranscode - added parameter -dar for forcing Display Aspect Ratio

FRIMTranscode, FRIMEncode - added cropping

For more details please refer to FRIM_release_notes.txt

[jamt]

Originally Posted by videofan3d

I was wondering how many of you still use FRIM Tools?
Is it still worth to update it with Intel Media SDK 2017?
Thanks in advance...

I'm glad you are still maintaining it. As far as I know there's no other option for encoding in MVC format. The fact that there's no sophisticated GUI available like Handbrake is probably an obstacle for some people. I suspect if BD3D2MK3D supported use of FRIM encode to create MVC format outputs there'd probably be more people using it. It is definitely a niche since not many media players support MVC playback, but for those of us in that niche, e.g. with media servers & 3D video collections, it is an invaluable tool.

[jdobbs]

Thanks for the new version!

[r0lZ]

Thanks!

I wonder why it is necessary to modify or recompile your sources to use the Intel library 2017. I did some tests, and it seems that the new lib (libmfxsw32.dll distributed with your package) is backward compatible with the previous version of FRIMSource (and with DGMVCSource, not updated yet). I haven't tried the hardware version of the Intel lib 2017, and FRIMdecode, FRIMencode and FRIMtranscode.

Of course, I will use the new FRIM, but can you explain why it was necessary to release the new version ? Is it for compatibility with recent Intel chipsets or drivers ?

[r0lZ]

Oh, well, I've just checked the new FRIMSource with the new Intel Lib (both from your latest 32-bit distribution, v1.27) and it crashes! As I wrote above, the new FRIMSource works well with the old Intel Lib, but obviously, it has a bug when used with the new lib.

Can you have a look?

[videofan3d]

Originally Posted by r0lZ

Oh, well, I've just checked the new FRIMSource with the new Intel Lib (both from your latest 32-bit distribution, v1.27) and it crashes! As I wrote above, the new FRIMSource works well with the old Intel Lib, but obviously, it has a bug when used with the new lib.

Can you have a look?

I quickly checked FRIMSource (32 and 64, hw and sw - all combinations) with the following .avs script:

LoadPlugin("c:\Prj\IntelMedia\_exe\win32\Release_v1.27\FRIMSource.dll")
#LoadPlugin("c:\Prj\IntelMedia\_exe\x64\Release_v1.27\FRIMSource64.dll")

FILE3D="c:\Prj\IntelMedia\_testing\PANY.m2ts"

FRIMSource(codec="mvc", filename=FILE3D, filename_dep=FILE3D, container="ts", platform="hw", \
              layout="sbs", swaplr=false, cache=0, reload=true, num_frames=120, fastmode=true, log_file="c:\Prj\IntelMedia\_testing\Z1.log").ShowSMPTE(size=128)

No issue, no crash ... (and logfile confirmed activation of Intel 2017 libraries and API version 1.23)

Please check your configuration (PATH and installation) whether - by chance - some old libraries are not activated....
(FRIMDecode and FRIMSource have no functional changes in source code)

[videofan3d]

Originally Posted by r0lZ

Thanks!

I wonder why it is necessary to modify or recompile your sources to use the Intel library 2017. I did some tests, and it seems that the new lib (libmfxsw32.dll distributed with your package) is backward compatible with the previous version of FRIMSource (and with DGMVCSource, not updated yet). I haven't tried the hardware version of the Intel lib 2017, and FRIMdecode, FRIMencode and FRIMtranscode.

Of course, I will use the new FRIM, but can you explain why it was necessary to release the new version ? Is it for compatibility with recent Intel chipsets or drivers ?

Well - the reason is simple: to be up to date ...
(And add few features which somebody here asked for )

[jamt]

Originally Posted by videofan3d

Well - the reason is simple: to be up to date ...
(And add few features which somebody here asked for )

While on the subject of new feature requests, I'll oblige

1. `-swaplr` option for FRIMTranscode

2. Some indication of % remaining (e.g. show total frames during FRIMEncode, and show frames instead of dots during FRIMTranscode)

Neither of these are a big deal, as I can get total frames from ffprobe, and I can use decode > encode instead of FRIMTranscode to swap. But being able to just use FRIMTranscode instead of decode > encode via SBS is probably more efficient, and of course would be nice to have some idea of time or % remaining.

Thanks again for the fantastic and unique software.

[r0lZ]

My original script is the script generated by BD3D2MK3D. It has always worked fine.

Anyway, to be sure, I've created a much simplified script, and I've put all necessary binaries in the same directory. When I use the old FRIMSource, it works fine, but the new FRIMSource crashes immediately, even without creating the log file. (I've tested the script from within AvsPMod and with Simple X264 Launcher, with the same result.)

Here is the simplified script:

# LoadPlugin("FRIMSource2015.dll")    # works fine
LoadPlugin("FRIMSource2017.dll")    # crashes

FRIMSource(codec = "mvc", filename = "01000.track_4113_CUT.264", \
		filename_dep = "01000.track_4114_CUT.mvc", num_frames = 120, cache = 2, platform = "sw", \
		log_file = "FRIMSource.log")

You can download the test files I've used here. Unless something is wrong on my PC, it should crash for you too. (Note that I've cut the h264 and MVC streams to create a relatively small archive file, and I'm pretty sure that it will crash if you try to encode the whole stream, but the streams are sufficient to check at least the 120 first frames.)

I've noticed something strange. On my system, I have the libmfxsw32.dll at different places, and when I use the old FRIMSource, the log file is created correctly, and I can see that it loads the Intel DLL from an unusual place (where it has been installed by a program I don't use any more). It doesn't use the DLL in the same directory as FRIMSource.dll. Not sure why. But that means that it can use an outdated Intel DLL instead of the latest one. For my tests, to be sure, I've replaced the DLL really used with the latest version, and the crash happens anyway, so I don't think that it's a mismatch with an older version. And the old FRIMSource works correctly anyway, apparently regardless of the version used. But I wonder if it is possible to force FRIMSource to use a specific Intel DLL, either by specifying its path or by registering libmfxsw32.dll in the Windows registry. Or is it supposed to load the Intel lib from its directory? (Of course, I know that it uses another DLL in hw mode if the lib has been installed with the Intel driver, but it's not the case here, and I use only the sw mode.)

[videofan3d]

Originally Posted by r0lZ

...
You can download the test files I've used here. Unless something is wrong on my PC, it should crash for you too.
...

Hi, I just downloaded your samples, unzipped it into single directory and opened test.avs using my MP-HC media player. And it played normally (there are mountains with logo NetBlender, right?). Both in SW as well as HW mode.

Log-file says:

Media SDK impl		SOFTWARE (C:\UTL\FRIM\libmfxsw32.dll)
Media SDK version	1.23
Memory type		System
Async depth		4

and

Media SDK impl		HARDWARE - D3D9 (C:\Program Files\Intel\Media SDK\libmfxhw32.dll)
Media SDK version	1.20
Memory type		System
Async depth		4

I don't mix installations. I have all FRIM files in single directory

Directory of c:\UTL\FRIM
08.07.2017  08:00           366 592 FRIMDecode.exe
08.07.2017  08:00           428 544 FRIMDecode64.exe
08.07.2017  08:00           388 096 FRIMEncode.exe
08.07.2017  08:00           451 584 FRIMEncode64.exe
08.07.2017  08:00           368 128 FRIMSource.dll
08.07.2017  08:00           431 104 FRIMSource64.dll
08.07.2017  08:00           395 776 FRIMTranscode.exe
08.07.2017  08:00           468 992 FRIMTranscode64.exe
21.04.2017  14:03        18 737 384 libmfxsw32.dll
21.04.2017  14:09        21 783 784 libmfxsw64.dll

which is in PATH (and HW libraries were installed together with Intel drivers).

Does anyone face similar issues? Please provide me with more info, symptoms - so far I cannot reproduce it.

[videofan3d]

Originally Posted by jamt

While on the subject of new feature requests, I'll oblige

1. `-swaplr` option for FRIMTranscode

2. Some indication of % remaining (e.g. show total frames during FRIMEncode, and show frames instead of dots during FRIMTranscode)

Neither of these are a big deal, as I can get total frames from ffprobe, and I can use decode > encode instead of FRIMTranscode to swap. But being able to just use FRIMTranscode instead of decode > encode via SBS is probably more efficient, and of course would be nice to have some idea of time or % remaining.

Thanks again for the fantastic and unique software.

ad 1. -swaplr in FRIMTranscode is in principle doable, but it would be likely very complicated change in the code. H.264 MVC format stores L/R frames sequentially, and internal surfaces in processing pipeline provide them in this sequence. Thus swapping would mean breaking&caching this sequence - this is pretty much complicated and risky to do it, especially when there is simple workaround: pipe FRIMDecode and FRIMEncode

ad 2. display percentage.
All FRIM tools are reading input sequentially, allowing pipeline. This is unix-style and in my view very nice, I like it. The slightly limiting consequence of such principle is that you don't know total number of frames in advance (and positive consequence is that you can encode an infinite input stream!). Which means that you cannot calculate any percentage - not knowing the total .
Therefore FRIMDecode and FRIMEncode display only progressing frames, and FRIMTranscode displays a dot "." after each 100 processed frames.
Btw. progress number and dot "." are displayed on "stderr", while all other info on "stdout"

Sorry if I disappointed you with these features....

[r0lZ]

Originally Posted by videofan3d

Hi, I just downloaded your samples, unzipped it into single directory and opened test.avs using my MP-HC media player. And it played normally (there are mountains with logo NetBlender, right?). Both in SW as well as HW mode.

Strange. Here, the crash is systematic.
Yes, the test files are the beginning of the NetBlender 3D demo. I use it often for quick tests. But I have exactly the same problem with other movies.

Originally Posted by videofan3d

I don't mix installations. I have all FRIM files in single directory [...] which is in PATH (and HW libraries were installed together with Intel drivers).

I have removed all unnecessary versions of the Intel lib, and rebooted, just to be sure. The problem persists. I will try again after having added the directory in PATH, but I don't think that will solve the problem.
[EDIT: Confirmed. Adding the directory in PATH doesn't solve the problem.]

Originally Posted by videofan3d

Does anyone face similar issues? Please provide me with more info, symptoms - so far I cannot reproduce it.

Currently, the only symptom that can be useful to find the cause of the bug is the fact that it crashes immediately, before the creation of the log file. I suppose that the problem is related to the initialisation of the plugin or to the opening of the intel lib. The other notable thing is that the old FRIMSource works well. The problem must therefore be related to something that has changed in the new version.

I will release an update of BD3D2MK3D with the new Intel lib, but still with the old version of FRIMSource. But I will explain the problem in the BD3D2MK3D thread, and encourage the users to check the new version of FRIMSource, and report if it works for them. If it appears that I'm the only one with that problem, the next update will contain the new version.

In the meantime, I will try to do some tests with FRIMdecode or FRIMtranscode, but I don't have much time, so don't expect it soon...

[EDIT] New BD3D2MK3D released, and I've added this post to encourage the users th check the new FRIMSource.

[Sharc]

Originally Posted by r0lZ

..... and encourage the users to check the new version of FRIMSource, and report if it works for them. ....

I tested your simplified script with the new FRIM version (x86, 32bit) => No crash.
(For testing I put everything into the same folder).

[r0lZ]

OK, thanks. It seems that my PC is the culprit. Could it be because I don't have an Intel CPU compatible with the hardware mode? (I encode usually with the platform = "" argument, and for my tests, I've forced platform = "sw" to be sure, but perhaps there is a bug in FRIMSource of in the Intel lib that assumes that the hardware mode is available anyway? Or does it crash when it tries to check anyway if hw mode is available?)

[jamt]

Originally Posted by videofan3d

Sorry if I disappointed you with these features....

Not at all, glad to have an explanation!