Free H.264 MVC 3D Encoder

[andresayang]

Hi,

I know this is a Huge question:

Is their any way for you (Videofan3d) to port this lib under Linux (Intel SDK is available under linux) or to make it open source (for the community to port it)

Many thanks for reply

Rgds

[videofan3d]

Is their any way for you (Videofan3d) to port this lib under Linux (Intel SDK is available under linux) or to make it open source (for the community to port it)


Hi,

I don't use any Linux distribution, and as far as I know, Adobe Premiere is not running on Linux - so there is no reason to port FRIM tools to Linux environment.

[andresayang]

Hi,

I don't use any Linux distribution, and as far as I know, Adobe Premiere is not running on Linux - so there is no reason to port FRIM tools to Linux environment.

Well, ok, if it is only suppose to work for Adobe Premiere, I understand ! (But adobe première is not really a "free tool").

[videofan3d]

Well, ok, if it is only suppose to work for Adobe Premiere, I understand ! (But adobe première is not really a "free tool").

Well, my point was to enable 3D-MVC encoding to create your own regular 3D videos (BD3D), and preferably as output from Adobe Premiere timeline (even if certain workaround is needed, as Premiere doesn't support native stereoscopic processing). Adobe's products are probably most often used tools for semi-professional video editing on Windows platform (3D video belongs to at least semi-pro level). And I guess there is nothing like this on Linux platform....

Please note:
- for MPEG2 encoding you can use HCEnc - it is free and probably better quality than Intel Media codec (does anybody still use MPEG2?)
- for h.264 encoding you can use x264 - it is free and top image quality
- for 3D-MVC ... there is no cheap or free 3D-MVC encoder on the market, but Intel Media, i.e. FRIM :-)

Remark:
Re-encoding and squeezing of original BD3D is nonsense!
3D video presentation requires BIG screen (80" is minimum, optimum is 100" and more). And big screen implies request for top image quality. Any re-encoding represents degradation - for what? for saving few GB diskspace?. Therefore I consider it wrong and useless approach.
Therefore I don't see a reason spending an effort on porting FRIM to Linux.

[andresayang]

Remark:
Re-encoding and squeezing of original BD3D is nonsense!


Well I do agree about re-encoding, but when we need video "image" editing we can not do it without going down to uncompressed files (especially for 3D)


3D video presentation requires BIG screen (80" is minimum, optimum is 100" and more). And big screen implies request for top image quality. Any re-encoding represents degradation - for what? for saving few GB diskspace?. Therefore I consider it wrong and useless approach.

Well not exactly true about the sceen size, I have a 46" screen, and (this is my personal point of view) 3D is better on my screen that it is in theater. "Saving few GB" is not exactly the point (I own a very huge nas server where I also run my apps).


Therefore I don't see a reason spending an effort on porting FRIM to Linux.


Well except if you have fun when programming ... you probably right. It was only a simple question as was "if you want to" no major issues, I can add dual boot on my server to use windows apps !

Rgds

[Anour]

Does anyone faced with artifacts when playing through Dune Solo?
MVC-3D, tsMuxeR (iso)

[Cedvano]

Hi everyone,

I would like re-encode all my sbs (mkv) files into mvc (combined) with Frimencode or other software.
Someone have the command line to do this ?

Thank you very much.

[Sharc]

Hi everyone,

I would like re-encode all my sbs (mkv) files into mvc (combined) with Frimencode or other software.
Someone have the command line to do this ?

Thank you very much.
You can do this with BD-Rebuilder.

[Cedvano]

You can do this with BD-Rebuilder.

Ok, thanks. That's work with TAB too ?

[Sharc]

Ok, thanks. That's work with TAB too ?
I don't think so. But you could make it a Feature Request for BD-RB.....

[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 (https://surveyplanet.com/5959c9f80181f921d337c401) ?
Thanks in advance...

[jdobbs]

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 (https://surveyplanet.com/5959c9f80181f921d337c401) ?
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]

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]

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]

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]

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]

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 (http://download.videohelp.com/r0lZ/tmp/TestFRIM.7z). 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]

...
You can download the test files I've used here (http://download.videohelp.com/r0lZ/tmp/TestFRIM.7z). 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]

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]

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.
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.]
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 (https://forum.doom9.org/showthread.php?t=170828), 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 (https://forum.doom9.org/showthread.php?p=1812132#post1812132) to encourage the users th check the new FRIMSource.

[Sharc]

..... 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]

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

Not at all, glad to have an explanation!

[videofan3d]

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

FRIM 1.27 is really mostly technical release, i.e. there are no changes in core-shared parts (including hw/sw detection), no changes in FRIMDecode, no changes in FRIMSource.
Changes are only in FRIMEncode and FRIMTranscode related to cropping.
And of course simple linkage with new Intel Media 2017 R1 source codes.

I can test only on my i7-4770K Haswell (desktop) and i3-3217U Ivy Bridge (laptop) - both have no issues
(although i3 is definitely not powerful enough for video encoding :) ... )

[r0lZ]

Indeed, so far, it seems that I'm the only one with that problem. But if I have that problem, I'm pretty sure that others will have it too.

Perhaps you could add some debug print commands to FRIMSource just before and during the initialisation of the Intel lib, and send me that version? Currently, the crash occurs BEFORE the creation of the log file, so I suppose that the problem occurs exactly when the intel lib is opened, or when FRIM calls it for the first time. If you open the log file immediately, and you print everything during the startup of the plugin, it should be relatively easy to locate the exact point of the crash. If you do a debug version, I'll be happy to test it...

[geheim]

@videofan3d

Thanks for still maintaining these great applications! Would it be possible to improve FRIM by keeping the SEI Messages for 3D subtitles intact (like MVCEnc does)?? That would be more than great as it is the one thing I'm still missing when doing backups of 3D movies.
Thanks so much!

[videofan3d]

@videofan3d

Thanks for still maintaining these great applications! Would it be possible to improve FRIM by keeping the SEI Messages for 3D subtitles intact (like MVCEnc does)?? That would be more than great as it is the one thing I'm still missing when doing backups of 3D movies.
Thanks so much!

Wow - that's the challenge! :D
This I need to study first .... :)

[videofan3d]

Indeed, so far, it seems that I'm the only one with that problem. But if I have that problem, I'm pretty sure that others will have it too.

Perhaps you could add some debug print commands to FRIMSource just before and during the initialisation of the Intel lib, and send me that version? Currently, the crash occurs BEFORE the creation of the log file, so I suppose that the problem occurs exactly when the intel lib is opened, or when FRIM calls it for the first time. If you open the log file immediately, and you print everything during the startup of the plugin, it should be relatively easy to locate the exact point of the crash. If you do a debug version, I'll be happy to test it...

Let's do first simple iteration:

https://ulozto.cz/!G0m8JPWmwalZ/frimsource-dbg20170714-dll

Use this library, which will create another file c:\FRIMSOURCE.log (always in root of C: )

This log should look like

**** Create_FRIMSource
**** FRIM.Open()
**** pPipeline->Init(&Params)
**** m_mfxSession.Init() - 1
... initiated
... initiated
**** FRIM.ReadFrame()
**** FRIM.ReadFrame()
**** FRIM.ReadFrame()
**** FRIM.ReadFrame()
**** FRIM.Close()

and then let me know.

If it doesn't create this file at all, or the first lines won't be
**** Create_FRIMSource
**** FRIM.Open()
then it means that Avisynth is not able to load plugin (and you need to check your Avisynth 2.6.0 installation)

[r0lZ]

Thanks for the debug version. I've just tested it. It crashes too, with no log file at all, exactly like the release version. But I don't think there is a problem with my avisynth installation. It can load every DLL I've tried so far, including the old FRIMSource, DGMVCDecode, and a lot of other plugins. Why should it be unable to load the new FRIMSource? And what is the difference with the old one that makes the new version impossible to load with my avisynth? Also, if I leave only the LoadPlugin() command in the script, without actually using it, avisynth doesn't crash. It's only the first call to FRIMSource() that makes it crash. Therefore, it seems that it can load it correctly.

Anyway, I will reinstall avisynth, just to be sure. I'll keep you informed...

[r0lZ]

I have de-installed avisynth, removed all additional plugins, rebooted, and re-installed avisynth 2.6.0. Still the same problem.

Windows shows me a debug message offering to send 3 files to M$. I have refused, but I have kept the files. If they can be useful to help diagnose the problem, you can download them here (http://download.videohelp.com/r0lZ/tmp/FRIMSourceDiagFilesFromM%24.7z).

Don't spend too mych time on this problem. If it is confirmed that the crash occurs only on my PC, I will distribute the new FRIMSource with the next version of BD3D2MK3D, and I will use DGMVCDecode personally. Thanks anyway for your patience!

[videofan3d]

I have de-installed avisynth, removed all additional plugins, rebooted, and re-installed avisynth 2.6.0. Still the same problem.


Let's try one more test: here (https://ulozto.cz/!XAY1lilEehzw/frimsource-dbg20170716-dll) is another dbg library.
Again, it will create file c:\FRIMSOURCE.log which should look like this:

*** AvisynthPluginInit3
done
**** Create_FRIMSource
**** FRIM.Open()
**** pPipeline->Init(&Params)
**** m_mfxSession.Init() - 1
... initiated
... initiated
**** FRIM.ReadFrame()
**** FRIM.ReadFrame()
**** FRIM.Close()

Function Create_FRIMSource() is the actual decoding function, while AvisynthPluginInit3 is assuring its registration in Avisynth framework. Registration is called as part of loading library.
Remark: Please check also if you don't have - by an accident - some residual avisynth.dll in your system, which could potentially harm loading 2.6.0 libraries (version 2.6.0 changed registration method if I remember correctly).
Let me know....

[r0lZ]

OK, I have removed all instances of avisynth.dll, except of course the one in %WINDIR%\SysWOW64, and rebooted again. Then I've tested the new FRIMSource_dbg20170716.dll with AvsPMod. Still the same problem. The script crashes immediately, and there is no log file. But then I did another test with Simple x264 Launcher... and it worked! :-)
Tested again with AvsPMod, crash again. With x264 launcher, it worked again.

I have then tested the recent release version... and it worked correctly from AvsPMod and from Simple Launcher! Rebooted again, and new test with AvsPMod and the release version of FRIMSource: perfect.

I really don't understand why it crashes in some circumstances but not every times. And why your latest debug version seems less stable than the release version. And why the presence of some (possibly outdated) avisynth.dll files in obscure directories NOT in my %PATH% can (perhaps) make a difference, but I suppose that removing them completely was the key. Thanks for suggesting it!

If you want, I can post the content of the log here, but I don't think that it's interesting, since it is produced only when everything works as expected.

I consider the problem as solved (although I still don't understand how it has been solved) and I will include the new FRIMSource with the next release of BD3D2MK3D.

Huge thanks for your patience, and sorry for having bothered you with this problem. (It would have been much more interesting for you and us to work on the SEI messages and the 3D depth of the subtitles. Of course, I'm also interested in this. It's the main thing that prevents me to add the possibility to convert to AVC+MVC in BD3D2MK3D.)

[Thalyn]

Not sure if you consider this to be an issue or not, but I discovered why I haven't been able to use FRIMSource properly since March of last year.

To quickly recap, I'd been having issues with software decoding simply stating that it "Cannot initialize Intel Media SDK session." This would be all the log would show, both for FRIMSource and for the program I was using (MeGUI, VirtualDub, etc). Hardware decoding would work, but I've since switched to a Ryzen so that isn't exactly an option anymore.

Curiosity (or some kind of dementia) got me, however, and I copied "libmfxsw32.dll" across to the path where the AVS script was, in addition to where I keep FRIMSource. Fired up the same script again and it seemed quite happy. Hopefully happy enough that this encode won't turn green part way (hence trying to get FRIMSource working again), but I won't know that for another 2 hours.

So, it would seem that it's looking for the Intel DLL in the same path as the script, rather than where the plugin is located. But it may only be doing that in software mode (or may only require that DLL for software decoding).

[videofan3d]

@videofan3d

Thanks for still maintaining these great applications! Would it be possible to improve FRIM by keeping the SEI Messages for 3D subtitles intact (like MVCEnc does)?? That would be more than great as it is the one thing I'm still missing when doing backups of 3D movies.
Thanks so much!

(Challenge was accepted)

Handling offset-metadata SEI messages in FRIM is difficult (due to pipeline processing), and I believe it is more generic task than only being part of MVC encoding.

I created a tool h264Offset3D for manipulation with offset-metadata.

I added this tool to my another SW package H.264 Patcher and BD-Tools (http://forum.doom9.org/showthread.php?t=174563). Please use this thread for all comments or questions...

[geheim]

(Challenge was accepted)

Handling offset-metadata SEI messages in FRIM is difficult (due to pipeline processing), and I believe it is more generic task than only being part of MVC encoding.

I created a tool h264Offset3D for manipulation with offset-metadata.

I added this tool to my another SW package H.264 Patcher and BD-Tools (http://forum.doom9.org/showthread.php?t=174563). Please use this thread for all comments or questions...

Thanks so much for this, I'll take a look at it :)

@jdobbs Perhaps you want to take a look at it as well, perhaps it would be possible to integrate this in BD Rebuilder to keep SEI Messages intact in the backup??

[MrVideo]

Where does one find the command line options for FRIMSource? Also, what if you do not know the value for num_frames?

[MrVideo]

I'm trying to run a script that BDRB created in my own script, as I am trying to encode H.264/4:2:2 videos to H.264/4:2:0. But, the script fails:
avs [error]: LoadPlugin: unable to load "C:\Program Files (x86)\BD_Rebuilder\tools\frimsource.dll", Proc not found. Update library version?
(e:\\00001.avs, line 2)
x264 [error]: could not open input file `e:\\00001.avs'
x264 pass 1 exited with error code 255.
The DLL is there (has to be, as BDRB uses it :D )
dir "C:\Program Files (x86)\BD_Rebuilder\tools\frimsource.dll"
-r-xr-xr-x+ 1 Administrator None 365568 Mar 27 2015 C:\Program Files (x86)\BD_Rebuilder\tools\frimsource.dll
So, what "Proc" is not being found?

[r0lZ]

You need the Intel library libmfxsw32.dll somewhere in the path, or if you have an Intel compatible CPU, you should update its drivers (that will probably update the hardware version of the same lib, libmfxhw32.dll).

[MrVideo]

You need the Intel library libmfxsw32.dll somewhere in the path, or if you have an Intel compatible CPU, you should update its drivers (that will probably update the hardware version of the same lib, libmfxhw32.dll).
I have an AMD CPU. I saw some postings regarding libmfxsw32.dll and copied it to the location of the video file I was working on. But that still resulted in the error. So, I have no clue as to where to put it.

[MrVideo]

You need the Intel library libmfxsw32.dll somewhere in the path
What path?

[sef]

@MrVideo
Folder with frimsource.dll

[MrVideo]

Folder with frimsource.dll
Well, that would be the BDRB installed location. Doesn't work for me when I try and call up frimsource.

Now I am really confused. BDRB works, yet I can't get it to work.

[r0lZ]

What path?
In one of the directories referenced by the %PATH% environment variable. For example, in C:\Windows\, or you can also put it in any directory and add that directory in the PATH variable (with Control Panel -> System and Security -> System -> Advanced System Settings -> Advanced tab -> Environment Variables -> User Variables frame).

As suggested by sef, you can also put it with the directory containing frimsource.dll itself, as it is theoretically dynamically added to the path when frimsource.dll is opened, but AFAIK it's not always sufficient.

If BDRB works, that might be because it changes its current directory to the directory containing libmfxsw32.dll when it needs it. An avisynth script does theoretically the same thing, but that depends of the version of fork of avisynth you use.

Anyway, tell us where is your copy of libmfxsw32.dll (and of libmfxhw32.dll, if you have it). Maybe we will be able to understand why it doesn't work.