View Full Version : Free H.264 MVC 3D Encoder
Pages :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[
19]
20
21
MrVideo
27th September 2017, 13:35
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).
My script is executed via cygwin. So my PATH is set up via that environment.
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.
It is in the same directory that frimsource.dll is in.
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.
I do not know if jdobbs does any directory switching when he runs frimsource.
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.
I did that, in the previous posts. I'm AMD, so no hw DLL.
I have a couple of other things I'm going to try after the computer frees up. I have a recoding job running at the moment. I'll report back.
MrVideo
27th September 2017, 14:49
OK, here is an update. In case I didn't mention it, the OS is XP-64.
I placed the two DLLs in the bin directory from which my script is run, which is in my $PATH. No diff.
I placed the two DLLs in the AVISynth/plugins directory and commented out the line that loads the frimsource.dll file.
I ran the AVISynth tool and it lists the DLLs that FRIMSource depends on. Two of them, d3d11.dll and dxgi.dll are not on my system. I guess that BDRB doesn't use any functions within those DLLs.
This gets further, sortof. Two error dialog boxes show up (both from x264.exe). The first error is that the entry point SetThreadErrorMode cannot be found in KERNEL32.dll. The 2nd is that the entry point EventRegister can't be found in ADVAPI32.dll. Then avs complains that there is no function FRIMSource.
I have no clue as to how BDRB is able to work when two entry points are not found in a couple of dependent DLLs.
No idea why trying to load the FRIMSource plugin via the AVS loadplugin doesn't want to work. At least it tries with the DLLs installed in the AVISynth plugins directory.
sef
27th September 2017, 18:32
the OS is XP-64.
From FRIMSource_readme.pdf, or FRIM_release_notes.txt, etc:
"Supported OS: Windows 7, Windows 8.x, Windows 10"
:confused:
MrVideo
28th September 2017, 02:26
Well, that is very confusing, since BDRB is using it and BDRB works very well under XP-64.
UPDATE: So, I'm going to try and see what happens under Win7. Well, I'm now going to have to go to the AVISynth thread because 2.6. is complaining that it can't find the Intel Media SDK. If it isn't one thing, it is another.
MrVideo
28th September 2017, 07:38
From what I can gather in the AVISynth thread, this is a FRIMSource want and not an AVISynth want. What does it takes to fix this error?
Trying to using FRIMSource would have resulted in my hair turning grey, if it weren't already grey. :D
Update: Looking at the Intel Media SDK at the Intel website, this is for Intel CPUs. I have an AMD CPU, so why is this being called? BDRD, under XP-64 and AMD CPU, has no issues using FRIMSource. From what I can gather, the associated SDK file is libmfxsw32.dll, which I have installed. It is in the AVISynth plugin directory, along with frimsource.dll.
MrVideo
28th September 2017, 10:30
I got desperate, so I moved the frimsource.dll and libmfx3sw32.dll to my cygwin home bin directory, which is in my $PATH. I then edited the avs script to look for frimsource.dll in that location.
I no longer get the SDK error, but I do get the following errors:
ERROR: undeveloped feature (-3), ..\frim_decode\src\pipeline_decode.cpp (297)
ERROR: undeveloped feature (-3), ..\frim_decode\src\pipeline_decode.cpp (818)
I keep getting closer and closer, only to take two steps forward and one step back. There's gotta be a light at the end of the tunnel at some point. :(
In case it isn't obvious, the AVS script is being called by the x264 program.
r0lZ
28th September 2017, 10:53
Update: Looking at the Intel Media SDK at the Intel website, this is for Intel CPUs. I have an AMD CPU, so why is this being called? BDRD, under XP-64 and AMD CPU, has no issues using FRIMSource. From what I can gather, the associated SDK file is libmfxsw32.dll, which I have installed. It is in the AVISynth plugin directory, along with frimsource.dll.
As I wrote above, there are two different DLLs: libmfxsw32.dll (with "sw" for software) and libmfxhw32.dll (the hardware version). The hardware version requires the right Intel CPU and is installed with its driver. The software version can theoretically be used with any CPU, and must be "installed" manually. As long as it is accessible by the calling program, it can be placed in any directory. But it seems that some things do not work as expected when it is run under cygwin and/or XP. I don't know why.
MrVideo
28th September 2017, 11:15
As I wrote above, there are two different DLLs: libmfxsw32.dll (with "sw" for software) and libmfxhw32.dll (the hardware version). The hardware version requires the right Intel CPU and is installed with its driver. The software version can theoretically be used with any CPU, and must be "installed" manually. As long as it is accessible by the calling program, it can be placed in any directory. But it seems that some things do not work as expected when it is run under cygwin and/or XP. I don't know why.
As I wrote, I am using the "sw" version from the BDRB install. The not working right when run under cygwin and/or XP is disheartening.
MrVideo
28th September 2017, 11:47
So, ok maybe using FRIMSource won't work. So, I went looking at FRIMDecode. The manual shows a nice example of piping the output to x264. So I created the following text file that I run with "sh frim.txt":
frimdecode -i::h264 00001.h264 -o - | \
x264 --input-csp i420 --input-res 1920x1080 --fps 29.97 \
--profile high --level 4.0 --bitrate 8000 --ref 4 \
--deblock 1:-1:-1 --me umh --subme 10 --psy-rd 1.00:0.15 --merange 24 \
--trellis 2 --deadzone-inter 21 --deadzone-intra 11 --fast-pskip \
--threads 12 --slices 4 --nr 0 --bframes 3 --b-pyramid strict \
--b-adapt 2 --b-bias 0 --direct auto --weightp 0 --keyint 30 \
--min-keyint 1 --scenecut 40 --rc-lookahead 60 --ratetol 1.0 \
--qcomp 0.60 --qpmin 10 --qpmax 51 --qpstep 4 --cplxblur 20.0 \
--qblur 0.5 --vbv-maxrate 16000 --vbv-bufsize 16000 \
--ipratio 1.40 --bluray-compat --open-gop --tff --sar 1:1 \
--output 0001_output.h264 -
So, what happens? I get the following errors:
ERROR: undeveloped feature (-3), src\pipeline_decode.cpp (297)
ERROR: undeveloped feature (-3), src\pipeline_decode.cpp (818)
In other words, the same errors when trying to use FRIMSource.
OK, let's run the following command in a CMD window:
[path to]\frimdecode -i::h264 00001.h264 -o 00001_output.yuv
I'm now not in a cygwin environment and guess what... the same two errors.
I'm going to end up pulling my hair out. :mad:
sef
28th September 2017, 15:15
Show your output of cmd, like that:
http://i89.fastpic.ru/big/2017/0928/bf/235a4dfa08a8048b594d539340954dbf.png
By the way, it's virtualbox ..
I'm just install Avisynth(first link in google(sourceforge)) and BD Rebuilder 0.50.24..
It's your "sh frim.txt":
http://i95.fastpic.ru/big/2017/0928/c0/181dd9a15a6e00a3bea25c90d976cac0.png
P.S. Hello, r0lZ! I'm glad to see you (I have not written here for a long time)
MrVideo
28th September 2017, 19:37
The output of the CMD window ONLY contains three lines; The two error lines shown above and one more:
ERROR: Cannot start decoding process.
It does not list any of the software's info at all.
sef
28th September 2017, 22:16
Make as I'm, in virtual machine..
Or, just for fun: make another user.. Install(reinstall), as i wrote above(Avisynth(first link in google(sourceforge)) and BD Rebuilder 0.50.24..) and.. ?????
MrVideo
28th September 2017, 23:03
I do not do virtual machines. The Win7 box is a new system. AVISynth 2.6 installed for the first time and BDRB installed for the first time. That is not the problem.
sef
29th September 2017, 00:37
I do not do virtual machines
Goodbye
MrVideo
29th September 2017, 06:36
At this point in time, I've decided to scrap this pursuit. It should not be this hard to get a simple program working. Many people are able to use it, but it just does not like me.
videofan3d
29th September 2017, 19:03
At this point in time, I've decided to scrap this pursuit. It should not be this hard to get a simple program working. Many people are able to use it, but it just does not like me.
Setting of PATH and other operational topics should be straightforward - this was already described many times here.
Regarding Cygwin - I never tried it.
But you are trying to run FRIM/Intel Media on Windows XP?
It is not guaranteed and supported. See here https://software.intel.com/en-us/media-sdk - only Win 7, 8.1, 10.
(If I remember correctly I tried it once few years ago - and it crashed. Obviously there is no point to investigate it further - Win-XP is perceived dead.)
MrVideo
30th September 2017, 10:04
But you are trying to run FRIM/Intel Media on Windows XP?
Initially. But, as noted, the recent posts are the result of trying on Win7.
frank
16th October 2017, 18:06
FRIMSource / FRIMDecode work very well in HW mode
BUT with 2 movies you'll get endless loop (B3D2MK3D):
- The Martian 3D
- Wonder Woman 3D
Black frames encoded. SW mode works. Same happens with DGMVCsource. :(
So something is wrong compiled with Intel's new SDK, I don't know. For the new Intel processors you have to use it.
Tested with Intel Core i7-7700HQ (Kaby Lake), Win10.
videoh
16th October 2017, 22:26
Hi frank,
Have you been able to see what causes the looping in the code?
I'll buy one of those two blurays and see what I can discover for DGMVCSource().
You say latest IMSDK is needed for 7700K, so how can you report results for DGMVCSource() on 7700K (DGMVCSource uses an older IMSDK)?
frank
17th October 2017, 12:16
I only tested on my Dell XPS 15 9560 (Core i7-7700HQ). There are Intel drivers for GPU 330 and using of AVX2. That's why I think you need latest SDK for stable hardware support.
DGMVCsource and FRIM work well but not with that two movies. I only can see that the decoders hang.
videoh
19th October 2017, 23:10
frank, is this something that happens only with B3D2MK3D? I ask that because I ripped 00042.ssif from the Wonder Woman 3D bluray and then demuxed the left.h264 and right.264 streams with EAC3TO, then made a script with DGMVCSource(...,mode="hw") and dropped the script on MPC-HC. It plays fine every time, not ever hanging or looping. I tested it on both a Haswell and a Kaby Lake.
What are the scenarios where you get these failures?
r0lZ
20th October 2017, 11:32
I don't think BD3D2MK3D could be the culprit, It creates only a AVS script with (basically) this:
LoadPlugin("D:\Tcl\work\BD3D2MK3D\toolset\FRIMSource.dll")
#LoadPlugin("D:\Tcl\work\BD3D2MK3D\toolset\DGMVCDecode.dll")
# Load the two video streams (192000 frames per stream)
interleaved = FRIMSource("mvc", "00001.track_4113.264", "00001.track_4114.mvc", num_frames = 192000, cache = 2, platform = "")
#interleaved = DGMVCSource("00001.track_4113.264", "00001.track_4114.mvc", view = 0, frames = 192000, mode = "auto") # Old syntax for mode: hw = 0
# Current base view: left eye.
# The views are in the common order: AVC stream = left view, MVC stream = right view.
left = SelectEven(interleaved)
right = SelectOdd(interleaved)
# Build Side-by-Side stream
StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))
In this example, the platform mode is left to automatic. The plugin should use the hardware decoder if it is available. You can also force sw or hw mode from the GUI, but it's normally not necessary.
That script is then encoded in h264 or h265 with a shell script containing a command similar to this:
"D:\Tcl\work\BD3D2MK3D\toolset\avs2yuv.exe" ^
"__ENCODE_3D_MOVIE.avs" -frames 192240 -o - ^
| "D:\Tcl\work\BD3D2MK3D\toolset\x264_8bit_x64.exe" ^
--crf 22 --preset slow --level 4.1 --vbv-bufsize 78125 --vbv-maxrate 62500 ^
--sar 1:1 --range tv --colormatrix bt709 ^
--frame-packing 3 --qpfile chapters_3D.qpfile --frames 192240 --fps 24000/1001 ^
--output "00001_3D.264" --demuxer y4m --stdin y4m -
That .CMD script is launched directly by the user and runs therefore in a command prompt window, totally independent to BD3D2MK3D.
frank
20th October 2017, 17:17
videoh:
frank, is this something that happens only with B3D2MK3D?The issue comes from the used decoder dll in the avs script. In HW mode they use the installed Intel graphics drivers (SDK).
FRIMdecode.exe without BD3D2MK3D has the same behavior.
Hmm... BD3D2MK3D demuxes the m2ts streams with tsMuxeR. You used eac3to. So I will test again with demuxed AVC and MVC streams by eac3to.
EDIT
No way, same behavior.
So you may have another version of Intel graphics drivers. I used v21.20.16.4664
I give up.
FlintEastwood
27th January 2018, 18:13
...
The dependent (.mvc) stream for the selected video is not Blu-ray complient or does not match the base stream.
May be this is due to the SEI messages being in the wrong order...
I get the same error with FRIM encodes in DVD Architect 7.
I try to make a 3D-Bluray with menus and this is not possible with TsMuxer only.
I used TsMuxer to rebuild the SEI data but it didn't help. DVD Architect still complains about the MVC-stream. :(
FlintEastwood
11th February 2018, 23:42
I'm having now a strange problem with my encodes in PowerDVD:
I try to make bluray-compatible streams:
FRIMEncode -i test.avs -o:mvc testMVC.avc testMVC.mvc -avi -sbs 2 -vbr 15000 40000 -cpbsize 3750 -u 3 -l 4 -profile high -level 4.1 -colormatrix bt709 -colorprim bt709 -colortransfer bt709 -viewoutput
When I set the target usage to "-u 1" or "-u 2" the muxed BD plays but it looses the second view at some frames. So 3D goes on and off and on and off.
When I set the target usage to "-u 3" or higher, everything plays fine.
I'm forced to use Software-mode, as my i7 870 doesn't support the hardware encoding. Is that the problem?
OS is Win10 64bit. Muxing is done with TsMuxer 2.6.12. I'm using Avisynth 2.60 32bit and FrimEncode 32bit, but that shouldn't be a problem?
marcotti
17th March 2018, 18:48
Hi All,
I have a movie Full HD Over/Under (or TAB 1920x2160) in MKV.
I extracted the video track with tsMuxer, to obtain a 264 file (~30GB).
I fed FRIMDecode64 with the following:
FRIMDecode64 -i:h264 E:\Video\Blu-Ray\AME\MyMovie_3D.track_1.264 -o E:\Video\Blu-Ray\AME\MyMovie_3D.track_1.yuv
And it looked working (the file is ~43GB).
Now I tried both these options but I optained in both cases a very little file (~5GB) that, btw, is unreadable.
FRIMEncode64 -tab 2 -i E:\Video\Blu-Ray\AME\MyMovie_3D.track_1.yuv -w 1920 -h 1080 -viewoutput -o:mvc E:\Video\MyMovie_3D_base.avc E:\Video\MyMovie_3D_dependent.mvc -vbr 28000 40000 -u 1
and
FRIMEncode64 -tab 2 -i E:\Video\Blu-Ray\AME\MyMovie_3D.track_1.yuv -w 1920 -h 1080 -viewoutput -o:mvc E:\Video\MyMovie_3D_base.avc E:\Video\MyMovie_3D_dependent.mvc -u 1
What do I do wrong?
Thanks for helping
Cheers
Marco
sneaker_ger
18th March 2018, 00:40
FRIMDecode64 -i:h264 E:\Video\Blu-Ray\AME\MyMovie_3D.track_1.264 -o E:\Video\Blu-Ray\AME\MyMovie_3D.track_1.yuv
And it looked working (the file is ~43GB).
43 GB is way too small. Decoding is not working correctly (unless it is a very short movie). Should be 750 GB for a 90 minute movie for 1920x2160 at 23.976 fps.
Is it using software or hardware decoding? Try software decoding.
Sharc
18th March 2018, 12:46
It may help to put the paths to the files between quotation marks (I don't spot any blanks though ....)
Did you run out of disc space?
astraub
17th April 2018, 10:07
Hi,
is there anywhere a simple example how to use FRIMDecode to separate the two video streams on a 3D Bluray disk?
What options does the command offer? Is the only output option .yuv format? Huge files?
I tried out the Geekit from DVDFab to shrink my 3D BluRays. basically this really works very fast and with very good quality.
The only problem is that even the activated version still puts random watermarks in the right eye stream and there seems to
be no willingness from the manufacturer to fix this.
So I am trying to find a replacement for the MVC decoder (their Encoder works REALLY good and very fast!).
So far the only option I hope to work is using FRIMDecode -> .yuv files -> H.264 encode -> .mkv
This way i could hopefully end up with the two streams needed to feed the MVC encoder to generate a smaller 3D BluRay.
I also tried BD Rebuilder, but my SW player is generating serious blocking artifacts in the right eye channel when using this.
The results of the Geekit MVC encoder work flawlessly.
I would be really glad about any hints/links in that direction!
Greetings
Andreas
sneaker_ger
17th April 2018, 11:24
What options does the command offer? Is the only output option .yuv format? Huge files?
From the start post:
FRIM Decoder (command-line tool) converts elementary or transport streams (MPEG2, H.264 AVC/MVC-3D, VC1) into planar-yuv. Output can be either regular file or Windows named pipe.
Output to a pipe allows further YUV processing without consumption of enormous diskspace.
[...]
FRIM Source is Avisynth plugin for sequential reading of elementary or transport streams (MPEG2, H.264 AVC/MVC-3D, VC1) in Avisynth scripts.
astraub
17th April 2018, 11:59
Yes, I have seen the pipe option. Unfortunately my MVC Encoder does not have a command line option - so I need the intermediate files. I will also need to re-compress the .yuv files to the size required. It would of course be better to extract the orginal H.264 streams - but so far only the DVDFAB Geekit appears to be able to do that.
I still need some help for the command line syntax of the FRIMDecoder to generate the two streams from a frame sequential MKV ...
sneaker_ger
17th April 2018, 12:11
Yes, I have seen the pipe option. Unfortunately my MVC Encoder does not have a command line option - so I need the intermediate files. I will also need to re-compress the .yuv files to the size required. It would of course be better to extract the orginal H.264 streams - but so far only the DVDFAB Geekit appears to be able to do that.
3D Blu-Ray is MVC which means one of the views depends on the base view. You cannot separate them into 2 H.264 streams without re-encoding. If you want to re-encode you can feed the yuv pipe or avs script into x264cli or ffmpeg or whatever you need.
astraub
17th April 2018, 12:44
Hmm ... I would dispute that. Not only because DVDFab wrote, that they can extract the H.264 streams without quality loss, but also based on the fact that in an actual 3D player there is simply no time to re-encode the dependent stream just to decode it afterwards. There must be a pretty simple mathematical calculation to combine the frames of the MVC stream and the dependant stream, which can be calculated easily in real time in a 3D player. This is basically reversing the encoding operation. You could call that a re-encode - but not in the sense that the actual frames are being completely decoded to an uncompressed format and re-encoded again.
The main problem here is, that it appears to be practically impossible to get a detailed specification of the MVC stream and the dependent stream formats and the generation of the dependent stream. I already searched the internet for hours - without success. That is most likely the reason, why so far the FRIM tools are the only non-commercial tools so far.
OK - so now I still need the syntax to use FRIMDecode with a frame sequential MKV file as an input and two .yuv files as output.
astraub
17th April 2018, 14:05
In the meantime I found this:
FRIMDecode mvc -i "MVCCombined.h264" -o "TMP.yuv"
should hopefully generate the two decoded .yuv files. Will test this tonight.
r0lZ
18th April 2018, 08:56
Hmm ... I would dispute that. Not only because DVDFab wrote, that they can extract the H.264 streams without quality loss, but also based on the fact that in an actual 3D player there is simply no time to re-encode the dependent stream just to decode it afterwards.
DVDFab can extract the h264 stream. In other words, it can extract the MAIN, AVC stream. And any good demuxer can also extract the MVC stream (the dependent view), but it's totally useless, as there is no way to decode it without the main AVC stream.
So, you can extract the AVC and the MVC streams (without quality loss) with any good demuxer (plus a decrypter to get rid of the protection), but to do something with that two video streams, you need a program that can decode the streams to either display them (like a 3D BD player) or to just output the raw streams to a file or a pipe (and it's exactly what FRIM does). Finally, you should re-encode the two streams to another format, more practical and requiring less disc space (like Half-SBS).
If you want to do that with free tools (and without watermarks), have a look at BD3D2MK3D (https://forum.doom9.org/showthread.php?t=170828). It does everything (except the removal of the protection) with the help of avisynth, and it outputs a final MKV in Half or Full-SBS or TAB, ready to be played with any 3D player. But it cannot re-encode to a smaller 3D BD.
astraub
22nd April 2018, 11:36
In the meantime I received a fixed version of the DVDFab Geekit - no watermarks any more. I hope this will make it to the official download page soon. It contains an MVC Decoder and MVC encoder so that I can now successfully change the size of all my 3D Bluray images to a more acceptable scale without losing any visible quality or reducing resolution! Problem solved.
videofan3d
9th July 2018, 21:51
Intel released recently new version of their Media SDK - 2018 R1. This version contains also free HEVC encoder/decoder.
New version of FRIM 1.29 incorporates (beside few other improvements) this HEVC codec.
Since implementation of HEVC represented significant rework of many internal routines, I marked version 1.29 as "experimental".
Changes are described in release notes and also in accompanied FRIM_setup_readme.pdf document (important!)
Would be great if somebody who is interested in this version could try and provide feedback here in this forum.
Alanick
14th July 2018, 05:13
Hey guys, quick question if I may.
Is there any tool out there that can allow to edit the .mp4 converted file to correct lets say audio language name?
For example if the mp4 has 5 audio streams, but all are named English/eng, how can I edit the video with out re-encoding/re-muxing?
I know how to do it for MKV with MKVToolnix, but what about mp4 format?
thank you in advance.
FlintEastwood
26th July 2018, 22:23
Hey guys, quick question if I may.
Is there any tool out there that can allow to edit the .mp4 converted file to correct lets say audio language name?
For example if the mp4 has 5 audio streams, but all are named English/eng, how can I edit the video with out re-encoding?
I know how to do it for MKV with MKVToolnix, but what about mp4 format?
thank you in advance.
This is the wrong thread for this question, isn't it?
Well, you can do this easily with Avidemux. The file has to be rewritten but nothing is reencoded.
There is a way to do it with Mp4Box too. I'm not familiar with it but you could give it a try.
Alanick
28th July 2018, 04:45
Thank you for your answer.
It isn't the wrong thread, I simply want to know how can one edit the already encoded/muxed file with out re-encoding/re-muxing all over again for an MP4 file.
SpasV
2nd September 2018, 12:54
I need some help with FRIMSource64(), please.
My working enviroment: Windows 10, FRIM version 1.29 (x64) (Avisynth+ (Intel Media SDK 2018 R1))
I'm trying to pipe .h265 video to x265.
>avs2yuv64 -frames 24 -raw -depth 10 -par 1:1 encode_Mission_Impossible.avs -
encode_Mission_Impossible.avs
LoadPlugin("C:\Programs\AviSynth+\plugins64+\FRIMSource64.dll")
FRIMSource64(codec="h264", filename="F:\Mission_Imposssible_Ghost_Protocol\Mission_Imposssible_Ghost_Protocol.h265", cache=1, num_frames=24)
The result is:
error: Script error: There is no function named 'FRIMSource64'.
(encode_Mission_Impossible.avs, line 2)
The requirenment for libmfxsw64.dll to be "placed in any directory which is specified in PATH environment variable" is fulfilled - it is in two directories.
What can I do about this?
Thanks.
videofan3d
3rd September 2018, 06:21
I need some help with FRIMSource64(), please.
My working enviroment: Windows 10, FRIM version 1.29 (x64) (Avisynth+ (Intel Media SDK 2018 R1))
I'm trying to pipe .h265 video to x265.
The requirenment for libmfxsw64.dll to be "placed in any directory which is specified in PATH environment variable" is fulfilled - it is in two directories.
What can I do about this?
Thanks.
What about
FRIMSource(codec="h264", filename=…
?
SpasV
3rd September 2018, 09:57
What about
FRIMSource(codec="h264", filename=…
?
LoadPlugin("C:\Programs\AviSynth+\plugins64+\FRIMSource64.dll")
FRIMSource64(codec="h264", filename="F:\Mission_Imposssible_Ghost_Protocol\Mission_Imposssible_Ghost_Protocol.h265", cache=1, num_frames=24)
FRIMSource64.dll is Version 1.29.
Maybe, it is because of the file I'm trying to source - .h265?
Format: HEVC
Bit depth: 10 bits
FRIM_release_notes.txt reads:
2018-07-08
FRIM all:
- experimental HEVC support
Actually, I'm trying to pipe .h265 stream to x265 encoder.:)
videofan3d
3rd September 2018, 19:48
FRIMSource64.dll is Version 1.29.
Maybe, it is because of the file I'm trying to source - .h265?
Format: HEVC
Bit depth: 10 bits
FRIM_release_notes.txt reads:
2018-07-08
FRIM all:
- experimental HEVC support
Actually, I'm trying to pipe .h265 stream to x265 encoder.:)
Second attempt:
FRIMSource(codec="h265", filename=…"
SpasV
4th September 2018, 01:55
Second attempt:
FRIMSource(codec="h265", filename=…"
The same result.
I've found a workaround:
ffmpeg -i Mission_Imposssible_Ghost_Protocol.h265 -strict -1 -f yuv4mpegpipe -
Maybe, I have some general problem. I cannot get this filter working at all.
SpasV
5th September 2018, 09:35
Second attempt:
FRIMSource(codec="h265", filename=…"
Are you suggesting my using 32-bit AviSynth+?
SpasV
5th September 2018, 10:24
OK. I've run plugins64.reg.
I've run
FRIMSource(codec="h265", filename="G:\Mission_Imposssible_Ghost_Protocol\Mission_Imposssible_Ghost_Protocol.h265", cache=1, num_frames=24)
in AvsPmod and got
ERROR:Failed to load plugin (1D962A45A43FF41A6)
ERROR:undeveloped feature (-3), ...
Is there an instruction for installing these plugins?
videofan3d
5th September 2018, 19:37
OK. I've run plugins64.reg.
I've run
FRIMSource(codec="h265", filename="G:\Mission_Imposssible_Ghost_Protocol\Mission_Imposssible_Ghost_Protocol.h265", cache=1, num_frames=24)
in AvsPmod and got
ERROR:Failed to load plugin (1D962A45A43FF41A6)
ERROR:undeveloped feature (-3), ...
Is there an instruction for installing these plugins?
Read document FRIM_setup_readme.pdf which is part of the distribution. There is description of the plugin installation.
In general, you need to edit plugins64.reg and set there path accordingly - only then can FRIM find relevant plugin.
Furthermore, the plugins which are part of free distribution, are SW based only. So you will need to use FRIMSource(…, platform="sw", …)
SpasV
9th September 2018, 12:29
Unfortunately, I cannot make FRIM works.
I’ve registered the plugins with plugins64.reg and I have:
>avs2yuv64 -seek 1 -frames 24 -raw -csp I420 -depth 10 avs\encode-FRIM.265.avs -| x265-10b - ...
error: ERROR: expect more data at input (-10), c:\prj\intelmedia\frim_decode\src\pipeline_decode.cpp (587)
ERROR: expect more data at input (-10), c:\prj\intelmedia\frim_decode\src\pipeline_decode.cpp (262)
encode-FRIM.265.avs
[FRIMSource(codec="h265", filename="F:\Mission_Imposssible_Ghost_Protocol\Mission_Imposssible_Ghost_Protocol.mkv", cache=1, num_frames=24, platform="sw")]
This one works:
>C:\Programs\FRIM_x64_version_1.29\x64\FRIMDecode64 -i:mvc insurgent_cut.264 -o output_L.yuv output_R.yuv
FRIM Decoder version 1.29 (experimental) - Win64 (build: Jul 8 2018)
- based on Intel(R) Media SDK
Media SDK impl SOFTWARE (C:\Programs\FRIM_x64_version_1.29\x64\libmfxsw64.dll)
Processing started
Frame number: 4087
Processing finished in 175.66 seconds
videofan3d
11th September 2018, 05:12
Unfortunately, I cannot make FRIM works.
Mission_Imposssible_Ghost_Protocol.mkv
FRIM does not parse .mkv container...
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.