Log in

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

Sharc
1st March 2015, 12:41
I tested Pacific Rim with FRIMsource (plugin).
=> No glitches, but MPC-HC crashes when trying to seek.

Tests with FRIMdecode:
- H.264 3D to L/R.yuv => o.k.
- H.264 3D into standard O/P and pipe to x264 SBS => o.k.
No issues found so far. All test in SW only.

r0lZ
2nd March 2015, 10:23
You cannot seek. Afaik, currently no MVC decoder plugin for avisynth support seeking. The crash is normal. Of course, it would be better if FRIMSource could issue a warning when it detects a seek operation instead of crashing, but it's not the most important improvement to do!

I know that Donald Graft has the intention to add seek support to its MVC decoders (including DGMVCSource), but that will probably require to create an index file, and it's still not implemented.

Pat357
2nd March 2015, 23:18
I'm still looking for a solution to use FRIMencoder from STDin using a pipe from AVS2YUV (Avisynth) or VSPIPE (Vapoursynth).

This time I get at least an error code, so maybe this can somehow help to see why it's not working as it should.


avs2yuv -raw "input.avs" -o - | FRIMEncode -i - -o::h264 "ffms_stdin.h264" -w 640 -h 360 -f 29.970

This doesn't work, the encoder stops at frame 0 and produces an empty file. (see error report in my previous posts.)

However this works brilliant :

FRIMEncode -avi -i "input.avs" -o::h264 "ffms_stdin.h264" -w 640 -h 360 -f 29.970


Now I have also tried with VSPIPE (Vapoursynth), and I finally got an error code :

>> vspipe "vyp.vpy" - | FRIMEncode -i - -o::h264 "4k_ffms_stdin.h264" -w 640 -h 360 -f 29.970
FRIM Encoder version 1.24 (build: Feb 27 2015)
- based on Intel(R) Media SDK

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

Input format YUV420

Output video AVC
Source picture:
Resolution 640x368
Crop X,Y,W,H 0,0,640,360
Destination picture:
Resolution 640x368
PAR 0:0
Crop X,Y,W,H 0,0,640,360
Frame rate 29.970
Bitrate control CBR
bitrate 1711
GOP structure:
GOP length 30
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 4
Target usage 4 (balanced)

Processing started
Frame number: 0
Processing finished in 0.00 seconds
Error: fwrite() call failed when writing frame: 0, plane: 0, line: 32, errno: 22
Output 10 frames in 0.06 seconds (160.26 fps)
>>


Maybe this can shed some light on my problem.
Is this coming from the encoder or from VSPIPE ?
Any idea what this errno 22 at line 32 means ?

I was thinking about what you said about being sure that AVS2YUV or VSPIPE or outputting indeed YV12 video.
Could the encoder maybe struggle with I420 video ?
The only difference I know is that YV12 has the U and V channel swapped compared to I420 and it would cause bad colors in the encoded files.
Could you please consider to add a yuv4mpeg-video demuxer to your encoder/decoder ?
YUV4MPEG-video is also a raw uncompressed format mostly identical to raw uncompressed YV12, but it contains the video properties(colorspace, resolution, FPS, ..) in the headers.
It's supported by FFMpeg, X264, X265 and a lot of other tools/encoders/decoders.


Another thing I noticed is that reading AVI's is limited to 2GB (even on Win7 NTFS).
When trying to encode larger AVI files, I get an error that frame X can not be read :

FRIMEncode -avi -i "2K_ffms2.avi" -o::h264 Max_limit_AVI.h264" f 60 -w 1920 -h 1080
FRIM Encoder version 1.24 (build: Feb 27 2015)
- based on Intel(R) Media SDK

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

Input format YUV420

Output video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
PAR 0:0
Crop X,Y,W,H 0,0,1920,1080
Frame rate 59.999
Bitrate control CBR
bitrate 4717
GOP structure:
GOP length 60
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 4
Target usage 4 (balanced)

Processing started
Frame number: 690
ERROR: Cannot get frame 691 from avi-file

ERROR: undefined behavior (-16), src\pipeline_encode.cpp (1361)


ERROR: the previous asynchrous operation is in execution (1), src\main_frim_encode.cpp (121)

Simple math tells use that 691 (x2 ?) frames of 1920x1080 uncompressed raw video format + some minimal overhead is over the limit of 2GB.

A last question : do you know a similar Intel HW based encoder/decoder called QSVEncC by Rigaya?
If interested, it's open source (all sources are available) and works also very well :
see http://rigaya34589.blog135.fc2.com/blog-category-10.html for info, download binaries and sources.

Direct download : https://onedrive.live.com/?cid=6bdd4375ac8933c6&id=6BDD4375AC8933C6!482

Has similar features as yours, and it works without any other tools (no FFDShow) + Avisynth/Vapoursynth/yuv4mpeg/AVI demuxer build in, but has no avisynth Source filter.
As far as I can see in the sources (Cpp + highly optimised SIMD assembler SSE/AVX/FMA instructions), it's well written, but unfortunately
I don't understand the comments as these are in has native far Eastern language (looks like chinese(?) like stuff for me ;-))

videofan3d
4th March 2015, 15:08
I'm still looking for a solution to use FRIMencoder from STDin using a pipe from AVS2YUV (Avisynth) or VSPIPE (Vapoursynth).
...


Wow! - a lot of questions :)

1. avs2yuv (or vspipe)
I downloaded avs2yuv and tried it and faced the same issue.
Format YU12 (assuming it is specified as output format in underlying .avs script) is correct, you can test it on some small file step-by-step:

avs2yuv -raw input.avs -o test.yv12
FRIMEncode -i - -o::h264 -w 1920 -h 1080 -f 23.976 -cbr 24000 < test.yv12

and you will get it properly encoded.

But when using direct stdio-pipe connection, it really fails.
Interestingly, error message "Output error: wrote only %d of %d bytes" is coming from avs2yuv (!), not from FRIMEncode.
avs2yuv somehow cannot write to stdout buffer.
At this moment I have no clue why.

2. yuv4mpeg-video
At this moment I don't plan to deal with other formats.
Intel Media supports only 8-bit 4:2:0, and also all common sources (DVD, BluRay) are encoded in this way.
I don't want to write format nor colorspace convertors - that's why we all use Avisynth (and it does it pretty well).

3. 2 GB limit
This is probably limit of the VFW (Video for Windows) engine, which is old, coming from Windows 3.11 I guess...
Try to wrap the .avi into simple .avs script

AVISource("source.avi")
ConvertToYV12()

- maybe this will help.

4. QSVEncC by Rigaya
No, I don't know this SW.

r0lZ
4th March 2015, 15:56
FRIM version 1.24 released.

Compiled with Intel Media SDK - INDE 2015 Update 1

Few new features (=parameters) added:
-lahrd bitRate depth ... new encoding mode LA HRD-compliant
-dar w:h ... set output display aspect ratio, e.g. 4:3, 16:9 (FRIM Encode only)
-gopfile filename ... GOP-structure file (=requested I-frames), e.g.: (FRIM Encode only)

Please read FRIM_release_notes.txt for more details.

(Kindly asking audience of this forum for further testing :) ... )
As you can see here (http://forum.doom9.org/showthread.php?p=1711985#post1711985), it seems that all MVC decoding problems are fixed now! Thanks again for the new version! :)

Pat357
4th March 2015, 18:35
Wow! - a lot of questions :)

1. avs2yuv (or vspipe)
I downloaded avs2yuv and tried it and faced the same issue.
Format YU12 (assuming it is specified as output format in underlying .avs script) is correct, you can test it on some small file step-by-step:

avs2yuv -raw input.avs -o test.yv12
FRIMEncode -i - -o::h264 -w 1920 -h 1080 -f 23.976 -cbr 24000 < test.yv12

and you will get it properly encoded.

But when using direct stdio-pipe connection, it really fails.
Interestingly, error message "Output error: wrote only %d of %d bytes" is coming from avs2yuv (!), not from FRIMEncode.
avs2yuv somehow cannot write to stdout buffer.
At this moment I have no clue why.

Thanks for your reply.
I suspect that a work around might be in the way FRIMencoder reads from pipes.
It is not something "inherent" to Intel Media Encoder, because the other Intel HW based encoder I mentioned (QSVencc) does succesfully read and can encode the output from AVS2YUV via the same method.
Maybe if you would take a quick look in the QSVenc sources, this would bring some idea's how to handle this.
(all sources are inluded with the program)

2. yuv4mpeg-video
At this moment I don't plan to deal with other formats.
Intel Media supports only 8-bit 4:2:0, and also all common sources (DVD, BluRay) are encoded in this way.
I don't want to write format nor colorspace convertors - that's why we all use Avisynth (and it does it pretty well).
You're very right about Avisynth : FRIM & Avisynth work very well togetter.
But what about the the newer and more powerfull VapourSynth ?
In my opinion, Vapoursynth has already the potential to become the successor from Avisynth, because :
1. It been designed to run in both 32-bit and 64-bit, not like the 64bit-hack in avisynth. I mean a real 64 bit engine with real 64 bit plugins.
2. It has internal multithreading, not like the Avisynth MT-hack.
3. It has a very active development and the list of plugins & scripts is growing every day.

The scripts are python based and to actually output or access the processed video, there is a incuded tool called VSPIPE.EXE
I would like to use your FRIMencoder with VapourSynth, but to be able to do that, it must :
1. to be able to read from STDIN via a pipe OR
2. the read from a "virtual AVI" (now a problem due the 2GB limit)

Tools like X264 / FFMpeg, Virtual dub, AVIsynth have no problems reading/encoding much larger than 2GB AVI's. (I 've used it already with over 2TB "virtual" AVI's!!)
Further both Avisnth and Virtualdub are also based on VFW, but these use the OpenDML handler to open AVI's larger than 2GB.
Do you use this OpenDML handler ? If not, would you please consider to implement it ?


Do you see any plans to make the FRIMencoder to work with Vapoursynth ?

videofan3d
4th March 2015, 23:23
Thanks for your reply.
I suspect that a work around might be in the way FRIMencoder reads from pipes.

But what about the the newer and more powerfull VapourSynth ?
Do you see any plans to make the FRIMencoder to work with Vapoursynth ?

ad 1. I will check what's wrong, just be a bit patient :)

ad 2. I don't know Vapoursynth, I didn't have a reason to use it so far. Nevertheless, here is a report (http://forum.doom9.org/showthread.php?p=1690382&highlight=Vapoursynth#post1690382) that it can be used with FRIMEncode. You can check it and report.

ad 3. 2 GB limit - as pointed above, you can wrap the big (unlimited) .avi file by simple .avs script

AVISource("source.avi")
ConvertToYV12()

Avisynth will do all necessary file manipulation for you and input will be processed by FRIMEncode without problems
(I just tested in on 6 GB uncompressed AVI)

Anyway, I don't expect that somebody will create such huge uncompressed files. I assume mostly avisynth preprocessing.
Btw. Originally I used in the same way also DebugMode Frameserver for feeding FRIMEncode from Adobe Premiere CS3.
This frameserver creates virtual .avi file (a stub), which I wrapped by simple .avs and then fed into FRIMEncode.

Pat357
5th March 2015, 18:41
ad 1. I will check what's wrong, just be a bit patient :)
My applogies for this, I don't want youto feel pushed by me.

ad 2. I don't know Vapoursynth, I didn't have a reason to use it so far. Nevertheless, here is a report (http://forum.doom9.org/showthread.php?p=1690382&highlight=Vapoursynth#post1690382) that it can be used with FRIMEncode. You can check it and report.
I just did a quick check and ... IT WORKS ! Unbelieveble !

>FRIMEncode -avi -i "Nedi_rpow2.vpy" -o::h264 "Nedi_rpow2.vpy_direct.h264" -u 1 -icq 20

FRIM Encoder version 1.24 (build: Feb 27 2015)
- based on Intel(R) Media SDK

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

Input format YUV420

Output video AVC
Source picture:
Resolution 2560x1440
Crop X,Y,W,H 0,0,2560,1440
Destination picture:
Resolution 2560x1440
PAR 0:0
Crop X,Y,W,H 0,0,2560,1440
Frame rate 29.970
Bitrate control ICQ
quality 20
GOP structure:
GOP length 30
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 4
Target usage 1 (quality)

Processing started
Frame number: 2000
Processing finished in 49.67 seconds


Now I feel stupid because I've never tried this myself :confused:
The clue is just using the .VPY as an .AVI and let the AVI parser do it job !
Thank you very much for providing me this info and also for your great encoder/decoder/Source !
I really do appreciate this !

ad 3. 2 GB limit - as pointed above, you can wrap the big (unlimited) .avi file by simple .avs script

AVISource("source.avi")
ConvertToYV12()

Avisynth will do all necessary file manipulation for you and input will be processed by FRIMEncode without problems
(I just tested in on 6 GB uncompressed AVI)

Anyway, I don't expect that somebody will create such huge uncompressed files. I assume mostly avisynth preprocessing.
These large AVI's were not real AVI-files.
They were created by "Pismo File Mount Audit Package" : it created virtual AVIs using the proper plugins. AVIsynth has the ASFS plugin and also Vapoursynth has the VSFS plugin.
If you need to serve a script to an app. (encoder,...) it's kind of the last resort to serve the scripts if nothing else works.
Also these AVI don't take any real space on your system.

It can become handy for some aps that won't take any other tricks (like MakeAVIS, Debug File Server, AVSProxy,...).

Btw. Originally I used in the same way also DebugMode Frameserver for feeding FRIMEncode from Adobe Premiere CS3.
This frame-server creates virtual .avi file (a stub), which I wrapped by simple .avs and then fed into FRIMEncode.
I just installed it to have a look : it seems to be able to use it, you need a proper plugin for the app you want to use it with...no ?
I don;t have any of the apps installed for the included plugins, so I guess I can only use it as a "network client" for getting data from a network port.. or am I missing something ?

videofan3d
6th March 2015, 10:16
I just installed it to have a look : it seems to be able to use it, you need a proper plugin for the app you want to use it with...no ?
I don;t have any of the apps installed for the included plugins, so I guess I can only use it as a "network client" for getting data from a network port.. or am I missing something ?

Not sure I understand your question about Debugmode Frameserver.

Debugmode Frameserver is a plugin to several NLE system for export to virtual .avi.
It works also with Adobe Premiere CS3 and higher (i.e. 32-bit version for CS3, 64-bit version for CS4 and higher).
I use it for export from Premiere and encoding either using x264, HCEnc, or FRIMEncode.
In all cases I wrap this virtual .avi into .avs (the simple trick I mentioned above) – and all works perfectly.

Later on I developed FRIMExport.prm, which is direct plugin to Premiere CS6 for export/encoding using FRIM technology - to be used mainly for Bluray 3D export.
(Two reasons:
1. Premiere CS3 has bug and is not able to process more than Full HD (it crashes), while for 3D we need 2x Full HD
2. I wanted to simplify the export chain, and reduce task switching overheads = faster encoding)

This plugin is not perfect, the process is slow and bit complicated, (Adobe Premiere has poor, practically zero, support for 3D stereoscopic editing), but once you get used to it, it leads to expected result.

Pat357
6th March 2015, 20:56
While comparing FRIMencoder (v1.24) with QSVenc (v1.27 dd Nov 2014), I noticed that the one has some options for H264 encoding that the other has not, and the other way around.

For encoding to H264, it seems these are not yet implemented or just not shown :

1. Trelis : used to set to perform trelis on just I frames and also on P en B frames. Also looking for b-pyramid mode and an intra-refresh option (enables adaptive I frame insert)

2. Bframes : the number of sequential B-frames.

3. Video processing like de-noise, image detail enhancement, image stabilization,... (all done using Intel HW)

4. Setting encoded video properties like : fullrange or not, video-format (undef, ntsc, component, pal,..), the color-matrix, color primaries, used transfer curve.
These are important for the decoder, but most for rendering.
The renderer needs this info to ensure correct color rendering.
If not available, the only thing the renderer can do is to guess these based on the resolution


Further, using d3d9/d3d11 surface for FRIMenoder is slowing down the encoding to less than 5-10 fps on my system (=Haswell CPU i7-4770 @ 3.7 GHz) ... ?
Is this a normal /to expect behavior ?
Shouldn't it be an advantage to use d3d surfaces ? (for de-interlacing, video processing, ..)

Maybe something to look into for the next releases ?

There are a few more minor things that don't bother me.

Just for completeness and because I thought you probably didn't have time/motivation to download QSVenc, I've included the complete option list from QSVenc.

QSVenc --help gives :

QSVEncC (x86) 1.27 by rigaya, build Nov 20 2014 21:06:30
based on Intel(R) Media SDK Encoding Sample 5,0,461,92695
avi reader: enabled
avs reader: enabled
vpy reader: enabled

Usage: qsvencc [Options] -i <filename> -o <filename>

input can be avi, avs, vpy, raw YUV or YUV4MPEG2(y4m) format.
when raw(default), fps, input-res are also necessary.

output format will be raw H.264/AVC ES.
when output filename is set to "-", H.264/AVC ES output is thrown to stdout.

Example:
QSVEncC -i "<avsfilename>" -o "<outfilename>"
avs2pipemod -y4mp "<avsfile>" | QSVEncC --y4m -i - -o "<outfilename>"

Example for Benchmark:
QSVEncC -i "<avsfilename>" --benchmark "<benchmark_result.txt>"

Options:
-h,-? --help show help
-v,--version show version info

-i,--input-file <filename> set input file name
-o,--output-file <filename> set ouput file name

Input formats (will be estimated from extension if not set.)
--raw set input as raw format
--y4m set input as y4m format
--avi set input as avi format
--avs set input as avs format
--vpy set input as vpy format
--vpy-mt set input as vpy format in multi-thread

--nv12 set raw input as NV12 color format,
if not specified YV12 is expected
--tff set as interlaced, top field first
--bff set as interlaced, bottom field first
-f,--fps <int>/<int> or <float> video frame rate (frames per second)

--input-res <int>x<int> input resolution
--output-res <int>x<int> output resolution
if different from input, uses vpp resizing
if not set, output resolution will be same
as input (no resize will be done).
--crop <int>,<int>,<int>,<int>
set crop pixels of left, up, right, bottom.

--slices <int> number of slices, default 0 (auto)

--sw use software encoding, instead of QSV (hw)
--check-hw check if QuickSyncVideo is available
--check-lib check lib API version installed
--check-features check encode features
--check-environment check environment info
--disable-d3d disable using d3d surfaces
--d3d use d3d9/d3d11 surfaces
--d3d9 use d3d9 surfaces
--d3d11 use d3d11 surfaces

EncMode default: --cqp
--cqp <int> or encode in Constant QP, default 24:26:27
<int>:<int>:<int> set qp value for i:p:b frame
--vqp <int> or encode in Variable QP, default 24:26:27
<int>:<int>:<int> set qp value for i:p:b frame
--la <int> set bitrate in Lookahead mode (kbps)
--la-hrd <int> set bitrate in HRD-Lookahead mode (kbps)
--icq <int> encode in Intelligent Const. Qualtiy mode
default value: 23
--la-icq <int> encode in ICQ mode with Lookahead
default value: 23
--cbr <int> set bitrate in CBR mode (kbps)
--vbr <int> set bitrate in VBR mode (kbps)
--avbr <int> set bitrate in AVBR mode (kbps)
AVBR mode is only supported with API v1.3
--avbr-unitsize <int> avbr calculation period in x100 frames
default 90 (= unit size 9000 frames)
--qvbr <int> set bitrate in Quality VBR mode.
--qvbr-q <int> or set quality used in qvbr mode. default: 23
--qvbr-quality <int> QVBR mode is only supported with API v1.11
--vcm <int> set bitrate in VCM mode (kbps)

--la-depth <int> set Lookahead Depth, 10-100
--la-window-size <int> enables Lookahead Windowed Rate Control mode,
and set the window size in frames.
--max-bitrate <int> set max bitrate(kbps)
-u,--quality <string> encode quality
- best, higher, high, balanced(default)
fast, faster, fastest

--ref <int> reference frames for sw encoding
default 0 (auto)
-b,--bframes <int> number of sequential b frames
default 3 (auto)

--gop-len <int> (max) gop length, default 0 (auto)
when auto, fps x 10 will be set.
--(no-)open-gop enables open gop (default:off)
--strict-gop force gop structure
--(no-)scenechange enables scene change detection

--level <string> set codec level, default auto
--profile <string> set codec profile, default auto
--sar <int>:<int> set Sample Aspect Ratio
--bluray for H.264 bluray encoding

--vpp-denoise <int> use vpp denoise, set strength
--vpp-detail-enhance <int> use vpp detail enahancer, set strength
--vpp-deinterlace <string> set vpp deinterlace mode
enabled only when set --tff or --bff
- none disable deinterlace
- normal normal deinterlace
- it inverse telecine
- bob double framerate
--vpp-image-stab <string> set image stabilizer mode
- none, upscale, box

--input-buf <int> buffer size for input (1-16)
default hw: 3, sw: 1
--log <string> output log to file.

settings below are only supported with API v1.3
--fullrange set stream as fullrange yuv
--videoformat <string> undef, ntsc, component, pal, secam, mac
default: undef
--colormatrix <string> undef, auto, bt709, smpte170m, bt470bg
smpte240m, YCgCo, fcc, GBR
default: undef
--colorprim <string> undef, auto, bt709, smpte170m, bt470m
bt470bg, smpte240m, film
default: undef
--transfer <string> undef, auto, bt709, smpte170m, bt470m
bt470bg, smpte240m, linear, log100, log316
default: undef

settings below are only supported with API v1.6
--(no-)mbbrc enables per macro block rate control
default: off
--(no-)extbrc enables extended rate control
default: off

settings below are only supported with API v1.7
--trellis <string> set trellis mode used in encoding
- auto(default), none, i, ip, all

settings below are only supported with API v1.8
--(no-)i-adapt enables adaptive I frame insert (default:off)
--(no-)b-adapt enables adaptive B frame insert (default:off)
--(no-)b-pyramid enables B-frame pyramid reference (default:off)
--lookahead-ds <string> set lookahead quality.
- auto(default), fast, normal, slow

settings below are only supported with API v1.9
--(no-)intra-refresh enables adaptive I frame insert
--no-deblock disables H.264 deblock feature
--qpmin <int> or set min QP, default 0 (= unset)
<int>:<int>:<int>
--qpmax <int> or set max QP, default 0 (= unset)
<int>:<int>:<int>

Settings below are available only for software ecoding.
--cavlc use cavlc instead of cabac
--rdo use rate distortion optmization
--inter-pred <int> set minimum block size used for
--intra-pred <int> inter/intra prediction
0: auto(default) 1: 16x16
2: 8x8 3: 4x4
--mv-search <int> set window size for mv search
default: 0 (auto)
--mv-precision <int> set precision of mv search
0: auto(default) 1: full-pell
2: half-pell 3: quater-pell

--benchmark <string> run in benchmark mode
and write result in txt file
--(no-)timer-period-tuning enable(disable) timer period tuning
default: enable

videofan3d
28th March 2015, 21:18
FRIM version 1.25 released.

Changes in FRIMEncode:
- fixed reading from stdin
- few new parameters added:

-f 24000/1001 - frame rate as rational number, or
-f 23.976 - frame rate as real number
-Trellis IPB|off
-Bpyramid on|off
-RDO on|off

-VPPbrightness factor - in range [-100.0,100.0]
-VPPcontrast factor - in range [0.00,10.00]
-VPPhue factor - in range [-180.0,180.0]
-VPPsaturation factor - in range [0.00,10.00]
-VPPdenoise factor - denoising, in range [0,100]
-VPPdetail factor - detail/edge enhancement, in range [0,100]
-VPPstabilize U|B - image stabilization, U=upscale, B=boxing
-VPPdeinterlace - activate deinterlacing

(setting parameters of output bitstream)
-videoformat code
-videofullrange
-colormatrix code
-colorprim code
-colortransfer code


Please read FRIM_release_notes.txt for more details.

Pat357
8th April 2015, 20:53
FRIM version 1.25 released.
.

Thanks a lot for this new release !!

I wondered how you solved the reading from Stdin problem ?
As far as I could see, the basic problem was that FRIMencode already closed the pipe before any frames where produced by Avisynth/Vapoursynth.

I think this is a great release and it should cover everyone's needs.

A small question about VPPdeinterlace : what options does it have ? Can it output double frame rate (like bobbing) ?
I didn't see it in the docs.

videofan3d
13th April 2015, 16:05
Re:
1. reading from stdin: there was a bug in the related routine :-) - fixed.

2. VPPdeinterlace: no options, it calls some basic routine in the Intel Media - probably some kind of field-blending. I didn't explore it too much deeply.
(FRIM doesn't change the frame rate, thus all methods which use double frame rate cannot be used).

I personally am not a friend of de-interlacing during encoding.
De-interlacing should be used always on decoding side and only when displaying video (on progressive screen),
while whole processing should keep the format (progressive vs. interlaced).
And definitely, interlaced video as legacy from analog television should be avoided in all new recordings.

l33tmeatwad
4th May 2015, 20:11
Any chance of getting a 64-bit AviSynth plugin?

videofan3d
5th May 2015, 17:57
Any chance of getting a 64-bit AviSynth plugin?

Is there any stable, "official" Avisynth 64-bity build?
Can it co-exist with 32-bit Avisynth on the same Windows machine?

Please direct me to its sources, web-pages, I can then check it.

l33tmeatwad
5th May 2015, 20:37
Is there any stable, "official" Avisynth 64-bity build?
Can it co-exist with 32-bit Avisynth on the same Windows machine?

Please direct me to its sources, web-pages, I can then check it.Not an "official" version, but the 64-bit version of AviSynth+ (fork off of 2.6 Alpha 5) is fairly stable and getting worked on regularly. It can also co-exist on the same machine with the 32-bit version. Here's the doom9 thread (http://forum.doom9.org/showthread.php?t=168856) for more information.

videofan3d
7th May 2015, 20:30
Hi,

please find here beta version of FRIMSource64.dll (https://drive.google.com/file/d/0BymRNDHq74DEMnB1QzFvV1pzS0U) for AviSynth+ (64-bit).

It is the same source code as 32-bit version FRIMSource.dll version 1.25 hence it is identical from functionality perspective.

Please test it.
Once confirmed and approved, I will add it to regular distribution package.

l33tmeatwad
9th May 2015, 05:01
The 64-bit AviSynth plugin works.

My next question...how in the world does this premiere plugin work? This documentation explains nothing...

videofan3d
9th May 2015, 16:33
The 64-bit AviSynth plugin works.

My next question...how in the world does this premiere plugin work? This documentation explains nothing...

Premiere plugin exports 3D-MVC encoded data (then to be muxed by tsMuxer into regular BD3D navigation structure).

Please download the synthetic sample project FRIM_Premiere_samples_1.23.zip, install plugins FRIMExport.prm and FRIMImport.frm into Premiere Pro 6(+) into its plugin directory (probably c:\Program Files\Adobe\Common\Plug-ins\CS6\MediaCore\) and follow the steps in FRIMPremiere_readme.pdf.

I use it for all video projects recorded using my 3D camcorder.
Remark: Keep on mind this plugin is suitable only for export of final project, not for its editing!
Editing need to be performed before as standard 2D project. Only at the end you have to "turn it" into 3D "top-above-below" and export using this plugin.

l33tmeatwad
9th May 2015, 18:23
Premiere plugin exports 3D-MVC encoded data (then to be muxed by tsMuxer into regular BD3D navigation structure).

Please download the synthetic sample project FRIM_Premiere_samples_1.23.zip, install plugins FRIMExport.prm and FRIMImport.frm into Premiere Pro 6(+) into its plugin directory (probably c:\Program Files\Adobe\Common\Plug-ins\CS6\MediaCore\) and follow the steps in FRIMPremiere_readme.pdf.

I use it for all video projects recorded using my 3D camcorder.
Remark: Keep on mind this plugin is suitable only for export of final project, not for its editing!
Editing need to be performed before as standard 2D project. Only at the end you have to "turn it" into 3D "top-above-below" and export using this plugin.Yeah, that part is get, what I don't really understand is:
Library libmfxsw64.dll needs to be placed in any directory which is specified in PATH evironment variable.
The plugins show up, but I can't really do anything with them (I assume because I do not know where to place that DLL).

videofan3d
9th May 2015, 21:42
Re: Library libmfxsw64.dll needs to be placed in any directory which is specified in PATH environment variable.

If FRIMSource64.dll works for you, than you have it placed correctly and FRIM Premiere plugins will work as well.
(Or just simply copy libmfxsw64.dll to "Windows" or "Windows"\system32 directory...)

l33tmeatwad
9th May 2015, 22:34
Re: Library libmfxsw64.dll needs to be placed in any directory which is specified in PATH environment variable.

If FRIMSource64.dll works for you, than you have it placed correctly and FRIM Premiere plugins will work as well.
(Or just simply copy libmfxsw64.dll to "Windows" or "Windows"\system32 directory...)I actually didn't need to place that anywhere at all for FRIMSource64.dll to work, it just worked.

RenderGuy2
13th May 2015, 16:44
videofan3d, thank you for FRIMSource64 (and your work in general). I believe this is the first x64 MVC source filter.

nel-son
28th May 2015, 17:00
i tested frimsource for the first time (windows 7 x64, avisynth 2.58 32-bit, frimsource 32-bit). i have this message in avspmod when i try to open the video.

can't initialize intel media sdk session

this is the line i use. is there an error?

frimsource(codec="mvc", filename="name.264", filename_dep="name.mvc", layout="sbs", cache=24, num_frames=126240)

videofan3d
28th May 2015, 19:07
i tested frimsource for the first time (windows 7 x64, avisynth 2.58 32-bit, frimsource 32-bit). i have this message in avspmod when i try to open the video.



this is the line i use. is there an error?

frimsource(codec="mvc", filename="name.264", filename_dep="name.mvc", layout="sbs", cache=24, num_frames=126240)

You have incorrectly installed core library libmfxsw32.dll.
Put it into directory which is in your %PATH%

tartak
13th July 2015, 09:06
FRIMSource kind of works for me (no errors but AvsPmod and virtualdub show weird pictures swirling around or breaking down into blocks - even though either left or right part is sometimes good). But FRIMencode returns "ERROR: Cannot initiate Intel Media Encoder - invalid parameters. ERROR: invalid video parameters (-15), src\pipeline_encode.cpp (1068)". This is without -hs/sw specified. However, if I use -sw option, I get "ERROR: Cannot initialize Intel Media SDK session."
avs file: FRIMSource(codec="mvc", filename="in.264", filename_dep="in.mvc", layout="sbs", cache=20, num_frames=1500)
encode command: FRIMEncode -avi -sbs 2 -i test.avs -viewoutput -o::mvc out.avc out_d.mvc -vbr 28000 40000 -u 1

Could it some how relate to Intel drivers? My monitor is on an NVidia card but there is an Intel graphic chip on the motherboard (drivers are inactive).

PS.
FRIMSource also returns "ERROR: Cannot initialize Intel Media SDK session." if I use platform="sw"

rocket_robot
13th July 2015, 21:27
Hi @VIDEOFAN3D,

I am trying to use myFFInfo within the FRIMSource .AVS file. FFVAR_PREFIX does not exist. (as it is part of FFVideoSource) . I just wondered if there was something I could do with FRIMSource that would be similar to display frame number and frame type? Do you have a Variable with Frame type?

thanks in advance.

r0lZ
14th July 2015, 06:38
FRIMSource kind of works for me (no errors but AvsPmod and virtualdub show weird pictures swirling around or breaking down into blocks - even though either left or right part is sometimes good). But FRIMencode returns "ERROR: Cannot initiate Intel Media Encoder - invalid parameters. ERROR: invalid video parameters (-15), src\pipeline_encode.cpp (1068)". This is without -hs/sw specified. However, if I use -sw option, I get "ERROR: Cannot initialize Intel Media SDK session."
avs file: FRIMSource(codec="mvc", filename="in.264", filename_dep="in.mvc", layout="sbs", cache=20, num_frames=1500)
encode command: FRIMEncode -avi -sbs 2 -i test.avs -viewoutput -o::mvc out.avc out_d.mvc -vbr 28000 40000 -u 1

Could it some how relate to Intel drivers? My monitor is on an NVidia card but there is an Intel graphic chip on the motherboard (drivers are inactive).

PS.
FRIMSource also returns "ERROR: Cannot initialize Intel Media SDK session." if I use platform="sw"
The problem can be caused by bad intel drivers in hw mode, and by an incorrectly installed or outdated version of the Intel lib in sw mode. The pixelisation problem with some (rare) BDs is well known and is caused by outdated versions of the intel lib.

I use libmfxsw32.dll v6.14.11.28 (28/11/2014) in sw mode with BD3D2MK3D without problem and as far as I know, it's the first version that has no pixelisation bug. Normally, that library should be either in your Windows path or in the current directory. Try to copy it in the same directory than your avisynth script, or in your system32 directory.

I don't have the intel hardware and therefore I don't know the problems related to the drivers, but I know that old drivers were also very buggy. Be sure to install the latest drivers. If they are correctly installed, they should work fine in hw mode, except perhaps with some models of the intel graphic chips.

tartak
15th July 2015, 07:39
The problem can be caused by bad intel drivers in hw mode, and by an incorrectly installed or outdated version of the Intel lib in sw mode. The pixelisation problem with some (rare) BDs is well known and is caused by outdated versions of the intel lib.

I use libmfxsw32.dll v6.14.11.28 (28/11/2014) in sw mode with BD3D2MK3D without problem and as far as I know, it's the first version that has no pixelisation bug. Normally, that library should be either in your Windows path or in the current directory. Try to copy it in the same directory than your avisynth script, or in your system32 directory.

I don't have the intel hardware and therefore I don't know the problems related to the drivers, but I know that old drivers were also very buggy. Be sure to install the latest drivers. If they are correctly installed, they should work fine in hw mode, except perhaps with some models of the intel graphic chips.
Thanks, installing the latest Intel drivers (May of this year) did the trick! My setup works now, in hw mode. The quality is very good.

The remaining concerns:
1) FRIMSource does not work with platform="sw" ("Cannot initialize Intel Media SDK session"). Is this expected? libmfxsw32.dll version 6.14.11.28 is in Windows\system32
2) I am getting less than 3 fps (2.8 to be exact) at "-u 1". That looks very, very slow. Quoting from the thread on MVCenc: "Can expect 80 - 90 fps for high quality 3D MVC transcoding BD50 to BD25 on modern i7-4770K based system and no less of 60 fps on i7-3770K". I have i7-3770 (with lots of RAM and everything else). Could the FRIMSource be the bottleneck?

videofan3d
15th July 2015, 20:15
The remaining concerns:
1) FRIMSource does not work with platform="sw" ("Cannot initialize Intel Media SDK session"). Is this expected? libmfxsw32.dll version 6.14.11.28 is in Windows\system32
2) I am getting less than 3 fps (2.8 to be exact) at "-u 1". That looks very, very slow. Quoting from the thread on MVCenc: "Can expect 80 - 90 fps for high quality 3D MVC transcoding BD50 to BD25 on modern i7-4770K based system and no less of 60 fps on i7-3770K". I have i7-3770 (with lots of RAM and everything else). Could the FRIMSource be the bottleneck?


ad 1.
I just quickly tested following AVS script:

LoadPlugin("c:\Prj\IntelMedia\_exe\x64\Release_v1.25\FRIMSource64.dll")

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

FRIMSource(codec="mvc", filename=FILE3D, filename_dep=FILE3D, container="ts", platform="sw", \
layout="SBS", cache=24, reload=true, num_frames=350, log_file="c:\Prj\IntelMedia\_testing\Z1.log")
i.e. in SW mode - and without any issues.
Seems that something is wrong in your environment setting. (path or whatever)

ad 2. ad performance:
encoding is not fast, in SW mode it is slow.
And on my i7-4770K Haswell 3.50 GHz 16 GB RAM I have never achieved 80 fps in -hw mode. Far far below this!
I don't know where the above mentioned quote is coming from, neither what were the conditions for its measurement.
Please keep on mind that that also disk access (2x 3 MB per each frame) takes its cost. Working on SSD is visibly faster.
3 fps in Full HD3D in -u 1 might be realistic.
(You can check -u 7 and compare)

videofan3d
15th July 2015, 20:17
Hi @VIDEOFAN3D,

I am trying to use myFFInfo within the FRIMSource .AVS file. FFVAR_PREFIX does not exist. (as it is part of FFVideoSource) . I just wondered if there was something I could do with FRIMSource that would be similar to display frame number and frame type? Do you have a Variable with Frame type?

thanks in advance.

Sorry, I have no clue what are "myFFInfo", "FFVAR_PREFIX", "FFVideoSource".

Please provide clear specific example what you are doing (and want to do) - then I can check.

tartak
16th July 2015, 06:25
ad 1.
I just quickly tested following AVS script:

LoadPlugin("c:\Prj\IntelMedia\_exe\x64\Release_v1.25\FRIMSource64.dll")

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

FRIMSource(codec="mvc", filename=FILE3D, filename_dep=FILE3D, container="ts", platform="sw", \
layout="SBS", cache=24, reload=true, num_frames=350, log_file="c:\Prj\IntelMedia\_testing\Z1.log")
i.e. in SW mode - and without any issues.
Seems that something is wrong in your environment setting. (path or whatever)

As I indicated, the dll is in the path, in windows\system32. Anything else I could check on?


ad 2. ad performance:
encoding is not fast, in SW mode it is slow.
And on my i7-4770K Haswell 3.50 GHz 16 GB RAM I have never achieved 80 fps in -hw mode. Far far below this!
I don't know where the above mentioned quote is coming from, neither what were the conditions for its measurement.
Please keep on mind that that also disk access (2x 3 MB per each frame) takes its cost. Working on SSD is visibly faster.
3 fps in Full HD3D in -u 1 might be realistic.
(You can check -u 7 and compare)
The quote is from the top of the thread on MVCEnc. In that thread, they gave a solution to the performance problem: activate Intel drivers by faking a display (http://forum.doom9.org/showthread.php?p=1727821#post1727821). Which I did and Intel Media SDK System Analyzer showed HW supported afterwards (before this procedure, it showed only SW was supported - even though FRIMSource was working only in HW mode!). Now, I am getting 40 fps at -u 1 (just slightly faster, 42 fps at -u 3)! The files are read from a fast enterprise-grade drive (file transfers are usually above 120 MB/s sustained) and written to a Samsung pro SSD - so the IO is fine.
I think I can do without SW working at this point. Nonetheless, I will try to do more tests, run dependency walker, etc.

PS. I have tried MVCenc on the same setup, with the same full HD3D, and got 60 fps, exactly as they claim. MVCEnc ran in HW mode and reported SW as unavailable.

videofan3d
16th July 2015, 10:17
1. As I indicated, the dll is in the path, in windows\system32. Anything else I could check on?


2. Now, I am getting 40 fps at -u 1 (just slightly faster, 42 fps at -u 3)! The files are read from a fast enterprise-grade drive (file transfers are usually above 120 MB/s sustained) and written to a Samsung pro SSD - so the IO is fine.
I think I can do without SW working at this point. Nonetheless, I will try to do more tests, run dependency walker, etc.

PS. I have tried MVCenc on the same setup, with the same full HD3D, and got 60 fps, exactly as they claim. MVCEnc ran in HW mode and reported SW as unavailable.

ad 1. This is strange, difficult to identify remotely.
Check if libmfxswNN.dll is not corrupted, or if there is no other (corrupted, old) somewhere on your PC which could be found before the actual one....

Ad 2. Maybe MVCEnc uses different internal frame processing .... (well, SW differs - some are faster, some slower, some better, some worse, more features, less features, .... ;) :) )

rocket_robot
16th July 2015, 14:04
Sorry, I have no clue what are "myFFInfo", "FFVAR_PREFIX", "FFVideoSource".

Please provide clear specific example what you are doing (and want to do) - then I can check.

Hi, Basically I want to use FRIMsource in AVSPmod, it is a program to preview .AVS scripts.

I use it to compare screenshots of different encodes to the original. Usually with a normal source I would have the following:

Import("F:\Encodes\FFMS2.avsi")
Import("F:\Encodes\avisynth\plugins\myffinfo.avsi")
LoadPlugin("F:\Encodes\ffms2.dll")
ffvideosource("f:\encodes\00800 - 2 - h264 (left eye), 1080p24.h264")
#crop(0,20,0,-20)
myFFInfo("Source")

myffinfo is a simple script that pops some useful text on the output like frame number and Frame type (I,P or B).

When I swap ffvideosource to FRIMSource, myffinfo does not work, (as expected).

I think myffinfo uses internal Variables passed from ffvideosource like FFVAR_PREFIX and FFPICT_TYPE, as it contains the frame type.

I just wondered if there was anything like FRAME_TYPE available in FRIMSource that I could use to display on the screen.

Thanks for you time.

myffinfo script below

function myFFInfo(clip c, string "bonusText") {

varprefix = FFVAR_PREFIX
bonusText = default(bonusText, "")

c.frameevaluate("""
fftempstring = ""
varprefix = """" + varprefix + """"
bonusText = """" + bonusText + """"""")

frameevaluate("""fftempstring = fftempstring + "Frame Number: " + string(current_frame) + " of " + string(framecount()) + "\n" """, after_frame=true)
frameevaluate("""fftempstring = fftempstring + "Picture Type: " + chr(eval(varprefix + "FFPICT_TYPE")) + "\n" """, after_frame=true)
frameevaluate("""fftempstring = fftempstring + bonusText """, after_frame=true)

return scriptclip("subtitle(fftempstring, lsp = 1)", after_frame=true)

}

videofan3d
16th July 2015, 16:45
Hi, Basically I want to use FRIMsource in AVSPmod, it is a program to preview .AVS scripts.

I think myffinfo uses internal Variables passed from ffvideosource like FFVAR_PREFIX and FFPICT_TYPE, as it contains the frame type.

I just wondered if there was anything like FRAME_TYPE available in FRIMSource that I could use to display on the screen.



I see - got your point.

Unfortunately, Intel Media SDK doesn't return FRAME_TYPE (I,P,B) during decoding (I didn't find a way how to obtain it - although there is internal structure.variable named mfxBitStream.FrameType which could according to its name contain such info, it returns always 0 during decoding :( ).

(During encoding you can specify requested GOP structure (forced I-frames), but as I realized, it also doesn't work perfectly - there was a bug in past in libmfxhwNN.dll so it worked only in -sw mode with libmfxswNN.dll)

Sorry...

rocket_robot
16th July 2015, 17:45
thanks anyway, I may have a plan..

tartak
18th July 2015, 20:40
i tested frimsource for the first time (windows 7 x64, avisynth 2.58 32-bit, frimsource 32-bit). i have this message in avspmod when i try to open the video.

can't initialize intel media sdk session

this is the line i use. is there an error?

frimsource(codec="mvc", filename="name.264", filename_dep="name.mvc", layout="sbs", cache=24, num_frames=126240)
You have incorrectly installed core library libmfxsw32.dll.
Put it into directory which is in your %PATH%
I've finally figured this out. I have the same environment and the same problem. Many people complain of this on various forums.

I tried Dependency Walker to see if there are statically linked missing dll's. There was none (it did report a bunch of missing stump "api" dll's but this is a well known problem of the Walker itself). I checked the Media SDK documentation - "can't initialize intel media sdk session" seems as something that SDK Dispatcher would produce when it is unable to locate the software library. Then I tried the most direct way: I deleted all other instances of 32 and 64 bit libmfxsw library and placed both dlls into the same directory as Media SDK system analyzers. Both 32 and 64-bit analyzers reported the soft library as supported. Then I moved these two dll's into Windows\system32 (which is definitely and always in the %PATH%). This time, the 64-bit analyzer reported the library as supported but the 32-bit one - as not! The whole thing has become obvious - I had had it in the past. On a 64-bit system, Windows\System32 is reserved for 64-bit dll's, while 32-bit dll's are supposed to reside in SysWOW64. However, normally you will not have SysWOW64 in your path. When a 32-bit app seeks a library and tries to access System32 directory, it is redirected (by file system redirector) to SysWOW64 (unless it somehow triggers UAC). So, I moved libmfxsw32.dll to SysWOW64 and everything is fine now.

Bottom line: %PATH% is not what it seems on a 64-bit Windows. Put libmfxsw32.dll into Windows\SysWOW64.

r0lZ
19th July 2015, 20:04
Smart! Indeed, SYSWOW64 is the directory for the 32-bit system DLLs, despite its name!
Thanks for the tip.

videofan3d
19th July 2015, 20:59
Bottom line: %PATH% is not what it seems on a 64-bit Windows. Put libmfxsw32.dll into Windows\SysWOW64.

Interesting finding, thanks on behalf of everyone here :)

I have defined in my Windows (just accidentally, without any my intended intervention :D )


PATH=%SYSTEMROOT%\;%SYSTEMROOT%\system32\;%SYSTEMROOT%\System32\Wbem\;%SYSTEMROOT%\SysWOW64\; ...


This is why everything always worked for me ...

r0lZ
20th July 2015, 09:58
Strange %PATH% content. According to the theory, SYSWOW64 should never be specified directly. If you put it in your path variable, that means that it will be searched by the 64-bit programs as well as system32, and since it is supposed to contain only 32-bit libs, that's just a waste of time. And 32-bit programs will search SYSWOW64 two times. The first time because when they search system32, they will be redirected to SYSWOW64 by Windows, and the second time because SYSWOW64 is explicitly specified. Again a waste of time.

As explained by tartak, the 32-bit libs should be copied to the correct directory, SYSWOW64, and all 32-bit programs should find them without problem, without SYSWOW64 in the %PATH%. 64-bit programs cannot use a 32-bit library anyway and therefore there is no need to place them in system32.

My method is to place a copy of the library in the directory containing the avisynth script. That has always worked fine. And for BD3D2MK3D, since the rendering is made with a batch script (ENCODE.cmd), I add the directory containing the lib to the %PATH% in ENCODE.cmd. Again, that has always worked fine. I prefer to keep system32 and SYSWOW64 for the system files officially installed by Windows.

BigPines
5th August 2015, 22:57
Sorry for the newbie questions. I am still reading through this thread. I plan to read all the posts.

I am editing 3D material sourced from 3D Blu-ray and then re-encoding into MVC. Over the last several years I have done limited experimentation with Avisynth and H264StereoSource.dll to decode the right eye stream and losslessly encode it to a file via x264. I used the resulting file in Adobe Premiere Pro for OS X to perform the editing. I then export from Premiere to Quicktime animation lossless. I then take the exported left and right eye files to Sony Vegas for MVC encoding. Finally, I used Scenarist to create a BD ISO. However, my workflow is cumbersome and I have experienced problems with H264StereoSource.dll. It seems like FRIM may be the answer to all of my problems since it can do both decoding and encoding.

Some questions:

1) I see in the FRIM Import and FRIM Export Read Me file, these Premiere plugins are Windows only. :( I assume it isn't trivial to compile OS X versions? Probably not since the underlying SDK is Windows. Bummer.
2) Can FRIM Import and FRIM Export be used with MVC from 3D BD? If not, can I convert the separate 3D BD files somehow to trick it into working like the camcorder MVC files?
3) The FRIM Export Read Me says: "last codec option is H.264 MVC-3D. This one is intended for export of native Adobe’s dual-stream 3D format. However, this format is not fully supported yet." What are the current limitations? Will this option work for my purposes?
4) If the above options fail, can I use FRIM Decoder to create a lossless video file that Premiere will accept for editing? Will the following command line result in what I want: FRIMDecode -i::mvc input_base.avc input_dependent.mvc -o \\.\nul output_R.yuv Not sure if that will be lossless or if Premiere can read YUV.
5) After I perform my editing, can I use FRIM Encoder to create MVC that can be burned back to a BD? FRIMEncode -i input_L.yuv input_R.yuv -o::mvc output_combined.h264 -w 1920 -h 1080 -f 23.976 -vbr 28000 40000 -u 1 Will that give me what I want? Not sure Premiere can export yuv or do I need to export to something else and then use Avisynth to convert to yuv?
6) Is there any advantage to using FRIM Source through Avisynth vs just using the standard command line tools?

Looking forward to the advice. Thanks in advance.

Mike

videofan3d
6th August 2015, 09:19
...
I am editing 3D material sourced from 3D Blu-ray and then re-encoding into MVC. ...

Looking forward to the advice. Thanks in advance.

Mike

Q 1) I see in the FRIM Import and FRIM Export Read Me file, these Premiere plugins are Windows only. I assume it isn't trivial to compile OS X versions? Probably not since the underlying SDK is Windows. Bummer.
Answer: Intel Media libraries are only for Windows (and possibly Linux), and I'm old-fashioned Windows guy :), hence yes, it is only for Windows.
There is wider community of developers in Windows environment, and they created many useful tools and plugins also for Adobe Premiere for Windows.
I recommend mainly DebugMode Frameserver which gives an option to export from Premiere to practically ANY encoder (including x264, HCEnc and also FRIM Encoder)
There also exists Avisynth Importer, which allows importing .avs script directly to Premiere timeline – which is great.

Q 2) Can FRIM Import and FRIM Export be used with MVC from 3D BD? If not, can I convert the separate 3D BD files somehow to trick it into working like the camcorder MVC files?
Answer: Yes, it can be used with MVC from 3DBD . Bluray 3D uses the same MVC coding as 3D camcorders. The difference is that BD stores AVC and MVC streams in different .m2ts files (apparently due to backward compatibility with 2D players), while 3D camcorders store both AVC and MVC streams in one .mts file. This can be easily solved with FRIM Import via proper definition in .frim file.

Q 3) The FRIM Export Read Me says: "last codec option is H.264 MVC-3D. This one is intended for export of native Adobe’s dual-stream 3D format. However, this format is not fully supported yet." What are the current limitations? Will this option work for my purposes?
Answer: Last codec option H.264 MVC-3D was intended for so called dual-stream processing in Adobe Premiere. This is not very often used feature of Adobe Premiere, it is supposed to be used for native Stereoscopic processing.
Unfortunately, Adobe SDK documentation is either incomplete, or there is a bug in Premiere, but based on Adobe SDK documentation I didn't succeed to implement it :( .

However, there is no need to go this direction. I use the process for 3D rendering in 3D Above-Below format described in FRIMPremiere_readme.pdf.
Principle is:
1. edit your footage in Premiere in 2D (using only AVC stream, directly processed in Premiere CS6/CC)
2. once editing is completed, convert it via process described in FRIMPremiere_readme.pdf to 3D
3. render final 3D output using FRIM Export.
(FRIM Import is not suitable for editing itself, but is suitable for linear, unidirectional rendering)
For the first look it might seem complicated, but believe me, when you get understood it, it takes only few minutes to prepare you Premiere project for rendering to 3D MVC output.
I use this process for all my personal 3D videos.

Q 4) If the above options fail, can I use FRIM Decoder to create a lossless video file that Premiere will accept for editing? Will the following command line result in what I want: FRIMDecode -i::mvc input_base.avc input_dependent.mvc -o \\.\nul output_R.yuv Not sure if that will be lossless or if Premiere can read YUV.
Answer: Yes, you would need to convert yuv-output from FRIM Decoder to uncompressed .avi or .mov (e.g. using ffmpeg) and then use it in Premiere.
However, it is heavy and impractical! Uncompressed files occupy enormous disk-space and cannot be played back in real time!
Therefore I designed FRIM Import for direct import into Premiere.

Q 5) After I perform my editing, can I use FRIM Encoder to create MVC that can be burned back to a BD? FRIMEncode -i input_L.yuv input_R.yuv -o::mvc output_combined.h264 -w 1920 -h 1080 -f 23.976 -vbr 28000 40000 -u 1 Will that give me what I want? Not sure Premiere can export yuv or do I need to export to something else and then use Avisynth to convert to yuv?
Answer: Yes, FRIM Encoder will produce 3D AVC+MVC output for multiplexing (using tsMuxer) and then burning to BD3D. Just experiment and set proper parameters for encoding to get output for tsMuxer or any other BD3D authoring SW.

Premiere will probably output only uncompressed avi/mov (pay attention, you need to have YUV 420 output), which need to be stripped to planar yuv (again, FFMPEG can do this job)
But again, to avoid huge uncompressed yuv files, you can use FRIM Export directly from Premiere (in Windows).

Q 6) Is there any advantage to using FRIM Source through Avisynth vs just using the standard command line tools?
Answer: Avisynth gives you options for further post-processing/filtering, but decoding itself using FRM Decode and FRIM Source are identical.

FRIM Source and FRIM Import and FRIM Decode use the SAME internal decoding engine, thus they provide identical output to Avisynth and Adobe Premiere and planar yuv-files (respectively).
Similarly, FRIM Export and FRIM Encode use the SAME internal encoding engine, thus they provide identical output from Adobe Premiere and yuv-planar files (respectively).

BigPines
6th August 2015, 18:43
videofan3d, Thank you for your detailed response...and thank you for creating these tools for all of us to use free of charge! They sound like they may be the perfect solution for me.

I myself am primarily a Windows developer so I understand all that you say about that. I prefer the Mac so I always try to find a native solution first. In this case, it looks like I will be setting up a virtual machine and installing CS6 so I can use your Premier plugins. I have several other people working with me editing in Premiere on Mac. I think it should be trivial to open a Premiere Mac project file in Premiere Windows so it shouldn't be a problem. Also, thank you for recommending those other handy plug-ins. I will definitely look into them.

Yes, it [FRIM Import] can be used with MVC from 3DBD . Bluray 3D uses the same MVC coding as 3D camcorders. The difference is that BD stores AVC and MVC streams in different .m2ts files (apparently due to backward compatibility with 2D players), while 3D camcorders store both AVC and MVC streams in one .mts file. This can be easily solved with FRIM Import via proper definition in .frim file.

Got it. So I would need a .frim file like the following?

[Video]
codec=mvc
layout=L
container=TS
filename=01037.m2ts
filename_dep=01038.m2ts

[Audio]
container=TS
filename=01037.m2ts
endian=big

Do I need to place this .frim file in any particular directory?

I am still a little confused though. I do not want to export TAB or SBS 3D. I want to export my edited footage in MVC. Can FRIM Export do that or do I need to use FRIM Encoder?

jmsmarcelo
7th August 2015, 02:13
Please, i'm encode parameter:
FRIMEncode -i 01_movie_L_eye.avi 01_movie_R_eye.avi -o::mvc OutputEncodedBase.avc OutputEncodedDependent.mvc -viewoutput -w 1920 -h 1080 -f 23.976 -u 4 -cpbsize 3570 -vbr 30000 40000 -profile high -level 4.1 -gop 24 4 0 O -EndOfSequence off
and when I import for Scenarist BD appears this error:
Error : ERROR: The MVC scalable nesting SEI message(offset_metadata) is not contain first view component in decoding order of GOP. AU No = 0
C:\Users\jmsma\Downloads\FRIM_x64_version_1.25\x64\OutputEncodedDependent.mvc

sef
7th August 2015, 08:10
@jmsmarcelo

In mui-generator, when importing mvc file, remove the checkbox: Enable Spec check mode.

jmsmarcelo
7th August 2015, 11:04
Thanks @sef :D

videofan3d
7th August 2015, 11:53
Got it. So I would need a .frim file like the following?
...
Do I need to place this .frim file in any particular directory?

I am still a little confused though. I do not want to export TAB or SBS 3D. I want to export my edited footage in MVC. Can FRIM Export do that or do I need to use FRIM Encoder?

Ad A: So I would need a .frim file like the following? Do I need to place this .frim file in any particular directory?
Answer: .frim file is kind of mapping side-car file. You will need two of them:

whatevername_L.frim

[Video]
codec=mvc
layout=L
container=TS
filename=01037.m2ts
filename_dep=01038.m2ts

[Audio]
; leave it empty for .m2ts from 3D-bluray

And also

whatever_R.frim

[Video]
codec=mvc
layout=R
container=TS
filename=01037.m2ts
filename_dep=01038.m2ts

[Audio]
; leave it empty for .m2ts from 3D-bluray

They should be located in the same directory as 01037.m2ts and 01038.m2ts.

Check the sample project FRIM_Premiere_samples_1.23.zip, this will give you hints.

Comment for audio: FRIM Import can read only LPCM audio track, which is very rare on Blu-ray. Audio encoded using in any other codec need to be processed separately.
Anyway, audio on regular Blu-ray disk is encoded usually in DTS or even DTSHD-MA, which will be a bit challenge for you in any case. I doubt that Premiere can read DTS audio.
So you will need to process audio somehow separately.

I such case I would go in the following way (principle):
1. Import and edit project in Premiere in 2D and process (somehow) audio
2. Export audio into WAV
3. Use 3D rendering for video only as described in FRIMPremiere_readme.pdf page 7.
4. Import 3D AVC and MVC streams and audio from point 2. into your BD3D authoring application (I’m using free tsMuxer) and create BD3D ISO.


Ad B: I am still a little confused though. I do not want to export TAB or SBS 3D. I want to export my edited footage in MVC. Can FRIM Export do that or do I need to use FRIM Encoder?
Answer: no worry :). TAB format is used ONLY internally during rendering as described in FRIMPremiere_readme.pdf and FRIM_Premiere_samples_1.23.zip.
Final rendered output are regular h.264 AVC+MVC stream which can be authored in BD3D.ISO and burned and played on BD3D players.
(I play the result mostly with BD-3D capable mediaplayers, and tested burned BD also on Samsung BD-3D player).


Comment: I’m not sure if Windows emulation on Mac will be suitable/usable. I have no experience with Mac, not at all.
3D MVC encoding is very heavy process. Really heavy.
FRIM is based on Intel Media SDK, and all core decoding/encoding is in Intel libraries libmfxsw64.dll or libmfxhw64.dll.
Library libmfxsw64.dll is pure software-based, running on every Windows 7 and 8.x machine. And is slow when encoding.
Library libmfxhw64.dll is HW accelerated but is supported only on Intel i5 and i7 CPU/GPU. Beside it is much faster, it supports also some advanced encoding methods (like Look Ahead).
If you will run emulation on Mac, probably you will be able to use only sw-based method. And Windows emulation itself will also cost some (maybe significant) CPU power, and may reveal some incompatibilities (need to be tested)…
(Just to let you know this impact)

BigPines
7th August 2015, 16:01
Thanks again videofan3d! I am really excited now. I am getting my virtual machine set up and will let you know how it works for me. I don't expect any problems using a virtual machine. I do lots of conversion/encoding on a VM. I have Sony Vegas on a VM and although the MVC export is slow, it works a treat. I am running a quad core i7 so that helps.

I also have the audio all worked out. I edit each channel as a separate wav in Premiere and eventually encode into DTS-MA. :)

Thanks for the tips on the .frim files. I saw in one place it said I needed two files but since each file accepted both left and right eye views, I was confused.

Where can I get the FRIM_Premiere_samples_1.23.zip? I don't see it on the first post. The package includes a Pattern_3D-TAB.prproj file. Is that the same thing?

Mike

videofan3d
7th August 2015, 18:04
Where can I get the FRIM_Premiere_samples_1.23.zip?
Mike

See line in the first post:
2014-03-22: FRIM version 1.23 - Premiere - example of Adobe Premiere project

BigPines
7th August 2015, 21:38
Wow! I have no idea how I missed that. Thanks, checking it out now.

Is there any way to deal with seamless branching 3D discs? In this case, there would be at least two left eye files and two right eye files. Is there a way to configure the .frim files to make FRIM Import work? Would we need to re-encode these types of discs?

Mike