Free H.264 MVC 3D Encoder

[videofan3d]

(Project is mirrored on site videofan3d (https://sites.google.com/site/videofan3d/))

Intel Media SDK provides framework for MPEG2, H.264 AVC/MVC-3D, and H.265 HEVC encoding and decoding.
SDK is supported on Windows 7, Windows 8.x, Windows 10 and it can be freely distributed and used.
Intel Media SDK is probably the only platform providing free MVC-3D encoding capabilities (end of 2013).

FRIM is free SW package based on patterns and examples from this SDK.

FRIM Encoder (command-line tool) converts planar-yuv file, named pipe, uncompressed avi or Avisynth script into elementary MPEG2, H.264 AVC/MVC-3D or H.265 HEVC streams.
Resulting elementary video streams can be then multiplexed into transport stream (.ts, .m2ts) or Blu-ray directory structure.
tsMuxeR 2.1.2 (and higher) is needed for 3D Blu-ray multiplexing.

FRIM Decoder (command-line tool) converts elementary or transport streams (MPEG2, H.264 AVC/MVC-3D, H.265 HEVC, 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, H.265 HEVC, VC1) in Avisynth scripts.

FRIM Export is plugin for Adobe Premiere Pro (CS6) for direct export and encoding to MPEG2, H.264 AVC/MVC-3D or H.265 HEVC elementary streams

FRIM Import is plugin for Adobe Premiere Pro (CS6) for import of 3D-material recorded in AVCHD-3D format (produced by camcorders like Sony HXR-NX3D1 or Panasonic Z10000).
FRIM Import and FRIM Export together support rendering workflow without re-encoding to any intermediate format.

FRIM executables and documentation can be downloaded from:
2020-03-08: FRIM version 1.31 (x86) (https://drive.google.com/file/d/1qnte9zwbU1S7n_DbSKrAcUJNzSdwr27C) - suitable for direct decoding/encoding and Avisynth 2.6.0 (Intel Media SDK 2019 R1)
2020-03-08: FRIM version 1.31 (x64) (https://drive.google.com/file/d/1lumXLd74U-E2k195bzfETbHgFcHcT4sH) - suitable for direct decoding/encoding (also HEVC), Adobe Premiere Pro and Avisynth+ (Intel Media SDK 2019 R1) - HEVC 10-bit support

2019-04-16: FRIM version 1.30 (x86) (https://drive.google.com/file/d/1J2FkWVPlR8XKgkAniTXYSbSpJTyons1A) - suitable for direct decoding/encoding and Avisynth 2.6.0 (Intel Media SDK 2018 R2) - maintenance release
2019-04-16: FRIM version 1.30 (x64) (https://drive.google.com/file/d/1LIRgUpB66HQgEo0DebQ6M4ewpNQzFmXr) - suitable for direct decoding/encoding (also HEVC), Adobe Premiere Pro and Avisynth+ (Intel Media SDK 2018 R2) - maintenance release

2018-07-09: FRIM version 1.29 (x86) (https://drive.google.com/file/d/1zgfyKAGL0d0nipX76EeqxKxkS2yER70c) - suitable for direct decoding/encoding and Avisynth 2.6.0 (Intel Media SDK 2018 R1)
2018-07-09: FRIM version 1.29 (x64) (https://drive.google.com/file/d/1Q9XzzyicXFVnm6wTylFQtatOUsx6Bl0t) - suitable for direct decoding/encoding (also HEVC), Adobe Premiere Pro and Avisynth+ (Intel Media SDK 2018 R1)

2017-07-08: FRIM version 1.27 (x86) (https://drive.google.com/file/d/0BymRNDHq74DEbFFrd0E5OFFIdGc) - suitable for direct decoding/encoding and Avisynth 2.6.0 (Intel Media SDK 2017 R1)
2017-07-08: FRIM version 1.27 (x64) (https://drive.google.com/file/d/0BymRNDHq74DEbUVsQ0NwSGJqdUU) - suitable for Adobe Premiere Pro and Avisynth+ (Intel Media SDK 2017 R1)

2016-01-16: FRIM version 1.26 (x86) (https://drive.google.com/file/d/0BymRNDHq74DEWWhWX1lmMW02MlE) - suitable for direct decoding/encoding and Avisynth 2.6.0 (Intel Media SDK 2016)
2016-01-16: FRIM version 1.26 (x64) (https://drive.google.com/file/d/0BymRNDHq74DETThuZDItZWFIUVU) - suitable for Adobe Premiere Pro and Avisynth+ (Intel Media SDK 2016)

2015-05-10: FRIMSource64.dll (x64) (https://drive.google.com/file/d/0BymRNDHq74DEMnB1QzFvV1pzS0U) - 64-bit version of FRIM decoder (FRIMSource) for AviSynth+ (64-bit).
2015-03-28: FRIM version 1.25 (x86) (https://drive.google.com/file/d/0BymRNDHq74DEaUhmQjBHOUlucW8) - suitable for direct decoding/encoding and Avisynth (Intel Media SDK - INDE 2015 Update 1)
2015-03-28: FRIM version 1.25 (x64) (https://drive.google.com/file/d/0BymRNDHq74DEU1Y5Um5BUEhQRVE) - suitable for Adobe Premiere Pro (Intel Media SDK - INDE 2015 Update 1)

2015-02-28: FRIM version 1.24 (withdrawn)

2014-03-22: FRIM version 1.23 (x86) (https://drive.google.com/file/d/0BymRNDHq74DEclJmZDVWWXlZTlk) - suitable for direct decoding/encoding and Avisynth
2014-03-22: FRIM version 1.23 (x64) (https://drive.google.com/file/d/0BymRNDHq74DEWnpqVVBpM0Z1Qmc) - suitable for Adobe Premiere Pro
2014-03-22: FRIM version 1.23 - Premiere (https://drive.google.com/file/d/0BymRNDHq74DERDBQYTI3TlFDNmc) - example of Adobe Premiere project

2014-02-02: FRIM version 1.22 (withdrawn)
2014-01-25: FRIM version 1.21 (withdrawn)
2014-01-13: FRIM version 1.20 (withdrawn)
2014-01-03: FRIM version 1.19 (withdrawn)
2013-11-26: FRIM version 1.18 (withdrawn)
2013-11-21: FRIM version 1.16 (withdrawn)
2013-11-12: FRIM version 1.15 (withdrawn)
2013-11-07: FRIM version 1.11 (withdrawn)
2013-11-05: FRIM version 1.10 (withdrawn)
2013-10-29: FRIM version 1.00 (withdrawn)

[HWK]

Intel Media SDK provides framework for MPEG2, H.264 AVC and H.264 MVC-3D encoding and decoding.
SDK is supported on Windows 7, Windows 8.x, and it can be freely distributed and used.

FRIM Encoder and FRIM Decoder are free command-line tools based on modification of examples from this SDK.


FRIM Encoder converts planar-yuv file, named pipe, uncompressed avi or Avisynth script into elementary MPEG2, H.264 AVC or MVC-3D streams.
Resulting elementary video streams can be then multiplexed into transport stream (.ts, .m2ts) or Blu-ray directory structure.
Input from named pipes, avi-files and Avisynth scripts allows connection of FRIM Encoder to NLE Editing systems like Adobe Premiere
(via frame-server even without consumption of enormous diskspace).

Intel Media SDK is probably the only platform providing free MVC-3D encoding capabilities.
tsMuxeR 2.1.2 (and higher) is needed for 3D Blu-ray multiplexing.

FRIM Decoder converts elementary MPEG2, H.264 AVC or MVC-3D streams into planar-yuv. Output can be either regular file or Windows named pipe.
Output to named pipe allows further YUV processing without consumption of enormous diskspace.


FRIM executables and documentation can be downloaded from:
FRIM version 1.00 (https://drive.google.com/file/d/0BymRNDHq74DETm5zSFdFT3ZiU1U)

Nice job, Although I already have encoder for MVC but will try out this one as well. Also would it be possible to provide encoder options, specially quality ones.

[tymoxa]

videofan3d
Thanks for your effort.
FRIM Decoder seems to work, but FRIM Encoder gives me an "Unknown codec" error (h264/mpeg2/mvc codec with .yuv/.avi/.avs/.pipe input).
My Cpu is an old Core2Duo.

[HWK]

videofan3d
Thanks for your effort.
FRIM Decoder seems to work, but FRIM Encoder gives me an "Unknown codec" error (h264/mpeg2/mvc codec with .yuv/.avi/.avs/.pipe input).
My Cpu is an old Core2Duo.

What file you are you trying to work with.

[videofan3d]

videofan3d
Thanks for your effort.
FRIM Decoder seems to work, but FRIM Encoder gives me an "Unknown codec" error (h264/mpeg2/mvc codec with .yuv/.avi/.avs/.pipe input).
My Cpu is an old Core2Duo.

You need to have at least Win7 - I tested both on W7/W8/64-bit, but FRIM itself is 32-bit application)

You probably need to have installed proper codecs for VFW API. e.g. K-Lite Mega Codec Pack (10.0.5).

[HWK]

You need to have at least Win7 - I tested both on W7/W8/64-bit, but FRIM itself is 32-bit application)

You probably need to have installed proper codecs for VFW API. e.g. K-Lite Mega Codec Pack (10.0.5).

Just wanted to ask what kind of speed you get when encoding. Also post system specs as well.

[tymoxa]

What file you are you trying to work with.
- .avs with DGSource("test.dgi").ConvertToYV12() in it
- short .avc converted to .yuv
- couple of avi/yuv created with MVCtoAVI converter
Maybe it's because my cpu support only sw mode?

[HWK]

- .avs with DGSource("test.dgi").ConvertToYV12() in it
- short .avc converted to .yuv
- couple of avi/yuv created with MVCtoAVI converter
Maybe it's because my cpu support only sw mode?

I don't think it is software since it can gracefully fall back if software can't take advantage processing capabilities.

What kind of OS are you using.

[tymoxa]

What kind of OS are you using.
Win7x32. I doubt that it's decoder related problem as i can play .avi files in Media Player Classic without using it internal filters plus i have K-Lite Codec Pack installed.

[videofan3d]

Win7x32. I doubt that it's decoder related problem as i can play .avi files in Media Player Classic without using it internal filters plus i have K-Lite Codec Pack installed.

Please provide exact error message, the input and exact command which you are running. Then I can check.:)

[videofan3d]

Just wanted to ask what kind of speed you get when encoding. Also post system specs as well.

I didn't perform measurements, yet (as it is time consuming :) )
I'll do some statistics during next weekend.

[bigotti5]

Same here using AVI, YUV , AVS
always get
Error: Unknown codec

FRIMEncode h264 –avi -i bars.avs -o bars.h264 -b 24000

[tymoxa]

It's strange but after reboot it worked with the same avs file/command line:
FRIMEncode h264 -avi -i test.avs -o output.h264 -b 20000
Testing further.

[videofan3d]

Same here using AVI, YUV , AVS
always get

This is strange: Message "Unknown codec" should appear only (and only) if you miss keyword "h264/mpeg2/mvc".

Which Windows do you have? Win 7/32 or Win 7/64
Do you run it from command prompt (cmd.exe) or batch file?

[frencher]

Hi very good news videofan3d ;)

Same problem for me with batch file
FRIMDecode mvc -i MVCCombined.h264 -o input.yuv
input_L.yuv and input_R.yuv OK Done...



FRIMEncode.exe mvc -i input_L.yuv -i input_R.yuv –viewoutput -o output_L.h264 -o output_R.h264 -w 1920 –h 1080 –f 23.976 -b 40000 –u 1
Return
FRIM Encoder version 1.00 (build: Oct 29 2013)
- based on Intel(R) Media SDK (version: 4.0.760.60435)

Error: Unknown codec

I have Wndows 7 x64 and i7 3930k

[videofan3d]

Hi very good news videofan3d ;)

Same problem for me with batch file

FRIMEncode.exe mvc -i input_L.yuv -i input_R.yuv –viewoutput -o output_L.h264 -o output_R.h264 -w 1920 –h 1080 –f 23.976 -b 40000 –u 1
Return


I have Wndows 7 x64 and i7 3930k

This is really strange, I cannot succeed to simulate it :(
I have Win8/64 and this command works - this is how I did all my tests...

Can you send me the batch file itself to check it?

[HWK]

This is really strange, I cannot succeed to simulate it :(
I have Win8/64 and this command works - this is how I did all my tests...

Can you send me the batch file itself to check it?

Remind me of Jdobbs when he released BD-RB to public and all the failure occurring.

I had failure as well with uncompressed out put with YV12 color space. I couldn't create h264 or mvc file. Also side by side didn't work for me either.

I just noticed those who are having problem are on win7 including me and you are on win 8. Could it be OS or some dependency.

[videofan3d]

Unknown Codec

Guys, maybe I got it :-)

I guess you all copied the sample command "FRIMEncode ..." from PDF, right? :)

Please note, that PDF is generated from MS Word, and MS Word is doing some smart formatting and sometimes replaces character 0x2D (hyphen '-') by 0x96 (which also looks like hyphen!!!), but it is some "pseudo-hyphen" not recognized by cmd.exe :):):)

Please retype the command directly and manually in notepad, and it will work :)

[HWK]

Guys, maybe I got it :-)

I guess you all copied the sample command "FRIMEncode ..." from PDF, right? :)

Please note, that PDF is generated from MS Word, and MS Word is doing some smart formatting and sometimes replaces character 0x2D (hyphen '-') by 0x96 (which also looks like hyphen!!!), but it is some "pseudo-hyphen" not recognized by cmd.exe :):):)

Please retype the command directly and manually in notepad, and it will work :)

Which might explain why encoder doesn't even start.

[videofan3d]

FRIMEncode.exe ... –u 1

Just to comment, -u 1 is the highest quality, but also slowest encoding (naturally).
I was positively surprised with Intel Media encoding quality.
In general, I use only high bitrates, 24 mbit/s for 2D and 40 mbit/s for 3D (quality is most important for me).

As for test I encoded so far two of my own "3D-films" recorded by 3D-camcorder Panasonic Z10000 - and I didn't notice any ugly artefacts on this high bitrate.

x264 is probably better but it doesn't support MVC-3D (unfortunately there is no big demand for it... )

[HWK]

Guys, maybe I got it :-)

I guess you all copied the sample command "FRIMEncode ..." from PDF, right? :)

Please note, that PDF is generated from MS Word, and MS Word is doing some smart formatting and sometimes replaces character 0x2D (hyphen '-') by 0x96 (which also looks like hyphen!!!), but it is some "pseudo-hyphen" not recognized by cmd.exe :):):)

Please retype the command directly and manually in notepad, and it will work :)


In case anyone needs it here are all available options for encoder and decoder


FRIM Encoder version 1.00 (build: Oct 29 2013)
- based on Intel(R) Media SDK (version: 4.0.760.60435)

Usage:

FRIMEncode.exe mpeg2|h264|mvc|jpeg [options]
-i InputFile -o OutputBitstream

options:
[-avi] - input file is in AVI format,
if not specified then YUV is expected
[-sbs|tab numViews] - input file is in side-by-side or top-above-below
format, valid only for multiview
[-w width] - source picture width (one view), mandatory for YUV
[-h height] - source picture height (one view), mandatory for YUV
[-f frameRate] - video frame rate (frames per second)
[-b bitRate] - encoded bit rate (Kbits per second),
valid for H.264, MPEG2 and MVC encoders
[-tff|bff] - input stream is interlaced, top|bottom fielf first,
if not specified then progressive is expected
[-nv12] - input is in NV12 color format,
if not specified then YUV420 is expected
[-u 1..7] - target usage: between 1(=quality) and 7(=speed),
default is 4(=balanced),
valid for H.264, MPEG2 and MVC encoders
[-q quality] - quality parameter for JPEG encoder,
in range [1,100]. 100 is the best quality.
[-la] - use the look ahead bitrate control algorithm (LA BRC)
for H.264 encoder. Supported only with -hw option
on 4th Generation Intel Core processors.
[-lad depth] - depth parameter for the LA BRC, in range [10,100],
the number of frames to be analyzed before encoding
[-dstw width] - destination picture width, invokes VPP resizing
[-dsth height] - destination picture height, invokes VPP resizing
[-hw] - use platform specific SDK implementation,
if not specified then software implementation is used
[-d3d] - work with d3d9 surfaces
[-d3d11] - work with d3d11 surfaces
[-viewoutput] - instruct the MVC encoder to output each view
in separate bitstream buffer.
Depending on the number of '-o' options
behaves as follows:
1: two views are encoded in single file
2: two views are encoded in separate files
3: behaves like two '-o' were used and then one '-o'
Example: FRIMEncode.exe mvc
-i InputFile_1 -i InputFile_2
-o OutputEncodedFile_1 -o OutputEncodedFile_2
-viewoutput -w width -h height

User module options:
[-angle 180] - enables 180 degrees picture rotation before encoding,
CPU implementation by default.
Rotation requires NV12 input.
Options -tff|bff, -dstw, -dsth, -d3d are not effective
together with this one, -nv12 is required.
[-opencl] - rotation implementation through OPENCL
Example: FRIMEncode.exe h264|mpeg2|mvc|jpeg
-i InputFile -o OutputEncodedFile
-w width -h height -angle 180 -opencl

------------------------------------------------------------------

FRIM Decoder version 1.00 (build: Oct 29 2013)
- based on Intel(R) Media SDK (version: 4.0.760.60435)


Usage:

FRIMDecode.exe mpeg2|h264|vc1|mvc|jpeg [options]
-i InputBitstream -o OutputYUVFile

options:
[-sbs|tab] - output file is in side-by-side or top-above-below
format, valid only for multiview
[-hw] - use platform specific SDK implementation,
if not specified software implementation is used
[-low_latency] - configures decoder for low latency mode
(supported only for H.264 and JPEG codec)
[-calc_latency] - calculates latency during decoding and prints log
(supported only for H.264 and JPEG codec)
[-jpeg_rotate n] - rotate jpeg frame n degrees (n=90,180,270)
[-nv12] - output is in NV12 color format,
if not specified then YUV420 is used
[-d3d] - work with d3d9 surfaces
[-d3d11] - work with d3d11 surfaces
[-r] - render decoded data in a separate window
[-wall w h n m f t tmo] - same as -r, and positioned rendering window
in a particular cell on specific monitor
w ... number of columns of video windows on selected monitor
h ... number of rows of video windows on selected monitor
n(0,.,w*h-1) ... order of video window in table that will be rendered
m(0,1..) ... monitor id
f ... rendering framerate
t(0/1) ... enable/disable window's title
tmo ... timeout for -wall option, in seconds

Press 1 to toggle fullscreen rendering on/off

[frencher]

Just to comment, -u 1 is the highest quality, but also slowest encoding (naturally).
I was positively surprised with Intel Media encoding quality.
In general, I use only high bitrates, 24 mbit/s for 2D and 40 mbit/s for 3D (quality is most important for me).

As for test I encoded so far two of my own "3D-films" recorded by 3D-camcorder Panasonic Z10000 - and I didn't notice any ugly artefacts on this high bitrate.

x264 is probably better but it doesn't support MVC-3D (unfortunately there is no big demand for it... )

Fixed nows thanks ;)

Works fine with this CMD Line:
FRIMDecode mvc -i MVCCombined.h264 -o \.\\pipe\TMP.yuv | FRIMEncode.exe mvc -i \.\\pipe\TMP_L.yuv -i \.\\pipe\TMP_R.yuv -viewoutput -o output_L.h264 -o output_R.h264 -w 1920 -h 1080 -f 23.976 -b 40000 -u 1

[HWK]

Just to comment, -u 1 is the highest quality, but also slowest encoding (naturally).
I was positively surprised with Intel Media encoding quality.
In general, I use only high bitrates, 24 mbit/s for 2D and 40 mbit/s for 3D (quality is most important for me).

As for test I encoded so far two of my own "3D-films" recorded by 3D-camcorder Panasonic Z10000 - and I didn't notice any ugly artefacts on this high bitrate.

x264 is probably better but it doesn't support MVC-3D (unfortunately there is no big demand for it... )

At least public got the encoder which does MVC for free :)

[colinhunt]

So if I want to test this, how do I get from a BD3D to a file I can feed to the encoder?

[HWK]

So if I want to test this, how do I get from a BD3D to a file I can feed to the encoder?

You will require MVC decoder in order to decode files. One which is built in with this release can't decode from SSIF file. Second method is to use Full SBS which require 3840*1080 resolution. Last option require to create yuv file and which are not compressed and will go quite large in size.

[frencher]

You will require MVC decoder in order to decode files. One which is built in with this release can't decode from SSIF file. Second method is to use Full SBS which require 3840*1080 resolution. Last option require to create yuv file and which are not compressed and will go quite large in size.

Or use YUV without large size temporary file with this rapid CMD line ;)
FRIMDecode mvc -i MVCCombined.h264 -o \.\\pipe\TMP.yuv | FRIMEncode.exe mvc -i \.\\pipe\TMP_L.yuv -i \.\\pipe\TMP_R.yuv -viewoutput -o output_L.h264 -o output_R.h264 -w 1920 -h 1080 -f 23.976 -b 40000 -u 1

[tymoxa]

frencher
Shouldn't it be \\.\pipe ?

Anyway it doesn't work for me :(
I can decode combined mvc to couple of yuv's with:
FRIMDecode.exe mvc -i MVCCombined.h264 -o test.yuv
then encode these with
FRIMEncode.exe mvc -i test_L.yuv -i test_R.yuv -o output_L.h264 -o output_R.h264 -viewoutput -w 1920 -h 1080 -f 23.976 -b 20000 -u 4
but with this line
FRIMDecode.exe mvc -i MVCCombined.h264 -o \\.\pipe\test.yuv | FRIMEncode.exe mvc -i \\.\pipe\test_L.yuv -i \\.\pipe\test_R.yuv -o output_L.h264 -o output_R.h264 -viewoutput -w 1920 -h 1080 -f 23.976 -b 20000 -u 4
it gives me an error
ERROR: Cannot open input file \\.\pipe\test_R.yuv
ERROR: File reader initialization failed.
ERROR: Cannot start encoding process.
Am i doing something wrong?

videofan3d
Why bitrate for main and dependent is almost the same? It is limitation of encoder?

[frencher]

Rapid package for test (http://ul.to/d74yc5mw) ;)

[tymoxa]

Rapid package for test ;)
Nope. Same error with your batch file:

C:\temp\Demo FRIM version 1.00>FRIMDecode mvc -i MVCCombined.h264 -o \.\\pipe\FR
IM_TMP.yuv | FRIMEncode.exe mvc -i \.\\pipe\FRIM_TMP_L.yuv -i \.\\pipe\FRIM_TM
P_R.yuv -viewoutput -o output_L.h264 -o output_R.h264 -w 1920 -h 1080 -f 23.976
-b 40000 -u 1

ERROR: Cannot open input file \.\\pipe\FRIM_TMP_L.yuv

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

C:\temp\Demo FRIM version 1.00>pause
Press any key to continue . . .

[HWK]

videofan3d
Why bitrate for main and dependent is almost the same? It is limitation of encoder?

You specify bitrate which is sum up of both streams and encoder will automatically choose bitrate for each file based on scene demand. Example if I set 20MB/s it may choose 13 for base view and 7 for dependent view or other way around depending on complexity of source also it will vary from one frame to another.

Set the bitrate and let encoder decide how to distribute between files and how much.

[videofan3d]

Windows named pipes

Windows named pipe must have a specific name:

\\.\pipe\somename

Also try this batch file:


start FRIMDecode mvc -i MVCCombined.h264 -o \\.\pipe\FRIM_TMP.yuv (new command window will be opened)

pause (here you have to press any key when prompted)

FRIMEncode.exe mvc -i \\.\pipe\FRIM_TMP_L.yuv -i \\.\pipe\FRIM_TMP_R.yuv -viewoutput -o output_L.h264 -o output_R.h264 -w 1920 -h 1080 -f 23.976 -b 40000 -u 4


Remark: selecting -u 1 is highest quality, but also slowest. For first testing choose -u 4, or even -u 7 (fastest)

[frencher]

Why dont use FRIMTranscode.exe with both output: output_L.h264 and output_R.h264

[tymoxa]

Why dont use FRIMTranscode.exe with both output: output_L.h264 and output_R.h264
How is that possible? Transcoder doesn't have -viewoutput option. It transcode to combined mvc. Is there any tool that can divide combined mvc into elementary streams?

[videofan3d]

How is that possible? Transcoder doesn't have -viewoutput option. It transcode to combined mvc. Is there any tool that can divide combined mvc into elementary streams?

Current version of Intel Media SDK doesn't provide support for processing of basic and dependent views in separate files in FRIM Decode and FRIM Transcoder (unfortunately).

It provides "only" support for their creation in FRIM Encoder (fortunately) - hence we can create and multiplex our own 3D films in standard Blu-ray 3D format.

[tymoxa]

Current version of Intel Media SDK doesn't provide support for processing of basic and dependent views in separate files in FRIM Decode and FRIM Transcoder (unfortunately).

That's why i asked about tool that can divide combined mvc into separate files. Is that kind of tool exist?

[Sharc]

That's why i asked about tool that can divide combined mvc into separate files. Is that kind of tool exist?
http://www.3dtv.at/Products/MvcConverter/Index_en.aspx

[tymoxa]

http://www.3dtv.at/Products/MvcConverter/Index_en.aspx

Sorry, not exactly what i need.
MVCCombined.h264 is sum of .avc + .mvc created with MVCCombine.exe.
I asked about a tool that can divide MVCCombined.h264 into separate .avc + .mvc. without decoding.

[videofan3d]

Sorry, not exactly what i need.
MVCCombined.h264 is sum of .avc + .mvc created with MVCCombine.exe.
I asked about a tool that can divide MVCCombined.h264 into separate .avc + .mvc. without decoding.

I'm not aware of any such tools. Such process is probably not simple (if it would have to reliable) - it would require deeper .h264 stream analysis.

Btw. where can I get MVCCombine.exe which you mentioned?

[physic]

tymoxa provide me combined AVC+MVC track example. I am going to support such tracks in tsMuxeR during weekend.

[videofan3d]

tymoxa provide me combined AVC+MVC track example. I am going to support such tracks in tsMuxeR during weekend.

I will send you both tonight with some further info - thanks!

[frencher]

Btw. where can I get MVCCombine.exe which you mentioned?

Download my program MVC Player Free (in my signature) and explore .\Tools\MVC Player Free Demuxer\MVCCombine.exe (From Neisklar)

[Sharc]

Does Combine.exe allow to interleave (combine) the base (AVC) view and the dependent view? Or do the 2 streams (Left and Right) have to be both independent AVC streams?
Actually I can combine the base AVC view (.h264 file) and the dependent view (.mvc file) successfully but when playing back the "combinedMVC.h264" e.g. with Stereoscopic Player the 3D depth seems to have almost gone. I tried various playback settings but no avail.

Edit:
Now I muxed the combinedMVC.h264 into a .ts or .mts with tsMuxeR and the 3D is perfect. However playback is intermittent i.e. a pause of about 0.5 sec every 1 or 2 seconds. Looks like a pause at every GOP :confused:

Edit2:
When I use the "old" tsMuxeR v1.10.6 playback is fluent. So there seems to be an issue with the new tsMuxer v2.1.4(b).

[videofan3d]

Why bitrate for main and dependent is almost the same? It is limitation of encoder?


Bitrate distribution between main and dependent view is controlled by Encoder. And probably it cannot be influenced too much - I didn't find any such parameter in the SDK.

Few comments to this:
1. FRIM Encoder version 1.00 uses only CBR - this I'm going to change in next version
2. Multiview encoding uses following principle:
main view has GOP structure I-B-P
dependend view(s) only B-P, i.e. they are also derived from I-frame of the main view.

The encoding logic is likely quite complex and complicated, and encoder needs to balance bitrate accordingly to assure equivalent visual quality in L and R eye. This is probably the reason why bitrate distribution is strictly controlled by encoder without user intervention.

3. Intel Media SDK is single pass encoder, so it is obvious that it cannot have such capabilities like two-pass mode of x264.
Two-pass processing allows much better picture analysis (and on the other side it has also its cost - encoding time)

[frencher]

:goodpost:
The max bitrate seems to be 65535 (Kbps) how increase up to 100000 (Kbps)
Lossless :)
2 pass mode yeah nice idea
Remaining time
Thanks for all ;)

[HWK]

:goodpost:
The max bitrate seems to be 65535 (Kbps) how increase up to 100000 (Kbps)
Thanks for all ;)

Why do you want such high bitrate in first place.

[videofan3d]

Why do you want such high bitrate in first place.

BD format restricts bitrates to ~40 Mbit for video.

H.264 is very effective compression.
Picture quality on 24 mbit is practically identical to professional ProRes codec on 180 mbit.
(ProRes is type on JPEG intra-frame compression and has significant advantage over H.264 for editing in NLE systems + 4:2:2 chroma subsampling - but visual quality in 4:2:0 is not so much higher in it)

And practically, all you video sources are either BD, or recordings from HD camcorder.
All those sources are limited to max 40 mbit/s in H.264.
For second generation of processing you don't need higher bitrate, there is no additional information in the picture.

And if you need to go to NLE intra-frame editing, then convert it to ProRes or DNxHD (using ffmpeg).

[frencher]

Why do you want such high bitrate in first place.

Lossless is better, it's for Rebuild BD25 in 2 pass mode with DVDFAB.

I works my MVC Player Free GUI for avisynth support and works fine just one problem with total frames :confused:

My source have 18816 (x2 = 37632) frames for 37634 recoded frames.
My recode log is:
Intel(R) Media SDK Encoding Sample Version 4.0.760.60435

Input format YUV420
Output video AVC
MFX dll: F:\Temp Recode\MVC Player\MVCtoAVI.exe\Tools\Frim MVC Decoder Encoder\libmfxsw32.dll

Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bit rate (Kbps) 65535
Target usage 7 (speed)

Memory type system
Media SDK impl sw
Media SDK version 1.7

Processing started
Frame number: 37634
Processing finished in 655.94 seconds

[videofan3d]

My source have 18816 (x2 = 37632) frames for 37634 recoded frames.

Frame rate 23.976
Bit rate (Kbps) 65535
Target usage 7 (speed)

Processing started
Frame number: 37634
Processing finished in 655.94 seconds[/CODE]

This shows that FRIM Encoder was fed by 37634 frames.
In MVC mode (3D) it sums number of both L+R frames, thus total number of processed frames is doubled.
Check your AviSynth script.

Remark: bitrate is limited to 65535 - related parameter in Intel SDK for bitrate is defined as uint16.

[frencher]

OK
Recode in progress of two large videos for test, i send my report when i done ;)

[HWK]

BD format restricts bitrates to ~40 Mbit for video.


3D can have up to 60 for video but it is combined for both views. Base view can not have more than 40.

Source: http://netblender.ning.com/forum/topics/max-bitrates-for-3d?xg_source=activity

[videofan3d]

Hi,

new version of FRIM Encoder (1.10) is available - see the link on the first page of this thread.

New features:
FRIM Encoder 1.10 added options
- for GOP control (length, IP-distance, IDR-interval, opened/closed/strict)
- added options for bitrate control -cbr, -vbr (for Blu-ray/DVD compatibility setting)
- added option -cpbsize for cpb/vbv buffer size (for Blu-ray/DVD compatibility setting)
- added option -l numSlices (for Blu-ray compatibility setting)
- added option -maxdpb for size of Decoded Picture Buffer
- added options -profile, -level for proper marking of elementary stream
- added options for CAVLC and CABAC encoding
- added options -VuiNalHrd, -VuiVclHrd, -PicTimingSEI, -EndOfSequence, -EndOfStream for H.264 elementary stream NAL structure control

FRIM Decoder, FRIM Transcoder - no changes.

[Cedvano]

Great software.
I already use MVC encoding by Intel, but the problem is that he can only encode MVC combined files.
Can you modify FRIMTranscode (the multi transcode) for use with Blu-ray MVC in 2 files (AVC and MVC files)?

[Sharc]

Thanks videofan3d. MVC VBR with v1.10 is great; ISO finally created with tsMuxeR (3D with ssif).
Would be awesome if Intel would support 2 separate input files for base and dependent view in future.

P.S.
Still I could not make it work with the pipe. I get the same 3 errors as tymoxa.
Works only via large .yuv files here ....

[videofan3d]

Still I could not make it work with the pipe. I get the same 3 errors as tymoxa.

Could you please remind me, how do you connect it it via pipes?
The exact command?
I'll look at it during days....

[tymoxa]

Could you please remind me, how do you connect it it via pipes?
The exact command?
I'll look at it during days....

I have tried this command:
FRIMDecode.exe mvc -i MVCCombined.h264 -o \\.\pipe\test.yuv | FRIMEncode.exe mvc -i \\.\pipe\test_L.yuv -i \\.\pipe\test_R.yuv -viewoutput -o output_L.h264 -o output_R.h264 -w 1920 -h 1080 -f 23.976 -u 4 -cpbsize 3570 -vbr 30000 40000 -l 6 -profile high -level 4.1 -gop 24 4 0 O

[frencher]

Very good update 1.10 have better compatibility with nero 3D player ;)
There in the large files of Frim a problem with avisynth (Source = SBS 3840x1080).
After a few minutes or a few seconds the screen become black until the end of the film (probably stall) at the time the encoding speed become faster there.
Have you any solution?
How to pass command line for complete compatibility for Blu-ray 3D encoding ?

[tymoxa]

How to pass command line for complete compatibility for Blu-ray 3D encoding ?

For 1080@23.976 fps try this:
FRIMEncode.exe mvc -i input_L.yuv -i input_R.yuv -viewoutput -o output.avc -o output.mvc -w 1920 -h 1080 -f 23.976 -u 4 -cpbsize 3570 -vbr 30000 40000 -l 6 -profile high -level 4.1 -gop 24 4 0 O
Just remember that maximum bitrate for main+dependent+audio+subtitles is 64Mbps

[colinhunt]

I get same errors as tymoxa and Sharc when trying to use a pipe. Windows 7 Ultimate 64-bit, in case that matters any.

[frencher]

FRIMEncode.exe mvc -i input_L.yuv -i input_R.yuv -viewoutput -o output.avc -o output.mvc -w 1920 -h 1080 -f 23.976 -u 4 -cpbsize 3570 -vbr 30000 40000 -l 6 -profile high -level 4.1 -gop 24 4 0 O

Thank ;)
And CABAC ? :confused:

[Sharc]

Could you please remind me, how do you connect it it via pipes?
The exact command?
I'll look at it during days....
My command:
FRIMDecode mvc -i CombinedMVC.h264 -o \\.\pipe\TMP.yuv | FRIMEncode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o output_L.h264 -o output_R.h264 -w 1920 -h 1080 -dstw 1280 -dsth 720 -f 23.976 -vbr 10000 20000 -u 4
pause
The errors I get:
ERROR: Cannot open input file \\.\pipe\TMP_L.yuv

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.
I am on Windows 7 /64 bit.
All files are in the same folder. Does it have to be a special folder? Root directory?

[Cedvano]

I confirm this error on Win 7 / 64Bits.

[tymoxa]

And CABAC ? :confused:
CABAC is ON by default.

[videofan3d]

My command:
FRIMDecode mvc -i CombinedMVC.h264 -o \\.\pipe\TMP.yuv | FRIMEncode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o output_L.h264 -o output_R.h264 -w 1920 -h 1080 -dstw 1280 -dsth 720 -f 23.976 -vbr 10000 20000 -u 4
pause
The errors I get:
ERROR: Cannot open input file \\.\pipe\TMP_L.yuv

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.
I am on Windows 7 /64 bit.
All files are in the same folder. Does it have to be a special folder? Root directory?

There are two issues:
1. failure above is related to timing. Encoding process is trying to read from named-pipe which Decoding process didn't open yet
2. beside of this, there is bug when reading end of pipe.

I'll check it and fix it.

[Sharc]

There are two issues:
1. failure above is related to timing. Encoding process is trying to read from named-pipe which Decoding process didn't open yet
2. beside of this, there is bug when reading end of pipe.

I'll check it and fix it.
Thanks! Glad you traced the cause.

[Sharc]

Why dont use FRIMTranscode.exe with both output: output_L.h264 and output_R.h264
We can use FRIMtranscode.exe to produce a re-encoded CombinedMVC.h264:
FRIMTranscode.exe -i::mvc CombinedMVC.h264 -o::mvc TranscodedCombinedMVC.h264 -w 1920 -h 1080 -f 23.976 -l 4 -b 8000 -u 4
The transcoded .h264 can then be remuxed with the new tsMuxeR.

FRIMTranscode.exe so far seems not support -vbr or any of the other advanced options which are available with FRIMEncode.exe. However it avoids the huge *.yuv intermediate files and could be a workaround until the fix for named pipe becomes available.

[videofan3d]

FRIMTranscode.exe so far seems not support -vbr or any of the other advanced options which are available with FRIMEncode.exe. However it avoids the huge *.yuv intermediate files and could be a workaround until the fix for named pipe becomes available.


Pipe-fix will be available soon, likely on Friday night, so you can test it over weekend.

FRIOM Transcoder modification (cbr, vbr, gop, ...) is on roadmap.

[Sharc]

Pipe-fix will be available soon, likely on Friday night, so you can test it over weekend.

FRIOM Transcoder modification (cbr, vbr, gop, ...) is on roadmap.
Wow! Good News. Just take your time .... no hurry.

[colinhunt]

Pipe-fix will be available soon, likely on Friday night, so you can test it over weekend.

FRIOM Transcoder modification (cbr, vbr, gop, ...) is on roadmap.
Fantastic! Thank you very much for all your hard work.

[HWK]

videofan3d can you add support for frame serving through directshowmvcsource plugin, currently when I open avs file in encoder I get message can't determine number of frames. I tired SBS as well and same thing is happening. However If I open file in virtual dub it correctly display how many frames video has and frame rate as well.

[videofan3d]

videofan3d can you add support for frame serving through directshowmvcsource plugin, currently when I open avs file in encoder I get message can't determine number of frames. I tired SBS as well and same thing is happening. However If I open file in virtual dub it correctly display how many frames video has and frame rate as well.

I don't understand.
Please describe your needs what do you want to achieve.

Avisynth is mighty tool (and well proven), I use for interractions between all my videoapplications without difficulties. Whenever I had a problem - it was always caused by mistake in my avs-script :).

[videofan3d]

Hi,

there is new version FRIM 1.11

FRIM Encoder 1.11
- fixed bug in handling named pipes (.yuv)

FRIM Decoder 1.11
- separate main and dependent views on input are supported

FRIMDecode mvc -i input_L.h264 -i input_R.h264 -o output.yuv

[frencher]

Yeah i test your update NOW !!!
It's possible to compile all *.exe to x64 for increase speed please.
Thank ;)

[videofan3d]

Yeah i test your update NOW ;)
It's possible to compile all *.exe to x64 for increase speed please.

Unfortunately, MSVC x64-compiler is not free... :(

[frencher]

Unfortunately, MSVC x64-compiler is not free... :(

There seems to have the better with pipe
By FrimEncoder against crashes during encoding with avisynth or MVC track is not decoded to give a black image instead of the right view (MVC).
A sync problem or Memory buffer

[videofan3d]

There seems to have the better with pipe
By FrimEncoder against crashes during encoding with avisynth or MVC track is not decoded to give a black image instead of the right view (MVC).
A sync problem or Memory buffer

How do you run it? Please provide me with details...

[colinhunt]

Unfortunately, MSVC x64-compiler is not free... :(
How much does it cost? Perhaps we could pass a hat around...

[frencher]

Avisynth Script:
LoadPlugin ("F:\MVC Player\MVCtoAVI.exe\DirectShowMVCSource.dll")

# Start AVS for CombinedMVC

File = "G:\Video.mts"
Left = DirectShowMVCSource(File,decodeleft=TRUE)
Right = DirectShowMVCSource(File)
Video = StackHorizontal(Left,Right) (3840x1080 @ 23.976 fps)

# End AVS for CombinedMVC

Video = Video.ConvertToYV12()
Return Video

Batch:
"F:\MVC Player\MVCtoAVI.exe\Tools\Frim MVC Decoder Encoder\FRIMEncode.exe" mvc -i "F:\MVC Player\MVCtoAVI.exe\Preview.avs" -avi -sbs 2 -viewoutput -o H:\L.h264 -o H:\R.h264 -b 60000 -u 4

[colinhunt]

FRIM Decoder 1.11
- separate main and dependent views on input are supported
FRIMDecode mvc -i input_L.h264 -i input_R.h264 -o output.yuv
Does this mean I can feed it demuxed h264 files directly from a 3DBD?

[HWK]

Avisynth Script:
LoadPlugin ("F:\MVC Player\MVCtoAVI.exe\DirectShowMVCSource.dll")

# Start AVS for CombinedMVC

File = "G:\Video.mts"
Left = DirectShowMVCSource(File,decodeleft=TRUE)
Right = DirectShowMVCSource(File)
Video = StackHorizontal(Left,Right) (3840x1080 @ 23.976 fps)

# End AVS for CombinedMVC

Video = Video.ConvertToYV12()
Return Video

Batch:
"F:\MVC Player\MVCtoAVI.exe\Tools\Frim MVC Decoder Encoder\FRIMEncode.exe" mvc -i "F:\MVC Player\MVCtoAVI.exe\Preview.avs" -avi -sbs 2 -viewoutput -o H:\L.h264 -o H:\R.h264 -b 60000 -u 4

Does it work for you? I tired with Directshowmvcplugin but no go for me and then I decied to send whole package to author for testing. Except magic path is stereoplayer.exe instead mvc toavi.exe

[HWK]

Does this mean I can feed it demuxed h264 files directly from a 3DBD?

I would think so, give it a try and let us know how it goes for you.

[frencher]

Does it work for you? I tired with Directshowmvcplugin but no go for me and then I decied to send whole package to author for testing. Except magic path is stereoplayer.exe instead mvc toavi.exe

Look my tutorial from my signature, i have updated my tutorial for support yuv from ffdshow (up of 1920x1080) ;)
If I understand :D

[frencher]

I would think so, give it a try and let us know how it goes for you.

F:\MVC Player\MVCtoAVI.exe>"F:\MVC Player\MVCtoAVI.exe\Tools\Frim MVC Decoder Encoder\FRIMEncode.exe" mvc -i "F:\MVC Player\MVCtoAVI.exe\Preview.avs" -avi -sbs 2 -viewoutput -o H:\L.h264 -o H:\R.h264 -b 60000 -u 4
FRIM Encoder version 1.11 (build: Nov 7 2013)
- based on Intel(R) Media SDK (version: 4.0.760.60435)

Input format YUV420
Output video AVC
MFX dll: F:\MVC Player\MVCtoAVI.exe\Tools\Frim MVC Decoder Encoder\libmfxsw32.dll

Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control CBR
bitrate 60000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 1
GOP type Opened
Num of slices 6
Target usage 4 (balanced)

Memory type system
Media SDK impl sw
Media SDK version 1.7

Processing started
Frame number: 37969

[frencher]

Does this mean I can feed it demuxed h264 files directly from a 3DBD?

Yes directly from iso 3DBD without demuxing (With Avisynth by DirectShowMVCSource in next update of MVC Player Free) ;)

[videofan3d]

Does this mean I can feed it demuxed h264 files directly from a 3DBD?

Yes -
demux main and dependent view (e.g. using eac3to -demux xxx.ssif) please try it...

[frencher]

:( new crash with avisynth script... (Ten recodage with x264 x86 and no crash, no crash with export to YUV)

http://i41.tinypic.com/2lt68fn.png

[HWK]

Hi,

FRIMDecode mvc -i input_L.h264 -i input_R.h264 -o output.yuv

I think it would be better if naming convention is like this

-i input_L.h264 > -i input_B.h264
-i input_R.h264 > -i input_D.h264

B: Base, D: Dependent

Since some movies have inverse in order how they store stream.

[videofan3d]

I think it would be better if naming convention is like this

-i input_L.h264 > -i input_B.h264
-i input_R.h264 > -i input_D.h264

B: Base, D: Dependent

Since some movies have inverse in order how they store stream.

Right - next release I'll update documentation to be more self-explanatory.

[videofan3d]

:( new crash with avisynth script... (Ten recodage with x264 x86 and no crash, no crash with export to YUV)

http://i41.tinypic.com/2lt68fn.png

- What is the length (in minutes) of the movie you are processing?
- Are you using avisynth script or elementary view .h264?

[HWK]

Look my tutorial from my signature, i have updated my tutorial for support yuv from ffdshow (up of 1920x1080) ;)
If I understand :D

Thank you, that make sense I will give it a try, however still it would be nice to feed full sbs to encoder with directshowmvcsourceplugin only and get encoding going.

[HWK]

- What is the length (in minutes) of the movie you are processing?
- Are you using avisynth script or elementary view .h264?

Avisynth, it is also in the header of the post.

[frencher]

I think it would be better if naming convention is like this

-i input_L.h264 > -i input_B.h264
-i input_R.h264 > -i input_D.h264

B: Base, D: Dependent

Since some movies have inverse in order how they store stream.

OK i change my CMD Line ;)
My tool for AVC/MVC order First view of SSIF.rar (http://ul.to/b3reswxz)

[HWK]

OK i change my CMD Line ;)
My tool for AVC/MVC order First view of SSIF.rar (http://ul.to/b3reswxz)

Post was geared towards videofan3d :p

[frencher]

- What is the length (in minutes) of the movie you are processing?
- Are you using avisynth script or elementary view .h264?

With Avisynth
133402 frames total 266804

[tymoxa]

videofan3d
Is it possible to add an option to decoder/transcoder (let's say it would be -d key) to have possibility of decoding/transcoding dependent view only?

[HWK]

videofan3d
Is it possible to add an option to decoder/transcoder (let's say it would be -d key) to have possibility of decoding/transcoding dependent view only?

It make sense for decoder, however for transcoding and encoding I can't think of reason to add it.

[videofan3d]

videofan3d
Is it possible to add an option to decoder/transcoder (let's say it would be -d key) to have possibility of decoding/transcoding dependent view only?

Do you mean to get only the R-eye?

Please note that from MVC principle: base view can be decoded to L-eye, but for decoding R-eye you need both: base view and dependent view together.

[HWK]

It make sense for decoder, however for transcoding and encoding I can't think of reason to add it.

Do you mean to get only the R-eye?

Please note that from MVC principle: base view can be decoded to L-eye, but for decoding R-eye you need both: base view and dependent view together.

I think, what op is referring to ability to decode data from dependent view in such way that it can be viewed without any dependence.

[tymoxa]

I think, what op is referring to ability to decode data from dependent view in such way that it can be viewed without any dependence.
Exactly.
I want do something like this:
FRIMDecode mvc -i l.h264 -i r.h264 -o \\.\pipe\out.yuv -d | x264 --qp 0 -o dependent.264 - --fps 23.976 --input-res 1920x1080

[HWK]

Exactly.
I want do something like this:

oh, I see what you are saying. Good news we already have decoder which can do it for you and yes you can use X.264 encoder with it.

[Sharc]

v1.11 named pipe still does not work here. Now I get the error:
Error: Unknown codec

[videofan3d]

Exactly.
I want do something like this:

I will thing about it :)

Probably you want to get pure_L.h264 (as AVC) and also pure_R.h264 (also as AVC), right?

[videofan3d]

v1.11 named pipe still does not work here. Now I get the error:
Error: Unknown codec

Unknown codec - you have likely wrong command line, some hyphen "-" is missing, or you have there extra space.

[tymoxa]

Good news we already have decoder which can do it for you and yes you can use X.264 encoder with it.
You are referencing to DirectShow MVC Source.dll? It's not an option to me.

[tymoxa]

Probably you want to get pure_L.h264 (as AVC) and also pure_R.h264 (also as AVC), right?
We already have pure_L.h264. I want pure_R.h264.

[HWK]

You are referencing to DirectShow MVC Source.dll? It's not an option to me.

May I know why, if that is ok with you?

[Eseninzhiv]

videofan3d
Thank you for your work, just super!
long looking for a decoder MVC 3D (interest only output YUV)

if use this method, everything is fine
Decoding H.264 MVC combined elementary stream into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1822500kb

if use this method
Decoding H.264 MVC separate main and dependent views into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1819463kb then the last frame is then removed

is it possible to add the conversion directly from the file SSIF?

[Sharc]

@videofan3d
I confirm that separate input files and named pipe now work perfectly with v1.11:

FRIMDecode.exe mvc -i base.264 -i dependent.mvc -o \\.\pipe\TMP.yuv | FRIMencode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -dstw 1280 -dsth 720 -f 23.976 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O

:thanks:

[tymoxa]

if use this method
Decoding H.264 MVC separate main and dependent views into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1819463kb then the last frame is then removed

That's odd. In my tests both methods give me the same size of .yuv's.

[Sharc]

Does this mean I can feed it demuxed h264 files directly from a 3DBD?
Workflow:
1. Rip the 3DBD to .iso
2. Mount the .iso
3. Start tsMuxeR and open the *.ssif (usually the largest for the movie)
4. Select the wanted tracks and demux with tsMuxeR
=> You will get the elementary files for the base view *.264, dependent view *.mvc, and the selected audio and sup files.
5. Now encode the video files with FRIMTools, like:
FRIMDecode.exe mvc -i 00049.track_4113.264 -i 00050.track_4114.mvc -o \\.\pipe\TMP.yuv | FRIMencode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -dstw 1280 -dsth 720 -f 23.976 -l 4 -cpbsize 3750 -vbr 8000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O(I included resizing to 1280x720 in the example)
=> You will get re-encoded base *.avc and dependent *.mvc streams.
6. Start tsMuxeR, open the video files from 5., add the audio and sup files from 4., select as output Blu-ray ISO, and start muxing ...
7. Burn the .iso

[videofan3d]

videofan3d
Thank you for your work, just super!
long looking for a decoder MVC 3D (interest only output YUV)

if use this method, everything is fine
Decoding H.264 MVC combined elementary stream into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1822500kb

if use this method
Decoding H.264 MVC separate main and dependent views into two yuv‐files (3D)
output_L.yuv 1822500kb
output_R.yuv 1819463kb then the last frame is then removed


This is strange - for investigation I need to simulate it.
How did get the original combined file and related separated files? Please describe me process in order to reproduce it.

[Eseninzhiv]

demux SSIF via tsMuxeR 2.1.6
1. MVC combined, use the utility http://forum.doom9.org/showthread.php?p=1628058#post1628058 files are the same
2. MVC separate, demux SSIF via tsMuxeR 2.1.6 http://i.imgur.com/haAbf6b.png

if demux with eac3to playlist, all right, files are the same
eac3to probably adds at the end of an empty frame
eac3to v3.24
command line: "F:\3D\H.264 MVC 3D Decoder\eac3to v3.24\eac3to.exe" "J:\BDMV\PLAYLIST\00250.mpls" 01: l.h264 02: r.h264
------------------------------------------------------------------------------
M2TS, 2 video tracks, 3 audio tracks, 3 subtitle tracks, 0:01:41, 24p /1.001
1: h264/AVC (left eye), 1080p24 /1.001 (16:9)
2: h264/AVC (right eye), 1080p24 /1.001 (16:9)
3: AC3, English, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
4: AC3, French, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
5: AC3, Russian, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
6: Subtitle (PGS), French
7: Subtitle (PGS), Dutch
8: Subtitle (PGS), Russian
[v02] Extracting video track number 2...
[v01] Extracting video track number 1...
[v02] Creating file "r.h264"...
[v01] Creating file "l.h264"...
Video track 1 contains 2419 frames.
Video track 2 contains 2420 frames.
eac3to processing took 4 seconds.
Done.

[videofan3d]

Post was geared towards videofan3d :p

@HWK
@frencher

Guys,

I copied HWK's package into directory C:\Stereoplayer,
then I used you ENCODE_3D_MOVIE.avs:

LoadPlugin("C:\Stereoplayer\DirectShowMVCSource.dll")
DirectShowMVCSource("c:\Stereoplayer\00000.ssif", seek=false, seekzero=true, stf=14) # 14 = SBS
AssumeFPS("ntsc_film")

File 00000.ssif was about 1 minute, but it doesn't change a principle.

Then I ran command

FRIMEncode.exe mvc -avi -sbs 2 -i ENCODE_3D_MOVIE.avs -viewoutput -o TEST_L.h264 -o TEST_R.h264 -cbr 40000

And two files TEST_L.h264, TEST_R.h264 were correctly created.

So, I don't see any problem here...

[HWK]

@HWK
@frencher

Guys,

I copied HWK's package into directory C:\Stereoplayer,
then I used you ENCODE_3D_MOVIE.avs:

LoadPlugin("C:\Stereoplayer\DirectShowMVCSource.dll")
DirectShowMVCSource("c:\Stereoplayer\00000.ssif", seek=false, seekzero=true, stf=14) # 14 = SBS
AssumeFPS("ntsc_film")

File 00000.ssif was about 1 minute, but it doesn't change a principle.

Then I ran command

FRIMEncode.exe mvc -avi -sbs 2 -i ENCODE_3D_MOVIE.avs -viewoutput -o TEST_L.h264 -o TEST_R.h264 -cbr 40000

And two files TEST_L.h264, TEST_R.h264 were correctly created.

So, I don't see any problem here...

Ok I will try again and see what happens.

Apparently it still doesn't work for me. Thanks for trying I think I will use previous mvc encoder I have.

[Cedvano]

Works fine for me.
Thank you very much videofan3D.

[Sharc]

Apparently it still doesn't work for me. Thanks for trying I think I will use previous mvc encoder I have.
Don't give up! DirectShowMVCSource works here as well. I'll post details later today ....

Edit:
Oooops! It runs for some time (few thousand frames), then FRIMencode crashes with the error
M_Alloc; error allocing 4552128
Doing more tests .....

Edit2:
Encoding a 2 hours movie with named pipes worked flawlessly and was reasonably fast.
Interesting that the original had a file size ratio dependent/base = 0.304 (which is exceptionally low, more typical ratios seem to be around 0.5), while after encoding with FRIMenocde this ratio became 0.83.

[HWK]

Don't give up! DirectShowMVCSource works here as well. I'll post details later today ....

That would be helpful, Although I own mainconcept mvc encoder but I want to help improve this as well.

In the mean time I would also try using ssif file decoder as well which doesn't rely on directshowmvcsource to decode file.

[colinhunt]

Workflow:
1. Rip the 3DBD to .iso
2. Mount the .iso
3. Start tsMuxeR and open the *.ssif (usually the largest for the movie)
4. Select the wanted tracks and demux with tsMuxeR
=> You will get the elementary files for the base view *.264, dependent view *.mvc, and the selected audio and sup files.
5. Now encode the video files with FRIMTools
6. Start tsMuxeR, open the video files from 5., add the audio and sup files from 4., select as output Blu-ray ISO, and start muxing ...
7. Burn the .iso
Awesome answer, thank you Sharc!

[Cedvano]

It's strange, I have 1 additional frame in the MVC file when I encode.

Edit: Work if Demuxing with eac3to.


Workflow:
1. Rip the 3DBD to .iso
2. Mount the .iso
3. Start tsMuxeR and open the *.ssif (usually the largest for the movie)
4. Select the wanted tracks and demux with eac3to
=> You will get the elementary files for the base view *.264, dependent view *.mvc, and the selected audio and sup files.
5. Now encode the video files with FRIMTools
6. Start tsMuxeR, open the video files from 5., add the audio and sup files from 4., select as output Blu-ray ISO, and start muxing ...
7. Burn the .iso

[frencher]

@HWK
@frencher

Guys,

I copied HWK's package into directory C:\Stereoplayer,
then I used you ENCODE_3D_MOVIE.avs:

LoadPlugin("C:\Stereoplayer\DirectShowMVCSource.dll")
DirectShowMVCSource("c:\Stereoplayer\00000.ssif", seek=false, seekzero=true, stf=14) # 14 = SBS
AssumeFPS("ntsc_film")

File 00000.ssif was about 1 minute, but it doesn't change a principle.

Then I ran command

FRIMEncode.exe mvc -avi -sbs 2 -i ENCODE_3D_MOVIE.avs -viewoutput -o TEST_L.h264 -o TEST_R.h264 -cbr 40000

And two files TEST_L.h264, TEST_R.h264 were correctly created.

So, I don't see any problem here...

@videofan3d

1 minute is too short for view from AVS problem
I have upload full video demo and log report with 266804 total frames (AVC/MVC from "MVCcombined.264")
Download:
FRIMDecode YUV FRIMEncode - VS - From AVS Script.rar (http://ul.to/k4q11xt8)
Watch FRIMDecode YUV FRIMEncode - VS - From AVS Script.mkv (include into package) before explore folder and report :logfile:

Low CPU Usage for recode, it's possible to add CPU optimisation ? x264x64 use 100% of my CPU (i7 3930k)
http://i42.tinypic.com/4j6kjk.png

Thanks for your bigest works ;)

[Sharc]

It's strange, I have 1 additional frame in the MVC file when I encode.

Edit: Work if Demuxing with eac3to.
Strange; should perhaps be reported to physic.
What is the consequence of the 1 frame difference? Does the encoding fail?

[Cedvano]

Strange; should perhaps be reported to physic.
What is the consequence of the 1 frame difference? Does the encoding fail?

No fail in encoding, but black screen with the TsMuxeR ISO.

[Sharc]

No fail in encoding, but black screen with the TsMuxeR ISO.
I haven't seen this happening in my tests yet.... :confused:

[videofan3d]

demux SSIF via tsMuxeR 2.1.6
1. MVC combined, use the utility http://forum.doom9.org/showthread.php?p=1628058#post1628058 files are the same
2. MVC separate, demux SSIF via tsMuxeR 2.1.6 http://i.imgur.com/haAbf6b.png

if demux with eac3to playlist, all right, files are the same
eac3to probably adds at the end of an empty frame

I also realized this symptom on one .ssif file.
(Not sure if problem is in .ssif itself, or in combining AVC+MVC, or in FRIM Decoder).
This I need to investigate...

[videofan3d]

@videofan3d

1 minute is too short for view from AVS problem
I have upload full video demo and log report with 266804 total frames (AVC/MVC from "MVCcombined.264")
Download:
FRIMDecode YUV FRIMEncode - VS - From AVS Script.rar (http://ul.to/k4q11xt8)
Watch FRIMDecode YUV FRIMEncode - VS - From AVS Script.mkv (include into package) before explore folder and report :logfile:


Friends,

I have looked to your issue with DirectShowMVCSource.dll in debugging mode.
And very clearly - problem is in DirectShowMVCSource itself.

Let me shortly describe you how FRIM Encoder works.

FRIM Encoder opens and read avi file using VWF (Video For Windows) API - which is standard part of Windows from version 3.x.
Avisynth script "input.avs" behaves like regular AVI and is for FRIM Encoder fully transparent.

Once FRIM Encoder opens succesfully avs-script (~avi-file), it reads it frame by frame, and undelaying Avisynth driver does all operations described in the script on background (it is its responsibility).

Now specifically:

@HWK:
In you case, when FRIM Encoder tries to open ENCODE_3D_MOVIE.avs, this operation fails because Avisynth cannot initialize CoreAVCDecoder.dll.
It is probably because you are running process from another directory.

When I put everything into one directory and ran it within this directory, all worked.
Once I moved FRIMEncode.exe into another, or started batch file from outside this directory, underlaying Avisynth could not
initialize CoreAVCDecoder.dll and opening failed - consequently FRIM Encoder reported "Cannot read YUV420 frame". Setting PATH properly could help.

@frencher:
In your case - problem with lost R-eye is caused by the DirectShowMVCSource.dll itself - apparently there is some bug.

FRIM Encoder reads frame from VFW-AVI, but it doesn't know what is hidden behind it.
VFW-API function AVIStreamGetFrame() simply returns full frame (3840x1080 in your case)

If right-eye is black, then it means that SsifSource3 in your .avs script didn't return data correctly

File1 = "Q:\BDMV\STREAM\SSIF\00000.ssif;0"
Left1 = SsifSource3(File1,avc_view=TRUE,mvc_view=FALSE)
Right1 = SsifSource3(File1)
Video1 = StackHorizontal(Left1,Right1)
Video = Video1
Video = Video.ConvertToYV12()
Return Video

I expect that the same symptom you will realize when you open and play Preview.avs using Windows Media Player, StereoscopicPlayer, MPC-HC
or any other player which uses the same VFW-API.

Library DirectShowMVCSource.dll is not official part of Windows, neither provided by any HW vendor.
I don't know who is author of DirectShowMVCSource.dll and how does he support it.
In the associated readme.txt he himself admits, that
"... this as an hack to the original DirectShowSource source code with possible bugs, maybe memory leaks... "
So, I recommend to approach author to investigate and fix...

[HWK]

Friends,

I have looked to your issue with DirectShowMVCSource.dll in debugging mode.
And very clearly - problem is in DirectShowMVCSource itself.

Let me shortly describe you how FRIM Encoder works.

FRIM Encoder opens and read avi file using VWF (Video For Windows) API - which is standard part of Windows from version 3.x.
Avisynth script "input.avs" behaves like regular AVI and is for FRIM Encoder fully transparent.

Once FRIM Encoder opens succesfully avs-script (~avi-file), it reads it frame by frame, and undelaying Avisynth driver does all operations described in the script on background (it is its responsibility).

Now specifically:

@HWK:
In you case, when FRIM Encoder tries to open ENCODE_3D_MOVIE.avs, this operation fails because Avisynth cannot initialize CoreAVCDecoder.dll.
It is probably because you are running process from another directory.

I think this is related to Frim application and it causes problem with this program only. I use virtualdub and other application and it works fine and can figure out number of frames with no problem.

Also calling application must be inside magic path, which is "STEREOPLAYER.exe" folder in this case.

When I put everything into one directory and ran it within this directory, all worked.
Once I moved FRIMEncode.exe into another, or started batch file from outside this directory, underlaying Avisynth could not
initialize CoreAVCDecoder.dll and opening failed - consequently FRIM Encoder reported "Cannot read YUV420 frame". Setting PATH properly could help.

@frencher:
In your case - problem with lost R-eye is caused by the DirectShowMVCSource.dll itself - apparently there is some bug.

FRIM Encoder reads frame from VFW-AVI, but it doesn't know what is hidden behind it.
VFW-API function AVIStreamGetFrame() simply returns full frame (3840x1080 in your case)

If right-eye is black, then it means that SsifSource3 in your .avs script didn't return data correctly

File1 = "Q:\BDMV\STREAM\SSIF\00000.ssif;0"
Left1 = SsifSource3(File1,avc_view=TRUE,mvc_view=FALSE)
Right1 = SsifSource3(File1)
Video1 = StackHorizontal(Left1,Right1)
Video = Video1
Video = Video.ConvertToYV12()
Return Video

I expect that the same symptom you will realize when you open and play Preview.avs using Windows Media Player, StereoscopicPlayer, MPC-HC
or any other player which uses the same VFW-API.

Surprise it doesn't I have used players and encoders with SSIFSource3 and it works. Even X.264 encoder work with it and MPC-HC works for me as well.

Library DirectShowMVCSource.dll is not official part of Windows, neither provided by any HW vendor.
I don't know who is author of DirectShowMVCSource.dll and how does he support it.
In the associated readme.txt he himself admits, that
"... this as an hack to the original DirectShowSource source code with possible bugs, maybe memory leaks... "
So, I recommend to approach author to investigate and fix...

Original author is Peter Wimmer, however asking him to fix it is not an option. BTW he did update coreavcdecode.dll, however doing so prevent other program from using it. This version is last one which allows other application to call it as long "stereoplayer.exe" is in path of calling application.

[Sharc]

Just in case someone wants to ceck / improve DirectShowMVCSource.dll, here the download link (http://www.share-online.biz/dl/I3CQBCDMI5)including the source.

[videofan3d]

I think this is related to Frim application and it causes problem with this program only. I use virtualdub and other application and it works fine and can figure out number of frames with no problem.

Also calling application must be inside magic path, which is "STEREOPLAYER.exe" folder in this case.


Re. "VirtualDub and other applications" - each application starts within some environment (you as a user define this environment) and in this environment it needs to find all required components. Directly and also indirectly. This is how operating systems works.
Please give to FRIM Encoder such environment, that it can find all necessary components, in this case indirectly.

Next version of FRIM will have an option to display some error messages reported by AviSynth, this will allow you to see what is wrong in the underlaying avisynth script.

[videofan3d]

Original author is Peter Wimmer, however asking him to fix it is not an option. BTW he did update coreavcdecode.dll, however doing so prevent other program from using it. This version is last one which allows other application to call it as long "stereoplayer.exe" is in path of calling application.

Don't take me wrong :)

Please accept an axiom: Each and every program has bugs.

And in our particular case we are processing whole long chain of components

- source data
- avisynth script (=its functions written by whoever)
- avisynth driver
- Windows drivers (VFW, DirectShow)
- FRIM Encoder
- Intel Media SDK
- and user him/ser-self !

Each part HAS some bugs, some of them can be overcome in other part, some need to be fixed on proper place.

Number of bugs decrease by time and by support of vendor - but it never drops to zero :)
So never presume some applications to be bug-free.
Our SW world is too complex.

Just for fun: Oracle published statistics which shows that in average there is one bug on every 10 lines of code! (but it is another discussion belonging to different thread :D )

[Sharc]

Environment which works here:
- Put the FRIM package into a Directory, e.g. FRIM
- Create a subdirectory under FRIM with Name stereoplayer.exe which contains the corresponding files plus a copy of FRIMEncode.exe

Script directshowMVC.avs (in the FRIM Directory):
LoadPlugin("c:\..your path ...\FRIM\stereoplayer.exe\DirectShowMVCSource.dll")
V2=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\xxxxx.SSIF")
V1=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\xxxxx.SSIF",decodeleft=true)
StackHorizontal(V1,V2)
ConvertToYV12().AssumeFPS(24000,1001)
Command (in the FRIM Directory):
"C:\...your path....\FRIM\stereoplayer.exe\FRIMEncode.exe" mvc -avi -sbs 2 -i directshowMVC.avs -viewoutput -o Base.avc -o Dependent.mvc -w 1920 -h 1080 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O
(Watch the quotation marks "....")

But as I wrote before FRIMEncode crashes after few thousand frames with error:
M_Alloc; error allocing 4552128

[videofan3d]

FRIMEncode crashes after few thousand frames with error:
M_Alloc; error allocing 4552128

Could you provide me with full description of reported error?
Meaning: how EXACTLY does this error display? There was probably some info in which file/line of code it happened...
I need to simulate it first...

[Sharc]

Could you provide me with full description of reported error?
Meaning: how EXACTLY does this error display? There was probably some info in which file/line of code it happened...
I need to simulate it first...
This error message is actually all I get from the cmd console.

However, from the Windows log there is an indication that divX.dll is responsible. Translated from German:

Name of the faulty application: FRIMEncode.exe, Version: 0.0.0.0, Time stamp: 0x527b8642
Name of the faulty module: DivX.dll, Version: 6.9.2.26, Time stamp: 0x4b7ee5fa
Exception code: 0xc0000005
Error offset: 0x00118a05
ID of the faulty process: 0x15cc
Start time of the faulty application: 0x01cedd26bf27d9c1
Path of the faulty application: C:\Program Files Video\FRIM\stereoplayer.exe\FRIMEncode.exe
Path of the faulty module: C:\Windows\system32\DivX.dll

Why gets DivX.dll involved at all?

Update 1:
I uninstalled DivX, now everything seems to work as expected ..... no crash ..... continuing testing .....
(I had DivX on my system for trying their HEVC/h265 encoder)

Update 2:
Now I run into another problem: No crash, but after some 1000 frames the dependent output file silently stops to grow, and only the base view continues encoding/growing.
No error message, it happens silently.

I guess I stick to the named pipe variant which worked flawlessly for the entire 2:25 hours movie.

Update 3:
Amazing. After a couple of new attempts with the directshowMVCSource variant I am now at frame 100'000 without a problem..... a miracle or a mystery????

[nunub]

any gui for this encoder will be most welcome to test.

[HWK]

Don't take me wrong :)

Please accept an axiom: Each and every program has bugs.

And in our particular case we are processing whole long chain of components

- source data
- avisynth script (=its functions written by whoever)
- avisynth driver
- Windows drivers (VFW, DirectShow)
- FRIM Encoder
- Intel Media SDK
- and user him/ser-self !

Each part HAS some bugs, some of them can be overcome in other part, some need to be fixed on proper place.

Number of bugs decrease by time and by support of vendor - but it never drops to zero :)
So never presume some applications to be bug-free.
Our SW world is too complex.

Just for fun: Oracle published statistics which shows that in average there is one bug on every 10 lines of code! (but it is another discussion belonging to different thread :D )

I am not taking you wrong at all. In fact I fully support you in first place since you bold enough to at least compile encoder and I know it will have bugs.

[HWK]

Environment which works here:
- Put the FRIM package into a Directory, e.g. FRIM
- Create a subdirectory under FRIM with Name stereoplayer.exe which contains the corresponding files plus a copy of FRIMEncode.exe

Script directshowMVC.avs (in the FRIM Directory):
LoadPlugin("c:\..your path ...\FRIM\stereoplayer.exe\DirectShowMVCSource.dll")
V2=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\xxxxx.SSIF")
V1=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\xxxxx.SSIF",decodeleft=true)
StackHorizontal(V1,V2)
ConvertToYV12().AssumeFPS(24000,1001)
Command (in the FRIM Directory):
"C:\...your path....\FRIM\stereoplayer.exe\FRIMEncode.exe" mvc -avi -sbs 2 -i directshowMVC.avs -viewoutput -o Base.avc -o Dependent.mvc -w 1920 -h 1080 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O
(Watch the quotation marks "....")

But as I wrote before FRIMEncode crashes after few thousand frames with error:
M_Alloc; error allocing 4552128

I will give this method a try and see how it goes.

[colinhunt]

Any chance I could use the Intel HD 4000 GPU of the i7-3770K to run encodes?

[videofan3d]

Any chance I could use the Intel HD 4000 GPU of the i7-3770K to run encodes?

In theory yes: option -hw

But you need to have proper HW library libmfxhw32.dll (which might be even HW dependent, I don't know).
I cannot test it cause I have nVidia GPU, not Intel GPU...

[colinhunt]

In theory yes: option -hw
But you need to have proper HW library libmfxhw32.dll (which might be even HW dependent, I don't know).
I cannot test it cause I have nVidia GPU, not Intel GPU...
Well, that didn't work:

ERROR: Cannot initialize Intel Media SDK session.
ERROR: Cannot start encoding process.

The dll is probably HW dependent, like you said. Any ideas where I could pick up the correct one?

update: Downloaded the latest drivers from Intel's website and installed them. They created a "Media SDK" directory under Program Files (i.e. 64bit), inside which I found a newer version of the dll (actually two, 32bit and 64bit dlls). Replaced the dll in FRIM directory with the new one, added -hw to both decoder and encoder options -- and it works. Both decoding and encoding are now running on HD4000.

I've got quality set to "-u 3" and the system did 1000 frames of decode/encode in 100 seconds.

[frencher]

@frencher:
In your case - problem with lost R-eye is caused by the DirectShowMVCSource.dll itself - apparently there is some bug.

FRIM Encoder reads frame from VFW-AVI, but it doesn't know what is hidden behind it.
VFW-API function AVIStreamGetFrame() simply returns full frame (3840x1080 in your case)

If right-eye is black, then it means that SsifSource3 in your .avs script didn't return data correctly

SsifSource3 have same black screen as DirectShowMVCSource with FRIMEncode (mplayer, x264, avstoavi, avstoyuv return corect right Stream), There would he no opportunity to fix the problem with the source code of avstoyuv ?

File1 = "Q:\BDMV\STREAM\SSIF\00000.ssif;0"
Left1 = SsifSource3(File1,avc_view=TRUE,mvc_view=FALSE)
Right1 = SsifSource3(File1)
Video1 = StackHorizontal(Left1,Right1)
Video = Video1
Video = Video.ConvertToYV12()
Return Video

I expect that the same symptom you will realize when you open and play Preview.avs using Windows Media Player, StereoscopicPlayer, MPC-HC
or any other player which uses the same VFW-API.
virtualdub not works with preview.avs for me - Works with magic path sorry
If possible, If you could take a look :p

Thank

[colinhunt]

Ehh, I thought I was being clever by trying to run 2 encodes simultaneously. Decode/encode on HW uses less than 50% CPU so I thought I'll run another encode on the side, on software only. Turns out that can't be done: piping throws up an error message.

[Cedvano]

Where I can find SSifsource3, please.

Thanks

[Sharc]

Where I can find SSifsource3, please.

Thanks
Here, author is slavanap:

http://forum.doom9.org/showpost.php?p=1630916&postcount=1353

and check for possibly newer posts by slavanap in the same thread.

Edit:
The file seems to have been withdrawn ..... Not sure if the .dll is still maintained. You may want to PM the author slavanap.
ssifsource2 can be found in frencher's MVC Player free package, or in the Tools folder of rOIz's BD3D2MK3D.

[videofan3d]

Ehh, I thought I was being clever by trying to run 2 encodes simultaneously. Decode/encode on HW uses less than 50% CPU so I thought I'll run another encode on the side, on software only. Turns out that can't be done: piping throws up an error message.

Pipename is like filename, i.e. it must be unique on your computer :-)

Try to set different pipename for each session...

[colinhunt]

Pipename is like filename, i.e. it must be unique on your computer :-)
Try to set different pipename for each session...
I did, didn't help.

.bat file:
start FRIMDecode.exe mvc -i left.264 -i right.mvc -o \\.\pipe\XMAS.yuv | FRIMEncode.exe mvc -i \\.\pipe\XMAS_L.yuv -i \\.\pipe\XMAS_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -f 23.976 -l 4 -cpbsize 3750 -vbr 34000 40000 -u 1 -profile high -level 4.1 -gop 24 4 0 O

result:
Return on error: error code -15, .\src\pipeline_encode.cpp 1174
Return on error: error code -15, .\src\pipeline_encode.cpp 1102
ERROR: Cannot start encoding process.

Currently running pipe is named simply "TMP".

[colinhunt]

This is kinda interesting: according to Intel's documentation, Look-ahead Bitrate Control (option -labrc instead of -vbr) requires a 4th generation Intel GPU, such as the HD4200 on some Haswell CPUs. I'm running a i7-3770K Ivy Bridge with a HD4000 on it, but the currently running job reports:

Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control LA
bitrate 24000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 4
Target usage 1 (quality)

So it appears to be running in Look-ahead mode, exactly as the job was configured for. It'll be interesting to see what comes out the other end once the job completes.

[Cedvano]

Here, author is slavanap:

http://forum.doom9.org/showpost.php?p=1630916&postcount=1353

and check for possibly newer posts by slavanap in the same thread.

Edit:
The file seems to have been withdrawn ..... Not sure if the .dll is still maintained. You may want to PM the author slavanap.
ssifsource2 can be found in frencher's MVC Player free package, or in the Tools folder of rOIz's BD3D2MK3D.

Thank you, I try with Ssifsource2.

I don't understand, after Encoding with FRIMEncode, the number of frames between the 2 files is different.
Someone have the same problem ?

[videofan3d]

I did, didn't help.

.bat file:
start FRIMDecode.exe mvc -i left.264 -i right.mvc -o \\.\pipe\XMAS.yuv | FRIMEncode.exe mvc -i \\.\pipe\XMAS_L.yuv -i \\.\pipe\XMAS_R.yuv -viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -f 23.976 -l 4 -cpbsize 3750 -vbr 34000 40000 -u 1 -profile high -level 4.1 -gop 24 4 0 O

result:
Return on error: error code -15, .\src\pipeline_encode.cpp 1174
Return on error: error code -15, .\src\pipeline_encode.cpp 1102
ERROR: Cannot start encoding process.

Currently running pipe is named simply "TMP".

This error code -15 means that Media core function MFXVideoENCODE_Init() cannot initialize some parameters.

I ran two sessions (in two cmd.exe) in parallel in -sw mode. Successfully!
So maybe there is some restriction of -hw mode...

[Cedvano]

videofan3d

1. I use eac3to to extract left and right
2. I use FRIMDecode and FRIMencode with pipe for convert
-> Result wrong files because wrong YUV

1. I use eac3to and CombineMVC with pipe for 1 file
2. I use FRIMDecode and FRIMencode with pipe to convert
-> Result good file

Can you correct FRIMDecode for the first soluce ?

Thanks

[videofan3d]

videofan3d

1. I use eac3to to extract left and right
2. I use FRIMDecode and FRIMencode with pipe for convert
-> Result wrong files because wrong YUV

1. I use eac3to and CombineMVC with pipe for 1 file
2. I use FRIMDecode and FRIMencode with pipe to convert
-> Result good file

Can you correct FRIMDecode for the first soluce ?

Thanks

Could you give examples of a 3D-movies when it happens?
I need to reproduce it.

[Cedvano]

If you got The Lion King BD3D, you can test with 278 or 234 SSIF.
I upload 240 and share the link.

[colinhunt]

FYI, HD4000 hardware decode + hardware encode + Look-ahead bitrate control = GARBAGE.

[Cedvano]

Here the link : 00278.ssif (http://ns5.freeheberg.com/~cedvano/00278.ssif)

[tymoxa]

1. I use eac3to to extract left and right
2. I use FRIMDecode and FRIMencode with pipe for convert
-> Result wrong files because wrong YUV


It's OK for me with this scheme and your sample:
http://savepic.ru/4817123m.jpg (http://savepic.ru/4817123.jpg)

Try this line:
FRIMDecode mvc -i input_L.h264 -i input_R.h264 -o \\.\pipe\test.yuv | FRIMEncode.exe mvc -i \\.\pipe\test_L.yuv -i \\.\pipe\test_R.yuv -viewoutput -o output.avc -o output.mvc -w 1920 -h 1080 -f 23.976 -u 4 -cpbsize 3570 -vbr 30000 40000 -l 6 -profile high -level 4.1 -gop 24 4 0 O

[Cedvano]

With this line, I've the same problem.

Have you compare the YUV files.

It's not all the ssif, I wait for more tests.

[videofan3d]

videofan3d

1. I use eac3to to extract left and right
2. I use FRIMDecode and FRIMencode with pipe for convert
-> Result wrong files because wrong YUV-length

1. I use eac3to and CombineMVC with pipe for 1 file
2. I use FRIMDecode and FRIMencode with pipe to convert
-> Result good file - both L- and R-yuv are of the same length

Can you correct FRIMDecode for the first soluce ?

Thanks

Hi, problem is identified, fix is in progress.

Next release FRIM 1.15 will be available on ~Thursday

[Cedvano]

Hi, problem is identified, fix is in progress.

Next release FRIM 1.15 will be available on ~Thursday

Yes, great ! Thanks.

[videofan3d]

HD4000 hardware decode + hardware encode .

Would be interesting to see if -sw and -hw give the same results. I.e. to encode very short video with the same conditions (bitrate, GOP, slices, ...) using -hw and then -sw.
@colinhunt: Could you conclude such test? ;)

[colinhunt]

Would be interesting to see if -sw and -hw give the same results. I.e. to encode very short video with the same conditions (bitrate, GOP, slices, ...) using -hw and then -sw.
Could you conclude such test? ;)
I actually ran a few tests to see why I got terrible encodes out of using the -hw option. Turns out the output is total garbage if Decoder uses -hw. Encoder can use either -vbr or -labrc with -hw, and the output is fine as long as decoding is done in software. I can run more tests if you give me a list of what you'd like to see.

[videofan3d]

I actually ran a few tests to see why I got terrible encodes out of using the -hw option. Turns out the output is total garbage if Decoder uses -hw. Encoder can use either -vbr or -labrc with -hw, and the output is fine as long as decoding is done in software. I can run more tests if you give me a list of what you'd like to see.

This is interesting - and strange.
Decoding is much simpler than encoding, and I'd expect to get the same results, the same YUV file for both -sw and -hw, byte to byte identical!
(Btw, I compared Intel Media SW decoder output with JM H.264/AVC Reference Decoder from http://iphome.hhi.de/suehring/tml/, and they are really 100% identical - that's good)

For encoding - in theory - if GPU is given the same parameters as CPU, it should be also identical.
But I can imagine that GPU routines have different implementation than corresponding C-routines in SW mode. Which will lead to different DCT encoding and resulting .h264 videofile will be different (but visually it should be similar).

Would be nice (I believe interesting for everyone) if you could upload 10-20 second sample of HD video (~16 mbit) encoded with same parameters in -sw and -hw mode. :)

[colinhunt]

Would be nice (I believe interesting for everyone) if you could upload 10-20 second sample of HD video (~16 mbit) encoded with same parameters in -sw and -hw mode. :)
I will, once I've cleared my current workload. It'll be a few days.

[videofan3d]

Hi,

FRIM 1.15 is available.

Changes:

FRIM Encoder 1.15
- avi/avs encoding - reports now a bit more detailed error information.
- new feature: CQP bitrate control mode added: [ -cqp QPI QPP QPB ]

FRIM Decoder 1.15
- fixed bug with wrong YUV-file length of decoded MVC
- new feature: MVC - both output filenames (L,R) can be specified by user

FRIM Transcoder 1.15
- added detailed parameters/options like in FRIM Encode (!)
- added base+dependent input for MVC

[tymoxa]

videofan3d
Thanks a lot!
Is possible to limit maximum bitrate in CQP mode? Like:
-cqp QPI QPP QPB maxrate

[Sharc]

Hi,

FRIM 1.15 is available.

Changes:

FRIM Encoder 1.15
- avi/avs encoding - reports now a bit more detailed error information.
- new feature: CQP bitrate control mode added: [ -cqp QPI QPP QPB ]

FRIM Decoder 1.15
- fixed bug with wrong YUV-file length of decoded MVC
- new feature: MVC - both output filenames (L,R) can be specified by user

FRIM Transcoder 1.15
- added detailed parameters/options like in FRIM Encode (!)
- added base+dependent input for MVC

Wow! :thanks:

[frencher]

Hi,

FRIM 1.15 is available.

Changes:

FRIM Encoder 1.15
- avi/avs encoding - reports now a bit more detailed error information.
- new feature: CQP bitrate control mode added: [ -cqp QPI QPP QPB ]

FRIM Decoder 1.15
- fixed bug with wrong YUV-file length of decoded MVC
- new feature: MVC - both output filenames (L,R) can be specified by user

FRIM Transcoder 1.15
- added detailed parameters/options like in FRIM Encode (!)
- added base+dependent input for MVC

Yeah, very nice update videofan3d ;)

One idea of CMD Line for use avstoyuv with FRIMEncode:
avs2yuv.exe (Script.avs) > FRIMEncode.exe

Same problem of black frames with (Left.mkv and Right.mkv = AVC) idea :confused:
L = DirectShowSource("H:\Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("H:\Right.mkv", audio=FALSE, video=TRUE)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V

[videofan3d]

Same problem of black frames with (Left.mkv and Right.mkv = AVC) idea :confused:
L = DirectShowSource("H:\Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("H:\Right.mkv", audio=FALSE, video=TRUE)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V

Please try to modify your script:

L = DirectShowSource("H:\Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("H:\Right.mkv", audio=FALSE, video=TRUE)
L=ShowSMPTE(L,size=100)
R=ShowSMPTE(R,size=100)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V

What do you see on output?

[Cedvano]

Thank you very much Videofan3d.

Edit: FRIMTRanscode does not support Pipe ?

[videofan3d]

FRIMTRanscode does not support Pipe ?

No. Core Intel Media routines read video-bitstream twice (for header detection, and then for processing itself). This disables using pipes which are unidirectional by their nature.

Neither FRIMDecode cannot have pipe on its input, and FRIMEncode on its output.

[videofan3d]

Btw. named pipes can be used also on local network between computers. In principle you could use:

Computer 1 named e.g. comp001:

FRIMDecode h264 -i input.h264 -o \\.\pipe\pipeA


and then start on Computer 2 another session:

FRIMEncode h264 -i \\comp001\pipe\pipeA -o output.h264



(I couldn't test it having no network at home...)

[frencher]

Please try to modify your script:

L = DirectShowSource("H:\Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("H:\Right.mkv", audio=FALSE, video=TRUE)
L=ShowSMPTE(L,size=100)
R=ShowSMPTE(R,size=100)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V

What do you see on output?

Hi videofan3d,

I have tested your version 1.15 with AVS:
L = DirectShowSource("Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("Right.mkv", audio=FALSE, video=TRUE)
L = ShowSMPTE(L,size=100).ShowFrameNumber(x=50,y=80,size=30)
R = ShowSMPTE(R,size=100).ShowFrameNumber(x=50,y=80,size=30)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V
and
"FRIMEncode.exe" mvc -i "3D.AVS" -avi -sbs 2 -viewoutput -o "H:\L.h264" -o "H:\R.h264" -w 1920 -h 1080 -f 23.976 -b 40000 -u 7

Here is what gives me FRIMencode and x264 with same AVS script

Download: FRIMEncode VS x264.rar (http://ul.to/zwlh1jsc)

Thanks for works and interest ;)

[videofan3d]

Hi videofan3d,

I have tested your version 1.15 with AVS:
...
L = ShowSMPTE(L,size=100).ShowFrameNumber(x=50,y=80,size=30)
R = ShowSMPTE(R,size=100).ShowFrameNumber(x=50,y=80,size=30)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V



This is strange - I don't understand it.

In parallel I created and encoded a synthetic clip using FRIM Encode 1.15 a with length 20 (!) minutes:


ClipLength=28800
L=Blankclip (length=ClipLength, width=1920, height=1080, fps=23.976, color=16711680)
R=Blankclip (length=ClipLength, width=1920, height=1080, fps=23.976, color=255)
L=ShowSMPTE(L)
R=ShowSMPTE(R)
StackHorizontal(L,R)
ConvertToYV12()


... and succesfully - no glitch on left nor right eye.
I'm using Avisynth version 2.60 (alpha "whatever") - because of ffmpeg 2.1

Please try to arrange the same test - I'd like to understand where is problem...

[frencher]

This is strange - I don't understand it.

In parallel I created and encoded a synthetic clip using FRIM Encode 1.15 a with length 20 (!) minutes:


ClipLength=28800
L=Blankclip (length=ClipLength, width=1920, height=1080, fps=23.976, color=16711680)
R=Blankclip (length=ClipLength, width=1920, height=1080, fps=23.976, color=255)
L=ShowSMPTE(L)
R=ShowSMPTE(R)
StackHorizontal(L,R)
ConvertToYV12()


... and succesfully - no glitch on left nor right eye.
I'm using Avisynth version 2.60 (alpha "whatever") - because of ffmpeg 2.1

Please try to arrange the same test - I'd like to understand where is problem...

FIXED
Avisynth 2.5.8 stable version have some problem with YUV.
Now fixed with AviSynth 13-09-18 2.6.0 Alpha 5 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) works perfectly. :cool:
I recode full lenght of large video for test :rolleyes:

It's possible to add x frame of total frame, remaining time, percentage, etc... ?

Thanls for your big works.

[HWK]

FIXED
Avisynth 2.5.8 stable version have some problem with YUV.
Now fixed with AviSynth 13-09-18 2.6.0 Alpha 5 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) works perfectly. :cool:
I recode full lenght of large video for test :rolleyes:

It's possible to add x frame of total frame, remaining time, percentage, etc... ?

Thanls for your big works.

It's kind of funny I had same problem when I used avisynth, color info in yuv file was messed up. However when I used raw yuv file it worked without any issues. I also tried with pipe and it worked as well. Only thing i notice is vbr go too much under size. I have to do more checking on that.

To conclude I would like to say thank you to videofan3d and Intel for making it possible for the masses and off course to those who find bugs in program.

[videofan3d]

FIXED
Avisynth 2.5.8 stable version have some problem with YUV.
Now fixed with AviSynth 13-09-18 2.6.0 Alpha 5 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) works perfectly. :cool:


Apparently it is some bug in Avisynth or VFW API (or both in coincidence).

Anyway, I'll try to workaround it by slightly different reading of AVI/AVS in 3D mode. In next release....

[Cedvano]

FRIMTranscode can output 2 separates files ? If no, can you put this function ?
Thanks for your answer.

[frencher]

Apparently it is some bug in Avisynth or VFW API (or both in coincidence).

Anyway, I'll try to workaround it by slightly different reading of AVI/AVS in 3D mode. In next release....

Very good news :thanks:

[videofan3d]

FRIMTranscode can output 2 separates files ? If no, can you put this function ?
Thanks for your answer.

Not at this moment.
But tsMuxer 2.1.8 already accepts combined AVC+MVC, so it is not any practical limitation.

[Cedvano]

Not at this moment.
But tsMuxer 2.1.8 already accepts combined AVC+MVC, so it is not any practical limitation.

Yes, but you think that the same quality ?
And for the frame number, how work the "point" ?

[videofan3d]

Yes, but you think that the same quality ?
And for the frame number, how work the "point" ?

Not sure I understand your question.

tsMuxer is only multiplexing elementary streams, without modifying it. No impact to "quality".
combined AVC+MVC is only "mixed" separated AVC and MVC, technically shuffled "NAL units" in certain sequence.
It doesn't matter if you will mux BD-structure from separated AVC and MVC, or from combined AVC+MVC. result is the same. You can easily test it.

[Cedvano]

Thanks for your answer, I thought it was best to go through YUV. After which testing is the same.

I only regret that displays "points" instead of the number of frames.

[videofan3d]

I only regret that displays "points" instead of the number of frames.

FRIM Transcoder operates in multisession (which is in general independednt multi-processing), thus number of frames is not relevant, each session is different.... (and one small hint: each dot is 100 encoded frames ;) )

Btw. multisession via -o::sink and -i::source is great for bitrate quality comparison. You can create several outputs with different bitrate or gop structure in one batch and then easily compare results.

[trevorjharris]

Cannot get it to work with the latest version of avisynth.

"Cannot get YUV420 frame from input avi-file input.avs"

yuv raw files work fine

[frencher]

Cannot get it to work with the latest version of avisynth.

"Cannot get YUV420 frame from input avi-file input.avs"

yuv raw files work fine

FIXED
Avisynth 2.5.8 stable version have some problem with YUV.
Now fixed with AviSynth 13-09-18 2.6.0 Alpha 5 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) works perfectly. :cool:
Try this

[HWK]

videofan3d, this is my second time and I noticed VBR algorithm undersize files as much as 40 % and I am using pacific rim as a example. While I expected file size to be 18GB+, it was around 10 GB or so for both stream. I have provided command line and specify bitrate in Kbit/s

FRIMDecode mvc -i 00098.track_4113.264 -i 00098.track_4114.mvc -o \\.\pipe\test.yuv | FRIMEncode.exe mvc -i \\.\pipe\test_L.yuv -i \\.\pipe\test_R.yuv -viewoutput -o Pacific_Rim_AVC.264 -o Pacific_Rim_MVC.264 -w 1920 -h 1080 -f 23.976 -u 1 -cpbsize 3570 -l 6 -vbr 19540 60000 -profile high -level 4.1 -gop 24 4 0 S -maxdpb 4

[update1]

I decided redo and change bitrate to 28000, after about 55% done (calculate from number of frames done, from total frames) total size is 7.10 GB for both stream.

[Cedvano]

videofan3d, this is my second time and I noticed VBR algorithm undersize files as much as 40 % and I am using pacific rim as a example. While I expected file size to be 18GB+, it was around 10 GB or so for both stream. I have provided command line and specify bitrate in Kbit/s



[update1]

I decided redo and change bitrate to 28000, after about 55% done (calculate from number of frames done, from total frames) total size is 7.10 GB for both stream.

Me, I have see increase size with version 1.15.

Can I have your calcul for Bitrate ?

[HWK]

Me, I have see increase size with version 1.15.

Can I have your calcul for Bitrate ?

I think I have figured out my problem, It has to do with Kilobytes and kilobits. When calculating for disc use Kilobytes, which I didn't. Where encoder wants them in Kbit/s dumb error.

Spoke to soon, error is still there, but I think I have manged to get bottom of this and that is encoder help fine need some work, instead kilobits unit it expect bit-rate to be in Kilobytes. When I enter 60000 KBps (kilobytes per second) media info report correctly about max bitrate for combine avc and mvc to be 60 MBps (megabytes per second) which can be confirmed by reading values from original and another mvc encoder.

FRIM Encoder version 1.15 (build: Nov 12 2013)
- based on Intel(R) Media SDK (version: 4.0.760.60435)

Usage:

FRIMEncode mpeg2|h264|mvc|jpeg [options]
-i InputFile -o OutputBS

options:

-avi - input file is in AVI format,
if not specified then YUV is expected
-sbs|tab numViews - input file is in side-by-side or top-above-below
format, valid only for multiview
-w width - source picture width (one view), mandatory for YUV
-h height - source picture height (one view), mandatory for YUV
-f frameRate - video frame rate (frames per second)

-cbr|b bitRate - CBR mode (in Kbits/s)
-vbr bitRate maxRate - VBR mode (in Kbits/s)
-cqp QPI QPP QPB - CQP mode
QPx quantization parameters for I,P,B frames
QPx in range [0,51]
-labrc bitRate depth - LA BRC mode (in Kbits/s) for H.264 encoder
look ahead depth, in range [10,100] or 0(=auto),
number of frames to be analyzed before encoding
Supported only with -hw option on 4th Generation
on Intel Core processors
bit rate is valid for H.264, MPEG2 and MVC
-cpbsize size - cpb/vbv buffer size (in KB)
max 3750 for H.264 Blu-ray
max 1194 for MPEG2 Blu-ray

-tff|bff - input stream is interlaced, top|bottom field first,
if not specified then progressive is expected
-nv12 - input is in NV12 color format,
if not specified then YUV420 is expected
-u 1..7 - target usage: between 1(=quality) and 7(=speed),
default is 4(=balanced),
valid for H.264, MPEG2 and MVC
-q quality - quality parameter for JPEG,
in range [1,100], 100 is the best quality
-l numSlices - number of slices, default value 0

-profile profile - codec profile name
MPEG2: simple, main, high
H.264: baseline, main, high
-level level - codec level
MPEG2: low/LL, main/ML, high1440/H14, high/HL,
H.264: 1, 1b, 1.1, 1.2, 1.3,
2, 2.1, 2.2, 3, 3.1, 3.2,
4, 4.1, 4.2, 5, 5.1, 5.2
MVC: 4, 4.1, 4.2, 5, 5.1, 5.2

-gop gopLength gopDist idrInterval O|C|S
- GOP structure control
GOP length
(0=unspecified, 1=I-frame only, ...)
GOP distance between I- or P-frames
(0=unspecified, 1=no B-frames, ...)
IDR interval:
H.264: between I- and IDR-frames
(0=every I-frame is an IDR frame, ...)
MPEG2: sequence header interval
(0=once at beginning, 1=every I-frame, ...)
Opened, Closed, Strict ... GOP structure

-maxdpb numFrames - maximum number of frames buffered in a DPB
(Decoded Picture Buffer), default value 0(=unspecified)
-CAVLC|CABAC - use CAVLC or CABAC for encoding, default is CABAC
(for H.264 only)
-VuiNalHrd on|off - insert NAL HRD parameters into bitstream,
default value on (for H.264 only)
-VuiVclHrd on|off - insert VCL HRD parameters into bitstream,
default value on (for H.264 only)
-PicTimingSEI on|off - insert picture timing SEI with pic_struct syntax
element into bitstream,
default value on (for H.264 only)
-EndOfSequence on|off - insert End of Sequence NAL into bitstream,
default value on (for H.264 only)
-EndOfStream on|off - insert End of Stream NAL into bitstream,
default value off (for H.264 only)

-dstw width - destination picture width, invokes VPP resizing
-dsth height - destination picture height, invokes VPP resizing
-hw - use platform specific SDK implementation,
if not specified then software implementation is used
-d3d - work with d3d9 surfaces
-d3d11 - work with d3d11 surfaces

-viewoutput - instruct the MVC encoder to output each view
in separate bitstream buffer.
Depending on the number of '-o' options behaves as follows:

1: two views are encoded in single file
2: two views are encoded in separate files
3: behaves like two '-o' were used and then one '-o'
Example: FRIMEncode mvc
-i InputFile_L -i InputFile_R
-o OutputEncodedBase -o OutputEncodedDependent
-viewoutput -w width -h height



23.3 GB
Here are my calculation result

Subtitle + DTS 7.1 Audio = 2.82GB
Subtitle + DTS 7.1 Audio + Muxinng Overhead = 4.68

23.3 - 4.68 = 18.62 GB Video


2H, 11M, 17S video bit-rate = 20304kbps after factoring in overhead.

20304Kbps

I also tried higher and lower values for bit-rate, but for me it is doing undersize. For example I use 28000 on higher side along with 60000 max, where after 55% it is only 7.10GB for both stream and with default bit-rate of 19540 expected target size is 18.62GB combined.

[Sharc]

@HWK
in my maths:
18.62GB = 19'067MB = 19'524'485kB = 156'195'881kbit
video duration = 7'877 sec
156'195'881kbit/7'877sec = 19'829kbit/s

[HWK]

@HWK
in my maths:
18.62GB = 19'067MB = 19'524'485kB = 156'195'881kbit
video duration = 7'877 sec
156'195'881kbit/7'877sec = 19'829kbit/s

You are right, I just checked encoder values indeed correct (19540, leave some room for error) But text file where I put all the information some how manage to get higher number.

Still resize is an issue for me, I am still trying to figure out why.

[Cedvano]

It's strange, I don't have this problem. I use Bitrate Calculator GPL and All my video are correct. (with max bitrate 48000)

[Sharc]

Still resize is an issue for me, I am still trying to figure out why.
I don't know the details of the Intel encoder, but perhaps encoder saturation comes into play at these high bitrates?
I have not seen undersize for my (usually much lower) bitrates.

[HWK]

I don't know the details of the Intel encoder, but perhaps encoder saturation comes into play at these high bitrates?
I have not seen undersize for my (usually much lower) bitrates.

I am thinking you are right, I also have mainconcept MVC encoder and every time I encode with it, target size is reached. Also I set bitrate 30928Kbps, but during preview I notice it is averaging around 15 Mbps or so with change in bitrate much more drastic than other encoders and maybe this might explain what is happening.

After all it's doing in VBR so may be that is expected from encoder :cool:

[HWK]

It's strange, I don't have this problem. I use Bitrate Calculator GPL and All my video are correct. (with max bitrate 48000)

I use Bitrate Calculator GPL as well and for some reason things are different, well I guess change is good thing :D
Also you do know you can go up to 60000 max rate combined, I use all the time and encoder is smart enough to split bitrate correctly. For example base view bitrate never go above 40Mbps, peaks not included.

[trevorjharris]

Has anyone got this to work with asv. I tried AviSynth 13-09-18 2.6.0 Alpha 5 and it failed with

"Cannot get YUV420 frame from input avi-file input.avs"

[HWK]

Has anyone got this to work with asv. I tried AviSynth 13-09-18 2.6.0 Alpha 5 and it failed with

"Cannot get YUV420 frame from input avi-file input.avs"

It failed for me as well, I also tried with avisynth with 2.6.0 Alpha 5. I just use pipe and for me it works very well.

[HWK]

I don't know the details of the Intel encoder, but perhaps encoder saturation comes into play at these high bitrates?
I have not seen undersize for my (usually much lower) bitrates.

I re-ran test and I can confirm some kind of saturation is happening in my case. I expect final output to be around 29GB or higher. However when encoder finished it was just above 16GB for both files.

I encoded with bitrate 30298Kbps, with max at 60000Kbps. However bitrate scanner tell different story altogether.

Source: Pacific Rim

Currently, I am re-doing the test with average bitrate and max bitrate at same value and it is set to 60000Kbps. It would be interested to see what happens with output.

[Cedvano]

I've test with BRAVE and I would like 18GB and I have 16,2 GB.

[HWK]

I've test with BRAVE and I would like 18GB and I have 16,2 GB.

Thanks, for the result. Good to know I am not the only one. My guess VBR need some work and in my case difference is huge though.

[videofan3d]

Regarding bitrate:

parameters for -vbr and -cbr are passed to Intel Media libmfxsw32.dll library, which controls the whole encoding.

Intel documentation specifies that it is in Kbit/s, defined as unsigned 16-bit number, where 1 kbit means 1000 bits.

Regarding "underbitrating" for VBR: I can imagine why it happens.
Intel Media is single pass encoder. When you specify -vbr 16000 24000, it means that maximum bitrate is 24000 Kbit/s which can be easily controlled. But average 16000 Kbits/s is a bit complicated issue for encoder, because single pass encoder cannot predict complexity of the videoscene, it can only evaluate current frame or maybe current GOP. So to achieve overall VBR on given value 16000 Kbits/s is only best guess for it. Therefore encoder uses rather lower bitrate whenever possible in order to prevent potential excess in future more complex scenes. As result it may happen that overall average bitrate is lower than specified.

[HWK]

Regarding bitrate:

parameters for -vbr and -cbr are passed to Intel Media libmfxsw32.dll library, which controls the whole encoding.

Intel documentation specifies that it is in Kbit/s, defined as unsigned 16-bit number, where 1 kbit means 1000 bits.

Regarding "underbitrating" for VBR: I can imagine why it happens.
Intel Media is single pass encoder. When you specify -vbr 16000 24000, it means that maximum bitrate is 24000 Kbit/s which can be easily controlled. But average 16000 Kbits/s is a bit complicated issue for encoder, because single pass encoder cannot predict complexity of the videoscene, it can only evaluate current frame or maybe current GOP. So to achieve overall VBR on given value 16000 Kbits/s is only best guess for it. Therefore encoder uses rather lower bitrate whenever possible in order potential excess in future more complex scenes. As result it may happen that overall average bitrate is lower than specified.

I understand your point of view, but I use different mvc encoder and use one pass on that as well and it is able to meet target size. I can't complain it is certainly better to have two mvc encoder than one.

[update1]
I just finished encoding on 60000 bitrate and so far my findings are file size is half of projected. For example I expected to be around 56GB, but final turn out to be around 27 GB.

Solution for me double the bitrate for example if I want 1000, write 2000 in encoder file and my final output would be of 1000 Kbps. In the meantime I would also try few more disc as well and see if it is some kind of pattern which I can repeat.

[swallace]

@HWK

Just out of curiosity: does changing the GOP length, or leaving it at default, have any effect on the output bitrate?

[Sharc]

@videofan3d
In your documentation for the Encoder (which is very helpful and clear, thanks!) you write:
Please note, side‐by‐side Full HD 3D avi‐input has to have size 3840(!)x1080, however output
MVC‐encoded elementary streams will have standard size 1920x1080.
I just like to comment that input resolution of 2560x720 (-sbs 2) or 1280x1440 (tab 2) are accepted as well. MVC encoded elementary streams will then be 1280x720.

[HWK]

@HWK

Just out of curiosity: does changing the GOP length, or leaving it at default, have any effect on the output bitrate?

Yes, it does. If it is open gop it will increase compression efficiency and less bitrate is need to achieve same quality.

[HWK]

@videofan3d
In your documentation for the Encoder (which is very helpful and clear, thanks!) you write:
Please note, side‐by‐side Full HD 3D avi‐input has to have size 3840(!)x1080, however output
MVC‐encoded elementary streams will have standard size 1920x1080.
I just like to comment that input resolution of 2560x720 (-sbs 2) or 1280x1440 (tab 2) are accepted as well. MVC encoded elementary streams will then be 1280x720.

What is the frame rate of 1280x720, if it is 23.976 fps then it is violation of BD3D standard.

[Sharc]

What is the frame rate of 1280x720, if it is 23.976 fps then it is violation of BD3D standard.
Do you have the official BD3D specs? For BD2D 1280x720 progressive is compliant for 23.975, 24, 50, 59.94 fps.
Even if BD3D would be conflicting with 23.976 I would assume that most players won't care. Is your experience different?

[HWK]

Do you have the official BD3D specs? For BD2D 1280x720 progressive is compliant for 23.975, 24, 50, 59.94 fps.
Even if BD3D would be conflicting with 23.976 I would assume that most players won't care. Is your experience different?

59.94 will work fine and as well these formats anything else is hit and miss on players, but not official.

1920x1080x23.976-p
1280x720x59.94-p
1280x720x50-p
Secondary video SD
720x480x24-p, 23.976-p (4:3/16:9)
720x576x25-i (4:3/16:9)
---------------------------
1440x1080 not allowed under any type for 3D. Yes I do own the specs as well.

[HWK]

videofan3d, this is my second time and I noticed VBR algorithm undersize files as much as 40 % and I am using pacific rim as a example. While I expected file size to be 18GB+, it was around 10 GB or so for both stream. I have provided command line and specify bitrate in Kbit/s

[update1]

I decided redo and change bitrate to 28000, after about 55% done (calculate from number of frames done, from total frames) total size is 7.10 GB for both stream.

I think I have figured out my problem, It has to do with Kilobytes and kilobits. When calculating for disc use Kilobytes, which I didn't. Where encoder wants them in Kbit/s dumb error.

Spoke to soon, error is still there, but I think I have manged to get bottom of this and that is encoder help fine need some work, instead kilobits unit it expect bit-rate to be in Kilobytes. When I enter 60000 KBps (kilobytes per second) media info report correctly about max bitrate for combine avc and mvc to be 60 MBps (megabytes per second) which can be confirmed by reading values from original and another mvc encoder.

I also tried higher and lower values for bit-rate, but for me it is doing undersize. For example I use 28000 on higher side along with 60000 max, where after 55% it is only 7.10GB for both stream and with default bit-rate of 19540 expected target size is 18.62GB combined.

I re-ran test and I can confirm some kind of saturation is happening in my case. I expect final output to be around 29GB or higher. However when encoder finished it was just above 16GB for both files.

I encoded with bitrate 30298Kbps, with max at 60000Kbps. However bitrate scanner tell different story altogether.

Source: Pacific Rim

Currently, I am re-doing the test with average bitrate and max bitrate at same value and it is set to 60000Kbps. It would be interested to see what happens with output.

Thanks, for the result. Good to know I am not the only one. My guess VBR need some work and in my case difference is huge though.

Regarding bitrate:

parameters for -vbr and -cbr are passed to Intel Media libmfxsw32.dll library, which controls the whole encoding.

Intel documentation specifies that it is in Kbit/s, defined as unsigned 16-bit number, where 1 kbit means 1000 bits.

Regarding "underbitrating" for VBR: I can imagine why it happens.
Intel Media is single pass encoder. When you specify -vbr 16000 24000, it means that maximum bitrate is 24000 Kbit/s which can be easily controlled. But average 16000 Kbits/s is a bit complicated issue for encoder, because single pass encoder cannot predict complexity of the videoscene, it can only evaluate current frame or maybe current GOP. So to achieve overall VBR on given value 16000 Kbits/s is only best guess for it. Therefore encoder uses rather lower bitrate whenever possible in order to prevent potential excess in future more complex scenes. As result it may happen that overall average bitrate is lower than specified.

I understand your point of view, but I use different mvc encoder and use one pass on that as well and it is able to meet target size. I can't complain it is certainly better to have two mvc encoder than one.

[update1]
I just finished encoding on 60000 bitrate and so far my findings are file size is half of projected. For example I expected to be around 56GB, but final turn out to be around 27 GB.

Solution for me double the bitrate for example if I want 1000, write 2000 in encoder file and my final output would be of 1000 Kbps. In the meantime I would also try few more disc as well and see if it is some kind of pattern which I can repeat.

I finally figured out why I was having issues with size when doing VBR. It was not fault of encoder but mine instead :p Basically it is the workflow which I am using is issue over here.

[Cedvano]

You double the bitrate ?

[Sharc]

59.94 will work fine and as well these formats anything else is hit and miss on players, but not official.

1920x1080x23.976-p
1280x720x59.94-p
1280x720x50-p
Secondary video SD
720x480x24-p, 23.976-p (4:3/16:9)
720x576x25-i (4:3/16:9)
---------------------------
1440x1080 not allowed under any type for 3D. Yes I do own the specs as well.

So to be on the safe side for Blu-Ray compliance I would for 1280x720p 3D encodes have to add to the script:
ChangeFPS(60000,1001)
ConvertToYV12().AssumeFPS(60000,1001)
which adds judder, or resize the 720p source to FullHD (just bloating the picure)..... weird.

Added:
I was lucky in my case as the SBS source was 29.97fps, so the frames are just getting duplicated for 59.94, means no judder, and frame duplication should not produce too much overhead bitwise I assume.
Pulldown is not supported by FRIMEncode, right?

For 720p 23.976fps sources, speedup to 25 fps and subsequent frame duplication for 50fps could be a solution for BD3D compliance.

[HWK]

You double the bitrate ?

No, it was a script which for some odd reason cutting of movie around 50% sometime before 50% reached and sometime after 50% reached even for same movie.

I modified workflow and doing quick test run.

[jdobbs]

Has anyone got this to work with asv. I tried AviSynth 13-09-18 2.6.0 Alpha 5 and it failed with

"Cannot get YUV420 frame from input avi-file input.avs"Has someone created a workaround for this? I decided I wanted to do some testing with FRIMEncode in the hope of eventually adding support to BD-RB, and this is all I ever get when I have an AVS as input (simple 2D source using DirectshowSource()) and AVISYNTH v2.5.8.

Am I doing something wrong?

[HWK]

Has someone created a workaround for this? I decided I wanted to do some testing with FRIMEncode in the hope of eventually adding support to BD-RB, and this is all I ever get when I have an AVS as input (simple 2D source using DirectshowSource()) and AVISYNTH v2.5.8.

Am I doing something wrong?

I haven't come across one where workaround works, even with avisynth 2.6.0. However if pipe is used then encode works and as an added bonus no large files are created other than files extracted by tsmuxer and no dependency on ffdshow and avisynth.

If you are interested in my workflow, it consist of following setting and yes these are new ones. Which allowed full encode to complete.

1. Call tsmuxer to extract avc and mvc stream, or any supported stream.
2. Create batch file with parameter similar to one shown shown on next line, for this example it is mvc

FRIMDecode mvc -i 00098.track_4113.264 -i 00098.track_4114.mvc -o \\.\pipe\test.yuv | FRIMEncode.exe mvc -i \\.\pipe\test_L.yuv -i \\.\pipe\test_R.yuv -viewoutput -o E:\Pacific_Rim_AVC.264 -o E:\Pacific_Rim_MVC.264 -w 1920 -h 1080 -f 23.976 -u 1 -cpbsize 3570 -l 6 -vbr 39081 60000 -profile high -level 4.1 -gop 24 4 0 S -maxdpb 4

3. Finally execute batch file and it will decode source files with frim decoder and feed it to frim encoder.

Although not required, but here all the parameters encoder and decoder will accept with encoder parameters first, follow by decoder.

FRIM Encoder version 1.15 (build: Nov 12 2013)
- based on Intel(R) Media SDK (version: 4.0.760.60435)

Usage:

FRIMEncode mpeg2|h264|mvc|jpeg [options]
-i InputFile -o OutputBS

options:

-avi - input file is in AVI format,
if not specified then YUV is expected
-sbs|tab numViews - input file is in side-by-side or top-above-below
format, valid only for multiview
-w width - source picture width (one view), mandatory for YUV
-h height - source picture height (one view), mandatory for YUV
-f frameRate - video frame rate (frames per second)

-cbr|b bitRate - CBR mode (in Kbits/s)
-vbr bitRate maxRate - VBR mode (in Kbits/s)
-cqp QPI QPP QPB - CQP mode
QPx quantization parameters for I,P,B frames
QPx in range [0,51]
-labrc bitRate depth - LA BRC mode (in Kbits/s) for H.264 encoder
look ahead depth, in range [10,100] or 0(=auto),
number of frames to be analyzed before encoding
Supported only with -hw option on 4th Generation
on Intel Core processors
bit rate is valid for H.264, MPEG2 and MVC
-cpbsize size - cpb/vbv buffer size (in KB)
max 3750 for H.264 Blu-ray
max 1194 for MPEG2 Blu-ray

-tff|bff - input stream is interlaced, top|bottom field first,
if not specified then progressive is expected
-nv12 - input is in NV12 color format,
if not specified then YUV420 is expected
-u 1..7 - target usage: between 1(=quality) and 7(=speed),
default is 4(=balanced),
valid for H.264, MPEG2 and MVC
-q quality - quality parameter for JPEG,
in range [1,100], 100 is the best quality
-l numSlices - number of slices, default value 0

-profile profile - codec profile name
MPEG2: simple, main, high
H.264: baseline, main, high
-level level - codec level
MPEG2: low/LL, main/ML, high1440/H14, high/HL,
H.264: 1, 1b, 1.1, 1.2, 1.3,
2, 2.1, 2.2, 3, 3.1, 3.2,
4, 4.1, 4.2, 5, 5.1, 5.2
MVC: 4, 4.1, 4.2, 5, 5.1, 5.2

-gop gopLength gopDist idrInterval O|C|S
- GOP structure control
GOP length
(0=unspecified, 1=I-frame only, ...)
GOP distance between I- or P-frames
(0=unspecified, 1=no B-frames, ...)
IDR interval:
H.264: between I- and IDR-frames
(0=every I-frame is an IDR frame, ...)
MPEG2: sequence header interval
(0=once at beginning, 1=every I-frame, ...)
Opened, Closed, Strict ... GOP structure

-maxdpb numFrames - maximum number of frames buffered in a DPB
(Decoded Picture Buffer), default value 0(=unspecified)
-CAVLC|CABAC - use CAVLC or CABAC for encoding, default is CABAC
(for H.264 only)
-VuiNalHrd on|off - insert NAL HRD parameters into bitstream,
default value on (for H.264 only)
-VuiVclHrd on|off - insert VCL HRD parameters into bitstream,
default value on (for H.264 only)
-PicTimingSEI on|off - insert picture timing SEI with pic_struct syntax
element into bitstream,
default value on (for H.264 only)
-EndOfSequence on|off - insert End of Sequence NAL into bitstream,
default value on (for H.264 only)
-EndOfStream on|off - insert End of Stream NAL into bitstream,
default value off (for H.264 only)

-dstw width - destination picture width, invokes VPP resizing
-dsth height - destination picture height, invokes VPP resizing
-hw - use platform specific SDK implementation,
if not specified then software implementation is used
-d3d - work with d3d9 surfaces
-d3d11 - work with d3d11 surfaces

-viewoutput - instruct the MVC encoder to output each view
in separate bitstream buffer.
Depending on the number of '-o' options behaves as follows:

1: two views are encoded in single file
2: two views are encoded in separate files
3: behaves like two '-o' were used and then one '-o'
Example: FRIMEncode mvc
-i InputFile_L -i InputFile_R
-o OutputEncodedBase -o OutputEncodedDependent
-viewoutput -w width -h height


FRIM Decoder version 1.15 (build: Nov 12 2013)
- based on Intel(R) Media SDK (version: 4.0.760.60435)

Usage:

FRIMDecode mpeg2|h264|mvc|vc1|jpeg [options]
-i InputBS [-i InputBS_dependent]
-o OutputYUVFile [-o OutputYUVFile_R]

options:

-sbs|tab - output file is in side-by-side or top-above-below format,
valid only for multiview
-hw - use platform specific SDK implementation,
if not specified software implementation is used
-low_latency - configures decoder for low latency mode
(only for H.264 and JPEG)
-calc_latency - calculates latency during decoding and prints log
(only for H.264 and JPEG)
-jpeg_rotate n - rotate jpeg frame n degrees (n=90,180,270)
(only for JPEG)
-nv12 - output is in NV12 color format,
if not specified then YUV420 is used
-d3d - work with d3d9 surfaces
-d3d11 - work with d3d11 surfaces
-r - render decoded data in a separate window
-wall w h n m f t tmo - same as -r, and positioned rendering window
in a particular cell on specific monitor
w ... number of columns of video windows on selected monitor
h ... number of rows of video windows on selected monitor
n(0,.,w*h-1) ... order of video window in table that will be rendered
m(0,1..) ... monitor id
f ... rendering framerate
t(0/1) ... enable/disable window's title
tmo ... timeout for -wall option, in seconds

Press 1 to toggle fullscreen rendering on/off



Hopefully this will help.

[jdobbs]

@HWK

Thanks. I modified your command line for a 2D input file and it works fine. I'm a little confused, though, by the first post of the thread that says v1.15 can work using an Avisynth script -- but I can't get one to work at all. It would sure save me a lot of time if I could use DirectshowMVCSource() or ssifsource3 to feed an OAU or SBS picture to the encoder.

That would be a good project for someone -- creating an AVISYNTH source filter out of FRIMDecode eliminating the need for directshow filters.

[HWK]

@HWK

Thanks. I modified your command line for a 2D input file and it works fine. I'm a little confused, though, by the first post of the thread that says v1.15 can work using an Avisynth script -- but I can't get one to work at all.

I couldn't manage it as well :D, If you used my command line and you set -u 1, it is considered placebo in x264 terms. I thought I let you know about this.

[HWK]

@HWK
It would sure save me a lot of time if I could use DirectshowMVCSource() or ssifsource3 to feed an OAU or SBS picture to the encoder.

If you want my opinion on mvc decoding part at least for 3D encoding, use frimdecode. One of the biggest benefit is you can distribute with BD-RB and get rid of external dependency altogether, but it won't do SBS or OU for you. However if I remember correctly you want to focus on 3D rather than SBS or OU.

Although I haven't tried I am thinking if x264 can accept pipe input, you can use frim to decode any of the following codecs
mpeg2|h264|mvc|vc1|jpeg which may open door for potential to have self contained package, rather than relying on external decoders.

[Sharc]

Has someone created a workaround for this? I decided I wanted to do some testing with FRIMEncode in the hope of eventually adding support to BD-RB, and this is all I ever get when I have an AVS as input (simple 2D source using DirectshowSource()) and AVISYNTH v2.5.8.

Am I doing something wrong?
Maybe I miss your point, but I don't have problems with avisynth 2.5.8 script and directshowsource.
Commandline for an O/U source (includes resizing):
"C:\Program Files Video\MVCtoAVI.exe\FRIMEncode.exe" mvc -avi -tab 2 -i directshowsource.avs -viewoutput -o Base1.avc -o Dependent1.mvc -w 1280 -h 720 -dstw 1280 -dsth 720 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O
pause

[HWK]

Maybe I miss your point, but I don't have problems with avisynth 2.5.8 script and directshowsource.
Commandline for an O/U source (includes resizing):
"C:\Program Files Video\MVCtoAVI.exe\FRIMEncode.exe" mvc -avi -tab 2 -i directshowsource.avs -viewoutput -o Base1.avc -o Dependent1.mvc -w 1280 -h 720 -dstw 1280 -dsth 720 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O
pause


It is probably some kind of local issue or something, I gave it a try and get same message "Cannot get YUV420 frame from input file Encode_3D_Movie.avs" where pipe works.

[jdobbs]

Maybe I miss your point, but I don't have problems with avisynth 2.5.8 script and directshowsource.
Commandline for an O/U source (includes resizing):
"C:\Program Files Video\MVCtoAVI.exe\FRIMEncode.exe" mvc -avi -tab 2 -i directshowsource.avs -viewoutput -o Base1.avc -o Dependent1.mvc -w 1280 -h 720 -dstw 1280 -dsth 720 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O
pauseYou don't miss the point. That's exactly what I want in order to avoid having to demux prior to encoding.

Can you show an example script. I get that error message every time I try any encode using frimencode with any script I try.

[HWK]

@HWK

I'm a little confused, though, by the first post of the thread that says v1.15 can work using an Avisynth script -- but I can't get one to work at all.


You don't miss the point. That's exactly what I want in order to avoid having to demux prior to encoding.

Can you show an example script. I get that error message every time I try any encode using frimencode with any script I try.

Jdobbs, Prehaps this post applies to your problem as well

http://forum.doom9.org/showthread.php?p=1653848#post1653848 (http://forum.doom9.org/showthread.php?p=1653848#post1653848)

[Update] After couple of tries it still didn't work for me.

[jdobbs]

Jdobbs, Prehaps this post applies to your problem as well

http://forum.doom9.org/showthread.php?p=1653848#post1653848 (http://forum.doom9.org/showthread.php?p=1653848#post1653848)

[Update] After couple of tries it still didn't work for me.Even if it did work, I wouldn't want to pile an alpha on top of a beta -- especially when I would intend to distribute it knowing it wouldn't work for everybody. I'll use FRIMDecoder, and maybe write an inline demuxer that will pipe to the decoder (if it supports it). I need to make sure the decoder works with Windows XP, though. There are a lot of people still using it out there.

[frencher]

Jdobbs, Prehaps this post applies to your problem as well

http://forum.doom9.org/showthread.php?p=1653848#post1653848 (http://forum.doom9.org/showthread.php?p=1653848#post1653848)

[Update] After couple of tries it still didn't work for me.

http://i41.tinypic.com/rua5pw.png

[HWK]

Even if it did work, I wouldn't want to pile an alpha on top of a beta -- especially when I would intend to distribute it knowing it wouldn't work for everybody. I'll use FRIMDecoder, and maybe write an inline demuxer that will pipe to the decoder (if it supports it). I need to make sure the decoder works with Windows XP, though. There are a lot of people still using it out there.

For inline demuxer are you referring to method where your demuxer will read files and demux and feed to frimdecode.

Also for windows xp, it won't work according videofan3d first post.

Intel Media SDK provides framework for MPEG2, H.264 AVC and H.264 MVC-3D encoding and decoding.
SDK is supported on Windows 7, Windows 8.x, and it can be freely distributed and used.


I also confirmed from Intel and it doesn't support Windows xp from their FAQ

Q6: What platforms does Intel Media SDK support?

A6: Intel Media SDK supports a broad selection of hardware platforms including those with 2nd, 3rd and 4th generation Intel Core processors that have Intel HD Graphics, tablets with Intel Atom processors, codenamed “Clovertrail”. Intel® Media SDK also supports the Windows* 7 and 8 operating systems (32-bit and 64-bit and Windows 8 ModernUI.*


Jdobbs, Even though I knew it won't work, but I decided to try anyways to confirm my findings as a result I attempt procedure on windows xp professional with sp3 and it didn't work at all. Message I get when executing FRIM decoder "The procedure entry point Direct3DCreate9Ex could not be located in the dynamic link library d3d9.dll" and in dialog box header it says "FRIMDecode.exe - Entry Point Not Found"

Same message is displayed for FRIMEncode and FRIMTranscode on XP, although xp has dll already but it needs different one.

[HWK]

http://i41.tinypic.com/rua5pw.png

I have done couple of times and it still doesn't work. Thanks for trying I will use pipe if I use Frimencode.

[Cedvano]

@HWK

Why you don't use FRIMTRanscode ?
You don't need to decode, you can use directly AVC and MVC.

[HWK]

@HWK

Why you don't use FRIMTRanscode ?
You don't need to decode, you can use directly AVC and MVC.

I never used so far :p, I have two mvc encoder and know how to use pipe and based on that didn't feel like it. Thanks for suggestion I will try it out and it look promising as well.

[Cedvano]

Ok, ;) I think it's about quality.

[Sharc]

You don't miss the point. That's exactly what I want in order to avoid having to demux prior to encoding.

Can you show an example script. I get that error message every time I try any encode using frimencode with any script I try.

Example script:
DirectShowSource("c:\Users\User1\Movies\Test_Movie\3-D AVCHD samples\Skull Rock 720p O-U.wmv")
#spline16resize(1920,2160)
ChangeFPS(60000,1001)
ConvertToYV12().AssumeFPS(60000,1001)

Added:
I have also "some" success with DirectShowMVCSource. However, FRIMEncode.exe usually crashes after some time (say about 1000 frames), or Base / Dependent views get out of step and one of the views is dropped (black pictures). I have no explanation as to why this happens.

Command:
"C:\Program Files Video\MVCtoAVI.exe\FRIMEncode.exe" mvc -avi -sbs 2 -i directshowMVC.avs -viewoutput -o Base2.avc -o Dependent2.mvc -w 1920 -h 1080 -dstw 1280 -dsth 720 -l 4 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.0 -gop 24 4 0 O
pause

Script:
LoadPlugin("c:\Program Files Video\MVCtoAVI.exe\DirectShowMVCSource.dll")
VIEW2=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\00000.SSIF")
VIEW1=DirectShowMVCSource("F:\BDMV\STREAM\SSIF\00000.SSIF",decodeleft=true)
StackHorizontal(VIEW1,VIEW2)
ConvertToYV12().AssumeFPS(24000,1001)

Note that a copy of FRIMEncode.exe must be put into the "Magic Folder" MVCtoAVI.exe.

Finally, FRIMEncode works most reliably and reasonably fast with -u 4 with named pipes. So far I did two 2-hours MVC movies without any issues. They also playback well as 2D on a 2D Standalone+TV. The quality -u 4 might not yet be at x264 level, but it is quite ok when compressed as 3D MVC to BD9 size. At least I didn't get any complaints from the family ......

@HWK:
The 720p@23.976fps is unfortunately not blu-ray MVC compliant as you wrote, means in order to make it compliant I should have left it at FullHD resolution or convert the 720p to 50fps or 59.94fps. Anyway I was lucky in having no issues with playback, and 720p was convenient for BD9 size and encoding speed.

[Sharc]

@HWK

Why you don't use FRIMTRanscode ?
You don't need to decode, you can use directly AVC and MVC.
Yes, this is a valid option.
FRIMTranscode works well here. If needed, the CombinedMVC output can be muxed to .iso/SSIF BD3D structure with tsMuxeR.

The only drawback is perhaps that neither with pipes nor with Transcode you have the option of processing the video with avisynth scripts.

[Cedvano]

The only drawback is perhaps that neither with pipes nor with Transcode you have the option of processing the video with avisynth scripts.

Yes, pipes doesn't work with Transcode.
For Avisynth, Decode and Transcode is required.

[HWK]

@HWK:
The 720p@23.976fps is unfortunately not blu-ray MVC compliant as you wrote, means in order to make it compliant I should have left it at FullHD resolution or convert the 720p to 50fps or 59.94fps. Anyway I was lucky in having no issues with playback, and 720p was convenient for BD9 size and encoding speed.

I never wrote 720P @23.976 is compatible. My post says 720P is only compatible at 50 and 59.94 fps.
http://forum.doom9.org/showthread.php?p=1654313#post1654313

[jdobbs]

I never wrote 720P @23.976 is compatible. My post says 720P is only compatible at 50 and 59.94 fps.
http://forum.doom9.org/showthread.php?p=1654313#post1654313I think that's what he said. But I can see how it could be misinterpreted....unfortunately not blu-ray MVC compliant as you wrote...

[Sharc]

I think that's what he said. But I can see how it could be misinterpreted.
Yes, I really wanted to comment that 720p23.976 is NOT compliant. Sorry if I have not been clear (non-native English speaker problem maybe ....)

[HWK]

I need to make sure the decoder works with Windows XP, though. There are a lot of people still using it out there.

Jdobbs, to make life easier for you, I ran test on windows Xp professional with SP3 and it didn't work as expected. Yo can find result at http://forum.doom9.org/showthread.php?p=1654544#post1654544

[jdobbs]

Jdobbs, to make life easier for you, I ran test on windows Xp professional with SP3 and it didn't work as expected. Yo can find result at http://forum.doom9.org/showthread.php?p=1654544#post1654544 I'll just have to caveat the 3D support with "requires Windows 7 or above" and do an O/S check before enabling 3D processing. I'm convinced FRIMDecode/FRIMEncode is the way to go.

[HWK]

I'll just have to caveat the 3D support with "requires Windows 7 or above" and do an O/S check before enabling 3D processing. I'm convinced FRIMDecode/FRIMEncode is the way to go.

Sounds like good plan. Also I ran test on physical pc instead of virtual machine so this way from my point of view there is no room for error.
Also I am doing test run for quality, this should help you with which preset map too.

[Sharc]

I'll just have to caveat the 3D support with "requires Windows 7 or above" and do an O/S check before enabling 3D processing. I'm convinced FRIMDecode/FRIMEncode is the way to go.
Straightforwardly:
- open the .ssif in tsMuxeR
- demux with tsMuxeR
- Transcode the video elementary streams with FRIMTranscode => combinedMVC
- Remux the combinedMVC with audio and sups to Blu-Ray ISO with tsMuxeR

Edit:
Oh I see: FRIMTools only working under Windows 7 onwards.

[jdobbs]

Straightforwardly:
- open the .ssif in tsMuxeR
- demux with tsMuxeR
- Transcode the video elementary streams with FRIMTranscode => combinedMVC
- Remux the combinedMVC with audio and sups to Blu-Ray ISO with tsMuxeR

Edit:
Oh I see: FRIMTools only working under Windows 7 onwards. It also gets a little complicated with a full backup, because I have to retain the original structure and TSMUXER can't really do that and output to ISO at the same time. It is designed more for movie-only work. I may have workaround, though, I'll have to see how it works.

[HWK]

It also gets a little complicated with a full backup, because I have to retain the original structure and TSMUXER can't really do that and output to ISO at the same time. It is designed more for movie-only work. I may have workaround, though, I'll have to see how it works.

Full backup might not be good option since you need 50% overhead for dependent view. However I do see this option viable for short movies and have good news for you

Message directly from physic
From roadmap of tsmuxer improvements

Hello! My roadmap is:
1. Add correct support for subpath (for DTS-express tracks and Pip possible)
2. Several minor tasks

Then I am going to start new big task:
- full disk processing. This ability will allow to keep source disk structure (menu e.t.c) and replace only specified M2TS file(s).

Full disc processing is really something look forward too and as you can see if you let Roman handle it then you don't have to worry about it. I thought I share road map with you as well.

Also Jdobbs I want to tell you about changes in Cinavia road map. Although I knew before but decided to wait so I can digest this news first and then post.

Verance the developer of the watermark based copy protection Cinavia, announced availability of Cinavia for devices like televisions, set-top boxes, tablets and mobile phones.

If you want to read more, I have included link as well

http://www.verance.com/AdminSavR/news/news_item.php?news_id=80

[Cedvano]

Hi guys,
I have create FRIMTranscode GUI for those who want.
It's simply and easy to use.
Send me MP for bugs and others.

http://ns5.freeheberg.com/~cedvano/images/img0002.png

Thank you for your indulgence. ;)

[HWK]

Hi guys,
I have create FRIMTranscode GUI for those who want.
It's simply and easy to use.
Send me MP for bugs and others.

http://ns5.freeheberg.com/~cedvano/images/img0002.png

Thank you for your indulgence. ;)

Thank you, for your effort but how to download? Also mvc require 6 slices minimum or else it is not BD standard.

[Cedvano]

Thank you, for your effort but how to download? Also mvc require 6 slices minimum or else it is not BD standard.

Click on download in bottom of page. You can change parameters (it's only for my tests the picture)

[HWK]

Click on download in bottom of page. You can change parameters (it's only for my tests the picture)

I can't see or download. If you don't mind you can send download link and I will upload google docs and provide link for everyone else.
It may be you used doom9 upload option and it will take time to get approve if this is the case.

[colinhunt]

Click on download in bottom of page. You can change parameters (it's only for my tests the picture)
Yeah, no download linky in sight.

FRIMTranscode supports hardware encoding; can you add that to the GUI?

Also, if -hw or -hw_d3d11 is enabled, Transcode can use LA BRC mode (-labrc parameter) so that would a nice additional option if the required hardware is present.

[Cedvano]

Here Google Docs : FRIMTranscode GUI (https://drive.google.com/file/d/0BxjaFf3cdexVZkRnQWJVVE50RjQ/edit?usp=sharing)
You can click on the picture in the website.

[HWK]

Here Google Docs : FRIMTranscode GUI (https://drive.google.com/file/d/0BxjaFf3cdexVZkRnQWJVVE50RjQ/edit?usp=sharing)
You can click on the picture in the website.
Initial impression job well done. Are you gone translate installer string to English? Also may I suggest offer to consider right click on option and offer brief detail about it.

[Cedvano]

Initial impression job well done. Are you gone translate installer string to English? Also may I suggest offer to consider right click on option and offer brief detail about it.

FRIMTranscode supports hardware encoding; can you add that to the GUI?
Also, if -hw or -hw_d3d11 is enabled, Transcode can use LA BRC mode (-labrc parameter) so that would a nice additional option if the required hardware is present.

Ok, thanks for your help, I work on it.
Don't hesitate for others suggestions.

[colinhunt]

Here Google Docs : FRIMTranscode GUI (https://drive.google.com/file/d/0BxjaFf3cdexVZkRnQWJVVE50RjQ/edit?usp=sharing)
You can click on the picture in the website.
Running first test now, seems to be working fine. This is a very nice addition to the toolset; thanks!

[Sharc]

Cedvano
VBR has to parameters: average and maxrate, like
-vbr 8000 15000.
I think in your GUI the maxrate is missing, no?

[colinhunt]

Cedvano
VBR has to parameters: average and maxrate, like
-vbr 8000 15000.
I think in your GUI the maxrate is missing, no?
I assumed that you type the average bitrate in the CBR box, maxrate in VBR box and select VBR. Yeah, assumptions...

[Cedvano]

If you select CBR, the max bitrate is selected for average. (option -cbr 15000)
If you select VBR, you have got the min and max bitrate. (option -vbr 8000 15000)

Edit: I add help box !

[jdobbs]

Full backup might not be good option since you need 50% overhead for dependent view. However I do see this option viable for short movies and have good news for youThat is good news, and I look forward to physic's implementation. But, as I tried to explain before -- you don't have to worry about additional overhead because from a 3D perspective the M2TS files have no purpose. If you want to create a 3D disc -- all you need is the corresponding SSIF file(s). The 3D playback is played from there. The two M2TS files can be replaced by dummy files that have the same attributes but are only a couple of seconds long (assuming the CLPI is correctly formatted) since they would be simply pointing to the same data that is interleaved in the SSIF. The base view M2TS might be replaced with a video saying "You need a 3D player, buddy". The downside is that the features, etc. can ONLY be played on a 3D player with a 3D monitor (2D playback would require the base view M2TS). But some discs are like that anyway (meaning they won't play except on a 3D player).

I've done it and on my 3D BD player it works fine.

[colinhunt]

Okay, first 5000 frame-long test encode using FRIMTranscode GUI is done. The result is very nice. I selected VBR, and entered 22000 in the CBR box and 48000 in the VBR box.

Dropped the combined output file into latest tsMuxer, output into BD3D ISO, then mounted ISO in virtual drive and used BDInfo to measure bitrates. Average bitrate for AVC was 12018 kbps and 9962 kbps for MVC. In total that's very close to the 22000 kbps average set in the CBR box. As for max bitrate... I'm not quite sure how to read BDInfo's output. It says 39485 kbps for "Max 1-sec Rate", but that appears to be for AVC only.

That's the MVC on top and AVC underneath:

http://i44.tinypic.com/n2da4g.png

[Cedvano]

Version 1.02b
- Add help for options
- some aesthetic corrections.

FRIMTranscode GUI 1.02b (https://drive.google.com/file/d/0BxjaFf3cdexVTWNxcWtpdU1WY2M/edit?usp=sharing)

[HWK]

That is good news, and I look forward to physic's implementation. But, as I tried to explain before -- you don't have to worry about additional overhead because from a 3D perspective the M2TS files have no purpose. If you want to create a 3D disc -- all you need is the corresponding SSIF file(s). The 3D playback is played from there. The two M2TS files can be replaced by dummy files that have the same attributes but are only a couple of seconds long (assuming the CLPI is correctly formatted) since they would be simply pointing to the same data that is interleaved in the SSIF. The base view M2TS might be replaced with a video saying "You need a 3D player, buddy". The downside is that the features, etc. can ONLY be played on a 3D player with a 3D monitor (2D playback would require the base view M2TS). But some discs are like that anyway (meaning they won't play except on a 3D player).

I've done it and on my 3D BD player it works fine.

Sound good, definitely looking forward to it and since quality is subjective I will leave it here. In the meantime I did some benchmark to help you decide which preset to use within BD-RB, I did benchmark of quality using preset Quality, Balanced and Fast and uploading result here to give you idea and hopefully it will help you decide. Should you need me to conduct more test or can offer help, just let me know.

I should also mention I ran them one by one.
System Setting and info
Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz, 3201 MHz, 6 Core(s), 12 Logical Processor(s) Clocked at 4.00GHZ
Source and Destination On Separate Physical Drive
Source Used: Pacific Rim, total runtime for sample 6min and 42 second and taken from beginning of movie.
Tota Frame processed 19329

Encoder Setting
Input format YUV420
Output video AVC
MFX dll: G:\FRIM_version_1.15\libmfxsw32.dll

Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control VBR
avg,maximum 39081,60000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Strict
Num of slices 6

Memory type system
Media SDK impl sw
Media SDK version 1.7



Preset U-1 (Quality)
Cpu Usage 36 % Min - 44% Max Encoder
Cpu Usage 1 % Min - 2% Max Decoder
Time Taken 5121.22 Second
-------------------------------------
Preset U-4 (Balanced)
Cpu Usage 41 % Min - 72% Max Encoder
Cpu Usage 1 % Min - 8% Max Decoder
Time Taken 1089.70 Second
-------------------------------------
Preset U-7 (Speed)
Cpu Usage 25 % Min - 51% Max Encoder
Cpu Usage 4 % Min - 5% Max Decoder
Time Taken 800.78 Second
-------------------------------------


Media Info Report

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Format settings, GOP : M=4, N=24
Codec ID : 27
Duration : 6mn 43s
Bit rate mode : Variable
Bit rate : 21.5 Mbps
Maximum bit rate : 32.7 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.432
Stream size : 1.01 GiB (96%)

Video
ID : 4114 (0x1012)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Stereo High@L4.1
MultiView_Count : 2
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : 32
Duration : 6mn 42s
Bit rate mode : Variable
Bit rate : 17.9 Mbps
Maximum bit rate : 27.3 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.359
Stream size : 858 MiB (96%)

[colinhunt]

Anyone know if there's a way to tell FRIM to start encoding from a specific frame number?

[Cedvano]

Anyone know if there's a way to tell FRIM to start encoding from a specific frame number?

Demux with split option in TsMuxer. The only way I know.

[colinhunt]

I'm no good at this command line lark, it seems. Transcoding ends with a bunch of error messages when I try to run this:

frimtranscode -i::mvc t:left.264 t:right.mvc -o::mvc outputcombined.264 -hw -labrc 22000 0 -profile high -level 4.1

FRIM Transcoder version 1.15 (build: Nov 12 2013)
- based on Intel(R) Media SDK (version: 4.0.760.60435)

MFX HARDWARE Session 0 API ver 1.7 parameters:
Input video: AVC
Output video: AVC
MFX dll: C:\Users\xxxxxxxxxxxx\encoders\libmfxhw32.dll

Session 0 was NOT joined with other sessions
Transcoding started
Return on error: error code -3, .\src\sample_utils.cpp 1472
Return on error: error code -3, .\src\pipeline_transcode.cpp 1783
Return on error: error code -3, .\src\pipeline_transcode.cpp 443
Return on error: error code -3, .\src\pipeline_transcode.cpp 744
Transcoding finished
MFX session 0 transcoding FAILED
Processing time: 0.11 sec
Number of processed frames: 0
Return on error: error code 1, .\src\sample_multi_transcode.cpp 603

... but if I leave out the last "-level 4.1", transcoding starts running just nicely. Huh?

edit: Figured it out. When running in -hw mode and using LA BRC (-labrc), Transcode will stop in error if "-level 4.1" is used. Switching from LA BRC to -vbr allows the use of -level 4.1.

[jdobbs]

Sound good, Definitely looking forward to it and since quality is subjective I will leave it here. In the meantime I did some benchmark to help you decide which preset to use within BD-RB, I did benchmark of quality using preset Quality, Balanced and Fast and uploading result here to give you idea and hopefully it will help you decide. Should you need me to conduct more test or can offer help, just let me know.Yes, quality is subjective, but I'd still like to know about where a given level falls... maybe I can use some kind of testing (PSNR etc.) that will give me some idea as to how an item (2D) encoded by FRIMEncode at a given quality level compares to an X264 encode with it's quality levels given an identical source. These "quality" metrics are never great -- but the quality level doesn't have to be perfectly 1:1, just close. That way I can still let users pick a preset quality level from within BD-RB.

Thanks for the info you provided.

[HWK]

Jdobbs, I am just curious how soon one may expect 3D support. Just rough timeline will do for know.

[colinhunt]

Well, poop. Can't use -hw option in FRIMTranscode: output is garbled, just riddled with artefacts. I believe it's the same issue I discovered earlier, i.e. hardware encoding works fine, but hardware decoding is futzed up.

[videofan3d]

Hi,

Minor update FRIM 1.16 is available.
Key changes:

FRIM Encoder 1.16
- workaround for Avisynth error (occasionally Avisynth 2.5.8 doesn't feed R-eye in -sbs mode) - please try if it helped

FRIM Encoder and Transcoder 1.16
- allowed bitrate higher than 65000 Kbps (although I personally doubt whether it is reasonable and useful :) )

(rest is in Release notes)

[HWK]

Hi,

Minor update FRIM 1.16 is available.
Key changes:

FRIM Encoder 1.16
- workaround for Avisynth error (occasionally Avisynth 2.5.8 doesn't feed R-eye in -sbs mode) - please try if it helped

FRIM Encoder and Transcoder 1.16
- allowed bitrate higher than 65000 Kbps (although I personally doubt whether it is reasonable and useful :) )

(rest is in Release notes)


Thank you

[HWK]

I notice when you mux file with tsmuxer number of frame is different. However if you extract it there are same.

Network Optix tsMuxeR. Version 2.2.3(b). www.networkoptix.com
Decoding H264 stream (track 1): H.264/MVC Views: 2 Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976
MVC muxing fps is not set. Get fps from stream. Value: 23.976
Decoding H264 stream (track 2): Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976
H.264 muxing fps is not set. Get fps from stream. Value: 23.976
Processed 9661 video frames (MVC)
Processed 9662 video frames (AVC)
Flushing write buffer
Creating Blu-ray stream info and seek index
Creating Blu-ray playlist
Mux successful complete
Muxing time: 30 sec

[colinhunt]

Minor update FRIM 1.16 is available.
Thank you. Any chance you could implement an option to use software decoding and hardware encoding in FRIMTranscode?

[HWK]

Anyone know if there's a way to tell FRIM to start encoding from a specific frame number?

Demux with split option in TsMuxer. The only way I know.

Tsmuxer doesn't support split option when demux is activated.

[videofan3d]

Thank you. Any chance you could implement an option to use software decoding and hardware encoding in FRIMTranscode?

1. you can try to use par-file (example):

-sw -i::h264 input.avc -o::sink
-hw -i::source -o::h264 output.avc

2. FRIM was so far compiled on Windows 7 and I didn't have a chance to test it on Intel Graphic card in -hw mode.
In near future I expect to have access to I7 Haswell so I'll check also -hw mode myself and try to figure out what's going on there.

[Cedvano]

Tsmuxer doesn't support split option when demux is activated.

Mux with split and Demux it.


FRIMTranscode GUI 1.03(b) (https://drive.google.com/file/d/0BxjaFf3cdexVM3lkM2tBTnJId28/edit?usp=sharing)

version 1.03(b)
- Add Hardware acceleration option
- Add FRIMTranscode 1.16
- some minors corrections.

Edit: Please re-download it because an option have change (-n become -length)

[jdobbs]

Jdobbs, I am just curious how soon one may expect 3D support. Just rough timeline will do for know.I'm going to be going away for the Thanksgiving holiday starting Friday, so that will delay it. I don't think it will be too terribly difficult (given the fact that FRIM and TSMUXER is carrying most of the load). But since I'll have to do some testing before release, I'd guess mid-December. Maybe earlier if I get a real groove going.

[Cedvano]

I'm going to be going away for the Thanksgiving holiday starting Friday, so that will delay it. I don't think it will be too terribly difficult (given the fact that FRIM and TSMUXER is carrying most of the load). But since I'll have to do some testing before release, I'd guess mid-December. Maybe earlier if I get a real groove going.

Thanks in advance for your work !

[HWK]

I'm going to be going away for the Thanksgiving holiday starting Friday, so that will delay it. I don't think it will be too terribly difficult (given the fact that FRIM and TSMUXER is carrying most of the load). But since I'll have to do some testing before release, I'd guess mid-December. Maybe earlier if I get a real groove going.

ok, thanks for info and have happy thanksgiving and in the mean time I will continue to run test and keep posted if I come across something interesting.

[colinhunt]

version 1.03(b)
- Add Hardware acceleration option
Thank you for this. However, the output is useless if -hw is used for both decode and encode. If you have the time and the inclination, perhaps you could alter the Hardware acceleration is such a way that decoding is done in software and -hw is used for encode only?

[jdobbs]

ok, thanks for info and have happy thanksgiving and in the mean time I will continue to run test and keep posted if I come across something interesting.Just remembered, I'm not leaving until Saturday. So I'll get some of it done tomorrow.

[Sharc]

I seem to get occasional glitches with FRIMTranscode.exe. Has anyone else experienced this? It happens with full length movies, you may not get it with short test clips.
The safest way seems still to be with FRIMDecode / FRIMEncode via pipes.

[colinhunt]

1. you can try to use par-file
Wow, this parameter file seems to be working:

-sw -i::mvc left.264 right.mvc -o::sink
-hw -i::source -o::mvc hw_sink_outcombined.264 -vbr 22000 48000 -profile high -level 4.1 -u 5 -l 6 -cpbsize 3750 -n 500 -gop 24 4 0 O

It reports this while running:

MFX SOFTWARE Session 0 API ver 1.7 parameters:
Input video: AVC
Output video: to child session
MFX dll: C:\Users\xxxxxxxxxx\encoders\libmfxsw32.dll

MFX HARDWARE Session 1 API ver 1.7 parameters:
Input video: from parent session
Output video: AVC
MFX dll: C:\Users\xxxxxxxxxx\encoders\libmfxhw32.dll

Session 0 was NOT joined with other sessions
WARNING: partial acceleration
Session 1 was NOT joined with other sessions

Ohhkay, I should probably have put the "-n 500" on the decoder line...

[videofan3d]

-hw -i::source -o::mvc hw_sink_outcombined.264 -vbr 22000 48000 -profile high -level 4.1 -u 5 -l 6 -cpbsize 3750 -n 500 -gop 24 4 0 O



Please note that -n has been renamed to -length ! (which is more self-explanatory :) - see Release notes ;) )

[colinhunt]

Please note that -n has been renamed to -length ! (which is more self-explanatory :) - see Release notes ;) )
I'm still on FRIMTranscode 1.15 - you're too quick! ;) ;)

Ooh, v1.16 reports more data:

Session 0:
Media SDK impl SOFTWARE (C:\Users\xx\encoders\libmfxsw32.dll)
Media SDK version 1.7
Memory type system

Input video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976

Output video (to child session)

------------------------------------------------------------
Session 1:
Media SDK impl HARDWARE (C:\Users\xx\encoders\libmfxhw32.dll)
Media SDK version 1.7
Memory type d3d

Input video (from parent session)

Output video AVC
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control VBR
avg,maximum 30000,48000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 8
Target usage 3
Session 0 was NOT joined with other sessions
WARNING: partial acceleration
Session 1 was NOT joined with other sessions

Nice!

[colinhunt]

I seem to get occasional glitches with FRIMTranscode.exe.
That sounds a wee bit worrying.

[jdobbs]

Please note that -n has been renamed to -length ! (which is more self-explanatory :) - see Release notes ;) ) Is there a way to force i-frames at certain points for chaptering?

[colinhunt]

Is still normal?

Transcoding finished
MFX session 0 transcoding passed
Processing time: 57.71 sec
Number of processed frames: 1000
MFX session 1 transcoding passed
Processing time: 58.42 sec
Number of processed frames: 500

This was with "-length 1000".

[Sharc]

That sounds a wee bit worrying.
Hmmm....... yes. I got it in two cases now (version 1.15 still).

[Cedvano]

I seem to get occasional glitches with FRIMTranscode.exe. Has anyone else experienced this? It happens with full length movies, you may not get it with short test clips.
The safest way seems still to be with FRIMDecode / FRIMEncode via pipes.

Only with Stereoscopic Player, not with TMT6.
For me, I think is SP.

[Sharc]

Only with Stereoscopic Player, not with TMT6.
For me, I think is SP.
Ahhh.... so there is hope ....

[colinhunt]

Interesting. Using the ::sink solution mentioned earlier, I can use "-level 4.1" and -labrc options together without transcoder errors. Or perhaps that collision was somehow fixed in v1.16.

[Sharc]

I'll just have to caveat the 3D support with "requires Windows 7 or above" and do an O/S check before enabling 3D processing. I'm convinced FRIMDecode/FRIMEncode is the way to go.
Did you try again with DirectShowSource and DirectShowMVCSource? Still no luck?

I am asking because I had for the first time success with DirectShowMVCSource without crashing FRIMEncode or "loosing" one of the views after some time. Thanks to FRIMEncode Version 1.16 or just a lucky punch? I don't know.

Added:
Hmmm......seems to work stably now with FRIMEncode 1.16.
If it truly works, DirectShowMVCSource would be very convenient as one can start from the .ssif directly and add video processing to the .avs script as needed.....

[colinhunt]

A 77-minute long 3D movie has now been transcoding for 8 hours, with quality set to 3, decoding in software and encoding in hardware. CPU usage hovers around 75-80%.

Videofan3d, would it be possible to implement some sort of percentage display so the user could see how much of the movie has been processed? An "Estimated time remaining" would be even nicer, actually, but not sure if such a thing is possible here.

[videofan3d]

A 77-minute long 3D movie has now been transcoding for 8 hours, with quality set to 3, decoding in software and encoding in hardware. CPU usage hovers around 75-80%.

Videofan3d, would it be possible to implement some sort of percentage display so the user could see how much of the movie has been processed? An "Estimated time remaining" would be even nicer, actually, but not sure if such a thing is possible here.

Transcoder operates in multi session, so you can run in parallel several decoding-encoding sessions (you can try it :) ).
Displying progress for each session would be confusing.
Remember: FRIM are command-line tools (I like unix-style :) ) which have certain presentation limitations - and on the other hand sigificant advantage in scripting integration.

Transcoder displays dot '.' after each 100 decoded frames.

[colinhunt]

Transcoder operates in multi session, so you can run in parallel several decoding-encoding sessions (you can try it :) ).
Scripting and all this command line brouhaha is usually too difficult for my limited skills, unfortunately :/

Transcoder displays dot '.' after each 100 decoded frames.
I was wondering about those! OK, the dots are some help in that case.

The transcode finished a moment ago. It took almost exactly 9 hours to process 110237 frames... and it looks like I miscalculated the bitrate, as the output file is larger than the source avc + mvc combined. It should have been smaller to fit on a BD25. Welp, at least I have an excuse to run the same encode again, this time in software only and with slightly lower bitrate :)

[videofan3d]

... and it looks like I miscalculated the bitrate, as the output file is larger than the source avc + mvc combined. It should have been smaller to fit on a BD25.

This is why Transcoder uses several sessions in parallel.
You can write par file like e.g. this:

-i::h264 input.avc -o::sink
-i::source -o::h264 output12.h264 -vbr 12000 24000
-i::source -o::h264 output17.h264 -vbr 17000 24000
-i::source -o::h264 output21.h264 -vbr 21000 24000


and create several output within one pass.
Of course, it consume more CPU for several parallel encodings, but only one decoding !

[colinhunt]

This is why Transcoder uses several sessions in parallel.
Oh, I understand its use now. That's very clever! I'll give it a shot right away.

Still, I hope that one day soon there'll be a GUI for all this :)

[trevorjharris]

Hi,

Minor update FRIM 1.16 is available.
Key changes:

FRIM Encoder 1.16
- workaround for Avisynth error (occasionally Avisynth 2.5.8 doesn't feed R-eye in -sbs mode) - please try if it helped

FRIM Encoder and Transcoder 1.16
- allowed bitrate higher than 65000 Kbps (although I personally doubt whether it is reasonable and useful :) )

(rest is in Release notes)

Just tried an avs file and it still does not work.

[videofan3d]

Just tried an avs file and it still does not work.

What is your script?
And please describe symptoms of the problem.

[Cedvano]

FRIMTranscode GUI 1.04 (https://drive.google.com/file/d/0BxjaFf3cdexVV0NXSE14Sko5WHM/edit?usp=sharing)

version 1.04
- Add SSIF and MPLS support
- Include tsMuxer by Roman/Physic

[colinhunt]

version 1.04
Thanks!

[Sharc]

Hi,

Minor update FRIM 1.16 is available.
Key changes:

FRIM Encoder 1.16
- workaround for Avisynth error (occasionally Avisynth 2.5.8 doesn't feed R-eye in -sbs mode) - please try if it helped

FRIM Encoder and Transcoder 1.16
- allowed bitrate higher than 65000 Kbps (although I personally doubt whether it is reasonable and useful :) )

(rest is in Release notes)
FRIMEncode 1.16 works now with DirectShowMVCSource here. The crashes and/or skips of 1.15 seem to be gone :)

[colinhunt]

So I tested running several sessions in parallel. Here's the par file contents:

-sw -i::mvc left.264 right.mvc -o::sink -length 3500
-hw -i::source -o::mvc clip_hw_33mbps_labrc.264 -labrc 33000 0 -profile high -level 4.1 -u 4 -l 6 -cpbsize 3750 -gop 24 4 0 O
-hw -i::source -o::mvc clip_hw_33mbps_vbr.264 -vbr 33000 48000 -profile high -level 4.1 -u 4 -l 6 -cpbsize 3750 -gop 24 4 0 O
-sw -i::source -o::mvc clip_sw_33mbps.264 -vbr 33000 48000 -profile high -level 4.1 -u 4 -l 6 -cpbsize 3750 -gop 24 4 0 O

And this is what happened:

Transcoding started
......................
Return on error: error code -16, .\src\pipeline_transcode.cpp 858
Return on error: error code -16, .\src\pipeline_transcode.cpp 693

Transcoding finished
MFX session 0 transcoding FAILED
Processing time: 491.41 sec
Number of processed frames: 2154
MFX session 1 transcoding FAILED
Processing time: 303.34 sec
Number of processed frames: 1060
MFX session 2 transcoding FAILED
Processing time: 491.61 sec
Number of processed frames: 1077
MFX session 3 transcoding FAILED
Processing time: 491.59 sec
Number of processed frames: 1077

Return on error: error code 1, .\src\sample_multi_transcode.cpp 629

It actually ran quite a while before "Return on error" happened. Could this be caused by LA BRC, i.e. look-ahead bitrate control? Should I have used -async (and how)?

update: ran the exact same params, but with one addition to line 1: "-async 2". Transcoding finished without errors this time.

This is a bit odd:

Session 3:
Media SDK impl SOFTWARE (C:\Users\xxx\encoders\libmfxhw32.dll)
Media SDK version 1.7
Memory type system

Session 3 is encoding on software, and yet it lists the Hardware DLL. Correct DLL is listed for sessions 0-2, however.

[videofan3d]

Transcoding started
......................
Return on error: error code -16, .\src\pipeline_transcode.cpp 858
Return on error: error code -16, .\src\pipeline_transcode.cpp 693

Transcoding finished
MFX session 0 transcoding FAILED
Processing time: 491.41 sec
Number of processed frames: 2154
MFX session 1 transcoding FAILED
Processing time: 303.34 sec
Number of processed frames: 1060
MFX session 2 transcoding FAILED
Processing time: 491.61 sec
Number of processed frames: 1077
MFX session 3 transcoding FAILED
Processing time: 491.59 sec
Number of processed frames: 1077

Return on error: error code 1, .\src\sample_multi_transcode.cpp 629

It actually ran quite a while before "Return on error" happened. Could this be caused by LA BRC, i.e. look-ahead bitrate control? Should I have used -async (and how)?

update: ran the exact same params, but with one addition to line 1: "-async 2". Transcoding finished without errors this time.


This all is likely related to -hw option, maybe some constraints of GPU.
(I cannot test HW acceleration yet - hopefully in next few weeks I'll have access to Haswell to check and tune it :) )

[colinhunt]

This all is likely related to -hw option, maybe some constraints of GPU.
Probably. Adding -async seems to have solved it, though.

[colinhunt]

Haven't got the foggiest idea how this happened or who did it... but some software/hardware encoding comparison files are located here (http://www.filedropper.com/clips).

[frencher]

Hi,

Minor update FRIM 1.16 is available.
Key changes:

FRIM Encoder 1.16
- workaround for Avisynth error (occasionally Avisynth 2.5.8 doesn't feed R-eye in -sbs mode) - please try if it helped

FRIM Encoder and Transcoder 1.16
- allowed bitrate higher than 65000 Kbps (although I personally doubt whether it is reasonable and useful :) )

(rest is in Release notes)

Cool interest update :p

Thank's videofan3d

[colinhunt]

What the... For poops and giggles, I tried to run FRIMTranscode in Hardware mode on i7-3930K. I was under the impression 3930K lacks the required hardware entirely, but nope, Transcode proceeded to run with -hw option just fine.

1000 frames on 3930K (u4)
hw decode 61.33 sec
hw encode (LA BRC) 62.01 sec (garbled output)

sw decode 58.66 sec
hw encode (LA BRC) 59.31 sec

sw decode 56.77 sec
hw encode (vbr) 57.42 sec

sw decode 52.04 sec
sw encode (vbr) 52.75 sec

sw decode 51.92 sec
sw encode (LA BRC [shouldn't work with -sw]) 52.66 sec

//

Compared -sw vbr and -sw labrc encoded outputs. Both are the same size, 84 523KB, but MediaInfo reports something interesting:

VBR: Maximum bit rate - 21.8 Mbps (-vbr 34000 40000)
LA BRC: Maximum bit rate - 62.5 Mbps (-labrc 34000 0)

[Sharc]

Only with Stereoscopic Player, not with TMT6.
For me, I think is SP.
I don't think it's Stereoscopic Player.
- the base and dependent views of the transcoded combinedMVC.h264 seem to be ok. Both views playback without problems.
- the glitch (garbled picture) comes only after remuxing the combinedMVC.h264 to .m2ts or ISO with tsMuxeR => the dependent view gets garbled and playback stops.
I noticed that tsMuxeR had to modify the h264 bitstream by inserting nal unit delimiters for some reason.

Anyway, I did it again using pipes instead of transcode and everything seems to be ok now.
I guess I put this problem aside for now. I may try transcoding later again with version 1.16.

[videofan3d]

What the... For poops and giggles, I tried to run FRIMTranscode in Hardware mode on i7-3930K. I was under the impression 3930K lacks the required hardware entirely, but nope, Transcode proceeded to run with -hw option just fine.

Compared -sw vbr and -sw labrc encoded outputs. Both are the same size, 84 523KB, but MediaInfo reports something interesting:

VBR: Maximum bit rate - 21.8 Mbps (-vbr 34000 40000)
LA BRC: Maximum bit rate - 62.5 Mbps (-labrc 34000 0)

Understand it might be "strange"...
I will check and tune -hw option once being able to use I7 for development...

[nunub]

@cedvano
Thanks for ur effort in producing a gui for frim transcoder but it would be still nicer for the whole 3d community to get a gui for frim encoder too.

[Cedvano]

@cedvano
Thanks for ur effort in producing a gui for frim transcoder but it would be still nicer for the whole 3d community to get a gui for frim encoder too.

It's in my project to include FRIM Encoder too.

[nunub]

@cedvano
That's great hearing from u.

[colinhunt]

It's in my project to include FRIM Encoder too.
Great!

[colinhunt]

FRIMTranscode GUI 1.04 (https://drive.google.com/file/d/0BxjaFf3cdexVV0NXSE14Sko5WHM/edit?usp=sharing)
version 1.04
- Add SSIF and MPLS support
- Include tsMuxer by Roman/Physic
Cedvano, one thing I believe the GUI should absolutely have: a built-in file size/bitrate calculator! It would be extremely useful to see immediately how large the resulting output file will be when encoded at the average bitrate user entered.

Wrt v1.04: Bitrates, shouldn't "min" be "avg"?

[Cedvano]

Cedvano, one thing I believe the GUI should absolutely have: a built-in file size/bitrate calculator! It would be extremely useful to see immediately how large the resulting output file will be when encoded at the average bitrate user entered.

Yes, I want to put this function in. But actually the result for a movie is not good (to smaller result).

For a small video, the size is good.

If someone have a good bitrate calcul, I take it.

[Sharc]

Yes, I want to put this function in. But actually the result for a movie is not good (to smaller result).

For a small video, the size is good.

If someone have a good bitrate calcul, I take it.
There is one available in the MeGUI Tools.

[colinhunt]

Yes, I want to put this function in. But actually the result for a movie is not good (to smaller result).
Others may disagree, but for my use it doesn't have to be 100% accurate. In fact, it's only good if the output is smaller than the estimate, because there are overheads to think of in muxing and in burning to disc.

[Sharc]

http://sourceforge.net/projects/bitratecalc/

I didn't try it. Overhead for BD muxing is a bit tricky.

[colinhunt]

http://sourceforge.net/projects/bitratecalc/

I didn't try it. Overhead for BD muxing is a bit tricky.
I suppose that's exactly why that calculator does not account for containers :)

[Sharc]

You have the choice:
http://www.videohelp.com/tools/sections/bitrate-calculators

I recall that AVCHDcalculator was one of the better ones....

[Cedvano]

http://sourceforge.net/projects/bitratecalc/

I didn't try it. Overhead for BD muxing is a bit tricky.

I use this one, I integrate it.

After some tests, I modify it later.

[Cedvano]

Hi guys,

Here the new release (with new name)

http://forum.doom9.org/showthread.php?t=169801

[colinhunt]

Hi guys,

Here the new release (with new name)

http://forum.doom9.org/showthread.php?t=169801
Thanks! I'll give it a try when the current transcoding is finished.

[colinhunt]

Had my first glitchy encode using Transcoder (v1.16). Demuxed source into avc + mvc with tsmuxer v2.2.3, ran Transcoder via cedvano's GUI. Output file appears to be OK and I can mux it into ISO using original playlist with tsmuxer, but mounting & playing the ISO results in movie freezing at the 19 minute mark. While the movie runtime looks normal, rest of the movie from 19 minutes onwards is a freeze frame without audio. Tested on Stereoscopic Player and a couple of PowerDVDs.

[Sharc]

Had my first glitchy encode using Transcoder (v1.16). Output files appear to be OK and I can mux them into a ISO with tsmuxer, but mounting & playing the ISO results in movie freezing at the 19 minute mark. Tested on Stereoscopic Player and a couple of PowerDVDs.
Hear hear..... ;)
Try with Pipes.

[colinhunt]

Hear hear..... ;)
Try with Pipes.
Yeah, I'm now testing cedvano's new GUI which allows the use of FRIMEncoder & pipes.

[nunub]

@cedvano
I m using 64bit windows 8 pro and i m getting error as such can't open command files.

[Cedvano]

@cedvano
I m using 64bit windows 8 pro and i m getting error as such can't open command files.

For encoding or demux ?

[videofan3d]

I started some tests with -hw coding.

@colinhunt
I didn't realize any problems with decoding:

FRIMDecode mvc -i test.h264 -o test_hw.yuv -hw
and
FRIMDecode mvc -i test.h264 -o test_sw.yuv

test.h264 was sample of Full HD-MVC-3D video (~80 seconds)

Both of them gave me byte-identical test_hw_L.yuv and test_sw_L.yuv . (and the same for R-eye).
Which I expect to be...

(Running on i7 Haswell - Intel Graphics 4600, Win8/64)

[colinhunt]

@colinhunt
I didn't realize any problems with decoding (Running on i7 Haswell - Intel Graphics 4600, Win8/64)
OK, let's do some comparison and debugging. Firstly, my systems are running Win7/64. Secondly, my latest CPU is i7-3770K, an Ivy Bridge CPU, with Intel Graphics HD4000. Thirdly, I never tested decoding like that, i.e outputting to a .yuv file. All my tests were done by piping directly from Decoder to Encoder, then dropping the output into tsmuxer and muxing into an .ISO file. There's a lot of difference in our respective test environments and methods, in other words.

Can you check what versions of libmfxhw32.dll and libmfxhw64.dll you have? Mine are 4.13.7.5; Digital signature timestamp is 5.7.2013.

[colinhunt]

videofan3d, this may have been asked earlier, but.... will FRIMEncode ever support 2-pass encoding?

[videofan3d]

videofan3d, this may have been asked earlier, but.... will FRIMEncode ever support 2-pass encoding?

Once Intel provides support for it :)

In my opinion - two pass is not necessary.
It can help only better to estimate total output file size, and thus provide bitrate control method "fit into size".

However, if you are interested in encoding quality, then every single pass encoder can do the job. MPEG compression is based on GOP, so if encoder can fit and process whole GOP, then it is - at least in theory - able to set all parameters for high-quality encoding.

[colinhunt]

In my opinion - two pass is not necessary.
It can help only better to estimate total output file size, and thus provide bitrate control method "fit into size".
I was under the impression that 2-pass also results in better, more efficient distribution of the available bit budget?

[HWK]

videofan3d, do you think it would be possible add support for creating I frame. Let say I want to insert I frame for chapters. I can specify 00:01:01:01, 00:04:02:08, 00:08:05:06 ....

[HWK]

I was under the impression that 2-pass also results in better, more efficient distribution of the available bit budget?

It does, since encoder know before hand how to best distribute bits throughout video.

[videofan3d]

videofan3d, do you think it would be possible add support for creating I frame. Let say I want to insert I frame for chapters. I can specify 00:01:01:01, 00:04:02:08, 00:08:05:06 ....

This I need to check - I guess that Intel provides some support for GOP manipulation .... patience, please :)

[HWK]

This I need to check - I guess that Intel provides some support for GOP manipulation .... patience, please :)

Thanks, Jdobbs wanted this feature as well for his program.

[videofan3d]

Can you check what versions of libmfxhw32.dll and libmfxhw64.dll you have? Mine are 4.13.7.5; Digital signature timestamp is 5.7.2013.

My libmfxhw32.dll is 4.13.9.19 (dig. signature 19.9.2013), libmfxhw64.dll the same.

I conducted some further performance tests:

Machine: Intel i7-4770K 3.5 GHz (Haswell), Intel Graphics HD 4600, 16 GB RAM:

Real Full HD 3D video ~80 seconds (1942 frames x 2 (for 3D)):

Decoding to regular yuv-file:

sw-decoding on regular HDD 271.33 s
hw-decoding on regular HDD 240.41 s
(i.e. not so much difference)

sw-decoding on SSD drive 74.79 s
hw-decoding on SSD drive 22.42 s (!)
(i.e. this is great)

This shows that bottleneck is disk access, decoding process itself is faster, and even much faster in -hw mode.

To separate decoding from disk access, I also ran the same decoding test with writing output to nul-device ( \\.\nul ),
i.e. eliminating disk write completely:

sw-decoding to nul-device 70.94 s
hw-decoding to nul-device 9.31 s

Fantastic! - Hardware decoding itself is almost 8x faster !!!
All the rest is thrown by disk access.
Use of pipes will probably lie somewhere between SSD and null-device.

Remember: uncompressed 3D YUV-video represents 2x3 MB per frame!, this is really huge volume of data to be written to disk.

This shows (together with proven identity of output file)that hardware decoding should be used if possible.

Could somebody conclude similar test and confirm these results? :)


(I'm looking forward to test also encoding performance - later this week)

[colinhunt]

My libmfxhw32.dll is 4.13.9.19 (dig. signature 19.9.2013), libmfxhw64.dll the same.
Good; can you tell me where I can download these newer versions?

[videofan3d]

Good; can you tell me where I can download these newer versions?

I think you need to run some "Intel video driver update" of whatever similar on your PC.
There is a lot of files in "c:\Program Files\Intel\Media SDK" which are related and hardware dependent.

[colinhunt]

I think you need to run some "Intel video driver update" of whatever similar on your PC.
There is a lot of files in "c:\Program Files\Intel\Media SDK" which are related and hardware dependent.
Downloaded the latest 32bit HD4600 drivers from Intel, and inside the .zip there's an even newer libmfxhw32.dll: v4.13.10.3, dated 3.10.2013.

No libmfxsw32.dll, however.

[videofan3d]

Downloaded the latest 32bit HD4600 drivers from Intel, and inside the .zip there's an even newer libmfxhw32.dll: v4.13.10.3, dated 3.10.2013.

No libmfxsw32.dll, however.

libmfxsw32.dll is in FRIM Installation package :)

[colinhunt]

libmfxsw32.dll is in FRIM Installation package :)
I know ;) I was only looking for a newer one.

[videofan3d]

@Cedvano:

Just a little heads up for GUI:
Next version FRIM 1.18 will contain few new/changed features:

FRIM "all" 1.18
- processing info message now reports correct number of processed frames (for "mvc" NOT(!) multiplied by 2 anymore)
- added parameter "-start firstFrame" (for processing), together with "-length" allows decode/encode portions of the video stream
optionally, SMPTE format is allowed: -start 00:01:25:14 -length 00:00:05:07
- unified option naming: -sw or -hw, -d3d, -d3d11
- running platform is now detected automatically, i.e. "software mode" (using libmfxsw32.dll) is not a default anymore!
To force "software mode" you MUST specify "-sw" option

FRIM Encoder 1.18
FRIM Decoder 1.18
- option "-b" removed, use "-cbr" instead
- changed of syntax of "-i" and "-o" (to be unified with FRIM Transcoder)
e.g.:
FRIMDecode -i::mvc input_base.avc input_dependent.mvc -o output_L.yuv output_R.yuv
FRIMEncode -i input_L.yuv input_R.yuv -o::mvc output_base.avc output_dependent.mvc -viewoutput -vbr 24000 40000

(previous syntax still remains valid, but this new one is preferred)

FRIM 1.18 will be released in second half of this week - stay tuned ;)...

[Cedvano]

@videofan3d
Ok, thanks for your information. I'm waiting this next version for change mine.
Great job !

[trevorjharris]

Please can you fix the avs problem.

[videofan3d]

Please can you fix the avs problem.

Please specify what is the problem?
(I didn't face any further issues with Avisynth)

I need to reproduce it first...

[trevorjharris]

Using very simple avs file

AVISource("e:\video\FRIM\old warden-lp.avi")
converttoyv12()

E:\video\frim>frimencode h264 -avi -i l.avs -viewoutput -o l.h264 -vbr 28000 40000 -u 7 -w 1920 -h 1080
FRIM Encoder version 1.16 (build: Nov 21 2013)
- based on Intel(R) Media SDK


ERROR: Cannot get YUV420 frame from input avi-file l.avs

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

Using latest avisynth 2.6. I have also tried sbs video.

[videofan3d]

Using very simple avs file

AVISource("e:\video\FRIM\old warden-lp.avi")
converttoyv12()


Using latest avisynth 2.6. I have also tried sbs video.

It is some problem with Video for Windows API on your machine, VFW doesn't provide frames in proper format (or at all).

Two questions:
1. Can you open and play the same avs file using standard Windows Media Player? And/or with MPC-HC ?

2. Do you have installed necessary codecs, e.g. "K-Lite Codec Pack" ?

[trevorjharris]

My "windows media player" does not support avs. However the avi file does play in windows media server. The avs file does work with virtualdub. The file is encoded with cineform and all the codecs are installed. The issue of not recognising YUV420 was mentioned in previous posts.

[Sharc]

My "windows media player" does not support avs. However the avi file does play in windows media server. The avs file does work with virtualdub. The file is encoded with cineform and all the codecs are installed. The issue of not recognising YUV420 was mentioned in previous posts.
Check your ffdshow Settings:
VFW-Configuration/Decoder/Codecs => RAW Video =>all supported

[videofan3d]

My "windows media player" does not support avs. However the avi file does play in windows media server. The avs file does work with virtualdub. The file is encoded with cineform and all the codecs are installed. The issue of not recognising YUV420 was mentioned in previous posts.

This is the problem - you have to make sure that avs is available for VFW. Usually, when an old Windows Media Player is able to play the avs, then it works.
Try also suggestion from Sharc.

FRIM is reading frames via VFW AVI-API, and requests final YUV420 stream. The original source is hidden behind this API and VFW/Windows/installed codecs are responsible for proper transformation.

[videofan3d]

Hi,

FRIM 1.18 is available for download.
(Key info in previous post - please read Release notes!)

[Sharc]

Thanks!

[trevorjharris]

Thankyou Sharc and Videofan3d

Check your ffdshow Settings:
VFW-Configuration/Decoder/Codecs => RAW Video =>all supported

I reinstalled ffdshow and set as above. Please can you tell me why this is important. I didn't think fddshow was used.

I have found that the avs file will not play if the converttoyv12 is included. If I remove it it does play but also says it does not recognize avs file.

So there does seem be be something wrong with converttoyv12.

[Sharc]

Thankyou Sharc and Videofan3d



I reinstalled ffdshow and set as above. Please can you tell me why this is important. I didn't think fddshow was used.


The answer is quite simple:
- When I don't enable it for VFW I get exactly your error messages.
- When I set it to "all supported" it works just fine.

Make sure that you press the 'Accept' button before OK in the ffdshow GUI. Pressing OK only is not effective.

You may also want to try with DirectShowSource("....") in your script instead of AVISource.

[trevorjharris]

I have definitly set "all supported" for RAW ffdshow. I tried direct show but that did work in virtualdub but not in wmp. I have uninstalled avisynth and reinstalled ( version 18 September 2013 2.6.0.4). I have also tried an avi file compressed with Lagarith YV12 and that does not work either. I am using windows 7 64bit.

[HWK]

I have also tried an avi file compressed with Lagarith YV12 and that does not work either. I am using windows 7 64bit.

I am using Lagarith as well with avi file and it works for me through Avisynth. You do know by default file compressed with lagarith won't work in avisynth. Also I am using windows 7 64 Ultimate as well.

More info from you would help.

[Sharc]

@trevorjharris
Do you have codec packs installed? Filter merit changed?
Maybe you run Codec Tweak Tool and check for broken filters.

When your *.avs plays in any other player (like vdub, mpc, mpc-hc) except wmp then you should not get error messages with FRIMencode, even though your script may not play in wmp. Don't worry about wmp.

[trevorjharris]

It works!!!!!

It turns out there are lots of different version of ffdshow out there. I finaly got one from sourceforge which is very recent. Thank you very much to everyone who has helped.

[frencher]

@videofan3d
FRIMencode with avisynth 2.5.8 stable version now fixed ;)
Thank's for FIX.
Recode in 2 pass mode for increase quality with low bitrate
Remaining time

[Sharc]

It works!!!!!

It turns out there are lots of different version of ffdshow out there. I finaly got one from sourceforge which is very recent. Thank you very much to everyone who has helped.

Cool!

[Cedvano]

Hi,

FRIM 1.18 is available for download.
(Key info in previous post - please read Release notes!)

Great, I work my software with this new version.
I just add some features, include new functions (start-end frames). I give my new version this week-end.

[alexxdls]

Hi there!
I have a broblem with AVS with RawSource() encoding.
Execute stringTools\FRIMEncode -tab 2 -i d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV_BD3D.avs -o::mvc d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV.avc d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV.mvc -viewoutput -w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1
AVS fileL=RawSource("d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV_1_LEFT.yuv",1920,1080,"I420") ++ RawSource("d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV_2_LEFT.yuv",1920,1080,"I420")
R=RawSource("d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV_1_RIGHT.yuv",1920,1080,"I420") ++ RawSource("d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV_2_RIGHT.yuv",1920,1080,"I420")
StackVertical(L,R)
ConvertToYV12()
AssumeFPS(24)AviSynth v.2.6.0 Alpha 6 is installed
VirtualDub opens AVS file properly (watch the attache file)
But FRIM Encoder runs with 0 frames encodedFRIM Encoder version 1.18 (build: Nov 26 2013)
- based on Intel(R) Media SDK

Media SDK impl SOFTWARE (d:\TEMP\MyDCPConverter\Tools\libmfxsw32.dll)
Media SDK version 1.7
Memory type System

Input format YUV420

Output video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 24.000
Bitrate control VBR
avg,maximum 28000,40000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 1 (quality)

Processing started
Frame number: 0
Processing finished in 0.01 secondsWhat is wrong here?

[Sharc]

alexxdls:

Try with changing position of -viewoutput

Tools\FRIMEncode -tab 2 -i d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV_BD3D.avs -viewoutput -o::mvc d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV.avc d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV.mvc -w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1

[alexxdls]

alexxdls:

Try with changing position of -viewoutput

Tools\FRIMEncode -tab 2 -i d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV_BD3D.avs -viewoutput -o::mvc d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV.avc d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV.mvc -w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1The same result. 0 frames

[videofan3d]

Hi there!
I have a broblem with AVS with RawSource() encoding.
Execute stringAVS fileAviSynth v.2.6.0 Alpha 6 is installed
VirtualDub opens AVS file properly (watch the attache file)
But FRIM Encoder runs with 0 frames encoded

What is wrong here?

It seems that
-avi is missing (Avisynth script is kind of avi-file )
-w -h and -f are then redundant

[alexxdls]

It seems that
-avi is missing (Avisynth script is kind of avi-file )
-w -h and -f are then redundantd:\TEMP\MyDCPConverter>Tools\FRIMEncode -avi -tab 2 -i d:\TRAILERS\DCP\47-RONIN_
TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51
_2K_UP_20131030_MPS_IOP_OV_BD3D.avs -o::mvc d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_
RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_2013
1030_MPS_IOP_OV.avc d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_201310
30_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV.mvc -vie
woutput -vbr 28000 40000 -u 1
FRIM Encoder version 1.18 (build: Nov 26 2013)
- based on Intel(R) Media SDK


ERROR: Cannot get YUV420 frame from input avi-file d:\TRAILERS\DCP\47-RONIN_TLR-
C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_
UP_20131030_MPS_IOP_OV_BD3D.avs

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

[videofan3d]

ERROR: Cannot get YUV420 frame from input avi-file d:\TRAILERS\DCP\47-RONIN_TLR-
C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_
UP_20131030_MPS_IOP_OV_BD3D.avs

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

Well!

Now read an advice about ffdshow setting just few post above :)
(From Sharc to trevorjharris)

[trevorjharris]

I am finding Frimencode to be rather slow. I have an HP Z800 with 2 xeon X5660 (24 threads), 48 GB of memory, Raid 5 drives and Quatro 5000 graphics card. I am getting about 1.5 frames per second with an mvc encode. I run windows 7 64 bit. I guess the the Intel Media SDK only supports hardware acceleration on it's own gpu's. My graphics card has a load of CUDA gpus. Can Intel Media SDK use Nvidias GP or can I buy a pci card with a supported Intel accelerator on it?

Thanks

[videofan3d]

I am finding Frimencode to be rather slow. I have an HP Z800 with 2 xeon X5660 (24 threads), 48 GB of memory, Raid 5 drives and Quatro 5000 graphics card. I am getting about 1.5 frames per second with an mvc encode. I run windows 7 64 bit. I guess the the Intel Media SDK only supports hardware acceleration on it's own gpu's. My graphics card has a load of CUDA gpus. Can Intel Media SDK use Nvidias GP or can I buy a pci card with a supported Intel accelerator on it?

Thanks

Obviously, Intel supports only its own graphics :)

Good side of the coin is, that we've got -sw mode which can run on every Win7/8 PC and supports MVC, and is free!
As far as I know, there is no other free MVC encoder at all.
(Commercial MVC encoders are above 1000 USD ...)

[HWK]

Obviously, Intel supports only its own graphics :)

Good side of the coin is, that we've got -sw mode which can run on every Win7/8 PC and supports MVC, and is free!
As far as I know, there is no other free MVC encoder at all.
(Commercial MVC encoders are above 1000 USD ...)

Yes, Indeed cheapest one around 6000 USD but not very useful. If you looking for good ones price easily go up-to 10000 USD for encoder only.

[alexxdls]

After VFW-Configuration/Decoder/Codecs => RAW Video => all supported => Apply my command runs with no error.

But I work on software that runs encoding commands and it should work without any additional actions and system configurations. May be is it possible to ad some function to be able to run FRIMEncode mvc -i LEFT_1.yuv+LEFT_2.yuv+...+LEFT_n.yuv -i RIGHT_1.yuv+RIGHT_2.yuv+...+RIGHT_n.yuv ,,,?

[trevorjharris]

Actually I use Vegas pro which does encode mvc. There is a cheaper option as well. I have been looking into hardware acceleration with Intel Media Sdk. The trouble is I know next to nothing about it. It seems that Intel uses opencl for non intel hardware. Unfortunatly this is not very well supported. The Intel Media Sdk does talk about using other acceleration platforms. Most video applications I know support CUDA. I will look into this more as it means Frimencode is not practical for every day use at the moment.

[Sharc]

Has anyone been successful with piping FRIMDecode to x264.exe?
Separate decoding to .yuv with subsequent encoding from .yuv to .h264 with x264 is working well, however no luck with piping like:
FRIMDecode.exe i::h264 inputfile.264 -o \\.\pipe\TMP.yuv | x264.exe --crf 24 --output "C:\temp\scratch\frimtest.h264" "\\.\pipe\TMP.yuv" --input-res 1920x1080 --fps 23.976
I get the x264 error: could not open input file '\\.\pipe\TMP.yuv'

[alexxdls]

Got another broblem. I execute commands automaticly with VBS script. There was everything ok with the older version of FRIM and left.yuv and right.yuv as inputs. Now avc and mvc encoding fails if I run FRIMEncode.exe with my script. But if I run the SAME command manualy (in CMD or TotalCommander) encoding goes right. It blows my mind.
And, videofan3d, could you sign your application? Windows always asks permition to execute the file.

[videofan3d]

Has anyone been successful with piping FRIMDecode to x264.exe?
Separate decoding to .yuv with subsequent encoding from .yuv to .h264 with x264 is working well, however no luck with piping like:
FRIMDecode.exe i::h264 inputfile.264 -o \\.\pipe\TMP.yuv | x264.exe --crf 24 --output "C:\temp\scratch\frimtest.h264" "\\.\pipe\TMP.yuv" --input-res 1920x1080 --fps 23.976
I get the x264 error: could not open input file '\\.\pipe\TMP.yuv'

There might be few issues with x264:

1. possibly x264 cannot read input from named-pipe.
2. x264 reads input in non-sequential way and performs "seek-to-begin" operation. If this is the case, that pipes cannot be used (from their principle). Please remember, prerequisite for using pipes is only sequential reading of input file. This also implies that you can use only 1-pass x264 encoding!
3. there might be a timing issue: x264 starts too quickly and FRIMDecode didn't manage to open an output pipe yet.
(This might be resolved by some wait or pause command in shell cmd-script)

Update:
I did some tests:
1. when using regular file TMP.yuv, then all worked - x264 created an elementary frimtest.h264

2. when I replaced | x264 by ffmpeg:
| ffmpeg.exe -f rawvideo -s 1920x1080 -r 23.976 -pix_fmt yuv420p -i \\.\pipe\TMP.yuv -vcodec copy -an -y frimtest.avi

then I got an output frimtest.avi (actual compression doesn't matter in this test)

This means that x264 somehow doesn't work with pipes correctly (or not at all :( )
- it looks that it tries to seek over an input file, which is forbidden operation for pipe. Pipe can be only read sequentially...

[videofan3d]

Actually I use Vegas pro which does encode mvc. There is a cheaper option as well. I have been looking into hardware acceleration with Intel Media Sdk. The trouble is I know next to nothing about it. It seems that Intel uses opencl for non intel hardware. Unfortunatly this is not very well supported. The Intel Media Sdk does talk about using other acceleration platforms. Most video applications I know support CUDA. I will look into this more as it means Frimencode is not practical for every day use at the moment.

Everybody has a choice. :)
(Vegas is also not free)

[alexxdls]

videofan3d, what about the bug I reported?Tools\FRIMEncode -avi -tab 2 -i "d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51
_2K_UP_20131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IO
P_OV_BD3D.avs" -o::mvc "d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20
131030_MPS_IOP_OV\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV.avc"
"d:\TRAILERS\DCP\47-RONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV\47-R
ONIN_TLR-C-3D_S_RU-XX_RU_51_2K_UP_20131030_MPS_IOP_OV.mvc" -viewoutput -vbr 2800
0 40000 -u 1This command executed by VBScript's oShell.Run (FRIMEncodeString, 1, true) runs with the result of 0 frames encoded (I've attached the screenshot to this post)
If I run the SAME command in command line it everything goes ok

[videofan3d]

videofan3d, what about the bug I reported?

This command executed by VBScript's oShell.Run (FRIMEncodeString, 1, true) runs with the result of 0 frames encoded (I've attached the screenshot to this post)
If I run the SAME command in command line it everything goes ok

It seems to be an issue related to Visual Basic running environment (otherwise you'd get problems also in command line). Probably some problems with initialization of Avisynth in VB - or something similar.

But I'm not familiar with VB at all, sorry...

[Sharc]

There might be few issues with x264:

1. possibly x264 cannot read input from named-pipe.
2. x264 reads input in non-sequential way and performs "seek-to-begin" operation. If this is the case, that pipes cannot be used (from their principle). Please remember, prerequisite for using pipes is only sequential reading of input file. This also implies that you can use only 1-pass x264 encoding!
3. there might be a timing issue: x264 starts too quickly and FRIMDecode didn't manage to open an output pipe yet.
(This might be resolved by some wait or pause command in shell cmd-script)

Update:
I did some tests:
1. when using regular file TMP.yuv, then all worked - x264 created an elementary frimtest.h264

2. when I replaced | x264 by ffmpeg:
| ffmpeg.exe -f rawvideo -s 1920x1080 -r 23.976 -pix_fmt yuv420p -i \\.\pipe\TMP.yuv -vcodec copy -an -y frimtest.avi

then I got an output frimtest.avi (actual compression doesn't matter in this test)

This means that x264 somehow doesn't work with pipes correctly (or not at all :( )
- it looks that it tries to seek over an input file, which is forbidden operation for pipe. Pipe can be only read sequentially...
I tried with ffmpeg, but no luck. Error message similar as for x264:
\\.\pipe\TMP.yuv: No such file or Directory.

My cmd:
FRIMDecode.exe i::h264 00098.track_4113.264 -o \\.\pipe\TMP.yuv | ffmpeg.exe -f rawvideo -s 1920x1080 -r 23.976 -pix_fmt yuv420p -i \\.\pipe\TMP.yuv -vcodec copy -an -y "C:\temp\scratch\frimtest.h264"

[videofan3d]

I tried with ffmpeg, but no luck. Error message similar as for x264:
\\.\pipe\TMP.yuv: No such file or Directory.
[/CODE]

Likely there is missing "minus" -i::h264 :), but anyway I'm worried it is timing issue.

ffmpeg is trying to open its input file (pipe in your case) too early, before FRIMDecode creates it.

Btw. connecting these two commands using "|" is a bit unlucky and it is in essence useless, because "|" connects standard output of one process to standard input of other process (using anonymous pipes).
But it is not our case! We are creating and opening named-pipes for connection! We don't use stdin and stdout.

Generally you should use command "start" for (at least) the first process:

start FRIMDecode.exe -i::h264 original.h264 -o \\.\pipe\TMP.yuv

rem and now we need to wait some short time, till FRIMDEcode opens output pipe
rem if there would exist command like "wait 2", we could use it more elegant, but Microsoft doesn't have it :(
pause

ffmpeg.exe -f rawvideo -s 1920x1080 -r 23.976 -pix_fmt yuv420p -i \\.\pipe\TMP.yuv -vcodec copy -an -y result.h264


Remark:
once you tune this, you can hide the "start" window like this

start /B FRIMDecode.exe -i::h264 original.h264 -o \\.\pipe\TMP.yuv 2>nul >nul

[trevorjharris]

Hi Videofan3d

I have found that the Nvidia Quadro 5000 does support opencl which should be supported by Intel Media SDK. Some did say

>>>In this set up you will be able to use hardware decoding/encoding with Media SDK just fine. The only detail you need to care of is to request the appropriate implementation type of Media SDK library in MFXInit call. For example you can use MFX_IMPL_HARDWARE_ANY (Find the platform-specific implementation on any display adapter including the default display adapter).For more detail please check out MFXImpl enumerator in the Media SDK reference manual (the file mediasdk_man.pdf under \doc).

Please can you tell me if this is set in MXFImpl in Frimencoder?

Thanks

[Sharc]

Likely there is missing "minus" -i::h264 :), but anyway I'm worried it is timing issue.

ffmpeg is trying to open its input file (pipe in your case) too early, before FRIMDecode creates it.

Btw. connecting these two commands using "|" is a bit unlucky and it is in essence useless, because "|" connects standard output of one process to standard input of other process (using anonymous pipes).
But it is not our case! We are creating and opening named-pipes for connection! We don't use stdin and stdout.

Generally you should use command "start" for (at least) the first process:

start FRIMDecode.exe -i::h264 original.h264 -o \\.\pipe\TMP.yuv

rem and now we need to wait some short time, till FRIMDEcode opens output pipe
rem if there would exist command like "wait 2", we could use it more elegant, but Microsoft doesn't have it :(
pause

ffmpeg.exe -f rawvideo -s 1920x1080 -r 23.976 -pix_fmt yuv420p -i \\.\pipe\TMP.yuv -vcodec copy -an -y result.h264


Remark:
once you tune this, you can hide the "start" window like this

start /B FRIMDecode.exe -i::h264 original.h264 -o \\.\pipe\TMP.yuv 2>nul >nul

Yes, Start .... pause for the decoding process did the trick. Thanks! :)

[videofan3d]

Hi Videofan3d

I have found that the Nvidia Quadro 5000 does support opencl which should be supported by Intel Media SDK. Some did say

>>>In this set up you will be able to use hardware decoding/encoding with Media SDK just fine. The only detail you need to care of is to request the appropriate implementation type of Media SDK library in MFXInit call. For example you can use MFX_IMPL_HARDWARE_ANY (Find the platform-specific implementation on any display adapter including the default display adapter).For more detail please check out MFXImpl enumerator in the Media SDK reference manual (the file mediasdk_man.pdf under \doc).

Please can you tell me if this is set in MXFImpl in Frimencoder?

Thanks

FRIM starting 1.18 is using autodetect:
i.e. it calls MFXInit(MFX_IMPL_AUTO_ANY), so system itself detects if to use hardware or software platform.
When you specify -sw, it uses MFXInit(MFX_IMPL_SOFTWARE),
and finally, -hw initiates MFXInit(MFX_IMPL_HARDWARE_ANY)

FRIM reports actually used platform and used dll library in info message.

[ExSport]

rem and now we need to wait some short time, till FRIMDEcode opens output pipe
rem if there would exist command like "wait 2", we could use it more elegant, but Microsoft doesn't have it :(
pause
...
Your tool doesn't work on Windows XP so you can use TIMEOUT command which is available from Vista (instead of PAUSE/PING etc...) :-)

[Sharc]

Your tool doesn't work on Windows XP so you can use TIMEOUT command which is available from Vista (instead of PAUSE/PING etc...) :-)
Yep, timeout works here on Windows 7. Thanks.

[alexxdls]

It seems to be an issue related to Visual Basic running environment (otherwise you'd get problems also in command line). Probably some problems with initialization of Avisynth in VB - or something similar.

But I'm not familiar with VB at all, sorry...VBS runs ffmpeg commands with AVS input without any bugs. It also runs FRIM commands with YUV input without bugs...
I askes you about possibility of merging YUVs at inputs. Is it possible to implent? I have to use AVS just because I need to merge parts of videostream for left and right eye.

[videofan3d]

VBS runs ffmpeg commands with AVS input without any bugs. It also runs FRIM commands with YUV input without bugs...
I askes you about possibility of merging YUVs at inputs. Is it possible to implent? I have to use AVS just because I need to merge parts of videostream for left and right eye.

I will put it on the feature list :)

[trevorjharris]

I have creared an avc and mvc file with frimencode with default setings. I then tired to import them into DVD Architect Pro 6.0 which supports mvc files. Unfortunatly it rejects the files as incompatable. Has anyone succesfully imported a frimencoded file into DVDA or other 3D Blu-ray authorer?.

[HWK]

I have creared an avc and mvc file with frimencode with default setings. I then tired to import them into DVD Architect Pro 6.0 which supports mvc files. Unfortunatly it rejects the files as incompatable. Has anyone succesfully imported a frimencoded file into DVDA or other 3D Blu-ray authorer?.

Is there an error you are getting from program or flat refuse to open file. Can you post sample related to this file for analysis make sure to upload avc and mvc stream.

[videofan3d]

I have creared an avc and mvc file with frimencode with default setings. I then tired to import them into DVD Architect Pro 6.0 which supports mvc files. Unfortunatly it rejects the files as incompatable. Has anyone succesfully imported a frimencoded file into DVDA or other 3D Blu-ray authorer?.

I personally don't have access to any official 3D Authoring SW, I rely on tsMuxer 3D.

It would be great if the guys, here who have such option, would share with us what is the best setting of FRIM parameters, i.e. the most compatible with BD3D standard :)
Thanks in advance...

[damorsoft]

This is no doubt the best thing for 3D ever!!! I love it, this and tsMuxeR combine to make the best BDR25 copies I have ever seen.
I wasn't crazy about the piping being an x264 kind of guy, but the quality is right up there.
Here is my notes that I put together may help abit.

HOWTO make 3DBDR25
1.Using ANYdvd copy 3Dmovie to some folder on C
2.Use eac3to to find mpls file of main movie
-c:\3d\eac3to\eac3to c:\3d\00002.mpls
-c:\3d\eac3to\eac3to c:\3d\00002.mpls 1) or what ever track you want..
-NOTE: length of movie and track #'s of left right audio
3.USE tsMuxeR to open the *.mpls and extract the left and right eyes and an audio
-rename the input files from tsMuxer sleft.264 and sright.mvc
-OR
-USE eac3to to open the *.mpls
-eg c:\3d\eac3to\eac3to c:\3d\00002.mpls 1: left.h264 2: right.h264 3: audio.ac3
4. CALCULATE bitrate kb/sec 1048576 bytes = 1MB
-DTS Audio = eg 1.23GiB
-MUX OVERHEAD = 2.5GiB total 3.73GiB
-25.0gib - 3.73gib = 21.2gib of video = 21,200,000,000 bytes
-1:46:40 =6360sec
-21200*8/6360=26.7 * 1,000,000 = 26700kb/sec
5. DEcode and ENcode with FRIM NOTE the input names are different with tsMuxeR and eac3to
-FRIMDecode mvc -i inputL.h264 -i inputR.h264 -o \\.\pipe\TMP.yuv | FRIMencode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o left.avc -o -right.mvc -w 1920 -h 1080 -f 23.976 -l 4 -cpbsize 3750 -vbr ***bitrate*** 60000 -u 4 -profile high -level 4.0 -gop 24 4 0 O
-You will get the elementary files for the base view left.avc and right.mvc
6. Start tsMuxeR, open the video files from 5, add the audio files from 3., select as output Blu-ray ISO
7. Burn the .iso
----------------- CMD files for Decoding NOTE input names ---------------------------------------------------------------------------
Convert.cmd
FRIMDecode mvc -i left.264 -i right.mvc -o \\.\pipe\TMP.yuv | FRIMencode.exe mvc -i \\.\pipe\TMP_L.yuv -i \\.\pipe\TMP_R.yuv -viewoutput -o nleft.avc -o nright.mvc -w 1920 -h 1080 -f 23.976 -l 4 -cpbsize 3750 -vbr 22300 60000 -u 4 -profile high -level 4.1 -gop 24 4 0 O

[tymoxa]

Has anyone succesfully imported a frimencoded file into DVDA or other 3D Blu-ray authorer?.

You can try this line:
FRIMEncode.exe mvc -i test_L.yuv -i test_R.yuv -viewoutput -o test.avc -o test.mvc -w 1920 -h 1080 -f 23.976 -u 4 -vbr 30000 40000 -cpbsize 3570 -l 6 -profile high -level 4.1 -gop 24 4 0 O -PicTimingSEI off -EndOfSequence off


This line gives bd compliant main stream. Dependent stream have one error: The order of SEI messages in a dependent unit is incorrect. DoStudio muxed such streams with no problem. Scenarist muxed too with one condition: you have to uncheck "Enable spec check.." in MUI-generator when throw .mvc on it.

[trevorjharris]

You can try this line:


This line gives bd compliant main stream. Dependent stream have one error: The order of SEI messages in a dependent unit is incorrect. DoStudio muxed such streams with no problem. Scenarist muxed too with one condition: you have to uncheck "Enable spec check.." in MUI-generator when throw .mvc on it.

Thankyou for your help. This did not work the error message was

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. Intel has a forum for the media SDK I may mention this there.

[tymoxa]

The dependent (.mvc) stream for the selected video is not Blu-ray complient or does not match the base stream.

You did something wrong.
Here is short sample encoded with FRIM: FRIM_SCEN_SAMPLE.zip (http://dl.dropboxusercontent.com/u/23069413/FRIM_SCEN_SAMPLE.zip)
Just change ESPath in .ves files for your path, drag-n-drop test.mvc.ves into Data Editor of Scenarist and when it ask for .avc - point to test.avc.ves.

[nunub]

I have creared an avc and mvc file with frimencode with default setings. I then tired to import them into DVD Architect Pro 6.0 which supports mvc files. Unfortunatly it rejects the files as incompatable. Has anyone succesfully imported a frimencoded file into DVDA or other 3D Blu-ray authorer?.

Even if it is saying the file is ok outside of vegas u will get later on multiplex error saying that u better render with vegas. It is only made for vegas.

[nunub]

frim encoder is the best and the fastest but lacking some compliancy factor just require some little tweaking, i hope the team of videofan3d and cedvano will complete this task also easily and very soon.

[Cedvano]

I terminate my software with multi-options (demux and remux inside)
But I must go in hospital this week and I'm late in my software.
I'm now in my house for 3 days, I hope to finish.

[HWK]

videofan3d, do you think it would be possible add support for creating I frame. Let say I want to insert I frame for chapters. I can specify 00:01:01:01, 00:04:02:08, 00:08:05:06 ....

This I need to check - I guess that Intel provides some support for GOP manipulation .... patience, please :)

Thanks, Jdobbs wanted this feature as well for his program.


Videofan3d, on Nov 25 I asked about is there ability in program to add I frame on demand for chapters. Did you get any chance to look into this.

[videofan3d]

Videofan3d, on Nov 25 I asked about is there ability in program to add I frame on demand for chapters. Did you get any chance to look into this.

Not yet - I'm busy now with my regular working staff :)
But still I keep it on the list ... ;)

[jdobbs]

@videofan3d

I'm a bit confused. Is libmfxsw32.dll required for FRIMDecode.exe and FRIMEncode.exe to run? I had assumed as much, but I just put just those two executables in a folder by themselves -- and they seem to be running fine without it. Am I missing something?

[HWK]

@videofan3d

I'm a bit confused. Is libmfxsw32.dll required for FRIMDecode.exe and FRIMEncode.exe to run? I had assumed as much, but I just put just those two executables in a folder by themselves -- and they seem to be running fine without it. Am I missing something?

I can confirm this as well, I ran Frim Encode, Decode and Transcoder and it is working or at least I can open executable. I will do encode and see how it goes and do some research at Intel site.

[HWK]

@videofan3d

I'm a bit confused. Is libmfxsw32.dll required for FRIMDecode.exe and FRIMEncode.exe to run? I had assumed as much, but I just put just those two executables in a folder by themselves -- and they seem to be running fine without it. Am I missing something?

Jdobbs, what is the make of your processor and details related to it.

[jdobbs]

Jdobbs, what is the make of your processor and details related to it.I've run it on two computers and both run fine without the DLL. One is running an AMD A6-3600 (4 core) and the other is an AMD FX-8350 (8 core) -- both are running Win7.

I'm going back through the previous pages of the thread to see what I can find. I saw this from the v1.18 release:

- running platform is now detected automatically, i.e. "software mode" (using libmfxsw32.dll) is not a default anymore!

I sounds like it must be related, but I don't really understand what it means.

I just need to find out if I need to distribute the DLL when I release the 3D version of BD-RB. The DLL is kinda' big and I don't want to include it if I don't have to.

[HWK]

Based on some reading at Intel website it seems this dll come handy when using feature such as

-labrc bitRate depth - LA BRC mode (in Kbits/s) for H.264 encoder
look ahead depth, in range [10,100] or 0(=auto),
number of frames to be analyzed before encoding
Supported only with -hw option on 4th Generation
on Intel Core processors

So far from my research it seems it is needed for 4th Generation on Intel Core processors, since frim take advantage of extra capabilities and if enabled during encoding. One of them is listed above, but let see what happens.

[jdobbs]

Based on some reading at Intel website it seems this dll come handy when using feature such as



So far from my research it seems it is needed for 4th Generation on Intel Core processors, since frim take advantage of extra capabilities and if enabled during encoding. One of them is listed above, but let see what happens.Since the default mode for hw/sw is auto -- I guess it's safest just to include the DLL. What kind of processor are you using? Is it an Intel platform?

[HWK]

Yeah, good idea. If I may can I ask on which day one might expect new version with 3D, since my finger has itching effect to try out new version :p

[HWK]

What kind of processor are you using? Is it an Intel platform?

Intel Core i7 3930K @ 4.5 GHZ

[jdobbs]

Yeah, good idea. If I may can I ask on which day one might expect new version with 3D, since my finger has itching effect to try out new version :pI'd guess some time in the next few days. I hate to be vague, but I don't know what I might run into. The new TSMUXER version helped by fixing the "PES len" error. But I also had to adjust in several places because the "mplsfile=" parameter is deprecated now. That means I have to start running through all the battery of test sources again.

[HWK]

I'd guess some time in the next few days. I hate to be vague, but I don't know what I might run into. The new TSMUXER version helped by fixing the "PES len" error. But I also had to adjust in several places because the "mplsfile=" parameter is deprecated now. That means I have to start running through all the battery of test sources again.

I understand, no pressure by any means. Also I can run some test to speed up if you want.

3D and 2D both available at your disposal and different encoders are available as well.

[damorsoft]

Playing with a gui for frim et al.

I have succeeded in running frim in myprocess but can not read the output.
have tried standard error and output I would like to show the frame# progress in my GUI.
eg. does not work

While (myProcess.HasExited = False)
Application.DoEvents()
Dim aLine As String = myProcess.StandardOutput.ReadLine
If (Not String.IsNullOrEmpty(aline)) Then
Label16.Text = aline ' & " % complete "
End If
End While

Thanks.

[Nico8583]

Hi,
Do you think it could be possible to create an Avisynth plugin with FRIM decoder ?
Thanks !

[jdobbs]

Hi,
Do you think it could be possible to create an Avisynth plugin with FRIM decoder ?
Thanks !That would be REALLY nice. It would eliminate the need for HAALI and FFDSHOW from BD Rebuilder. The whole need for DirectshowSource() is a constant issue (especially when other software installs overwrites thing or changes system defaults).

[videofan3d]

That would be REALLY nice. It would eliminate the need for HAALI and FFDSHOW from BD Rebuilder. The whole need for DirectshowSource() is a constant issue (especially when other software installs overwrites thing or changes system defaults).

I'm worried it is not that simple / maybe even not possible.

FRIM Decoder is single pass decoder, you cannot scroll over the file there-and-back-again.

But Avisynth simulates AVI, which is in principle quite opposite.

[Sharc]

I'm worried it is not that simple / maybe even not possible.

FRIM Decoder is single pass decoder, you cannot scroll over the file there-and-back-again.
.....
This might be one of the reasons why piping of FRIMDecoder into x.264 seems not to work (at least I have not been successful)
Piping works with ffmpeg though.

[jdobbs]

I'm worried it is not that simple / maybe even not possible.

FRIM Decoder is single pass decoder, you cannot scroll over the file there-and-back-again.

But Avisynth simulates AVI, which is in principle quite opposite.There are other AVISYNTH decoders that don't support seeking. But you obviously know this software better than I do, so I'll assume it's a lost cause.

[frencher]

Hi,
Do you think it could be possible to create an Avisynth plugin with FRIM decoder ?
Thanks !

Very nice idea for full free MVC players ;) :goodpost:

[nunub]

@frencher
How it is that we are unable to download ur free mvc player although u r changing versions but i for one would not be able to download it.

[HWK]

@frencher
How it is that we are unable to download ur free mvc player although u r changing versions but i for one would not be able to download it.

I can download fine, can you explain error message or something similar to describe what you are experiencing.

[frencher]

Thanks for download test HWK ;)
nunub it's good ?

[nunub]

@frencher
I m experiencing difficulty from ur download site as ur page seems to me blank and even if i m trying to download it from frd it is showing as to no string attached.

[HWK]

@frencher
I m experiencing difficulty from ur download site as ur page seems to me blank and even if i m trying to download it from frd it is showing as to no string attached.

Try this link instead and see if it works, I have included MVC Player Free v0.0.2.6.rar & uNicAudio.dll + Source Code.rar

https://drive.google.com/file/d/0B2c8pQSAQa3qc0RUZG4tYkFZMWc/edit?usp=sharing

There are two rar file under one main rar file.

[nunub]

Try this link instead and see if it works, I have included MVC Player Free v0.0.2.6.rar & uNicAudio.dll + Source Code.rar

https://drive.google.com/file/d/0B2c8pQSAQa3qc0RUZG4tYkFZMWc/edit?usp=sharing

There are two rar file under one main rar file.

thanks for that link and on my 64bit win8 with 3dm2ts file it is unable to playback.

[frencher]

thanks for that link and on my 64bit win8 with 3dm2ts file it is unable to playback.


Continue this thread > Guide to convert BD 3D to 3D Left+Right Stereoscopic and Anaglyph (http://forum.doom9.org/showthread.php?p=1602605#post1602605)

Have you see my tutorial in my signature

[Thalyn]

Videofan3D: Is there any chance you could re-work the FRIMDecoder into an AVISynth plugin?

There's been a few issues cropping up with more recent rendered titles (DreamWorks and Disney/Pixar) that seem to be solved by FRIM, but there's no easy way to work it into AVISynth at present without a very large intermediate file.

[Sharc]

@Thalyn:
Sure, but see posts #403 .... 407.

[Thalyn]

Wow... I'm 2 and 0 for reading posts and forgetting their existence entirely within weeks. I'd quit while I'm ahead but, well, I can't even say that I'm ahead of anything.

Even without the seeking ability it would still be useful; so long as it's actually possible. I'm pretty sure H264StereoSource can't actually seek and it was remarkably useful (up until better tools became available).

[colinhunt]

OK guys, I'm running a slight fever and feeling kinda lazy... so can someone tell me if it's possible to use FRIM to create a proper (although lower on resolution) 3D Blu-ray from a Side-by-Side 3D video, and how?

[Sharc]

colinhunt:
What is your source (starting point) exactly? Is it a 2x960x1080 SBS in an .m2ts container?

If so, the workflow would likely be:
1) Demux the .m2ts (e.g. with tsMuxeR or eac3to)
2) Create a script 'input.avs' to resize the Video to 3840x1080
3) Encode with FRIMEncode
4) Remux encoded videostreams and Audio with tsMuxeR to a Blu-ray ISO.

Example for 3) cmd:

FRIMEncode -avi -sbs 2 -i input.avs -viewoutput -o::mvc base.avc dependent.mvc -w 1920 -h 1080 -l 6 -cpbsize 3750 -vbr 8000 15000 -u 4 -profile high -level 4.1 -gop 24 4 0 O -PicTimingSEI off -EndOfSequence off

(it's too late to try it here in detail now ....)

[HWK]

colinhunt:
What is your source (starting point) exactly? Is it a 2x960x1080 SBS in an .m2ts container?

Shouldn't it be 3840x1080 instead.

[Sharc]

Shouldn't it be 3840x1080 instead.
Yes, as a source for FRIMEncode.
SBS sources are however often 2x half horizontal resolution. These must be resized to (2x1920x1080) for FRIM in order to work. FRIMEncode output will then become 1920x1080 for Base and Dependent view.
(I edited my last post).

[colinhunt]

colinhunt:
What is your source (starting point) exactly? Is it a 2x960x1080 SBS in an .m2ts container?
It's a HDTV 3D broadcast, a Half-SBS, i.e. both views forced into a regular 1920x1080 frame by squeezing the views horizontally. In short, yes :)

So I need to stretch it into a Full-SBS 3840x1080 first, then feed it into FRIM encoder... right? I'm not much of an Avisynth scripter, unfortunately.

[Sharc]

It's a HDTV 3D broadcast, a Half-SBS, i.e. both views forced into a regular 1920x1080 frame by squeezing the views horizontally. In short, yes :)

So I need to stretch it into a Full-SBS 3840x1080 first, then feed it into FRIM encoder... right? I'm not much of an Avisynth scripter, unfortunately.

Save this code as text file named "input.avs" and use the FRIMEncode command as suggested in my previous post:

DirectShowSource("C:\.......\your_source.m2ts")
spline16resize(3840,1080)
converttoyv12()

[colinhunt]

Save this code as text file named "input.avs" and use the FRIMEncode command as suggested in my previous post:

DirectShowSource("C:\.......\your_source.m2ts")
spline16resize(3840,1080)
converttoyv12()
Brilliant. Thank you ever so much!

Whoops. On closer inspection (I blame the fever) I see the original is 1440x1080 and 29.97fps. Dammit.

Indexed the file with DGIndex and came up with an .avs like this:

LoadPlugin("DGDecode.dll")
DGDecode_mpeg2source("video.d2v")
Load_Stdcall_Plugin("yadif.dll")
Yadif(order=0)
ConvertFPS(23.976)
Spline16resize(3840,1080)
ConvertToYV12()

Running first test now.

u: Encode finished OK, but tsmuxer 2.6.7 could not create a readable ISO. Went back to 2.3.2 and all's fine... except skintones are messed up. Everyone has blue skin. Whaaa..?

[frencher]

There are other AVISYNTH decoders that don't support seeking. But you obviously know this software better than I do, so I'll assume it's a lost cause.

However someone has already done
http://forum.doom9.org/showthread.php?p=1658935&posted=1#post1658935
http://i41.tinypic.com/2rc2zbt.png

[jdobbs]

However someone has already done
http://forum.doom9.org/showthread.php?p=1658935&posted=1#post1658935
http://i41.tinypic.com/2rc2zbt.pngHmmm, that's interesting. Where is it available for download?

[frencher]

Hmmm, that's interesting. Where is it available for download?

From BDtoAVCHD install folder

[Nico8583]

You can find informations in 3D topic : http://forum.doom9.org/showthread.php?t=155246&page=88
MVCsource.dll is free to use but not to redistribute, you can see this point with the author (pistacho) ;)

[Cedvano]

I would like to encode directly a SSIF file, but with DirectShowMVCSource or SsifSource2, I've always an error.
Access violation for DirectShowMVC and another with Ssifsource
It's work fine with X264.
I use BD3D2MK3D scripts.
Someone have a solution ?
Thanks in advance.

[nunub]

I would like to encode directly a SSIF file, but with DirectShowMVCSource or SsifSource2, I've always an error.
Access violation for DirectShowMVC and another with Ssifsource
It's work fine with X264.
I use BD3D2MK3D scripts.
Someone have a solution ?
Thanks in advance.
what happen to that prestigious project of urs for frim encoder gui. The site has disappeared.

[Cedvano]

what happen to that prestigious project of urs for frim encoder gui. The site has disappeared.

I work on a complete software, but I would like to simplify this and encode without demuxing. Working directly with SSIF save time.
It's the reason of my question.

I add SBS->MVC and other options.

[nunub]

I work on a complete software, but I would like to simplify this and encode without demuxing. Working directly with SSIF save time.
It's the reason of my question.

I add SBS->MVC and other options.

Very great to hear from u at least u responded and i hope u complete that and also dont forget HOU also. I found the quality of intel mvc greater and also the speed.

[Cedvano]

Very great to hear from u at least u responded and i hope u complete that and also dont forget HOU also. I found the quality of intel mvc greater and also the speed.

Yes, it's a great encoder !

[colinhunt]

I add SBS->MVC and other options.
Ooh, that's a very welcome feature. Looking forward to the new software!

[jdobbs]

@videofan3d

Can you tell me what kind of security token you are creating when you set up the named pipe in FRIMDecode? I keep getting an "Access Denied" error when I try to open the named pipe from another app.

[Added] Is there any way FRIMDecode can be modified to allow output to stdout so it can be used with X264? If so, then I don't need an answer to the above question (it was just a CLI app that would input from the named pipe and output to stdout).

[videofan3d]

@videofan3d

Can you tell me what kind of security token you are creating when you set up the named pipe in FRIMDecode? I keep getting an "Access Denied" error when I try to open the named pipe from another app.

[Added] Is there any way FRIMDecode can be modified to allow output to stdout so it can be used with X264? If so, then I don't need an answer to the above question (it was just a CLI app that would input from the named pipe and output to stdout).

Technically: named pipe server is created using standard CreateNamedPipe() with security attributes NULL, i.e. named pipe gets a default security descriptor - see CreateNamedPipe (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).aspx). So security is purely derived from operating system.

stdout is not suitable for binary transfer in Windows environment since it is textual and translates \n to \r\n. :(

x264 seems not suitable for pipe processing, I observed it does not read input in purely sequential way but is seeks also backward, which in principle disallow using pipes...
(also two-pass encoding is out of the game when using pipes).
However, ffmpeg can read named pipe from FRIMDecode - this was already mentioned in this thread

[videofan3d]

FRIM 1.19 with minor updates is available:

FRIM Encoder with new optional parameters:
-rf numRefFrame .... parameter number of ref. frames
-ResetRefList on|off .... parameter for reset ref. frames
-goplog filename .... added report for actually created GOP structure

+ some minor fixes and internal code changes.

Also utilities bincopy.exe and pipecopy.exe added to distribution pack - see documentation.

[jdobbs]

Technically: named pipe server is created using standard CreateNamedPipe() with security attributes NULL, i.e. named pipe gets a default security descriptor - see CreateNamedPipe (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).aspx). So security is purely derived from operating system.

stdout is not suitable for binary transfer in Windows environment since it is textual and translates \n to \r\n. :(

x264 seems not suitable for pipe processing, I observed it does not read input in purely sequential way but is seeks also backward, which in principle disallow using pipes...
(also two-pass encoding is out of the game when using pipes).
However, ffmpeg can read named pipe from FRIMDecode - this was already mentioned in this threadI've tested X264 with sequential input through stdout/stdin using avs2yuv and it works fine.

Thanks for the new version. :)

[videofan3d]

I've tested X264 with sequential input through stdout/stdin using avs2yuv and it works fine.


I don't know details how x264 does work but neither myself nor other people here succeeded to use FRIMDecode as source for x264 - unfortunately.

avs2yuv probably translates AVS (i.e. AVI) to flat yuv, right?
This might be a key, because AVI container is "seekable"!
i.e. you can seek to the beginning.
I assume that x264 opens data-source, read some header or portion of data for preliminary analysis, then close it. and in the second round it re-open the source again and read it from beginning to the end.

But pipe is from its principle unidirectional channel, once it is closed, it is its end-of-life.
FRIMDecode uses pure pipe on its output, and there is no way to get a signal for re-opening the pipe.

Regarding stdout/stdin - I would be very careful when using it for binary data transfer.
Simple test:

char sss[] = "abcd\nefgh\n1234";
fwrite(sss, strlen (sss), 1, stdout);

will produce output (when redirected to file) with 16 bytes!
Each \n is converted to \r\n.
If you pass generic binary data via stdout (in Windows), you may get corrupted file! Maybe there is some switch in Windows to turn this translation off, but I'd prefer not to rely on this.

(Unlike in Unix, there is no new-line translation by definition)

[jdobbs]

I don't know details how x264 does work but neither myself nor other people here succeeded to use FRIMDecode as source for x264 - unfortunately.

avs2yuv probably translates AVS (i.e. AVI) to flat yuv, right?
This might be a key, because AVI container is "seekable"!
i.e. you can seek to the beginning.
I assume that x264 opens data-source, read some header or portion of data for preliminary analysis, then close it. and in the second round it re-open the source again and read it from beginning to the end.

But pipe is from its principle unidirectional channel, once it is closed, it is its end-of-life.
FRIMDecode uses pure pipe on its output, and there is no way to get a signal for re-opening the pipe.

Regarding stdout/stdin - I would be very careful when using it for binary data transfer.
Simple test:

char sss[] = "abcd\nefgh\n1234";
fwrite(sss, strlen (sss), 1, stdout);

will produce output (when redirected to file) with 16 bytes!
Each \n is converted to \r\n.
If you pass generic binary data via stdout (in Windows), you may get corrupted file! Maybe there is some switch in Windows to turn this translation off, but I'd prefer not to rely on this.

(Unlike in Unix, there is no new-line translation by definition)It's up to you, and you know FRIMDecode a lot better than I do... but people use stdin/stdout with binary data all the time. I've encoded entire movies feeding video through stdout/stdin using X264. It can't be seeking backward, because that method wouldn't allow it. As another example, in BD-RB I use stdin/stdout pipes between LAME and AFTEN for MP3 to AC3 encoding. I do the same using WAVI and AFTEN for reencoding .WAV to AC3. This is all done in a Windows environment. A lot of the open source CLI packages allow for input from stdin and output to stdout (usually using "-" as the file indicator for the command line).

[MasterNobody]

If you pass generic binary data via stdout (in Windows), you may get corrupted file! Maybe there is some switch in Windows to turn this translation off, but I'd prefer not to rely on this.

(Unlike in Unix, there is no new-line translation by definition)
There is simple way to make this standard streams binary in Windows:
#ifdef _WIN32
_setmode( _fileno( stdin ), _O_BINARY );
_setmode( _fileno( stdout ), _O_BINARY );
_setmode( _fileno( stderr ), _O_BINARY );
#endif
And that is pretty standard way so I don't see any problems with using it.

P.S. As for problem with x264 and named pipes. It was problem with double fopen/fclose because stat() function didn't worked with named pipes and so we couldn't find out if specified path is pipe or regular file (and default is regular file). This patch (http://privatepaste.com/e79989bceb) should fix it.

[jdobbs]

@videofan3d

Including an option for using stdout would certainly make encoding of SBS and O/U versions of 3D encodes via X264 easier. Your choice, but I'd certainly appreciate it. Currently I'm relying on end users having a commercial package installed so DirectshowMVCSource() can be used.

Also I find FRIMDecode to be a lot more dependable for MVC decodes. In my experience it works perfectly.

[videofan3d]

There is simple way to make this standard streams binary in Windows:
#ifdef _WIN32
_setmode( _fileno( stdin ), _O_BINARY );
_setmode( _fileno( stdout ), _O_BINARY );
_setmode( _fileno( stderr ), _O_BINARY );
#endif
And that is pretty standard way so I don't see any problems with using it.



Good point - thanks ;) :)

[videofan3d]

@videofan3d

Including an option for using stdout would certainly make encoding of SBS and O/U versions of 3D encodes via X264 easier. Your choice, but I'd certainly appreciate it. Currently I'm relying on end users having a commercial package installed so DirectshowMVCSource() can be used.

Also I find FRIMDecode to be a lot more dependable for MVC decodes. In my experience it works perfectly.

I'll consider it (with input from MasterNobody) :) ;) ...

[jdobbs]

I'll consider it (with input from MasterNobody) :) ;) ...Cool. :)

[Cedvano]

How the wall option work ? Have you got an exemple ?

[Sparktank]

Hi guys,

Here the new release (with new name)

http://forum.doom9.org/showthread.php?t=169801

The site has disappeared.

I work on a complete software

Whoever's maintaining the VideoHelp.com page should edit the other section where it says you can download the GUI, as the link is non-existent.

http://www.videohelp.com/tools/FRIM
(scroll down for "other downloads" to get the GUI...

More information and other downloads:
Download Transcoder GUI for FRIMTranscode and FRIMEncode here.

^leads to http://forum.doom9.org/showthread.php?t=169801 which doesn't exist.

Cedvano, you should update your previous posts for clarity. (whichever have a link to a non-existent thread/page)

FRIMTranscode GUI 1.04 (https://drive.google.com/file/d/0BxjaFf3cdexVV0NXSE14Sko5WHM/edit?usp=sharing)

I have no idea if that's your latest release before your makeover of the software.
Should people download that or should everyone avoid downloading that and wait for the complete version?

That post should be edited for clarity, as well.

[Cedvano]

http://img4.hostingpics.net/thumbs/mini_2373153dvonvert.png (http://www.hostingpics.net/viewer.php?id=2373153dvonvert.png)

Here the next release of FRIMTrancode GUI
I change the name by .::3D Encode::..

I make some changes and put the next FRIM 1.19

I don't forget but I have a [BEEP] work. ;-)

Thanks for your patience.

Edit: It's in French, but it's in English too.

[colinhunt]

Here the next release of FRIMTrancode GUI
Looking forward to it.

[nunub]

http://img4.hostingpics.net/thumbs/mini_2373153dvonvert.png (http://www.hostingpics.net/viewer.php?id=2373153dvonvert.png)

Here the next release of FRIMTrancode GUI
I change the name by .::3D Encode::..

I make some changes and put the next FRIM 1.19

I don't forget but I have a [BEEP] work. ;-)

Thanks for your patience.

Edit: It's in French, but it's in English too.

Its mouth watering.

[HWK]

@Videofan3d,

About few months back I requested a feature to add I frame on demand. Any update on it?

[Disclaimer, I requested this feature so Jdobbs can add chapter support for his program]

[videofan3d]

FRIM 1.20 is available:

FRIM Decoder 1.20
- output to standard output (stdout) added

FRIM Encoder 1.20
- input from standard input (stdin) added

See examples in documentation.

[Cedvano]

thanks Videofan3d

[jdobbs]

FRIM 1.20 is available:

FRIM Decoder 1.20
- output to standard output (stdout) added

FRIM Encoder 1.20
- input from standard input (stdin) added

See examples in documentation.Cool, cool, cool. :D

[Sharc]

Thanks videofan3d. FrimDecode into x264 now up and running :)

[jdobbs]

So what does "FRIM" stand for in "FRIMEncode"? Sorry, but it's just something I can't help asking.

[omegaman7]

So what does "FRIM" stand for in "FRIMEncode"? Sorry, but it's just something I can't help asking.

Wondering the same thing myself lol ;)

[videofan3d]

So what does "FRIM" stand for in "FRIMEncode"? Sorry, but it's just something I can't help asking.

You can "decipher" it as "FRee Intel Media" :)
Or maybe a bit self-praise "FRank & Intel Media" (- my name is Frank!) :)))))

But rather simply, I was looking for some single-syllabic name with IM in it (as Intel Media) :)

[omegaman7]

Ah, I wondered about "FRee". Thanks Frank ;)

[jdobbs]

I like "FRank & Intel Media" better -- it gives credit where credit is due.

I have a half-SBS encode running right now using FRIMDecoder and X264 -- it's working flawlessly. I'm loving it.

[HWK]

Looking at bright side, those who are running win 7 can use frimdecode as a option to decode MVC, AVC and Mpeg2 and serve to x264 encoder.

[videofan3d]

Hi,

just for fun I started plugin for Avisynth

LoadPlugin ("some_path\FRIMSource.dll")
FRIMSource (codec="mvc", file="some_path\SRC_L.h264", dependent="some_path\SRC_R.h264", layout="sbs", cache=24, num_frames=250)

which is based on kernel of already tested FRIMDecode.

Since scrolling through elementary stream is not supported, I added there at least a cache for last N frames which can help a bit in case of subsequent temporal filters.

If anyone is interested - you can download this beta 1 from FRIMSource_v1.zip (https://drive.google.com/file/d/0BymRNDHq74DEQVdTN2RiUXNyQXM).

Remark: to be used together with libmfxhw32.dll or libmfxsw32.dll from Intel Media SDK or FRIM Package (http://forum.doom9.org/showthread.php?p=1650646#post1650646)

[jdobbs]

Hi,

just for fun I started plugin for Avisynth

LoadPlugin ("some_path\FRIMSource.dll")
FRIMSource (codec="mvc", file="some_path\SRC_L.h264", dependent="some_path\SRC_R.h264", layout="sbs", cache=24, num_frames=250)

which is based on kernel of already tested FRIMDecode.

Since scrolling through elementary stream is not supported, I added there at least a cache for last N frames which can help a bit in case of subsequent temporal filters.

If anyone is interested - you can download this beta 1 from FRIMSource_v1.zip (https://drive.google.com/file/d/0BymRNDHq74DEQVdTN2RiUXNyQXM).

Remark: to be used together with libmfxhw32.dll or libmfxsw32.dll from Intel Media SDK or FRIM Package (http://forum.doom9.org/showthread.php?p=1650646#post1650646)Nice job. I'm loving the fact that it decodes ALL legal BD codec types!

[jdobbs]

I'm having problems feeding a SBS avisynth source into FRIMEncode.

AVISYNTH script:LoadPlugin("frimsource.dll")
frimsource(codec="mvc",file="s:\working6\workfiles\00001.track_4113.264",dependent="s:\working6\workfiles\00001.track_4114.mvc",layout="sbs",cache=24,num_frames=1000)
AssumeFPS(24000,1001)
ConvertToYV12()

I can play the script in MPC with no problem, but when I try to encode it with FRIMEncode the result is:
D:\test>d:\bd_rebuilder\tools\frimencode -avi -sbs 2 -i frimtest.avs -viewoutput
-o::mvc frimbase.264 frimdep.mvc -vbr 28000 40000 -u 4

ERROR: Cannot get YUV420 frame from input avi-file frimtest.avs

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

[videofan3d]

I'm having problems feeding a SBS avisynth source into FRIMEncode.

AVISYNTH script:LoadPlugin("frimsource.dll")
frimsource(codec="mvc",file="s:\working6\workfiles\00001.track_4113.264",dependent="s:\working6\workfiles\00001.track_4114.mvc",layout="sbs",cache=24,num_frames=1000)
AssumeFPS(24000,1001)
ConvertToYV12()

I can play the script in MPC with no problem, but when I try to encode it with FRIMEncode the result is:
D:\test>d:\bd_rebuilder\tools\frimencode -avi -sbs 2 -i frimtest.avs -viewoutput
-o::mvc frimbase.264 frimdep.mvc -vbr 28000 40000 -u 4

ERROR: Cannot get YUV420 frame from input avi-file frimtest.avs

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

I repeated steps using your script but I faced no problem - video was correctly encoded.

Please check your VFW setting, if FRIMEncode can read YUV AVS - in general.

Remarks:
AssumeFPS(24000,1001) is not necessary, fps is retrieved from source.
Also, FRIMSource() returns video in YV12 thus ConvertToYV12() is redundant.

[jdobbs]

I don't think I understand what you're saying. I can feed the same script into X264 and it encodes it without problem (but no MVC, of course).

[Cedvano]

I have error "Cannot initialize Intel Media SDK session"
I have put the libmfxsw32.dll in plugin directory.

[videofan3d]

I don't think I understand what you're saying. I can feed the same script into X264 and it encodes it without problem (but no MVC, of course).

Please try to play with directories and setting of your Video For Windows subsystem (via ffdshow - I guess that someone in this thread already commented what needs to be set).

I didn't reproduce your problem. On my computer I repeated your scenario without issues...

[videofan3d]

I have error "Cannot initialize Intel Media SDK session"
I have put the libmfxsw32.dll in plugin directory.

Please describe me more info.

libmfxsw32.dll is using standard Windows DLL-location system, and loaded automatically. Exactly as FRIMDecode or FRIMEncode do it.
(I.e. no special directories for it - I don't like such approach)

[Cedvano]

Here my script :
LoadPlugin("D:\eac3\FRIM\FRIMsource.dll")
frimsource(codec="mvc",file="D:\Temp\left.264",dependent="D:\Temp\right.mvc",layout="sbs",cache=24,num_frames=2152)

And when I want to play it with MPC, I have error.

[videofan3d]

Here my script :
LoadPlugin("D:\eac3\FRIM\FRIMsource.dll")
frimsource(codec="mvc",file="D:\Temp\left.264",dependent="D:\Temp\right.mvc",layout="sbs",cache=24,num_frames=2152)

And when I want to play it with MPC, I have error.

Message "Cannot initialize Intel Media SDK session" means that Intel Media Core cannot find any relevant library: neither libmfxsw32.dll nor libmfxhw32.dll (or its subcomponents)

Where is your libmfxsw32.dll located?

Remark: On my computer I have set
PATH= ..... ;C:\Program Files\Intel\Media SDK 2013 R2\bin\win32\; ....

and this is the only directory where is libmfxsw32.dll stored.
and everything works well.

[jdobbs]

I'm having problems feeding a SBS avisynth source into FRIMEncode.

AVISYNTH script:LoadPlugin("frimsource.dll")
frimsource(codec="mvc",file="s:\working6\workfiles\00001.track_4113.264",dependent="s:\working6\workfiles\00001.track_4114.mvc",layout="sbs",cache=24,num_frames=1000)
AssumeFPS(24000,1001)
ConvertToYV12()

I can play the script in MPC with no problem, but when I try to encode it with FRIMEncode the result is:
D:\test>d:\bd_rebuilder\tools\frimencode -avi -sbs 2 -i frimtest.avs -viewoutput
-o::mvc frimbase.264 frimdep.mvc -vbr 28000 40000 -u 4

ERROR: Cannot get YUV420 frame from input avi-file frimtest.avs

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.Please try to play with directories and setting of your Video For Windows subsystem (via ffdshow - I guess that someone in this thread already commented what needs to be set).

I didn't reproduce your problem. On my computer I repeated your scenario without issues...Ok. For anyone else who is getting this error:

1. Select FFDSHOW from Start Menu/All Programs
2. Select VFW Configuration
3. On the DECODER tab, scroll down to "Raw Video"
4. Select "All Supported"

[Sharc]

I have error "Cannot initialize Intel Media SDK session"
I have put the libmfxsw32.dll in plugin directory.
Simply put the libmfxsw32.dll it into the Windows system directory, and you are done for all times.
Which system directory to choose has been explained in detail by LordMulder.

[Sharc]

FRIMsource.dll works well here into x264 and into FRIMencode.

Script:
LoadPlugin("c:\Program Files Video\AviSynth 2.5\plugins\FRIMSource.dll")

FRIMsource(codec="mvc", file="00098.track_4113.264", dependent="00098.track_4114.mvc", layout="sbs", cache=24, num_frames=2000)
horizontalreduceby2() #for Half-SBS

command for SBS x264:
x264.exe "c:\Program Files Video\FRIM\FRIMSource_.avs" --bluray-compat --crf 20 --vbv-bufsize 15000 --vbv-maxrate 15000 --sar 1:1 --fps 23.976 --output "C:\temp\scratch\FRIMSourceTox264.h264"
command for MVC FRIMEncode:
FRIMEncode.exe mvc -avi -sbs 2 -i FRIMSource_.avs -viewoutput -o::mvc FRIMSource_Base_.avc FRIMSource_Dependent_.mvc -l 6 -cpbsize 3750 -vbr 6000 15000 -u 4 -profile high -level 4.1 -gop 24 4 0 O -PicTimingSEI off -EndOfSequence off

[Cedvano]

Simply put the libmfxsw32.dll it into the Windows system directory, and you are done for all times.
Which system directory to choose has been explained in detail by LordMulder.

Yeah ! works fine ! Thanks for your help.

[frencher]

@videofan3d
Strange test,
My left and right view source have framerate @ 25 fps
My CMD is:
"FRIMEncode.exe" mvc -i "FRIM.AVS" -avi -sbs 2 -viewoutput -o "L.h264" -o "R.h264" -cbr 20000 -f 23.976 -u 1 -level 4.1

Framerate output is 25 fps :(

[videofan3d]

@videofan3d
Strange test,
My left and right view source have framerate @ 25 fps
My CMD is:
"FRIMEncode.exe" mvc -i "FRIM.AVS" -avi -sbs 2 -viewoutput -o "L.h264" -o "R.h264" -cbr 20000 -f 23.976 -u 1 -level 4.1

Framerate output is 25 fps :(

It is clear (and expected)

For FRIMEncode parameters -w -h and -f are valid only for YUV planar input.
In case of avi input, these three are retrieved from .avi file (and on command line they are ignored)

You have to modify it already on "avi" level, i.e. adding command AssumeFPS(24000,1001) in your Avisynth script.

[frencher]

It is clear (and expected)

For FRIMEncode parameters -w -h and -f are valid only for YUV planar input.
In case of avi input, these three are retrieved from .avi file (and on command line they are ignored)

You have to modify it already on "avi" level, i.e. adding command AssumeFPS(24000,1001) in your Avisynth script.

OK thanks ;)

[frencher]

Ok. For anyone else who is getting this error:

1. Select FFDSHOW from Start Menu/All Programs
2. Select VFW Configuration
3. On the DECODER tab, scroll down to "Raw Video"
4. Select "All Supported"

http://i41.tinypic.com/rua5pw.png

[Jeedog]

Hi all,

I have used FRIM decode to try and split a .MTS file shot with a Panasonic Z10000 3D camcorder, but the video I get out is a scrembled green mess. Has anyone used FRIM on these types of files, or no why I might not be getting the results I wanted.

I can provide a sample file if needed.

Many thanks

[Sharc]

Jeedog:
You cannot encode .mts files with FRIM directly.
You must at first demultiplex the .mts and only then encode the elementary video streams.
You can try to demultiplex with tsMuxeR.

[videofan3d]

Hi all,

I have used FRIM decode to try and split a .MTS file shot with a Panasonic Z10000 3D camcorder, but the video I get out is a scrembled green mess. Has anyone used FRIM on these types of files, or no why I might not be getting the results I wanted.

I can provide a sample file if needed.

Many thanks

You are probably working with MTS directly - this is not possible.

First you need to demux it into elementary streams:

eac3to -demux Z10000.mts

and then feed resulting (e.g.)
"Z10000 - 1 - h264 (left eye), 1080p24.h264"
"Z10000 - 2 - h264 (right eye), 1080p24.h264"

into FRIMDecode, e.g.

FRIMDecode -i::mvc "Z10000 - 1 - h264 (left eye), 1080p24.h264" "Z10000 - 2 - h264 (right eye), 1080p24.h264" -o Z10000_L.yuv Z10000_R.yuv

Btw. Panasonic Z10000 is primary reason why I created FRIM Package ! :-)

[Jeedog]

Thanks both for your help,

Didn't know of eac3to.

Am trying now and will report back.

Good to hear you wrote FRIM to do exactly what I'm doing!

[Jeedog]

Thanks both - got it working.

Now to just to get it all the way to Avid DNxHD OpAtom MXF, with audio in one command...:scared:

[videofan3d]

Thanks both - got it working.

Now to just to get it all the way to Avid DNxHD OpAtom MXF, with audio in one command...:scared:

It is possible using ffmpeg (to .mov).

Probably not with one command, but still doable

Principle:

1. demux Z10000.mts (L.h264, R.h264, audio.wav)
2. FRIMDecode to two named pipes (one for L-eye, one for R-eye)
3. start two sessions of ffmpeg
one ffmpeg for (L.pipe to DNxHD + Audio.wav) -> L.mov
decond ffmpeg for (R.pipe to DNxHD + Audio.wav) -> R.mov

With a bit of experience, you can prepare a batch script to do it ;-)

[videofan3d]

FRIM package 1.21 moved to platform Intel Media SDK 2014 (distribution contains both libmfxsw32.dll and libmfxsw64.dll)
Build x86 and x64!

FRIM Decoder 1.21
FRIM Encoder 1.21
- parameter -swaplr added ... swap L- and R-eye in -tab or -sbs mode

FRIM Transcoder 1.21
- no functional changes

FRIM Source for Avisynth (only 32-bits for Avisynth 2.58)
- see FRIMSource_readme.pdf for description
- uses the same kernel as FRIM Decoder

FRIM Exporter for Adobe Premiere CS6 (only 64-bits)
- plugin FRIMExport.prm to be placed with other CS6 plugins in
"c:\Program Files\Adobe\Common\Plug-ins\CS6\MediaCore\FRIMExport.prm"

- uses the same kernel and the same parameters as FRIM Encoder
- tested on CS6, possibly will work also with other 64-bit versions of Adobe Premiere (like CS5, CC)
- example/pattern how to use it in 3D in Adobe Premiere is in project file Pattern_3D-TAB.prproj

[tymoxa]

FRIM package 1.21 moved to platform Intel Media SDK 2014

Just curious.. MFX_RATECONTROL_ICQ will be implemented? :)

[videofan3d]

Just curious.. MFX_RATECONTROL_ICQ will be implemented? :)

It is not end of the world :)
Let's stabilize SDK 2014, then extend it.

(I already noticed that e.g. MPEG2 with "-hw" stuck somewhere in SDK core :( )

[videofan3d]

Thanks both - got it working.

Now to just to get it all the way to Avid DNxHD OpAtom MXF, with audio in one command...:scared:


Assuming you have three files
SRC_L.h264
SRC_R.h264
SRC.wav
demuxed from Panasonic Z10000 (SRC.mts)


Then batch file with three commands

start /MIN FRIMDecode.exe -i::mvc SRC_L.h264 SRC_R.h264 -o \\.\pipe\L.yuv \\.\pipe\R.yuv

start /MIN ffmpeg.exe -pixel_format yuv420p -video_size 1920x1080 -framerate 23.976 -i \\.\pipe\L.yuv -i SRC.wav -vcodec dnxhd -b:v 175M -acodec pcm_s16le DST_L.mov

start /MIN ffmpeg.exe -pixel_format yuv420p -video_size 1920x1080 -framerate 23.976 -i \\.\pipe\R.yuv -i SRC.wav -vcodec dnxhd -b:v 175M -acodec pcm_s16le DST_R.mov

will do the work for you :)
(Output DST_L.mov and DST_R.mov)

[Cedvano]

After update, I can't use FRIMsource.dll, I can play with MPC but can't encode.


D:\Temp\DEMO>"C:\Program Files\FRIM\FRIMEncode.exe" mvc -avi -sbs 2 -i "D:\Temp\
DEMO\video.avs" -viewoutput -o "G:\Temp\\VIDEO_ENC\00067.h264" -w 1920 -h 1080 -
f 23.976 -l 6 -cpbsize 3750 -vbr 15000 40000 -u 7 -profile high -level 4.1 -gop
24 4 0 o -rf 3

ERROR: Cannot get YUV420 frame from input avi-file D:\Temp\DEMO\video.avs
Frame was written in default format to file D:\Temp\DEMO\video.avs.error.
bmp

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

D:\Temp\DEMO>


And the bmp file say : Cannot load file 'C:\....\FRIMsource.dll'... (I have not scribe all text ;-))

Have you change something ?

Edit: With the last version of FRIMEncode, that's work (x86) but x64 doesn't work.

[videofan3d]

After update, I can't use FRIMsource.dll, I can play with MPC but can't encode.


D:\Temp\DEMO>"C:\Program Files\FRIM\FRIMEncode.exe" mvc -avi -sbs 2 -i "D:\Temp\
DEMO\video.avs" -viewoutput -o "G:\Temp\\VIDEO_ENC\00067.h264" -w 1920 -h 1080 -
f 23.976 -l 6 -cpbsize 3750 -vbr 15000 40000 -u 7 -profile high -level 4.1 -gop
24 4 0 o -rf 3

ERROR: Cannot get YUV420 frame from input avi-file D:\Temp\DEMO\video.avs
Frame was written in default format to file D:\Temp\DEMO\video.avs.error.
bmp

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

D:\Temp\DEMO>


And the bmp file say : Cannot load file 'C:\....\FRIMsource.dll'... (I have not scribe all text ;-))

Have you change something ?

Edit: With the last version of FRIMEncode, that's work (x86) but x64 doesn't work.

No, FRIMSource.dll is the same - you have probably some mismatch in paths since Avisynth subsystem cannot find it.
Remark: FRIMSource is only 32 bit in order to be used with 32-Avisynth

x86 and x64 use different Intel Media libraries (naturally).
Both libmfxsw32.dll and libmfxsw64.dll have to be in your PATH.

Remark: Beside using different core IM-libraries there is no functional difference between x86 and x64.
The reason for x64 was mainly to create FRIMExport.dll for Adobe Premiere (which requires x64 interface)

[Cedvano]

Thanks for your answer.

After tests, FRIMSource(x86) and FRIMEncoder(x64) not compatible.
FRIMDecoder(x64) and FRIMEncoder(x64) work

For FRIMSource, I can use X86 version only.

And I have see for librairies in software path.

Thank you.

[videofan3d]

Thanks for your answer.

After tests, FRIMSource(x86) and FRIMEncoder(x64) not compatible.


This is expected: FRIMEncoder(x64) with -avi activates 64-bit VFW, but this cannot work with 32-bit Avisynth.

I'm not sure if already exists some official (or at least very stable and ".h-compatible") 64-bit version of Avisynth. And whether it can co-exist with official Avisynth 2.5.8. ...

[Thalyn]

There's no official x64 version yet. There's an unofficial build of 2.5.8 which is both 64-bit and MT, but it cannot co-exist with the 32-bit version at present.

It is, however, possible to pipe from 32-bit AVISynth to a 64-bit program. MeGUI does it using AVS2YUVMod, and it does have an appreciable speed difference using the 64-bit version of x264 instead of the 32-bit version. Given it outputs to YUV it should be possible to use it with FRIMEncoder.

[Cedvano]

There's no official x64 version yet. There's an unofficial build of 2.5.8 which is both 64-bit and MT, but it cannot co-exist with the 32-bit version at present.

It is, however, possible to pipe from 32-bit AVISynth to a 64-bit program. MeGUI does it using AVS2YUVMod, and it does have an appreciable speed difference using the 64-bit version of x264 instead of the 32-bit version. Given it outputs to YUV it should be possible to use it with FRIMEncoder.

Ok, thanks, I stay with 32-bit version.

[videofan3d]

Remark: Beside using different core IM-libraries there is no functional difference between x86 and x64.
The reason for x64 was mainly to create FRIMExport.dll for Adobe Premiere (which requires x64 interface)

I did also quick result comparison:
both core libraries libmfxsw32.dll and libmfxsw64.dll produce the same (bit-to-bit identical) .h264 file. There is no encoding difference.
(I didn't test a performance of x64 vs. x86 - but it is more complex matter, and significantly depends also on other factors, mainly disk access (when processing huge YUV files).
So it is only user's preference to use FRIM in 32bit or 64 bits.

Differentiator can be
- FRIMSource.dll - 32-bits for Avisynth, or
- FRIMExport.dll - 64-bits for Adobe Premiere.

[Stinger]

Hi all,

I've tried to FRIMTranscode 3d movie using following command

frimtranscode -i::mvc left.264 right.mvc -o::mvc out.264 -vbr 16425 40000 -cpbsize 3750 -u 4 -profile high -level 4.1

Output video plays ok in 3D with TotalMediaTheatre on my PC but when I tried to play it on my Onkyo blu-ray player (BD-SP809) movie plays but every ~1 second it stops playing for a fraction of second and then plays again and stops again and so on - I don't get smooth playback. When I try to play the same movie in 2d it plays smooth on my player so it seems that there is some kind of problem with AVC/MVC synchronization.

I would appreciate if you can give me some suggestions what can be wrong here and how to achieve smooth 3D playback on my hardware player - maybe some extra options should be applied to get more blu-ray compatible stream...

[Eseninzhiv]

Thanks for your plug-in for Adobe Premiere!

Adobe Premiere CS6 (64-bits)
http://iceimg.com/5PjLBRgr/snimok-thumb.jpg (http://iceimg.com/5PjLBRgr/snimok)

or need to install it on PC?
Download for SW developers: http://software.intel.com/en-us/vcsource/tools/media-sdk

[videofan3d]

Thanks for your plug-in for Adobe Premiere!

Adobe Premiere CS6 (64-bits)
http://iceimg.com/5PjLBRgr/snimok-thumb.jpg (http://iceimg.com/5PjLBRgr/snimok)

or need to install it on PC?
Download for SW developers: http://software.intel.com/en-us/vcsource/tools/media-sdk

It seems that you don't have library libmfxsw64.dll properly installed. Intel Media SDK dispatcher cannot find it.
Put is somewhere to your PATH.

[Eseninzhiv]

Pattern_3D-TAB.prproj, Thank you, all ok!

try my files
inserted in the project from the camcorder file .MP4 (Side by Side)
try to get avc, mvc
put these parameters for the encoder
-viewoutput -o output_L.avc -o output_R.mvc -w 1920 -h 1080 -f 23.976 -u 4 -cpbsize 3570 -vbr 30000 40000 -l 6 -profile high -level 4.1 -gop 24 4 0 O -EndOfSequence off

http://iceimg.com/VQ56vm70/1-thumb.jpg (http://iceimg.com/VQ56vm70/1) http://iceimg.com/YfHvoo1i/2-thumb.jpg (http://iceimg.com/YfHvoo1i/2)

I receive an error
please tell me, what parameters needed?

and if perhaps, please make presets in the following versions

[videofan3d]

Pattern_3D-TAB.prproj, Thank you, all ok!

try my files
inserted in the project from the camcorder file .MP4 (Side by Side)
try to get avc, mvc
put these parameters for the encoder


http://iceimg.com/VQ56vm70/1-thumb.jpg (http://iceimg.com/VQ56vm70/1) http://iceimg.com/YfHvoo1i/2-thumb.jpg (http://iceimg.com/YfHvoo1i/2)

I receive an error
please tell me, what parameters needed?

and if perhaps, please make presets in the following versions

Few comments:

FRIMEncoder for 3D expects 2x HD (=not squeezed by 2!), either top-above-below or side-by-side.

So, if you have video already squeezed side-by-side from consumer camcorder, you need to spread it by 2 in Premiere (to resolution 3840 (!) x 1080 - still in side-by-side) = you need to define proper Custom parameters of the Sequence in Premiere, and apply some spreading filter to the video itself.

Output filename, resolution and framerate is taken from Premiere, no need to set it in Codec options.

Codec options should be only aditional parameters, e.g.:
-viewoutput -u 4 -cpbsize 3570 -vbr 30000 40000 -l 6 -profile high -level 4.1 -gop 24 4 0 O -EndOfSequence off

[videofan3d]

FRIM package 1.22
Support reading transport stream .ts/.mts/.m2ts directly

FRIM Decoder / FRIM Transcoder
- optional parameter -ts added
example:
FRIMDecode -ts -i::h264 input.m2ts -o output.yuv

FRIM Source for Avisynth
- optional parameter ts=false/true (default is false) added
example:
FRIMSource(codec="h264", filename="input.m2ts", ts=true, cache=24, num_frames=300)

example for Panasonic 3D-Z10000 (with audio):

FILE3D="Z10000.m2ts"
V=FRIMSource(codec="mvc", filename=FILE3D, filename_dep=FILE3D, ts=true, layout="sbs", cache=24, num_frames=300)
A=DirectShowSource(FILE3D).KillVideo()
AudioDub(V,A)

[Cedvano]

Oh, great ! Thank you very much.
SSIF work or not ?

[videofan3d]

Oh, great ! Thank you very much.
SSIF work or not ?

SSIF likely not (= never tested), but for each SSIF you have two regular .m2ts files which will work.

[Cedvano]

Work only for 2D (like M2ts) but not for 3D.

[videofan3d]

Work only for 2D (like M2ts) but not for 3D.

I don't like this SSIF - it is virtual fake.
I already expressed my opinion about SSIF here (http://forum.doom9.org/showthread.php?p=1662997#post1662997).

On the contrary, those two real m2ts files associated with virtual SSIF have very clear and natural meaning:
base.m2ts serves for 2D - as standard, keeping bitrate for 2D compatibility, playable on every HW/SW media player.
dependent.m2ts ads only 3D information, multiplexed into standard TS-container, and playable together with base.m2ts on 3D compatible media players.

[Cedvano]

Like this that's work fine. Thank you very much for your work !

[Sharc]

I don't like this SSIF - it is virtual fake.
I already expressed my opinion about SSIF here (http://forum.doom9.org/showthread.php?p=1662997#post1662997).

On the contrary, those two real m2ts files associated with virtual SSIF have very clear and natural meaning:
base.m2ts serves for 2D - as standard, keeping bitrate for 2D compatibility, playable on every HW/SW media player.
dependent.m2ts ads only 3D information, multiplexed into standard TS-container, and playable together with base.m2ts on 3D compatible media players.
Agree, with the sidenote that .ssif can be just convenient as it links the associated pair of base & dependent .m2ts.
These are often in sequence like 0002.m2ts / 0003.m2ts and easy to identify. But sometimes the pair(s) are "wildly" numbered which makes their identification a bit more difficult -- especially in the case of multi-segmented structures.
Thanks for the update :)

[jdobbs]

SSIF likely not (= never tested), but for each SSIF you have two regular .m2ts files which will work.From a video perspective the SSIF is just an M2TS with a different name. In fact you can rename it to .M2TS and play it in 2D with Media Player Classic. The two M2TS files are just interleaved. I think the only difference is the MVC stream uses a different PID.

With that said, it really doesn't matter. As long as you can read from the two M2TS files it should be fine. Thanks for the new feature!

[jdobbs]

Ran this command, and it froze after 825 frames:
"c:\CLI\FRIMDecode.exe" -i::mvc "P:\BD_KEEP\ROAD_RUNNER (SHORT 3D TEST)\BDMV\STREAM\00000.M2TS"
"P:\BD_KEEP\ROAD_RUNNER (SHORT 3D TEST)\BDMV\STREAM\00001.M2TS" -o \\.\pipe\bdrb.yuv -sw | "C:\CLI\FRIMEncode.exe"
mvc -i \\.\pipe\bdrb_L.yuv -i \\.\pipe\bdrb_R.yuv -viewoutput -o "D:\WORKING7\WORKFILES\VID_00000.AVS.264"
-o "D:\WORKING7\WORKFILES\VID_00000.AVS.mvc" -w 1920 -h 1080 -f 23.976 -u 6 -cpbsize 1625 -profile high
-level 4.0 -vbr 15000 15000 -gop 24 4 0 S -maxdpb 4

[nunub]

Like this that's work fine. Thank you very much for your work !

Gear up now for the ultimate gui.

[videofan3d]

Ran this command, and it froze after 825 frames:
"c:\CLI\FRIMDecode.exe" -i::mvc "P:\BD_KEEP\ROAD_RUNNER (SHORT 3D TEST)\BDMV\STREAM\00000.M2TS"
"P:\BD_KEEP\ROAD_RUNNER (SHORT 3D TEST)\BDMV\STREAM\00001.M2TS" -o \\.\pipe\bdrb.yuv -sw | "C:\CLI\FRIMEncode.exe"
mvc -i \\.\pipe\bdrb_L.yuv -i \\.\pipe\bdrb_R.yuv -viewoutput -o "D:\WORKING7\WORKFILES\VID_00000.AVS.264"
-o "D:\WORKING7\WORKFILES\VID_00000.AVS.mvc" -w 1920 -h 1080 -f 23.976 -u 6 -cpbsize 1625 -profile high
-level 4.0 -vbr 15000 15000 -gop 24 4 0 S -maxdpb 4

Didn't you forget
FRIMDecode.exe -ts -i::mvc ...
?

[jdobbs]

Didn't you forget
FRIMDecode.exe -ts -i::mvc ...
? Hmmm... I guess I missed that. Thanks!

[Eseninzhiv]

Great ! Thank you very much
works fine
FRIMDecode -ts -i::mvc -i 00000.m2ts -i 00001.m2ts -o output_L.yuv -o output_R.yuv

[jdobbs]

@videofan3d

Any idea what the error below could be? I get it when I try to run two instances of FRIMEncode against a source. It takes a while, but fails at the same point in each try. It also fails on every source I've tried, but at different points. The same files encode fine if I only use one instance of FRIMEncode.

Frame number: 16140
ERROR: unknown error (-1), src\pipeline_encode.cpp (1086)


ERROR: unknown error (-1), src\pipeline_encode.cpp (1282)


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

[videofan3d]

@videofan3d

Any idea what the error below could be? I get it when I try to run two instances of FRIMEncode against a source. It takes a while, but fails at the same point in each try. It also fails on every source I've tried, but at different points. The same files encode fine if I only use one instance of FRIMEncode.

Frame number: 16140
ERROR: unknown error (-1), src\pipeline_encode.cpp (1086)


ERROR: unknown error (-1), src\pipeline_encode.cpp (1282)


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

Hi,

Are you running on Intel i5/i7 CPU ? (or with some new Intel Graphics)? More precisely, are you using "autodetect" or -hw option?

Please try to switch to -sw.

[jdobbs]

Hi,

Are you running on Intel i5/i7 CPU ? (or with some new Intel Graphics)? More precisely, are you using "autodetect" or -hw option?

Please try to switch to -sw.I am running on an AMD CPU, and am running with -sw forced already.

[sef]

http://i57.fastpic.ru/big/2014/0207/59/4a79a16bbcc841c3668dd3296f86c059.jpg

http://i33.fastpic.ru/big/2014/0207/5d/ac9ecb263137212d74354ffd0a77b95d.jpg

What am I doing wrong??

[videofan3d]

I am running on an AMD CPU, and am running with -sw forced already.

Please send exact command which you are running + running conditions, I will try to simulate it.

[videofan3d]

http://i57.fastpic.ru/big/2014/0207/59/4a79a16bbcc841c3668dd3296f86c059.jpg

http://i33.fastpic.ru/big/2014/0207/5d/ac9ecb263137212d74354ffd0a77b95d.jpg

What am I doing wrong??

This is strange, this is how it should be used.
I ran your command without any issues

c:\Prj\IntelMedia\_bin\Win32\Release\FRIMDecode -i::mvc SRC_L.h264 SRC_R.h264 -sbs -o - | c:\Prj\IntelMedia\_bin\Win32\Release\FRIMEncode -sbs 2 -i - -o::mvc Z.h264 -w 1920 -h 1080 -f 23.976 -vbr 28000 40000
FRIM Encoder version 1.22 (build: Feb 2 2014)
- based on Intel(R) Media SDK

Media SDK impl HARDWARE - D3D9 (C:\Program Files\Intel\Media SDK\libmfx
hw32.dll)
Media SDK version 1.7
Memory type System

Input format YUV420

Output video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control VBR
avg,maximum 28000,40000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 4 (balanced)

Processing started
Frame number: 276
Processing finished in 3.43 seconds

Please try it with FRIMEncode -sw (or maybe also for FRIMDecode)
(I faced some issues when running in -hw mode, HW acceleration depends on driver version)

[sef]

Please try it with FRIMEncode -sw (or maybe also for FRIMDecode)

Problem solved, had to manually set the path to Intel Media SDK(2014).. Only -sw, with FRIMDecode and FRIMEncode simultaneously..
P.S. What is your video card?(HD 4000).. And, why -hw not working at all, with first example..

[videofan3d]

Problem solved, had to manually set the path to Intel Media SDK(2014).. Only -sw, with FRIMDecode and FRIMEncode..
P.S. What is your video card?(HD 4000).. And, why -hw not working at all, with first example..

(I use Haswell CPU i7 4770K with integrated GPU HD 4600)

I noticed that there are sometimes some limitations (or bugs?) when using -hw mode.
In -hw mode Intel Media uses graphic driver and calls GPU accelerated routines. They are "bloody-faster", on decoding 8x(!), but with some limits.

I can only guess:
In -sw mode each process allocates resources (memory, thread pool, etc.) in regular PC memory, so there are almost no limitations.
But in -hw mode each process can use/share resources on the GPU - which are not endless, and probably depend on specific given GPU. Once exhausted (for example when running more processes/threads), each additional process fails. And number of available resources probably depends on specific GPU family.

My experience is to play with -hw and -sw, and try to find proper combination.

[sef]

And number of available resources probably depends on specific GPU family.


That's what I was expecting:), thanks for the detailed explanation, soon I will replace hardware..

[jdobbs]

Please send exact command which you are running + running conditions, I will try to simulate it.The goal of running multiple instances is to speed up encoding. I've noticed that only a little over half of the available CPU usage was being used when doing a single instance encode. The multiple instances gives me about a 30% increase in encoding speed. But, as I said, only one of the instances will complete, and the other will get the error I posted (http://forum.doom9.org/showthread.php?p=1666619#post1666619). In the example here I am accepting a half-SBS source and reencoding to full MVC using FRIMEncode (to create a 3D BD disc). Frame serving is being provided by DGDecNV so I can get frame-accurate seeking. The two AVISYNTH scripts:#Created by BD Rebuilder - v0.46.12 (beta)
LoadPlugin("C:\APPS\DGDecNV\DGDecodeNV.dll")
DGSource("D:\WORKING8\WORKFILES\VID_00000.DGI", fieldop=0).Trim(0,-91203)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)#Created by BD Rebuilder - v0.46.12 (beta)
LoadPlugin("C:\APPS\DGDecNV\DGDecodeNV.dll")
DGSource("D:\WORKING8\WORKFILES\VID_00000.DGI", fieldop=0).Trim(91203,0)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)

Here are the command lines being used:"D:\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i
"D:\WORKING8\WORKFILES\VID_00000.1.avs" -viewoutput -o::mvc "D:\WORKING8\WORKFILES\VID_00000.1.264"
"D:\WORKING8\WORKFILES\VID_00000.1.mvc" -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr
23376 35000 -gop 24 4 0 S -maxdpb 4"D:\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i
"D:\WORKING8\WORKFILES\VID_00000.2.avs" -viewoutput -o::mvc "D:\WORKING8\WORKFILES\VID_00000.2.264"
"D:\WORKING8\WORKFILES\VID_00000.2.mvc" -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr
23376 35000 -gop 24 4 0 S -maxdpb 4One of the two instances will end with the error I posted every time. If the source changes, the frame at which it fails changes -- but it has happened on every source I've tried. Unfortunately it can be several thousand frames into the encode, so repeating the issue always takes a lot of time.

If I do a single file with the same settings etc... it will complete with no issues.

It's not something critical -- as a single encode always works. The purpose of the experiment is just to save time when encoding.

[Edit] Note also, that either of the two specific command lines above will complete successfully if run as a single instance -- but one will fail if run concurrently.

[videofan3d]

That's what I was expecting:), thanks for the detailed explanation, soon I will replace hardware..

I just noticed that your HW system reports Media SDK Version 1.4 while on my side 1.7.
Maybe try also upgrade video driver - Intel HW library used to be part of it, and I realized it really matters what version you have.

[videofan3d]

The goal of running multiple instances is to speed up encoding. I've noticed that only a little over half of the available CPU usage was being used when doing a single instance encode. The multiple instances gives me about a 30% increase in encoding speed. But, as I said, only one of the instances will complete, and the other will get the error I posted (http://forum.doom9.org/showthread.php?p=1666619#post1666619). In the example here I am accepting a half-SBS source and reencoding to full MVC using FRIMEncode (to create a 3D BD disc). Frame serving is being provided by DGDecNV so I can get frame-accurate seeking. The two AVISYNTH scripts:#Created by BD Rebuilder - v0.46.12 (beta)
LoadPlugin("C:\APPS\DGDecNV\DGDecodeNV.dll")
DGSource("D:\WORKING8\WORKFILES\VID_00000.DGI", fieldop=0).Trim(0,-91203)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)#Created by BD Rebuilder - v0.46.12 (beta)
LoadPlugin("C:\APPS\DGDecNV\DGDecodeNV.dll")
DGSource("D:\WORKING8\WORKFILES\VID_00000.DGI", fieldop=0).Trim(91203,0)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)

Here are the command lines being used:"D:\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i
"D:\WORKING8\WORKFILES\VID_00000.1.avs" -viewoutput -o::mvc "D:\WORKING8\WORKFILES\VID_00000.1.264"
"D:\WORKING8\WORKFILES\VID_00000.1.mvc" -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr
23376 35000 -gop 24 4 0 S -maxdpb 4"D:\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i
"D:\WORKING8\WORKFILES\VID_00000.2.avs" -viewoutput -o::mvc "D:\WORKING8\WORKFILES\VID_00000.2.264"
"D:\WORKING8\WORKFILES\VID_00000.2.mvc" -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr
23376 35000 -gop 24 4 0 S -maxdpb 4One of the two instances will end with the error I posted every time. If the source changes, the frame at which it fails changes -- but it has happened on every source I've tried. Unfortunately it can be several thousand frames into the encode, so repeating the issue always takes a lot of time.

If I do a single file with the same settings etc... it will complete with no issues.

It's not something critical -- as a single encode always works. The purpose of the experiment is just to save time when encoding.

[Edit] Note also, that either of the two specific command lines above will complete successfully if run as a single instance -- but one will fail if run concurrently.

I don't have DGDecNV (it is linked to NVidia CUDA (and for that reason requires some 3rd party SW license) card which I don't have).
I'll try to simulate it somehow differently ...

[sef]

Intel HW library used to be part of it..

I know, but unfortunately, for my card(HD 3000) already installed the latest drivers..:(

[jdobbs]

I don't have DGDecNV (it is linked to NVidia CUDA (and for that reason requires some 3rd party SW license) card which I don't have).
I'll try to simulate it somehow differently ...I'll run the same job with DirectshowSource() and post the results. I'll have to do the split differently, though, since I can't count on it's seeking.

[HWK]

I don't have DGDecNV (it is linked to NVidia CUDA (and for that reason requires some 3rd party SW license) card which I don't have).
I'll try to simulate it somehow differently ...

I'll run the same job with DirectshowSource() and post the results. I'll have to do the split differently, though, since I can't count on it's seeking.

I have Nvidia card and dgdecnv, if you want jdobbs I can run test as well and see if it is related specific configuration.

[jdobbs]

I have Nvidia card and dgdecnv, if you want jdobbs I can run test as well and see if it is related specific configuration.I'll send you a test version of BD-RB that does multiple instances. That way you can run a job and see what happens.

[jdobbs]

I'll run the same job with DirectshowSource() and post the results. I'll have to do the split differently, though, since I can't count on it's seeking.Yeah, it choked with DirectshowSource() also.

[HWK]

Not sure, if this is any help or not. I finish encoding world war z with multiple instance of FRIMEncode (x2) and it finished without a problem, will do Pacific Rim next with two instance and balance setting in FRIM.

(Around 60% done)
http://i58.tinypic.com/255o20y.jpg

(100% done)
http://i62.tinypic.com/4ujw51.jpg

First Instance
FRIMDecode.exe -ts -i::mvc "E:\BD_RB\WORKFILES\00800.M2TS" "E:\BD_RB\WORKFILES\00800.M2TS" -o \\.\pipe\_L1.yuv -o \\.\pipe\_R1.yuv | FrimEncode.exe -i \\.\pipe\_L1.yuv -i \\.\pipe\_R1.yuv -viewoutput -o::mvc "E:\WORLD_WAR_Z_Part1.264" -o "E:\WORLD_WAR_Z_Part1.mvc" -w 1920 -h 1080 -f 23.976 -u 7 -cpbsize 3750 -profile high -level 4.1 -vbr 30000 60000 -gop 24 4 0 S -maxdpb 4
pause

Second Instance
FRIMDecode.exe -ts -i::mvc "E:\BD_RB\WORKFILES\00810.M2TS" "E:\BD_RB\WORKFILES\00810.M2TS" -o \\.\pipe\_L2.yuv -o \\.\pipe\_R2.yuv | FrimEncode.exe -i \\.\pipe\_L2.yuv -i \\.\pipe\_R2.yuv -viewoutput -o::mvc "E:\WORLD_WAR_Z_Part2.264" -o "E:\WORLD_WAR_Z_Part2.mvc" -w 1920 -h 1080 -f 23.976 -u 7 -cpbsize 3750 -profile high -level 4.1 -vbr 30000 60000 -gop 24 4 0 S -maxdpb 4
pause

I split movie into two files 00800.m2ts and 00810.m2ts file and ran two instance simultaneous.

[videofan3d]

Yeah, it choked with DirectshowSource() also.

I tried to reproduce it .... with mixed results :scared: ...

VID.1.avs:

L=DirectShowSource("VIDEO.m2ts").Trim(0,-60000)
StackHorizontal(L,L)


VID.2.avs:

L=DirectShowSource("VIDEO.m2ts").Trim(60000, 0)
StackHorizontal(L,L)


Both inputs were artifically made 2*1920 to simulate 3D SBS input.
Input video was ~130000 frames long.

Encode 1

FRIMEncode.exe -avi -sbs 2 -sw -i VID.1.avs -viewoutput -o::mvc VID.1.h264 VID.1.mvc -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 23376 35000 -gop 24 4 0 S -maxdpb 4


Encode 2

FRIMEncode.exe -avi -sbs 2 -sw -i VID.2.avs -viewoutput -o::mvc VID.2.h264 VID.2.mvc (...same params..)


i.e. I tried to set similar conditions as you have.
Running on i7 Haswell.

And my results:

When I run in -sw encoding mode, I faced the same (rather stochastic) failure on one process.

When I run in -hw encoding mode, both finished correctly!

As you commented, it is very time consuming to reproduce it.

.... at this moment I can only add it will be very difficult to investigate the root cause - in order even to try to fix it :( ...)

[jdobbs]

Did you get a significant speed-up with -hw set? Just wondering... I'm just going to disable multiple instance processing for FRIM in BD-RB, I think it's too unpredictable as to when it will or will not fail. While it was failing on every job before, I've since had a couple shorter jobs that completed successfully. The probability is that the issue is in the library somewhere anyway -- and that would have to be fixed by Intel anyway.

I think it's a lot more likely to happen when BD-RB starts the process and has to make frequent checks for process completion -- although I don't know why that would impact it. But even then it goes through thousands of frames (and a few hours) before it finally trips.

Thanks for the look.

[HWK]

Jdobbs, so you are dropping the idea of multi-process for time being. I manage to do something which is shown in post # 533 not sure if it is any good.

I am gone try later today with method similar to yours for dgdecnv.

[jdobbs]

Jdobbs, so you are dropping the idea of multi-process for time being. I manage to do something which is shown in post # 533 not sure if it is any good.

I am gone try later today with method similar to yours for dgdecnv. I'm not sure whether I'll drop it completely. I don't have a system that would support -hw -- so I'm not sure whether is has any issues at all. I would think, though, that -hw might be where it might benefit the most.

I may just leave it in and use an undocumented hidden option to enable it. Unfortunately when it happens, the encode process never ends and BD-RB just keeps waiting. Eventually you have hit the "Abort" button. Unless you have "show_encoder=1" set in the config file, you don't even know why it's hung.

[HWK]

I'm not sure whether I'll drop it completely. I don't have a system that would support -hw -- so I'm not sure whether is has any issues at all. I would think, though, that -hw might be where it might benefit the most.

I'll probably just leave it in and use a hidden option (with warning) to enable it.

Hmm, I use software option and used two instance of frimdecode & frimencode and it worked without problem, three work as well but it slows down encoding with little or no benefit.

At least there is light at end of tunnel :D Anyways, like I said I will use script posted by you and see if it works at all for information purposes, if it works fine and if not good with me.

[jdobbs]

Hmm, I use software option and used two instance of frimdecode 7 frimencode and it worked without problem, three work as well but it slows down encoding with little or no benefit.

At least there is light at end of tunnel :D Anyways, like I said I will use script posted by you and see if it works at all for information purposes, if it works fine and if not good with me.Oh, I'm confident you'll get it if you repeat my method. I get it every time on a long job. But sometimes it may be 50,000+ frames before it happens. On other jobs it may happen at 8,000. I also noticed you're using FRIMDecode in your test. I'm using AVISYNTH and the -avi option, which might make a difference. In my test version of BD-RB it is currently only enabled when converting SBS to MVC.

I see the same speed effect on my system when trying to run more than 2 instances. But that makes sense when there's no available processor bandwidth available. I would expect it to do better with -hw set.

[HWK]

Oh, I'm confident you'll get it. I get it every time on a long job. But sometimes it may be 50,000+ frames before it happens. On other jobs it may happen at 8,000.

Fair enough, but it doesn't hurt to try. On a side note I was reading Neuron2 has intention to develop plugin which mvc decode without need NVidia and is frame accurate or at least that is what I understand. Let me search for the link and will post it here, if I find it.

http://forum.doom9.org/showthread.php?p=1667083#post1667083

[jdobbs]

Removed link -- realized I had some bad test-code still in it.

Ok. If you have BD Rebuilder installed and you want to test download this executable (http://www.jdobbs.net/Freeware/bdrb.exe) and replace BDRB.EXE. Then set FRIM_SBS_PROCESSES=2 (for two instances) and set SHOW_ENCODER=1. Then import a SBS source and run it. It will eventually error out.

I saw Neuron2's post.

[videofan3d]

Did you get a significant speed-up with -hw set? Just wondering...

Some time ago I measured FRIMDecode on -hw|sw - see here (http://forum.doom9.org/showthread.php?p=1655287#post1655287).

Encoding with -hw is visibly faster than -sw.
But also resulting H.264 files are different - in size and content (I'm not evaluating visual difference since it is matter of personal preference if even possible to recognize).
Intel also confirmed that algorithms in SW and HW libraries slighly differ.

(Unlike decoding - YUV file from the same source H.264 is identical for both FRIMDecode -hw and -sw)

[jdobbs]

Some time ago I measured FRIMDecode on -hw|sw - see here (http://forum.doom9.org/showthread.php?p=1655287#post1655287).

Encoding with -hw is visibly faster than -sw.
But also resulting H.264 files are different - in size and content (I'm not evaluating visual difference since it is matter of personal preference if even possible to recognize).
Intel also confirmed that algorithms in SW and HW libraries slighly differ.

(Unlike decoding - YUV file from the same source H.264 is identical for both FRIMDecode -hw and -sw)I assumed hw was faster, I was more interested in how much faster it would be with multiple instances, since I would assume it uses less CPU time than sw.

[HWK]

Removed link -- realized I had some bad test-code still in it.

Ok. If you have BD Rebuilder installed and you want to test download this executable (http://www.jdobbs.net/Freeware/bdrb.exe) and replace BDRB.EXE. Then set FRIM_SW_PROCESSES=2 (for two instances) and set SHOW_ENCODER=1. Then import a SBS source and run it. It will eventually error out.

I saw Neuron2's post.

Thank you, will try later today. Also do you know specs of GPU you are using for frame serving.

[jdobbs]

Thank you, will try later today. Also do you know specs of GPU you are using for frame serving. It happens on both an AMD Radeon 6530D (using DirectshowSource) and an Nvidia GeForce GT520 (using either DirectshowSource or DGDecNV). They are on two different computers.

[jdobbs]

It happens on both an AMD Radeon 6530D (using DirectshowSource) and an Nvidia GeForce GT520 (using either DirectshowSource or DGDecNV). They are on two different computers.The job I tried today went over 78,000 frames before it hit the error.

[HWK]

I am currently doing Pacific Rim and see what happens. Just want to know why BD-RB use mkvmerge in the beginning when importing. I am using m2ts file with h.264 codec.

[jdobbs]

I am currently doing Pacific Rim and see what happens. Just want to know why BD-RB use mkvmerge in the beginning when importing. I am using m2ts file with h.264 codec.It converts all non-mkv sources to mkv when it imports in order to simplify processing.

[HWK]

It converts all non-mkv sources to mkv when it imports in order to simplify processing.

Aha, I see thanks for information. I would be much better off if I knew what I am up against. I am using lossless source and it is slow 2:11:16 length translate to 163GB of file and it is taking it's time.

[HWK]

Jdobbs, does "MULTIPROCESS" need to be in hidden option for this method to work? I tired with instructions and it run in only one instance.

I am doing again by adding multiprocess to options.

[jdobbs]

Jdobbs, does "MULTIPROCESS" need to be in hidden option for this method to work? I tired with instructions and it run in only one instance.

I am doing again by adding multiprocess to options.No. I purposely made it independent of multiprocess because there were issues. You have to import using the SBS option. But that's about it.

[HWK]

No. I purposely made it independent of multiprocess because there were issues. You have to import using the SBS option. But that's about it.

Hmm, then why didn't it run with two instance even though I set this before opening main program and of course I replace exe file.

I use option import and choose side by side 3D which is 4th option in import caterogy.

Source: Pacific Rim and it is half SBS.

[Options]
VERSION=0.46.0.12
MODE=3
ENCODE_QUALITY=0
ONEPASS_ENCODING=2
AUTO_QUALITY=0
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=all
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=0
RESIZE_720=0
DEINTERLACE=1
SD_TO_1080=0
IGNORE_3D=0
CONVERT_WIDE=0
DTS_REENCODE=0
AC3_REENCODE=0
AC3_640=1
AC3_192=0
KEEP_HD_AUDIO=1
AVCHD=1
REMOVE_WORKFILES=0
MOVIE_ONLY_LOOP=1
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=1
USE_LAVF=0
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
UNMASK_CHAPTER=1
COMPLETION_BEEP=1
DGDECNV=1
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
AUDIO_TRACK_LIMIT=1
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=23500
FRIM_SW_PROCESSES=2
SHOW_ENCODER=1
MINIMIZE_TO_TRAY=1
TARGET_SIZE=23500
[Paths]
DGIndexNV=D:\Blu-ray Remaster\dgdecnv2046\DGIndexNV.exe
DGDecNV=D:\Blu-ray Remaster\dgdecnv2046\DGDecodeNV.dll
WORKING_PATH=E:\BD_RB\WORKFILES\
SOURCE_PATH=E:\BD_RB\WORKFILES\IMPORTS\PACIFIC_RIM\


Maybe something you can see or which I have missed.

[Hajnal]

No. I purposely made it independent of multiprocess because there were issues. You have to import using the SBS option. But that's about it.

http://thumbnails109.imagebam.com/30730/e0343b307290167.jpg (http://www.imagebam.com/image/e0343b307290167)

source
avc ~14.8gb
mvc ~8.8gb

bdrb software
avc ~11gb
mvc ~9.1gb ??

Frimtranscode gui
avc ~10gb
mvc ~10gb

dvdfab
avc ~12.5gb
mvc ~8gb

upd.

bdrb hardware
avc ~10gb
mvc ~10gb - Why become larger than the original?

and no 3D subtitles

http://thumbnails110.imagebam.com/30733/1ce105307328210.jpg (http://www.imagebam.com/image/1ce105307328210)

[jdobbs]

Hmm, then why didn't it run with two instance even though I set this before opening main program and of course I replace exe file.

I use option import and choose side by side 3D which is 4th option in import caterogy.

Source: Pacific Rim and it is half SBS.



Maybe something you can see or which I have missed. I apologize, my fault. I typed it wrong in my post. You have FRIM_SW_PROCESSES=2 and it should be FRIM_SBS_PROCESSES=2.

[HWK]

You have FRIM_SW_PROCESSES=2 and it should be FRIM_SBS_PROCESSES=2

hmm, thanks I will test again.

[jdobbs]

hmm, thanks I will test again.Sorry about that. I wasted a lot of your time with bad instructions.

[HWK]

Sorry about that. I wasted a lot of your time with bad instructions.

nah, don't be that is fun part of beta testing :D

[HWK]

http://thumbnails109.imagebam.com/30730/e0343b307290167.jpg (http://www.imagebam.com/image/e0343b307290167)

source
avc ~14.8gb
mvc ~8.8gb

bdrb software
avc ~11gb
mvc ~9.1gb ??

Frimtranscode gui
avc ~10gb
mvc ~10gb

dvdfab
avc ~12.5gb
mvc ~8gb

upd.

bdrb hardware
avc ~10gb
mvc ~10gb - Why become larger than the original?

and no 3D subtitles

http://thumbnails110.imagebam.com/30733/1ce105307328210.jpg (http://www.imagebam.com/image/1ce105307328210)
You are trying two address two issues in one post, lets discuss one thing at a time.

BD-Rb is software, there is no hardware part to it.
Muxer used by BD-RB has broken 3D subtitle support in latest version.

[update]
After having closer look I realized you were referring to hardware support provided by Intel not BD-RB.

[jdobbs]

@Hajnal

As you probably know (since you posted in this thread), BD-RB uses FRIMEncode for encoding MVC. In the version you are using there is a bug that doesn't allow BD-RB to keep original 3D sources intact -- in the next release you should never see a target that is larger than the source. It is the bitrate that sets the output size -- and I would guess that your target size that drives the size. The ratio of the base to dependent stream is pretty much out of BD-RB's control, as it is driven by the Intel SDK. I can't really speak to the HW results, as I have no system that uses it. As for comparison to other packages -- I'd rather not comment and I'd appreciate it if those discussions were avoided. For one thing it isn't even close to apples-to-apples, second it violates the "what's best" forum rule -- but more importantly we really shouldn't care how other packages do. I personally only care about my software and the apps it uses (like FRIMEncode) perform.

[Hajnal]

sorry, it's just a compare only

BDRB & Intel Hardware ~40 minutes (i5)

- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 130873 frames
- Bitrate: 31047 Kbs
- Using FRIMEncoder for MVC encoding
- [17:58:55] Reencoding: VID_00098, Pass 1 of 1
- [18:36:06] Video Encode complete

[jdobbs]

sorry, it's just a compare only

BDRB & Intel Hardware ~50 minutes (i5)

- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 130*873 frames
- Bitrate: 31*047 Kbs
- Using FRIMEncoder for MVC encoding The HW setting is pretty fast in comparison. On my AMD system with 8 processors (FX-8350) that would likely take about 3 1/2 hours in SW mode.

[Hajnal]

The HW setting is pretty fast in comparison. On my AMD system with 8 processors (FX-8350) that would likely take about 3 1/2 hours in SW mode.


the settings wrong, moving plaid
http://thumbnails101.imagebam.com/30738/147cb5307375980.jpg (http://www.imagebam.com/image/147cb5307375980)

BDRB make MVCENCODE.BAT (workfiles)
-gop 24 4 0 S

edit

-gop 50 1 2 o

[HWK]

What is playback device for which you are seeing this error?

[omegaman7]

What is playback device for which you are seeing this error?

Indeed. If I wanna confirm results like that, I use a standalone player, or VirtualDub to snatch the frame.

[Hajnal]

What is playback device for which you are seeing this error?

pdvd
windvd
but only when playing 3d

Frimtranscode Gui

[jdobbs]

the settings wrong, moving plaid
http://thumbnails101.imagebam.com/30738/147cb5307375980.jpg (http://www.imagebam.com/image/147cb5307375980)

BDRB make MVCENCODE.BAT (workfiles)
-gop 24 4 0 S

edit

-gop 50 1 2 oI'm not sure what you're trying to say. But BD-RB's settings are meant for blu-ray output. The edited setting you've shown completely violates the blu-ray standard. Maximum GOP length is 24 for 1080p 3D unless the maxbitrate is under 15Mbs (which is likely too low) -- and even then the maximum GOP length is limited to 48.

I've done lots of encoding with FRIMEncode, likely more than most, since my system has been encoding 24/7 testing it -- and I have never once seen anything like that. You haven't given enough information to make heads-or-tails of it... without logs and settings it is pretty much useless.

[Hajnal]

I'm not sure what you're trying to say. But BD-RB's settings are meant for blu-ray output. The edited setting you've shown completely violates the blu-ray standard. Maximum GOP length is 24 for 1080p 3D unless the maxbitrate is under 15Mbs (which is likely too low) -- and even then the maximum GOP length is limited to 48.

I've done lots of encoding with FRIMEncode, likely more than most, since my system has been encoding 24/7 testing it -- and I have never once seen anything like that. You haven't given enough information to make heads-or-tails of it... without logs and settings it is pretty much useless.


BDRB - movie-only backup

FRIM_SW_DECODE=0
FRIM_SW_ENCODE=0
FRIM_SW_PROCESSES=2

MVCENCODE.BAT (fix cli?)

"C:\Programok\BD_Rebuilder\tools\FRIMDecode.exe" -ts -i::mvc "K:\BDMV\STREAM\00098.m2ts" "K:\BDMV\STREAM\00104.m2ts" -o \\.\pipe\bdrb.yuv | "C:\Programok\BD_Rebuilder\tools\FRIMEncode.exe" mvc -i \\.\pipe\bdrb_L.yuv -i \\.\pipe\bdrb_R.yuv -viewoutput -o "D:\TEMP4\WORKFILES\VID_00098.AVS.264" -o "D:\TEMP4\WORKFILES\VID_00098.AVS.mvc" -w 1920 -h 1080 -f 23.976 -u 2 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 31046 45000 -gop 50 4 0 S -maxdpb 4

job done, play bad as the picture, (only 3D) 2D good

Frimtrancode gui
-gop 50 4 0 S change 48 4 0 o

encod,mux 3d.iso, good play

[HWK]

BDRB - movie-only backup

FRIM_SW_DECODE=0
FRIM_SW_ENCODE=0
FRIM_SW_PROCESSES=2

MVCENCODE.BAT (fix cli?)

"C:\Programok\BD_Rebuilder\tools\FRIMDecode.exe" -ts -i::mvc "K:\BDMV\STREAM\00098.m2ts" "K:\BDMV\STREAM\00104.m2ts" -o \\.\pipe\bdrb.yuv | "C:\Programok\BD_Rebuilder\tools\FRIMEncode.exe" mvc -i \\.\pipe\bdrb_L.yuv -i \\.\pipe\bdrb_R.yuv -viewoutput -o "D:\TEMP4\WORKFILES\VID_00098.AVS.264" -o "D:\TEMP4\WORKFILES\VID_00098.AVS.mvc" -w 1920 -h 1080 -f 23.976 -u 2 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 31046 45000 -gop 50 4 0 S -maxdpb 4

job done, play bad as the picture, (only 3D) 2D good

Frimtrancode gui
-gop 50 4 0 S change 48 4 0 o

encod,mux 3d.iso, good play

See the things I have highlight in red, they are responsible for your problem. BD specs clearly state GOP length must be one sec if max bitrate is higher than 15000 which it is. Example if fps 23.976024 then GOP must be 24 frames.

As for second question you can't compare, transcoder only deal with quantization to lower output requirement. Where encoder rebuild picture from scratch.

Either way, bottom line is you need follow specs or let BD-RB handle it. Else do not complain if things don't work.

[HWK]

pdvd
windvd
but only when playing 3d

Frimtranscode Gui

Given the setting you are using, I wouldn't be surprised if it doesn't play on hardware player.

Also consider yourself lucky if it plays at all on software. Also software usually don't follow specs that closely as hardware do and once again it is best to stick BD-RB default setting.

[Hajnal]

See the things I have highlight in red, they are responsible for your problem. BD specs clearly state GOP length must be one sec if max bitrate is higher than 15000 which it is. Example if fps 23.976024 then GOP must be 24 frames.

As for second question you can't compare, transcoder only deal with quantization to lower output requirement. Where encoder rebuild picture from scratch.

Either way, bottom line is you need follow specs or let BD-RB handle it. Else do not complain if things don't work.

http://thumbnails110.imagebam.com/30743/52e930307421207.jpg (http://www.imagebam.com/image/52e930307421207)

I did so
and play bad as the picture

[HWK]

http://thumbnails110.imagebam.com/30743/52e930307421207.jpg (http://www.imagebam.com/image/52e930307421207)

I did so
and play bad as the picture

Try with software, instead of hardware. Accroding this picture media SDK is hardware. At very least decoding is done on software.

[Hajnal]

Try with software, instead of hardware. Accroding this picture media SDK is hardware. At very least decoding is done on software.

the fault is with me
GOP type
- strict = bad
- open = good

tested

[HWK]

Jdobbs, which version of DgdecNV were you using?

[HWK]

@videofan3d

Just want update or progress on ability to insert I frame on demand

http://forum.doom9.org/showpost.php?p=1656939&postcount=390 (http://forum.doom9.org/showpost.php?p=1656939&postcount=390)

[jdobbs]

Jdobbs, which version of DgdecNV were you using?I'm using 2046 (32 bit).

[HWK]

Jdobbs, how many movies you want me to try?

I am finished Pacific Rim and currently doing Avatar with balanced setting in FRIMEncoder, next one I am gone try World War Z (3-way in Dgdecnv) with target usage in frim set to value of 2 or 1 and then something else.

Also if you want I can try with directshowsource as well. Anyways here is the result of first one and no I didn't experience any error during encoding, also just a reminder I am using software mode in FRIMEncoder.

[09:47:13] Importing M2TS: PACIFIC_RIM
- Preparing M2TS for processing...
- Collecting audio/video streams from source...
- Building pseudo-BD source structure...
[11:55:59] Video import completed successfully.
----------------------
[02/11/14] BD Rebuilder v0.46.12t (beta)
[12:00:00] Source: PACIFIC_RIM_00000
- Input BD size: 163.20 GB
- Approximate total content: [02:11:16.952]
- Target BD size: 46.26 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Converting SBS source to BD-3D format
- Quality: Good (Very Fast), ABR
- MVC BD-3D Output Mode enabled
- Decoding/Frame serving: DGDecNV [2-way]
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[12:00:00] PHASE ONE, Encoding
- [12:00:00] Processing: VID_00000 (1 of 1)
- [12:00:00] Extracting A/V streams [VID_00000]
- [12:59:52] Reencoding video [VID_00000]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 188,858 frames
- Bitrate: 35,000 Kbs
- Using FRIMEncoder for MVC encoding
- [12:59:52] Reencoding: VID_00000, Pass 1 of 1
- [16:52:55] Video Encode complete
- [16:52:55] Processing audio tracks
- Track 4352 (eng): Keeping original audio
[16:52:55]PHASE ONE complete
[16:52:55]PHASE TWO - Rebuild Started
- [16:52:56] Rebuilding BD file Structure
[17:05:28] - Encode and Rebuild complete
[17:05:28] JOB: PACIFIC_RIM finished.


http://i58.tinypic.com/9hrn7b.jpghttp://i59.tinypic.com/ir5ouc.jpg

In first screenshot I want to show encoding completely successfully and for second one I want to show tsmuxer had no problem in joining files and building structure.

[02/11/14] Checking System Settings
- BD-Rebuilder v0.46.12t (beta)
- Windows Version: 6.1 [7601]
- AVISYNTH Version: 2.5.8.0, Ok
- HAALI Splitter: 1.9.42.1, Ok
- FFDSHOW: 4504, Ok
- WIN7 preferred AVC CODEC: Ok
- WIN7 preferred VC-1 CODEC: Ok
- WIN7 preferred MPEG2 CODEC: Ok
- FFDSHOW VC-1 set to "wmv9", Ok
- FFDSHOW MPEG2 set to "libavcodec": Ok
- FFDSHOW AVC set to "libavcodec": Ok
- AnyDVD settings check: Ok.
- X264: Ok
- AFTEN: Ok
- FAAC: Ok
- WAVI: Ok
- TSMUXER: Ok
- FRIMEncode: Ok
- FRIMDecode: Ok
[02/11/14] Systems Settings Check complete


First VID_00000.AVS.1 file contents

"D:\Blu-ray Remaster\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.1.avs" -viewoutput -o::mvc "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.1.264" "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.1.mvc" -sw -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 35000 35000 -gop 24 4 0 S -maxdpb 4


Second VID_00000.AVS.2 file contents

"D:\Blu-ray Remaster\BD_Rebuilder\tools\FRIMEncode.exe" -avi -sbs 2 -i "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.2.avs" -viewoutput -o::mvc "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.2.264" "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.2.mvc" -sw -w 3840 -h 1080 -f 23.976 -u 6 -cpbsize 3750 -l 6 -profile high -level 4.1 -vbr 35000 35000 -gop 24 4 0 S -maxdpb 4


First avisynth script

#Created by BD Rebuilder - v0.46.12t (beta)
LoadPlugin("D:\Blu-ray Remaster\dgdecnv2046\DGDecodeNV.dll")
DGSource("E:\BD_RB\WORKFILES\WORKFILES\VID_00000.DGI", fieldop=0).Trim(0,-94429)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)


Second avisynth script

#Created by BD Rebuilder - v0.46.12t (beta)
LoadPlugin("D:\Blu-ray Remaster\dgdecnv2046\DGDecodeNV.dll")
DGSource("E:\BD_RB\WORKFILES\WORKFILES\VID_00000.DGI", fieldop=0).Trim(94429,0)
Spline16Resize(3840,1080)
ConvertToYV12().AssumeFPS(24000,1001)

Pacific Rim Status
[Status]
LABEL=PACIFIC_RIM
VERSION=v0.46.12t (beta)
SOURCE_SIZE=175236993024
SOURCE_VIDEO_SIZE=175236993024
TARGET_SIZE=49666850816
REDUCTION=.283426746595667
RESIZE_1080=0
RESIZE_1440=0
AUDIO_TO_KEEP=eng;
KEEP_HD_AUDIO=-1
SUBS_TO_KEEP=all
BACKUP_MODE=1
MOVIEONLY_TYPE=0
USE_LAVF=0
INSTANCES=4
DGDECNV=-1
SSIF_MODE=0
QUICK=0
ENCODE_STEP=0
COMPLETED=1
REBUILD_COMPLETE=1
[00000]
AUDIO=1
PGS=1
APULLDOWN=0
S1440=0
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=49666850816
RATE=35000
SPLITS=2
NSIZE=0
FLINK=0
MLINK=0


tsmuxer meta file contents

MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --label=PACIFIC_RIM --vbr --custom-chapters=00:00:00.000;00:05:00.000;00:10:00.000;00:15:00.000;00:20:00.000;00:25:00.000;00:30:00.000;00:35:00.000;00:40:00.000;00:45:00.000;00:50:00.000;00:55:00.000;01:00:00.000;01:05:00.000;01:10:00.000;01:15:00.000;01:20:00.000;01:25:00.000;01:30:00.000;01:35:00.000;01:40:00.000;01:45:00.000;01:50:00.000;01:55:00.000;02:00:00.000;02:05:00.000;02:10:00.000 --vbv-len=500 --start-time=27000000
V_MPEG4/ISO/AVC, "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.1.264"+"E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.2.264", fps=23.976, insertSEI, contSPS
V_MPEG4/ISO/MVC, "E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.1.mvc"+"E:\BD_RB\WORKFILES\WORKFILES\VID_00000.AVS.2.mvc", fps=23.976, insertSEI, contSPS
A_DTS, "E:\BD_RB\WORKFILES\WORKFILES\00000.track_4352.DTS", lang=eng
S_HDMV/PGS, "E:\BD_RB\WORKFILES\WORKFILES\00000.track_4608.SUP",fps=23.976,3d-plane=0,lang=eng


If you are wondering about size, it is because I am feeding almost lossless file to BD-RB created by x264. Also just want to say quality looks quite good even with half SBS source.

[Cedvano]

BD-Rebuilder v0.46.12t (beta) ?
I can't find this version for test. Or it's a reserved beta ?

[jdobbs]

BD-Rebuilder v0.46.12t (beta) ?
I can't find this version for test. Or it's a reserved beta ?It's a page or so (http://forum.doom9.org/showthread.php?p=1667297#post1667297) back in this thread. It's meant just for testing multiple processes in SBS encoding.

[videofan3d]

@videofan3d

Just want update or progress on ability to insert I frame on demand

http://forum.doom9.org/showpost.php?p=1656939&postcount=390 (http://forum.doom9.org/showpost.php?p=1656939&postcount=390)

Unfortunately, it seems it doesn't work properly in the Intel Media core libraries :(

There is already a hidden feature in FRIMEncode (you can try it)

-gopfile gopfilename.txt

where gopfilename.txt is text file in structure:

<frame_no> I
e.g.


40 I
256 I
1025 I


etc. (frame_no starting 0)


BUT:
It seems there is a bug in Intel Media core libraries.
I observed the following:

1. when using -sw library, no extra key I-frame is inserted - never !!! Bad! :(
2. when using -hw library, and -gop 24 1 0 O (i.e. no B-frames), then Key I-Frame is inserted in expected position
3. when using -hw library, and -gop 24 4 0 O , the Key I-Frame is inserted but on wrong position (usually shifted few frames earlier) - Bad! :(

This is practically useless for HD video processing because B-frames are essential for efficient video encoding...

(I also contacted Intel regarding this issue, but it seems this is not their top priority (I guess they are concentrating to upcoming HEVC))

[HWK]

It's a page or so (http://forum.doom9.org/showthread.php?p=1667297#post1667297) back in this thread. It's meant just for testing multiple processes in SBS encoding.

Jdobbs, do you need more info from me about multiprocess of pacific rim. Also would you be interested in result of others.

[HWK]

Unfortunately, it seems it doesn't work properly in the Intel Media core libraries :(

There is already a hidden feature in FRIMEncode (you can try it)

-gopfile gopfilename.txt

where gopfilename.txt is text file in structure:

<frame_no> I
e.g.


40 I
256 I
1025 I


etc. (frame_no starting 0)


BUT:
It seems there is a bug in Intel Media core libraries.
I observed the following:

1. when using -sw library, no extra key I-frame is inserted - never !!! Bad! :(
2. when using -hw library, and -gop 24 1 0 O (i.e. no B-frames), then Key I-Frame is inserted in expected position
3. when using -hw library, and -gop 24 4 0 O , the Key I-Frame is inserted but on wrong position (usually shifted few frames earlier) - Bad! :(

This is practically useless for HD video processing because B-frames are essential for efficient video encoding...

(I also contacted Intel regarding this issue, but it seems this is not their top priority (I guess they are concentrating to upcoming HEVC))

Thank you, I guess I will live without I frame support.

[HWK]

Jdobbs, for SBS 3D. How did you prepare source files? I am wondering if it has to do something.

[jdobbs]

Jdobbs, do you need more info from me about multiprocess of pacific rim. Also would you be interested in result of others.Are you seeing any significant speed increase when using two instances with sw encoding? I'm just wondering if it is worth the effort. It would also be nice if someone tested with various settings to see if the -hw setting increases encoding speeds. I know your system is like mine, though, and doesn't support the -hw option.

If it looks worthwhile I could extend the splitting/encoding to normal (non SBS) 3D backups as well.

[jdobbs]

Thank you, I guess I will live without I frame support.It's not too much of a problem anyway. It just makes chapter seeking landings an average of 1/2 second off when strict GOPs are used. If open GOPS are used it might get a little worse, I haven't tried it.

[HWK]

Are you seeing any significant speed increase when using two instances with sw encoding? I'm just wondering if it is worth the effort. It would also be nice if someone tested with various settings to see if the -hw setting increases encoding speeds. I know your system is like mine, though, and doesn't support the -hw option.

If it looks worthwhile I could extend the splitting/encoding to normal (non SBS) 3D backups as well.

Yeah, my speed did increase but bottleneck was massive data rate coming into encoder.

BTW: I manage to reproduce your crash with another movie and I will try the setting which I used before to see if there is some sort of pattern which cause crash.

At this stage it is too early to say, but as soon as I have something useful I will let you know.

When I did pacific rim I only used I Frame in original video, no P and B. However I just did avatar with P and b frames included and it crashed as well. I am encoding it in such a way that it has only I frame and then I will run through FRIMEncoder and see what happens. Also few days back I posted about using frimdecode to serve frame and it caused crash as well if splitting is not done properly.

[jdobbs]

Yeah, my speed did increase but bottleneck was massive data rate coming into encoder.

BTW: I manage to reproduce your crash with another movie and I will try the setting which I used before to see if there is some sort of pattern which cause crash.

At this stage it is too early to say, but as soon as I have something useful I will let you know.

When I did pacific rim I only used I Frame in original video, no P and B. However I just did avatar with P and b frames included and it crashed as well. I am encoding it in such a way that it has only I frame and then I will run through FRIMEncoder and see what happens. Also few days back I posted about using frimdecode to serve frame and it caused crash as well if splitting is not done properly.You didn't have any issues when the split was done by BD-RB, did you? BD-RB scans the CLPI's EP_Map table to ensure the split is done at the right points.Yeah, my speed did increase but bottleneck was massive data rate coming into encoder. My best case was about 32% speed increase, and it averaged somewhere in the 20-30% range. I would expect to see a lot more on a HW based encode (assuming no bottleneck in the GPU). Of course that didn't do me much good since it crashes almost every time for me. The real pain is that it takes so long to happen. My last test went 78,000 frames before it crashed.

[HWK]

You didn't have any issues when the split was done by BD-RB, did you? BD-RB scans the CLPI's EP_Map table to ensure the split is done at an IDR frame.

That test was not conducted by using BD-RB, I was just writing this to warn about issues I saw if you decide to go ahead with splitting/encoding to normal (non SBS) 3D backups option. If time and resource permit and you are willing to write code I can test it for you.

[HWK]

My best case was about 32% speed increase, and it averaged somewhere in the 20-30% range. I would expect to see a lot more on a HW based encode (assuming no bottleneck in the GPU). Of course that didn't do me much good since it crashes almost every time for me. The real pain is that it takes so long to happen. My last test went 78,000 frames before it crashed.

My time was roughly cut in half with that and if source was say around 23 gb in size instead of 163 GB. It was going at 0.98X speed. Also all read and write was done on same drive.

[jdobbs]

My time was roughly cut in half with that and if source was say around 23 gb in size instead of 163 GB. It was going at 0.98X speed. Also all read and write was done on same drive.Interesting. All of mine were done with the source being on a different drive than the working folder. I think I'll test and see if that makes a difference. FYI, I already did some tests in which I placed a redundant executable and DLL in different folders -- and it still failed. I was thinking there might be an issue with multiprocessing calls.

Your system is definitely going faster than mine. I peak at around 14fps with two processes and most of the time it is 12-13fps.

One other thing I noticed... that lowering the output bitrate seems to speed up encoding. That makes me think it may be I/O bound.

[HWK]

One other thing I noticed... that lowering the output bitrate seems to speed up encoding. That makes me think it may be I/O bound.

Can you fire up resource monitor and see how much read and write is happening during encode session. Also how much RAM you machine have?

[HWK]

Your system is definitely going faster than mine. I peak at around 14fps with two processes and most of the time it is 12-13fps.



That was with target quality in Frim set to value of 4.

[jdobbs]

Can you fire up resource monitor and see how much read and write is happening during encode session. Also how much RAM you machine have?I have 8GB RAM. There's lot's of available/unused RAM during encode.

[Hajnal]

hello

Gravity 3D
BDRB - FRIMEncoder for MVC encoding even sw or hw coded
-gop 24 4 0 S command , bad movie

but the command
-gop 24 4 0 O , good movie

[jdobbs]

hello

Gravity 3D
BDRB - FRIMEncoder for MVC encoding even sw or hw coded
-gop 24 4 0 S command , bad movie

but the command
-gop 24 4 0 O , good moviePlease don't post any more of these. You've made your point -- but the reported issue doesn't happen to anybody else, and repeating it over-and-over doesn't change anything. I've personally done hundreds of encodes in testing and have never had a single issue with the strict parameter. I've tested on software players and standalone players. That leads me to believe it is your configuration (either setup or playback) that is at fault. Changing from strict to open GOPs is highly unlikely to cause any kind of detectable difference on a good playback device (other than slightly more efficiency).

Also, this isn't a BD-RB thread -- and we don't need to hijack it. This thread is meant for comments on the topic of "Free H.264 MVC 3D Encoder". If you want to report issues specific with BD-RB please post in the BD-RB Bug Reporting thread.

If anyone else out there is seeing issues when using the "S" (strict) parameter of FRIMEncode. Please post what you are seeing.

[jdobbs]

@HWK

I took note of this post (http://forum.doom9.org/showthread.php?p=1667884#post1667884) by r0lZ today. I'm going to run some tests to see if I still get the multiple instance issue with one of the v4.x.x.x libraries.

[update] No joy. Same issue.

[colinhunt]

Gravity 3D
BDRB - FRIMEncoder for MVC encoding even sw or hw coded
-gop 24 4 0 S command , bad movie
I did Gravity last night, latest BD-RB and MVC encoder running on software, using "-gop 24 4 0 S"... and it came out perfect. No problems at all.

[jdobbs]

Has anyone here successfully used AVS2YUV to feed AVS files to FRIMEncode via stdin? I can't seem to get it to work. If I use AVS2YUV to output to a .YUV file and then use that as input and it works fine -- but no luck piping via stdin.

I know I can use the -avi option and read the AVS directly -- but I'm trying to find a workaround for an issue.

[HWK]

Has anyone here successfully used AVS2YUV to feed AVS files to FRIMEncode via stdin? I can't seem to get it to work. If I use AVS2YUV to output to a .YUV file and then use that as input and it works fine -- but no luck piping via stdin.

I know I can use the -avi option and read the AVS directly -- but I'm trying to find a workaround for an issue.

It is interesting I tried yesterday and I couldn't get avs2yuv to work. It says can't write multiple times or similar as error message. I also gave try avs2pipe which is modification of avs2yuv to allow audio as well but it doesn't serve raw yuv frames.

Oh well back on drawing board. Just an update I didn't have time to run avatar yesterday, I am hoping today I can make some time.

[HWK]

Jdobbs, just update on multiprocess of FRIMEncode, it seems failure. Oh well at least attempt was taken.

[jdobbs]

Jdobbs, just update on multiprocess of FRIMEncode, it seems failure. Oh well at least attempt was taken.Yeah, same for me. I'm giving up for a while.

[nunub]

@Cedvano
Still waiting for ur frim encoder gui. I hope it will be ready sooner.

[Cedvano]

Sorry, I just go home after journey in hospital. When I still fine, I re-work on it. Thanks

[HWK]

Sorry, I just go home after journey in hospital. When I still fine, I re-work on it. Thanks

Ouch, hopefully you will recover soon and will be back in full force.

[jdobbs]

Sorry, I just go home after journey in hospital. When I still fine, I re-work on it. Thanks I hope everything is alright. Take your time and get better.

[nunub]

@Cedvano
Thanks for responding and i would like to clear u all that cedvano is working in a hospital and this is just a research and a hobby kind side work for him.

[trevorjharris]

Tried your premiere pro application with -viewoutput -vbr 28000 40000 as options. This produces 3 files a .h264, .avc, .mvc. Is there a way of producing just 3 files.

[HWK]

Tried your premiere pro application with -viewoutput -vbr 28000 40000 as options. This produces 3 files a .h264, .avc, .mvc. Is there a way of producing just 3 files.

Can you elaborate on your question or what do you want to find out?

[nerdfactormax]

I hate to pollute this thread with what could be a complete noob question, but here goes:

I'm trying to render direct from Premiere Pro CC -> Debugmode Frameserver -> avisynth -> FRIMEncode but I get an error "Cannot open input avi-file input.avs"
I've tried to copy the example (6) in the FRIMEncode_readme as close as possible.

In the frameserver I have tried RGB24 and YUY2
My batch file is:
FRIMEncode -avi -sbs 2 -i input.avs -viewoutput -o::mvc output_base.avc output_dependent.mvc -vbr 28000 40000 -u 1
My input.avs is:
AVISource(“full_filename_shown_in_frameserver.avi”)
ConvertToYV12()

The batch file and input.avs are both in the same directory as the frimencode.exe

Incidentally (and maybe related), the frameserver seems to run fine the first time, but after that Premiere wont open the export window until you remove the frameserver plugin.

Could it be an issue of mixing 32/64bit within the chain? I believe Premiere is 64 bit but the rest of the path is 32.

[videofan3d]

I hate to pollute this thread with what could be a complete noob question, but here goes:

I'm trying to render direct from Premiere Pro CC -> Debugmode Frameserver -> avisynth -> FRIMEncode but I get an error "Cannot open input avi-file input.avs"
I've tried to copy the example (6) in the FRIMEncode_readme as close as possible.

In the frameserver I have tried RGB24 and YUY2
My batch file is:
FRIMEncode -avi -sbs 2 -i input.avs -viewoutput -o::mvc output_base.avc output_dependent.mvc -vbr 28000 40000 -u 1
My input.avs is:
AVISource(“full_filename_shown_in_frameserver.avi”)
ConvertToYV12()

The batch file and input.avs are both in the same directory as the frimencode.exe

Incidentally (and maybe related), the frameserver seems to run fine the first time, but after that Premiere wont open the export window until you remove the frameserver plugin.

Could it be an issue of mixing 32/64bit within the chain? I believe Premiere is 64 bit but the rest of the path is 32.

Hi, process you have described is in principle correct, and it should work.
Premiere and Debugmode plugin are 64-bit, Avisynth and FRIMEncode are 32 - but those are separate processes interfacing on file level, so there is no conflict.

Please check if you have correct setting of ffdshow for AVI processing - it was described somewhere above in this thread:
1. Start ffdshow (usually from Start Menu/All Programs)
2. Select “VFW Configuration”
3. On the “Decoder” tab, scroll down to "Raw Video"
4. Select "All Supported"

i.e. if you are able to encode any YUV 4:2:0 avs file.


Btw. did you also try direct FRIMExport.prm plugin with Adobe CC? (I could test it only with CS6)

[nerdfactormax]

Hi, process you have described is in principle correct, and it should work.
Premiere and Debugmode plugin are 64-bit, Avisynth and FRIMEncode are 32 - but those are separate processes interfacing on file level, so there is no conflict.

Please check if you have correct setting of ffdshow for AVI processing - it was described somewhere above in this thread:
1. Start ffdshow (usually from Start Menu/All Programs)
2. Select “VFW Configuration”
3. On the “Decoder” tab, scroll down to "Raw Video"
4. Select "All Supported"

i.e. if you are able to encode any YUV 4:2:0 avs file.


Btw. did you also try direct FRIMExport.prm plugin with Adobe CC? (I could test it only with CS6)

I don't think I ffdshow installed, now I do.

I just tried the FRIMExport.prm with Adobe CC and got
ERROR: Cannot initialize Intel Media SDK Session
ERROR: Cannot start encoding process.
these lines also appear on subsequent attempts
ERROR: Cannot create output file blah:\blah\blah.avc
ERROR: Cannot start encoding process.
ERROR: Cannot create output file blah:\blah\blah2.avc
ERROR: Cannot start encoding process.

It seems multiple attempts remember past attempted filenames (and failed attempts create empty files which can't be deleted while premiere is open)

I would like to attempt a less convoluted tool-chain to start with, but I'm not sure how to render YUV straight out of Premiere. I've had a look at all the options of the different export types and come to the conclusion that I'm out of my depth.

I retried the original method with ffdshow now setup, but had the same result (cannot open avi-file input.avs).

I'll search the internet for a sample yuv file to play with.

[videofan3d]

I just tried the FRIMExport.prm with Adobe CC and got
ERROR: Cannot initialize Intel Media SDK Session
ERROR: Cannot start encoding process.
these lines also appear on subsequent attempts
ERROR: Cannot create output file blah:\blah\blah.avc
ERROR: Cannot start encoding process.
ERROR: Cannot create output file blah:\blah\blah2.avc
ERROR: Cannot start encoding process.

It seems multiple attempts remember past attempted filenames (and failed attempts create empty files which can't be deleted while premiere is open)


It seems that FRIMExport.prm cannot find libmfxsw64.dll library!

Please note that FRIMExport is 64-bit DLL for Adobe, thus it requires also 64-bit Intel Media core libraries.
You need to have either libmfxsw64.dll (-sw mode, part of FRIM 64-bit distribution pack) or libmfxhw64.dll (part of Intel graphic driver) in your %PATH%.

FRIMExport should eliminate any interim chain, it produces directly elementary h264 or mpeg2 stream, suitable for multipexing with audio (tsMuxer 3D)

[nerdfactormax]

It seems I had the 64bit FRIMEncode. Trying with the 32bit version I get
ERROR: Cannot get YUV420 frame from input avi-file input.avs
I tried the frameserver with RGB24 and YUY2

[videofan3d]

It seems I had the 64bit FRIMEncode. Trying with the 32bit version I get
ERROR: Cannot get YUV420 frame from input avi-file input.avs
I tried the frameserver with RGB24 and YUY2

Then this message clearly identifies incorrect setting of ffdshow filters. Try to play with its setting (as mentioned above) - at the end you will find proper combination :-)

Remark:
frameserver RGB24 or YUV2 has impact only to interface between Premiere and Debugmode.
But once you have command ConvertToYV12() in your AVS script (which is necessary), then output is converted to the needed format YUV4:2:0.
And then ffdshow will do the work for passing data into Video For Windows (VFW) API for FRIMEncode.

[videofan3d]

...
I'll search the internet for a sample yuv file to play with.

You can create your own YUV420.AVI.
Take short sample of input.h264 file and use example (3) from FRIMDEcode_readme.pdf:

FRIMDecode -i::h264 input.h264 -o \\.\pipe\yuvpipe

and then in another separate command-session:

ffmpeg -f rawvideo -s 1920x1080 -r 23.976 -pix_fmt yuv420p -i \\.\pipe\yuvpipe -vcodec copy -y output.avi

will create an AVI-file with uncompressed YUV 4:2:0 video.

(assuming you have installed ffmpeg, of course :) )

[nerdfactormax]

To whoever made FRIMEncode and to whoever made tsMuxer:
THANKYOU THANKYOU THANKYOU.
I've spent the last year editing a 3D concert video. At the start of the journey, I wasn't expecting to be able to easily author a proper 3D Bluray so discovering this forum has been awesome.

Being able to render from original source, through after effects, into premiere pro and export to the 3D encoded file without any intermediate rendering is AMAZING.

My problem now is that everything was done at 25fps (zero budget, had to borrow cameras for the shoot) and it seems that 25fps is not a bluray standard :(
My choices seem to be 24p or 50i.
Thats probably a question for a different forum, but I thought I'd drop by and express my gratitude.

[titlis]

@nerdfactormax

you can make blu-ray compliant 25p stream with either x264's --fake-interlaced parameter or simply encode 25p as 50i, psf
or I believe 2:2 pulldown option could also do that

[nunub]

@nerdfactormax

you can make blu-ray compliant 25p stream with either x264's --fake-interlaced parameter or simply encode 25p as 50i, psf
or I believe 2:2 pulldown option could also do that

He is talking about 3D bluray compliancy not normal bluray.

[nunub]

@videofan3d
I think the parameters for premiere pro export of frim encoder is showing error. Can u please detail me where to put that libmfxsw64.dll into the right path. As i m using AMD quad core machine.

[videofan3d]

@videofan3d
I think the parameters for premiere pro export of frim encoder is showing error. Can u please detail me where to put that libmfxsw64.dll into the right path. As i m using AMD quad core machine.

You can place it anywhere you want, just make sure that this directory is defined in PATH variable :)

My own setup:

"c:\Program Files\Intel\Media SDK 2014 for Clients\bin\win32\libmfxsw32.dll"
"c:\Program Files\Intel\Media SDK 2014 for Clients\bin\x64\libmfxsw64.dll"

and
PATH=...;C:\Program Files\Intel\Media SDK 2014 for Clients\bin\x64;C:\Program Files\Intel\Media SDK 2014 for Clients\bin\win32;...

Remark info:
During a week I'm going to release also FRIMImport.dll for Premiere CS6 which will allow importing .MTS files from 3D-camcorders (specifically my beloved Panasonic Z10000) directly to Adobe Premiere.
This will allow (together with FRIMExport.dll) rendering Bluray-3D without any time-or-space-or-quality consuming re-encoding via some intermediate format.

[nunub]

@videofan3d
Thanks for ur info i will look into it and will see what is the outcome. And also would request ur kindself in ur frimimport kindly decode sbs or ou files inside premiere pro also as it will kill those tedious job of enlarging those frames or atleast a preset for it. And is there any problem using adobe 7.2.1 with frim.
Thanks once again for ur very and most important work for all the 3d community.

[nerdfactormax]

So I slowed my video down to 23.976fps and it still looks and sound great. I can render to mvc-3d straight out of premiere for shorter sections, but when I tried to render the whole video (70mins), it crashed about halfway with:
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1086)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1282)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1086)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1282)

I use tsMuxerGUI to combine the .h264 with the .wav and generate an iso. That creates a proper 3d bluray and all is well. Is there a way I can generate a file that I can import into encore which it wont try to retranscode (and destroy the 3d on the way)? I would like to be able to create menu/chapters etc.

[colinhunt]

Is there a way I can generate a file that I can import into encore which it wont try to retranscode (and destroy the 3d on the way)? I would like to be able to create menu/chapters etc.
Not possible, as far as I know. It's a limitation of Encore. You need other, more expensive software to author BD3Ds with menus.

[videofan3d]

... but when I tried to render the whole video (70mins), it crashed about halfway with:
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1086)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1282)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1086)
ERROR: unknown error (-1),
..\frim_encode\src\pipeline_encode.cpp (1282)



Frankly, I have never rendered such long video - all my videos are shorter, up to 20 minutes.
(nowadays is "time of youtube" when users are used to watch up to 1 minute, everything longer is considered old-fashioned and boring :D :D :D )

Now seriously: I personally didn't face this issue so far.
Unknown error (-1) is reported by core Intel Media library, and line 1086 indicates it is when allocating internal memory during thread synchronization.
Similar error was reported some time ago, when people here tried to run two instances of FRIMEncode in parallel.
I have no solution for it... :(

[Guest]

Try it with Intel driver 3496 beta. They have fixed a lot of memory allocation issues.

At the Intel site use Driver Browse/Search and search for "3496"; don't use auto driver detect. Please report the results.

[nerdfactormax]

Try it with Intel driver 3496 beta. They have fixed a lot of memory allocation issues.

At the Intel site use Driver Browse/Search and search for "3496"; don't use auto driver detect. Please report the results.
Thanks, I'll try that tonight.
I notice that the rendered file has 0 size until it is finished. Does that mean that it's trying to keep everything in RAM? That could pose a problem when I want to render an entire Bluray at high quality and I only have 16gig of ram.

[videofan3d]

I notice that the rendered file has 0 size until it is finished. Does that mean that it's trying to keep everything in RAM? That could pose a problem when I want to render an entire Bluray at high quality and I only have 16gig of ram.

No, this is just a consequence that file is opened for a long time and not "flushed". Operating system then doesn't present its exact size.
No worry about this phenomenon :)

[videofan3d]

Hi,

FRIM version 1.23 is released.

Changes:
all modules - code refactoring (removal of dependency on legacy stdout/stderr, optimized CPU utilization)

FRIM Encode, FRIM Transcode
- new encoding modes
-lavbr bitRate depth (.... renamed from -labrc)
-avbr bitRate accuracy convergence
-icq quality
-laicq quality depth

FRIMSource.dll
- fixed identification of interlaced sources
- parameter reload=false|true (default true)
- parameter num_frames=0 ... zero as num_frames will imply automatic length calculation, works only for TS-container !

FRIMExport.prm
- manual setting of MVC-3D TAB vs. SBS layout added
- viewoutput creates only two files .avc and .mvc

FRIMImport.prm
- new module, importer to Adobe Premiere Pro (CS6), see FRIMPremiere_readme.pdf for description

Please read more in release notes.

[colinhunt]

Well, it's been a while since I last used FRIMTranscode or FRIMEncoder, so it could well be I'm out of touch... but when I ran the latest FRIMTranscode, I got this:

frimtranscode -i::mvc base.avc dependent.mvc -o::mvc output.h264 -vbr 34000 48000 -u 3

FRIM Transcoder version 1.23 (build: Mar 19 2014)
- based on Intel(R) Media SDK

ERROR: unknown error (-1), src\pipeline_transcode.cpp (1321)
ERROR: unknown error (-1), src\pipeline_transcode.cpp (1693)

Encoding rig: Windows 7 64-bit, i7-3770K and 16GB of RAM, operated via Remote Desktop.

[videofan3d]

Well, it's been a while since I last used FRIMTranscode or FRIMEncoder, so it could well be I'm out of touch... but when I ran the latest FRIMTranscode, I got this:

frimtranscode -i::mvc base.avc dependent.mvc -o::mvc output.h264 -vbr 34000 48000 -u 3

FRIM Transcoder version 1.23 (build: Mar 19 2014)
- based on Intel(R) Media SDK

ERROR: unknown error (-1), src\pipeline_transcode.cpp (1321)
ERROR: unknown error (-1), src\pipeline_transcode.cpp (1693)

Encoding rig: Windows 7 64-bit, i7-3770K and 16GB of RAM, operated via Remote Desktop.


error line 1321 points to surface memory allocation error in core Intel Media libraries.

Try to run it in -sw mode, or install newer Intel driver.

Neuron2 pointed out above:
"Try it with Intel driver 3496 beta. They have fixed a lot of memory allocation issues.
At the Intel site use Driver Browse/Search and search for "3496"; don't use auto driver detect. "

Btw.: this driver 3496 contains SDK API ver 1.8 - where new ICQ mode is available.

[colinhunt]

Try to run it in -sw mode, or install newer Intel driver.
I had actually installed the 3496 drivers only minutes earlier. I'll try -sw mode next.

[worknstiff]

I have an i7-2600k and have been trying to get BD_Rebuilder to use FRIMEncoder with it. I was hoping you have had better luck than I have. Did the latest intel driver help or should I just break down and buy the latest i7 and hope it will work with FRIME?

[colinhunt]

I have an i7-2600k and have been trying to get BD_Rebuilder to use FRIMEncoder with it. I was hoping you have had better luck than I have. Did the latest intel driver help or should I just break down and buy the latest i7 and hope it will work with FRIME?
Nah, it's been playing silly buggers, crashing all too often. I've just installed the one release older drivers to see if that makes a difference.

[colinhunt]

@ videofan3d, do you know how well or poorly FRIMEncoder scales in multi-cpu systems? I replaced the Xeon CPUs in my old encoding rig with newer Xeons (X5660), and got a total of 12 cores and 24 threads. That looks great on paper, but I'm now running the new BD-RB (47.03), doing a full 3D backup using software decode/encode - and CPU usage hovers around 30-35% only. BD-RB reports FRIMEncoder is pushing only 5 fps.

So I'm wondering where to start looking for a bottleneck. Could it be that FRIMEncoder is unable to take full advantage of all the cores/threads on a dual-Xeon setup? Or should I be looking for a bottleneck elsewhere?

[videofan3d]

@ videofan3d, do you know how well or poorly FRIMEncoder scales in multi-cpu systems? I replaced the Xeon CPUs in my old encoding rig with newer Xeons (X5660), and got a total of 12 cores and 24 threads. That looks great on paper, but I'm now running the new BD-RB (47.03), doing a full 3D backup using software decode/encode - and CPU usage hovers around 30-35% only. BD-RB reports FRIMEncoder is pushing only 5 fps.

So I'm wondering where to start looking for a bottleneck. Could it be that FRIMEncoder is unable to take full advantage of all the cores/threads on a dual-Xeon setup? Or should I be looking for a bottleneck elsewhere?

Hi,

I personally use Intel i7-4770K 3.5 GHz (Haswell), Intel Graphics HD 4600, 16 GB RAM, so I cannot comment on XEON. For this you can try to search on Intel Media SDK forum (http://software.intel.com/en-us/forums/intel-media-sdk?page=1).

And I also didn't do any deep performance tests on encoding-decoding schema, specifically not related to multithreading (which is implemented internally in core Intel Media libraries)

Few months ago I did performance and quality test for decoding on i7 (it is described somewhere before in this thread) which showed me that -hw and -sw decoding provides identical YUV output but -hw is significantly faster.

For encoding, I only realized that -wh and -sw produces slightly different results which points to the fact that HW-library uses different algorithm than SW-library (this was also confirmed by Intel support).

And obviously: HW encoding is faster than SW, but it may share/occupy some more GPU resources and thus HW decoding-encoding chain can exhaust them.
I personally use -hw for decoding and -sw for encoding portion of processing chain.

[colinhunt]

I personally use Intel i7-4770K 3.5 GHz (Haswell), Intel Graphics HD 4600, 16 GB RAM, so I cannot comment on XEON.
In order to figure out what's going on, I ran another instance of BD-RB while the first one was still encoding MVC in software at 30-35% CPU utilization. I also set up the 2nd BD-RB in such a way that it was using super-slow, super high-quality settings for x264.

After 2 hours of two BD-RBs running simultaneously, the one encoding MVC had dropped from 5 to 4 fps. The second BD-RB is running x264 pass 2/2 at 7.25 fps. That's pretty much the encoding speed I got from a dual-Xeon E5520 during pass 2/2 when set for the same super high-quality settings.

All this looks to me like FRIMEncoder, or the Intel SDK it's based on, is not optimized for multithreading and/or multi-CPU. I'm not a programmer so I might be totally incorrect about this, however :)

[jdobbs]

In order to figure out what's going on, I ran another instance of BD-RB while the first one was still encoding MVC in software at 30-35% CPU utilization. I also set up the 2nd BD-RB in such a way that it was using super-slow, super high-quality settings for x264.

After 2 hours of two BD-RBs running simultaneously, the one encoding MVC had dropped from 5 to 4 fps. The second BD-RB is running x264 pass 2/2 at 7.25 fps. That's pretty much the encoding speed I got from a dual-Xeon E5520 during pass 2/2 when set for the same super high-quality settings.

All this looks to me like FRIMEncoder, or the Intel SDK it's based on, is not optimized for multithreading and/or multi-CPU. I'm not a programmer so I might be totally incorrect about this, however :)Be careful. If you look back through the thread you'll see that running multiple instances of FRIMEncode can cause a crash. I tried adding multiple instances to speed up encoding and had to give up the idea.

[colinhunt]

Be careful. If you look back through the thread you'll see that running multiple instances of FRIMEncode can cause a crash. I tried adding multiple instances to speed up encoding and had to give up the idea.
That's good to know, thanks. My test above was running a single instance of FRIMe and a single instance of x264, however.

[Shylock]

Hi,

Using Frim through BDRB with Intel I7 4770k and hardware setting, both for decoding and encoding, No errors reported but the resulting stream is heavily corrupted and unwatchable, as if the disc was not ripped correctly.
The same with 3 different discs.
If switching to software encoding, everything is OK.
I'm using the last 3496 beta drivers. Have someone experienced the same issue ?

[Hajnal]

hi

using frimencoder and scenarist 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
D:\temp\WORKFILES\VID_00000.AVS.mvc

command: "D:\TEMP\WORKFILES\VID_00000.AVS.mvc" -laicq 1 -d3d11 -hw -rf 4 -w 1920 -h 1080 -f 23.976 -u 1 -cpbsize 3743 -l 6 -profile high -level 4.1 -vbr 32331 34826 -gop 24 4 0 O -maxdpb 4

-gop 24 4 0 O - other setting?

[acsphere]

Hi,

Using FRIMDecoder version 1.23 (build: Mar 19 2014), and get the following near the very end of the decoding:

ERROR: undefined behavior (-16), src\pipeline_decode.cpp (1116)

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



More details:

FRIMDecode.exe -i::mvc track.264 track.mvc -o \\.\nul \\.\pipe\rightyuvpipe


Media SDK impl SOFTWARE (libmfxsw64.dll)
Media SDK version 1.8
Memory type System

Input video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,0,0
Frame rate 23.976

Output format YUV420


The original video has the following information from tsMuxeR:

Track ID: 4114
Stream type: MVC
Stream ID: V_MPEG4/ISO/MVC
Stream info: H.264/MVC Views: 2 Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976 3d-pg-planes: 32
Stream lang:

Track ID: 4113
Stream type: H.264
Stream ID: V_MPEG4/ISO/AVC
Stream info: Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976
Stream lang:

[...]

File #00000 name=[...]\BDMV\STREAM\SSIF\[...].ssif
Duration: 00:00:00.824
Base view: left-eye
start-time: [...]
Marks: 00:00:00.000

File #00001 name=[...]\BDMV\STREAM\SSIF\[...].ssif
Duration: 01:40:01.259
Base view: left-eye
start-time: [...]
Marks: 00:06:04.769 [...]


Any ideas?

thanks!

[videofan3d]

Hi,

Using FRIMDecoder version 1.23 (build: Mar 19 2014), and get the following near the very end of the decoding:

ERROR: undefined behavior (-16), src\pipeline_decode.cpp (1116)

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



More details:

FRIMDecode.exe -i::mvc track.264 track.mvc -o \\.\nul \\.\pipe\rightyuvpipe


Media SDK impl SOFTWARE (libmfxsw64.dll)
Media SDK version 1.8
Memory type System




Error "undefined behavior (-16)" is returned from some core-function in libmfxsw64.dll library.

Interesting and strange.
I have never faced any "undefined" error during decoding process.
(It happens usually during encoding, and especially in HW mode, as reported by few users here, while SW mode is more stable.)

Try to use 32-bit version.
Or maybe try to use older libmfxswNN.dll from previous release, which is older and has API version 1.7

[colinhunt]

videofan3d, I sure hope you haven't stopped working on this fantastic encoder...?

[videofan3d]

videofan3d, I sure hope you haven't stopped working on this fantastic encoder...?

:)

Is there anything specific what needs to be improved? :D

[colinhunt]

:)

Is there anything specific what needs to be improved? :D
Well-ll, since you asked... :D

Version 1.23 keeps crashing when used with BD-Rebuilder 0.47.06. For a moment I thought that simply rebooting after every successful encode solved the problem, but no, FE crashes at random points during the encoding regardless. Most encoding jobs finish OK eventually if I restart the job again and again... but I'm trying to backup Tinker Bell 3D now, and have already restarted it at least 10 times. There's no logic as to when FE crashes; it can happen at 3%, 24%, 76%... it's just totally random.

The encoding rig is not overclocked and it's running cool. I'm doing hardware decode/encode, and I can see CPU load stays below 30% during encoding.


Dammit, there it goes again. This time it got to 90.84%, then FE crashed. "FRIMEncode.exe has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."

I've tried driver versions 3412, 3496 and the 3574 beta. Yesterday I found and installed even newer drivers, v3621, that are originally for Intel NUC but they support a wide range of 2nd, 3rd and 4th generation Intel CPUs.

This random crashing has affected all versions listed above.

[videofan3d]

Well-ll, since you asked... :D

Version 1.23 keeps crashing when used with BD-Rebuilder 0.47.06.
....
I've tried driver versions 3412, 3496 and the 3574 beta. Yesterday I found and installed even newer drivers, v3621, that are originally for Intel NUC but they support a wide range of 2nd, 3rd and 4th generation Intel CPUs.

This random crashing has affected all versions listed above.

Is there any message in the log, stdout/stderr which I could analyze?
If this issue is coming from FRIM wrapper itself then I can fix it - I only need to get identified where it happens.
If it is something in libmfxswNN.dll / libmfxhwNN.dll then likely not - it will be rather in Intel's hands.

Please check also whether combination HW decoding + SW encoding is more stable. (I know it is slower, but in my view stability pays more in this case... )

Remark: I personally use FRIM only for encoding my own 3D videos, not for shrinking Blu-rays :)

[colinhunt]

Is there any message in the log, stdout/stderr which I could analyze?
If this issue is coming from FRIM wrapper itself then I can fix it - I only need to get identified where it happens.
If it is something in libmfxswNN.dll / libmfxhwNN.dll then likely not - it will be rather in Intel's hands.
I'll have to get back to you on those.

In the meanwhile, I have an interesting data point for you. That Tinker Bell 3D I tried to re-encode, the one I gave up on after 12 re-starts? Well, I went back to driver version 3412, rebooted the rig, ran the encode again... and it finished without crashing the first time. Howeverrrrr... the next title I tried to encode crashed almost immediately, and so did the next 4 re-starts. So, it almost looks like a simple reboot is not enough; I need to install drivers and reboot, and following that the next encode job finishes without problems.

Weeeeeird....

Please check also whether combination HW decoding + SW encoding is more stable. (I know it is slower, but in my view stability pays more in this case... )
It's a difference between 35 minutes and 9 hours for me, so I'll do what I can to enable the 35 minute option :)

[videofan3d]

I'll have to get back to you on those.

In the meanwhile, I have an interesting data point for you. That Tinker Bell 3D I tried to re-encode, the one I gave up on after 12 re-starts? Well, I went back to driver version 3412, rebooted the rig, ran the encode again... and it finished without crashing the first time. Howeverrrrr... the next title I tried to encode crashed almost immediately, and so did the next 4 re-starts. So, it almost looks like a simple reboot is not enough; I need to install drivers and reboot, and following that the next encode job finishes without problems.

Weeeeeird....



It looks like some memory leak somewhere in core system, which "appear" accidentally, or even infrequently.... :(
It won't be easy to identify it. And if it is really in core libraries - then I'll have no chance to influence it.

Please tell me, which BD3D titles are impacted the most?
(I don't have this Tinker Bell 3D available in our Blockbuster video-library)
I'll try to get some of them and simulate it....

[colinhunt]

Please tell me, which BD3D titles are impacted the most?
After maybe two dozen encodes and countless restarts in the past week, I'd say the issue is not limited to certain titles, nor do some titles crash FE more than others. It's just... random. Like I mentioned, Tinker Bell crashed FE 12 times before I installed earlier drivers and rebooted, after which it finished encoding on the first attempt - but I'm pretty sure the same thing could have happened with any other 3D title. I had to restart Universal Soldier several times, same with Loser (a German post-conversion) and right now I'm trying to encode Battle Royale (Japanese post-conversion); already had to restart encoding at least 5 times.

I sooooo wish I had more precise and helpful information to give to you :(

//

Hold on. BD-RB does not output error logs for any FRIM crashes... but the next time encoding crashes, I'll shut down BD-RB and will run the same encoding.bat in a command line window. When that crashes, I should have some error information for you.

[colinhunt]

Here you go!

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

Input format YUV420

Output video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control VBR
avg,maximum 24149,45000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 2
Processing started
Frame number: 6225Frame number: 4905
ERROR: undefined behavior (-16), src\pipeline_decode.cpp (1116)


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

What if I replaced that libmfxhw32.dll from a newer set of drivers...?

Hmm... why do I remember a parameter, something like -async, which I used successfully with a much earlier version of FRIMDecode/Encode?

[colinhunt]

I replaced the DLL from the latest set of drivers, and for a while it looked like that solved the problem. But then:

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

Input format YUV420

Output video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control VBR
avg,maximum 24149,45000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 2
Processing started
Frame number: 70885Frame number: 68215
ERROR: undefined behavior (-16), src\pipeline_decode.cpp (1116)


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

[frank]

Did you notice?
With FRIMencode /Intel Media SDK the dependend MVC stream gets the same vbr bitrate as the basic one. So the size of 3D encodings is twice as large as 2D encodings. :scared:.

That issue talked a guy to the Intel dev forum in January. Guess what they answered... Nothing!!

The dependend stream requires only half the bitrate of the basic view. It includes the deviations from the main. So a 3D blu-ray is 1.5 times greater than a 2D one.

The question:
How can we set the bitrate of the two views separately, according to a profile?
The professional encoders (Rovi, Encore) make it in this way.

Without that option FRIMencode /Media SDK makes no sense.
Then the HalfSBS/TAB method is more suitable for 3D encodings at home.

[Sharc]

Did you notice?
With FRIMencode /Intel Media SDK the dependend MVC stream gets the same vbr bitrate as the basic one. So the size of 3D encodings is twice as large as 2D encodings. :scared:.
Where did you see this? In all my encodes the dependent stream was about 80% of the basic one, which is not terribly efficient but at least the saving is about 20%...25%.
The dependend stream requires only half the bitrate of the basic view. It includes the deviations from the main. So a 3D blu-ray is 1.5 times greater than a 2D one.
There is no such rule or law. The ratio depends on the encoder and the video itself.
The question:
How can we set the bitrate of the two views separately, according to a profile?
AFAIK there is no such setting for the free Intel/FRIM encoder.
The professional encoders (Rovi, Encore) make it in this way.
Without that option FRIMencode /Media SDK makes no sense.
Easy; just buy a professional encoder in this case.
Then the HalfSBS/TAB method is more suitable for 3D encodings at home.
The decision remains with you :)

[HWK]

Did you notice?
With FRIMencode /Intel Media SDK the dependend MVC stream gets the same vbr bitrate as the basic one. So the size of 3D encodings is twice as large as 2D encodings. :scared:.

That issue talked a guy to the Intel dev forum in January. Guess what they answered... Nothing!!

The dependend stream requires only half the bitrate of the basic view. It includes the deviations from the main. So a 3D blu-ray is 1.5 times greater than a 2D one.

The question:
How can we set the bitrate of the two views separately, according to a profile?
The professional encoders (Rovi, Encore) make it in this way.

Without that option FRIMencode /Media SDK makes no sense.
Then the HalfSBS/TAB method is more suitable for 3D encodings at home.

Yes, I am aware of it. What really is happening is bitrate is equally divided between views with very little variance. In fact I am convinced reduce size is caused by absence of I frames. Since dependent view still contain P and B frames.

Although dependent view require 50 less bitrate but this is not the case 100% of time, it usually change based on scene complexity and and depth info present. However with that said 90% total size of mvc stream will be 50% of avc stream.

CCE and Rovi will change bitrate scene by scene ranging from 30% to 70% change between avc and mvc stream. Example if you are encoding with 10Mbps encoder may assign anywhere between 3 to 7 Mbps to avc and remaining to mvc or other way around, again it all depends on scene and complexity of source.

[superleo]

Apologize in advance since this question is off topic a bit, but I've been researching the question and I have seen it mentioned in several different places but have not found a definite answer or how to fix it.

I'm working on a 3D Bluray Demo Disc, comprised of scenes from different BDs. My intent is to author the disc in scenarist. When I demuxed the clips and try to import them into scenarist I'm getting an error message stating that the base stream and the dependent stream have different number of frames. This is indeed the case. If I remember someone has discover this and wanted to add some empty frames to make them the same while someone different suggested just to remove some frames. The question is anyone ever found out how to fix the frames so they have the same number on both streams?

[HWK]

Ok, here we go. In order to fix it you need to decode two streams altogether so they not dependent on each other and more important time base and run time is same. Once that is done you need to run through mvc encoder and it will fix it.

Once all is done then you can import into program of your choice.

[frank]

@sharc
Where did you see this?
Look with Mediainfo into professional 3D Blu-rays (corresponding streams), then you can see the video bitrates and max values that the encoder has used. All dependent bitrates on 3D Blu-rays are much lower (I have seen 0.3x - 0.6x). The encoder uses separate processes for main and dependent stream, and the bitrates must be set correctly for both processes. MediaSDK equals the bitrates and that is certainly an error as well as the decoder bug in Pacific Rim. INTEL should fix the SDK.
FRIMencode/MediaSDK usually sets the bitrates (target!) to 12500 for both streams. The 80% difference with your FRIMencodes represents the absence of I-frames.

[colinhunt]

No new development in the past 2 months? Shame, that.

[alexxdls]

Can I use VapourSynth script instead AviSynth one at input?

[videofan3d]

Can I use VapourSynth script instead AviSynth one at input?

Try it and let us know ;)

[alexxdls]

Here results come
d:\TOOLS\MyDCPConverter>Tools\FRIMEncode -avi -sbs 2 -i F:\TEMP\TRAIN-DRAGON-2_T
LR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy -viewoutput -o::mvc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.avc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.mvc
-w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1

ERROR: Cannot open input avi-file F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_
51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

d:\TOOLS\MyDCPConverter>Tools\vspipe TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K
_TCF_20140417_DWA_IOP-3D_BD3D.vpy - | Tools\FRIMEncode -sbs 2 -i - -viewoutput -
o::mvc F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-
3D.avc F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-
3D.mvc -w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1
Script evaluation failed:
File reading exception:
[Errno 2] No such file or directory: 'TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2
K_TCF_20140417_DWA_IOP-3D_BD3D.vpy'
FRIM Encoder version 1.22 (build: Feb 2 2014)
- based on Intel(R) Media SDK

Media SDK impl SOFTWARE (d:\TOOLS\MyDCPConverter\Tools\libmfxsw64.dll)
Media SDK version 1.8
Memory type System

Input format YUV420

Output video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 24.000
Bitrate control VBR
avg,maximum 28000,40000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 1 (quality)

Processing started
Frame number: 0
Processing finished in 0.00 secondsd:\TOOLS\MyDCPConverter>Tools\vspipe.exe F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_
RU-00_51_2K_TCF_20140417_DWA_IOP-3D_IOP-3D_BD3D.vpy - -info
Width: 3840
Height: 1080
Frames: 72
FPS: 24/1
Format Name: YUV420P8
Color Family: YUV
Bits: 8
SubSampling W: 1
SubSampling H: 1

[videofan3d]

Here results come
d:\TOOLS\MyDCPConverter>Tools\FRIMEncode -avi -sbs 2 -i F:\TEMP\TRAIN-DRAGON-2_T
LR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy -viewoutput -o::mvc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.avc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.mvc
-w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1

ERROR: Cannot open input avi-file F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_
51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.



I have no personal experience with VapourSynth, so I cannot comment whether it can even work or not.
From principle: if the VapourSynth substitutes AVI, and can be opened using VFW functions of Windows, then it could work.
(This is the way how Asisynth works.)

Hence:
Is VapourSynth engine 32-bit or 64-bit? Probably corresponding version of FRIM Encoder needs to be used.
Can this VapourSynth script be opened using Windows Media Player? If yes, then FRIM Encoder could (possibly) open it as well.
Maybe some tuning via ffdshow will be needed (32-bit or 64-bit respectively)

[alexxdls]

Hence:
Is VapourSynth engine 32-bit or 64-bit? Probably corresponding version of FRIM Encoder needs to be used.
Can this VapourSynth script be opened using Windows Media Player? FRIM is x64 and VS x86 because of some issues with a plugin.
And yes, the script is openned with WMP freely.
I'll do some checks and report back

[alexxdls]

Hence:
Is VapourSynth engine 32-bit or 64-bit? Probably corresponding version of FRIM Encoder needs to be used.Yeap. That was a solution. x86 encoder version works flawlessly with x86 VapourSynth scriptd:\TOOLS\MyDCPConverter>Tools\FRIMEncode -avi -sbs 2 -i F:\TEMP\TRAIN-DRAGON-2_T
LR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D_BD3D.vpy -viewoutput -o::mvc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.avc
F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_S_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D.mvc
-w 1920 -h 1080 -f 24 -vbr 28000 40000 -u 1
FRIM Encoder version 1.23 (build: Mar 19 2014)
- based on Intel(R) Media SDK

Media SDK impl SOFTWARE (d:\TOOLS\MyDCPConverter\Tools\libmfxsw32.dll)
Media SDK version 1.8
Memory type System

Input format YUV420

Output video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 24.000
Bitrate control VBR
avg,maximum 28000,40000
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 1 (quality)

Processing started
Frame number: 72
Processing finished in 17.04 seconds

[SquallMX]

Does FRIM support the Haswell Advanced Options like Look-Ahead?

It seems to be a great option for improving quality on complex scenes.

[videofan3d]

Does FRIM support the Haswell Advanced Options like Look-Ahead?

It seems to be a great option for improving quality on complex scenes.

Yes.

You can check all options: FRIMEncode -help

However, keep on mind that Look-Ahead is not HRD (Hypothetical Reference Decoder) compliant method - per Intel documentation.

[bebolan]

I wonder my cpu i7 920 is supported by FRIM?

[damorsoft]

Due to an disc cleanup error I deleted my earlier version of the SDK (2013) I had downloaded earlier this year. I have written a routine to compress a DL 3d movie to a bdr25, it was working great. It did not create a proper 3d copy using the SDK 2014. I did manage to find a copy of SDK 2013 R2 (media SDK 1.7) that does seem to be working OK again.
Was this something I could have done wrong or has there been some subtle changes with 2014??

[DMagic1]

No update to support the newer drivers?

[DMagic1]

Driver version 15.36.7.64.3960 seems to have fixed some pixel issues with decoding that some experienced at times with other software.
Could support be added for this version with Frim?

[videofan3d]

Driver version 15.36.7.64.3960 seems to have fixed some pixel issues with decoding that some experienced at times with other software.
Could support be added for this version with Frim?

HW drivers should be transparent for FRIM.

Just install new version.
New libraries (together with newer libmfxhw64.dll) will be installed probably to "c:\Program Files\Intel\Media SDK\" .

Then when calling FRIMDecode/Encode -hw (or default) will use the one which is installed.

[DMagic1]

HW drivers should be transparent for FRIM.

Just install new version.
New libraries (together with newer libmfxhw64.dll) will be installed probably to "c:\Program Files\Intel\Media SDK\" .

Then when calling FRIMDecode/Encode -hw (or default) will use the one which is installed.

I mean frim fails with all the latest driver versions using decode with Rebuilder.

[damorsoft]

HW drivers should be transparent for FRIM.

Just install new version.
New libraries (together with newer libmfxhw64.dll) will be installed probably to "c:\Program Files\Intel\Media SDK\" .

Then when calling FRIMDecode/Encode -hw (or default) will use the one which is installed.

Intel 2014 ran fine with FRIM decode/encode it is just the resulting 3D iso file wasn't. The picture did indeed look like 3d but the TV did not recognize it as 3D. When I went back to the older version on INTEL the 3D was perfect.. Something is not quite right.

Thanks

[DMagic1]

Intel 2014 ran fine with FRIM decode/encode it is just the resulting 3D iso file wasn't. The picture did indeed look like 3d but the TV did not recognize it as 3D. When I went back to the older version on INTEL the 3D was perfect.. Something is not quite right.

Thanks

Sorry what version is "Intel 2014"?

[blatantsubtext]

I'm trying to extract the two 3D views from an MVC elementary stream into two separate yuv files and I can't seem to get FRIMDecode to produce anything. It runs for awhile, then crashes. I used MakeMKV to get the stream off the BD, then mkvextract to pull just the .264 file from the MKV.

If I run FRIMDecode (32-bit), the program runs for about 20-30 mins, then Windows reports a "This program has stopped working" dialogue box, and it closes.

If I run FRIMDecode (64-bit), the program runs for about 20-30 mins and I get this error:
E:\MVC>FRIMDecode -i::mvc Input.h264 -o Output_L.yuv Output_R.yuv

ERROR: undeveloped feature (-3), src\pipeline_decode.cpp (114)


ERROR: undeveloped feature (-3), src\pipeline_decode.cpp (785)


ERROR: Cannot start decoding process.

I don't have an Intel GPU, so this should be a software decode. I have tried running both with and without the -sw flag, and it makes no difference. Any thoughts or guidance would be much appreciated.

*EDIT* One last note, the Output_L.yuv and Output_R.yuv files never get made, so I'm really unsure what FRIM is doing for the 20-30 mins it runs.

[pistacho]

I used MakeMKV to get the stream off the BD, then mkvextract to pull just the .264 file from the MKV.


mvkextract is NOT MVC 3D compatible and do you not need to create intermediate MKV. Just use eac3to or TsMuxeR to extract AVC/MVC streams from BD.

[damorsoft]

Sorry what version is "Intel 2014"?

I am using Intel Media SDK64bit 4.13.6.21, not sure of the 2014 version but it is still available from INTEL.

Just did Maleficent and was a great copy.

[blatantsubtext]

mvkextract is NOT MVC 3D compatible and do you not need to create intermediate MKV. Just use eac3to or TsMuxeR to extract AVC/MVC streams from BD.

Ahh, I would have thought mkvextract would not have cared anything about the stream itself and would have simply dumped its data to a file. TsMuxer did the trick, though. Thanks!

[blatantsubtext]

So I did some tests and it turns out that you CAN use mkvextract to get the MVC stream out of a MakeMKV-created MKV file:

mkvextract -f tracks "input.mkv" 0:output_mvc.264 --fullraw

I'm unsure about needing to use the -f flag, but this definitely produces a single H.264 bitstream file that FRIMDecode can take as input.

While this does add one more step and one more intermediate file, I personally think this is better than the AnyDVD + TsMuxer method, if only that MakeMKV is about US$50 cheaper than AnyDVD HD (regular price €79=~US$98).

[Nico8583]

Hi,
Do you plan to update your FRIM with latest Intel SDK ?
The latest version seems to solve problems with Pacific Rim and Dragon Gate movies (tested with pistacho software).
Thanks !

[videofan3d]

Hi,
Do you plan to update your FRIM with latest Intel SDK ?
The latest version seems to solve problems with Pacific Rim and Dragon Gate movies (tested with pistacho software).
Thanks !


Hi,

so far I didn't have a time to explore the latest Intel Media SDK. But I plan to do it in the future and possibly bring additional bitrate control methods (e.g. LA HRD).

Anyway, I presume that Intel keeps backward compatibility, so you can try to replace libmfxsw32.dll with the latest one, and everything should/could work (with some fixed bugs, of course :) ).
Please try and report back to other users...

[frank]

My tests showed that libmfxsw32.dll later than 4/2014 doesn't work properly on Intel's 2nd gen cpu, Sandy Bridge, gfx3000!
Latest graphics drivers for this cpu/chipset are from 4/2014.:mad:

And that was the time where FRIM was developed.

[r0lZ]

Yes, unfortunately, it appears that the version you have used works fine in most cases, but fails with Dragon Gate and Pacific Rim. Changing only the Intel DLL results (on my machine without hardware acceleration) in completely bad conversions. All frames of all movies are pixellized and never decoded properly. Obviously, something has changed in the latest Intel lib and is not backward compatible. According to tests I did with frank, it seems that the problem is hardware dependent, even when you use the software decoder!

Donald has a new version of his DGMVCSource decoder, that I will test right now. Perhaps he has found the solution. Anyway, frank, Nico or me will let you know if a good solution is found...

[Sharc]

I tested Donalds new DGMVCsoure (SW only) with Pacific Rim. The glitch is gone!
(I can't test the HW option with my PC).

[r0lZ]

Yes, it's confirmed. The latest versions of the Intel SDK and libs solve the problem. However, the latest lib is not backward compatible.

As Donald said, FRIM will need to be rebuilt with INDE 2015 Update 1. Then, FRIMSource will work fine with the libmfxsw32.dll v6.14.11.28 (28/11/2014). It's the intel lib distributed with DGMVCSource, and currently incompatible with FRIMSource. Therefore, I need a recompiled version of your DLL, to include it in BD3D2MK3D. As far as I know, there is no need to modify your code. Can you do that?

Thanks in advance! :thanks:

[videofan3d]

Yes, it's confirmed. The latest versions of the Intel SDK and libs solve the problem. However, the latest lib is not backward compatible.

As Donald said, FRIM will need to be rebuilt with INDE 2015 Update 1. Then, FRIMSource will work fine with the libmfxsw32.dll v6.14.11.28 (28/11/2014). It's the intel lib distributed with DGMVCSource, and currently incompatible with FRIMSource. Therefore, I need a recompiled version of your DLL, to include it in BD3D2MK3D. As far as I know, there is no need to modify your code. Can you do that?

Thanks in advance! :thanks:

Unfortunately, it is not only about recompilation with INDE 2015 Update 1.
There are few incompatibilities which I need to investigate and treat in the source code (and overcome some newly introduced bugs in libmfxhw32.dll :-( )

I will look at this deeper next week and then provide new version for thorough testing.

[r0lZ]

I'm interested to know what are those newly introduced bugs in libmfxhw32.dll ?

[Pat357]

I'm trying to let FRIMencode to read from STDIN, but I get nothing but errors or 0 bytes files as output.264
Reading fom .AVS & AVI seems to work just fine for me.

To rule out a lot of other things, this creates a nice output :
FRIMEncode -avi -i 2k_ffms.avs -o::h264 2k_ffms.h264 -icq 22 -u 1

But this does not :
avs2yuv -raw 2K_ffms.avs - | FRIMEncode -i - -o::h264 2k_ffms_stdin.h264 -icq 22 -u 1 -w 1920 -h 1080

It creates a an emty output file (0 bytes)

and this s what I get :

>> avs2yuv -raw 2K_ffms.avs - | FRIMEncode -i - -o::h264 2k_ffms_stdin.h264 -icq 22 -u 1 -w 1920 -h 1080
FRIM Encoder version 1.23 (build: Mar 19 2014)
- 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

Input format YUV420

Output video AVC
Source picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Destination picture:
Resolution 1920x1088
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control ICQ
quality 22
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 4
Target usage 1 (quality)

Processing started
2K_ffms.avs: 1920x1080, 60060/1001 fps, 500 frames
Frame number: 0
Processing finished in 0.08 seconds


I've tried to let avs2yuv output a raw stream (-raw switch) but that also did not work.

The idea behind reading from STDIN is to be also able to feed VapourSynth .VPY scripts to the encoder using VSPIPE.

To be honest, I don't know how to use named pipes ; the most output from common tools is like AVS2YUV and VSPIPE is STDOUT with an option to deliver raw or yuv4mpeg.
The latter (yuv4mpeg) is a great option because it sends also all video properties like resolution and framerate.

[jdobbs]

Not sure if this is your problem -- but I think you're supposed to use the "-o" parameter in the command line:

avs2yuv -raw 2K_ffms.avs -o - | FRIMEncode -i - -o::h264 2k_ffms_stdin.h264 -icq 22 -u 1 -w 1920 -h 1080

[Pat357]

Not sure if this is your problem -- but I think you're supposed to use the "-o" parameter in the command line:

avs2yuv -raw 2K_ffms.avs -o - | FRIMEncode -i - -o::h264 2k_ffms_stdin.h264 -icq 22 -u 1 -w 1920 -h 1080

Thanks for your input !
Unfortunatelly this didn't resolve the problem.
Here is what I get now :
(after also adding the -f 60 parameter & put AssumeFPS(60) in avs-script.

>avs2yuv -raw 2K_ffms.avs -o - | FRIMEncode -i - -o::h264 "2k_ffms_stdin_test.h264" -icq 22 -u 1 -w 1920 -h 1080 -f 60
FRIM Encoder version 1.23 (build: Mar 19 2014)
- 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

Input format YUV420

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

Processing started
2K_ffms.avs: 1920x1080, 60 fps, 1000 frames
Frame number: 0
Processing finished in 0.07 seconds
error: wrote only 3087595 of 3110400 bytes
>

[videofan3d]

Thanks for your input !
Unfortunatelly this didn't resolve the problem.
Here is what I get now :
(after also adding the -f 60 parameter & put AssumeFPS(60) in avs-script.


Please check the input side (avs2yuv or avs script itself).

I just tested piped commands:

set SRC=f:\BD\BDMV\STREAM\00011.m2ts
set DST=c:\_testing\DST.h264

FRIMDecode.exe -ts -i::vc1 %SRC% -o - | FRIMEncode.exe -i - -o::h264 %DST% -w 1920 -h 1080 -f 23.976 -vbr 24000 30000 -u 1

And all worked pretty well. :-)

[videofan3d]

I'm interested to know what are those newly introduced bugs in libmfxhw32.dll ?

E.g.:

FRIMEncode uses (till version 1.23) hardcoded setting for H.264 options AdaptiveI=on and AdaptiveB=on. These settings are supposed to allow SDK encoder to change B&P -> I and B -> P frames according to actual situation in the input scene being encoded, i.e. not exactly to follow predefined requested GOP structure. (for details please see Intel Media SDK documentation)

However, I realized, that libmfxhw32.dll from Intel Driver version 15.36.14.64.4080 fails and does not accept AdaptiveI=on nor AdaptiveB=on.
Fortunately -sw (i.e. libmfxsw32.dll) works as expected.
(It took me quite time to trace it and find what is happening there; it looked like mystery at the first time).

Hence I need to tweak these setting in FRIMEncode.

(... and I'm sure there few more new bugs ;-) )

[Pat357]

Please check the input side (avs2yuv or avs script itself).

I just tested piped commands:

set SRC=f:\BD\BDMV\STREAM\00011.m2ts
set DST=c:\_testing\DST.h264

FRIMDecode.exe -ts -i::vc1 %SRC% -o - | FRIMEncode.exe -i - -o::h264 %DST% -w 1920 -h 1080 -f 23.976 -vbr 24000 30000 -u 1

And all worked pretty well. :-)
That's odd...but can you tell me the format of the stream between the decoder and the encoder ?
It's obvoiusly RAW uncompressed video, but what format/color-space ? YV12, NV12 or something else ?
My .AVS script is OK since it works when using :

FRIMEncode -avi -i 2k_ffms.avs -o::h264 "2k_ffms.h264 -u 1 -f 60

This produces a nice encoded .264 that also plays fine in any player.
This should rule out all possible HW-issues/setup-issues and most environemt parameters as being a problem.

However the encode fails if I try :
avs2yuv -raw 2k_ffms.avs -o - | FRIMEncode -i - -o::h264 "2k_ffms_stdin.h264" -u 1 -f 60 -w 1920 -h 1080
The problem seems to be one of the following :
-There is a bug in my cmd-line or syntax.
-AVS2YUV has a bug or is not compatible with your encoder because the RAW uncompressed format is not what the encoder expects/accepts.
I've also tried VSPIPE (part of VapourSynth and I got exactly the same error.)
- I really don't know.

Can you please try it the same way I did (using avs2yuv/Avisynth) on your system just to rule out any problem wih this approach ?

My AVS script is :

LoadPlugin("c:\plugs\FFMS2.DLL")
Import("c:\plugs\FFMS2.AVSI")
FFVideoSource("test_1080p.mkv", colorspace="YV12")
AssumeFPS(60)
It plays fine is any player like MPC-HC, Mplayer, FFplay,...

What could be the reason, you think, why the first method for encoding *does* work, while the other (using AVS2YUV) does not ?
I'm using the same Avisynth script.

For the first method, FFDShow is some needed, because whitout it it does not work.
The second (invoving AVS2YUV) , FFDShow is not involved, so maybe this could be the reason ?
Do you maybe use FFDShow for the color-space convertion from YUV420 to NV12 needed for the Intel HW encoder ?


PS.

FRIMDecode.exe -ts -i::vc1 %SRC% -o - | FRIMEncode.exe -i - -o::h264 %DST% -w 1920 -h 1080 -f 23.976 -vbr 24000 30000 -u 1
I just tested your decoder-encoder example on my system and it works indeed perfect.
The encoder accepts what the decoder produces, that's for sure.
This brings me back to wheter the encoder accepts "normal" (by AVS2YUV) produced RAW YV12 /I420 video.
I suspect the problem lies there somewhere.

[videofan3d]

....

For the first method, FFDShow is some needed, because whitout it it does not work.
The second (invoving AVS2YUV) , FFDShow is not involved, so maybe this could be the reason ?
Do you maybe use FFDShow for the color-space convertion from YUV420 to NV12 needed for the Intel HW encoder ?

I don't know nor have AVS2YUV.
But it may be the right point: while FRIMEncode -avi -i input.avs involves ffdshow, using stdin doesn't !

Input format via stdout-stdin has to be YV12, so make sure that AVS2YUV sends data to stdout in this format.
Optionally it could be also NV12, then try FRIMEncode -nv12 but I didn't test it (having no input source in NV12)

[r0lZ]

E.g.:

FRIMEncode uses (till version 1.23) hardcoded setting for H.264 options AdaptiveI=on and AdaptiveB=on. These settings are supposed to allow SDK encoder to change B&P -> I and B -> P frames according to actual situation in the input scene being encoded, i.e. not exactly to follow predefined requested GOP structure. (for details please see Intel Media SDK documentation)

However, I realized, that libmfxhw32.dll from Intel Driver version 15.36.14.64.4080 fails and does not accept AdaptiveI=on nor AdaptiveB=on.
Fortunately -sw (i.e. libmfxsw32.dll) works as expected.
(It took me quite time to trace it and find what is happening there; it looked like mystery at the first time).

Hence I need to tweak these setting in FRIMEncode.

(... and I'm sure there few more new bugs ;-) )
Wow, it's Chinese for me. What are the visible symptoms of these bugs? Are they responsible of AVC or MVC decoding glitches?

If I understand correctly, those bugs are present only in the hardware drivers, and the software decoder should be safe. Is it correct?

Sorry to ask you that, but I would like to know if I can trust the latest version of the decoder, in sw, hw and "auto" modes. If hw is not safe, I can at least set sw as the default setting for BD3D2MK3D. Unfortunately, I can't test the hw mode myself, because I have an old processor w/o graphics.

Anyway, thanks for trying to adapt your decoder to the newest version. Unfortunately, it seems that Intel is unable to release a bug free version. When they fix a bug, they introduce another one!

[videofan3d]

Wow, it's Chinese for me. What are the visible symptoms of these bugs? Are they responsible of AVC or MVC decoding glitches?

If I understand correctly, those bugs are present only in the hardware drivers, and the software decoder should be safe. Is it correct?

Sorry to ask you that, but I would like to know if I can trust the latest version of the decoder, in sw, hw and "auto" modes. If hw is not safe, I can at least set sw as the default setting for BD3D2MK3D. Unfortunately, I can't test the hw mode myself, because I have an old processor w/o graphics.

Anyway, thanks for trying to adapt your decoder to the newest version. Unfortunately, it seems that Intel is unable to release a bug free version. When they fix a bug, they introduce another one!

The symptom is, that FRIMEncode/FRIMTranscode version 1.23 (and lower) with Intel driver 15.36.14.64.4080 doesn't work at all. It fails
ERROR: Cannot initiate Intel Media Encoder - invalid parameters.

Full stop.:-D

-sw is fortunately not impacted.

I will overcome it in version 1.24 (to be released soon - I hope)

Re: "bug free version"
There is no such thing like bug free SW! It is only a dream :-D
Each and every SW has bugs. More complex SW = more new bugs.
It is only about approach of the vendor to be able to fix them.

Golden rule of programming: "If it already works, don't touch it anymore!!!" :-D

[r0lZ]

OK, thanks!

And of course I agree that a complex program cannot be fully bug free. But Intel is very irritating, because they should fix the bugs that have been reported, without trying to add new features immediately. Then, when everything works as expected, new features can be added, and the users happy with the old version can stick with it. At least, a version is usable. But that seems impossible to obtain from the guys at Intel.

[videofan3d]

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 :) ... )

[r0lZ]

Thanks! I'll test FRIMSource right now...

[Sharc]

Thanks videofan.
I will do some tests as well.

[r0lZ]

I did 2 tests with FRIMSource, and everything is OK so far. But I don't have a CPU with the hardware acceleration, so my tests are limited. Anyway, for me, it's OK, and I'll distribute this version of FRIMSource with the next release of BD3D2MK3D (to be released soon).

Sorry, but I haven't tested FRIMEncode and FRIMDecode.

[Sharc]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Any chance of getting a 64-bit AviSynth plugin?

[videofan3d]

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]

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]

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]

The 64-bit AviSynth plugin works.

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

[videofan3d]

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]

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]

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]

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]

videofan3d, thank you for FRIMSource64 (and your work in general). I believe this is the first x64 MVC source filter.

[nel-son]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

thanks anyway, I may have a plan..

[tartak]

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]

Smart! Indeed, SYSWOW64 is the directory for the 32-bit system DLLs, despite its name!
Thanks for the tip.

[videofan3d]

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]

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]

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]

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

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]

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]

@jmsmarcelo

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

[jmsmarcelo]

Thanks @sef :D

[videofan3d]

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]

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]

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]

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

[videofan3d]

Is there any way to deal with seamless branching 3D discs? Mike

Try this several times mentioned tsMuxer (probably the only freely available muxer supporting also MVC elementary stream)

[BigPines]

Can FRIM Export be used with Adobe Media Encoder. I'd like to queue a couple movies up and just let them export one after another. However, when I try to do this, I get a message box with a progress bar that says Export Media - Preparing data for export and it seems like it is hung. Premiere is using 80+ % of the processing power so maybe I just need to be patient?

EDIT: Yep, I decided to try a small 1 min clip and it sent it to Media Encoder so I guess I just need to be patient for a full film.

Now I just have to figure out the encoder options...I'm starting with:

-vbr 28000 40000 -u 1 -level 4.1

[BigPines]

I was able to successfully export a 5 min clip using these Premiere tools and it looked great! I do have some questions I would like answers to:

The encoder didn't seem to follow my bitrate or level flags. I flagged the level as 4.1 and it came out as 4, I flagged the bitrate as 28 and the average bitrate came out as 20.9 and I flagged the max bitrate as 40 and it came out as 35.5. Any ideas on this?

5 mins of video took 2 hours to encode. Ouch! I read it was slow but that was much slower than I had expected. Still for the level of quality I got out of it, I figure it is worth it. Using a virtual machine likely had an impact here. I would be curious to hear what others' encode times are for comparison. I may have to set up a dedicated PC for encoding.

After success with my 5 min clip I decided to try a full length film with a length of 1 hour and 45 mins. It never seemed to start encoding. After sitting there for several hours, it crashed the VM. Again, I may have to go to a dedicated hardware encoder or split the export out into smaller chunks and then combine them with tsMuxeR. Has anyone had success doing anything like that?

When attempting to encode the full length film, I received a message that 2.3 TB of storage was necessary to perform the encode. I assume the encoder works by writing temp files and processing them. Is this storage necessary on the scratch disk or in the same directory the project is in?

What does FRIM stand for? :)

One last thing...thank you very much videofan3d! These are some of the coolest tools I have ever seen on doom9. I am in your debt.

[videofan3d]

I was able to successfully export a 5 min clip using these Premiere tools and it looked great! I do have some questions I would like answers to:
...


Re bitrate:
I also noticed that Intel Media core sometimes lower the bitrate, probably it realizes that source video has less details (aka lower real bitrate) and thus it is not needed to encode in the requested 28 Mbit/s.
(Flagging the levels has only informative meaning to comply with MPEG norm, but has no impact on actual encoding)

Re Encoding time:
I myself encoded maximum 20 minutes of my own movies, and it also took several hours.

Specifically, on my i7 Haswell I obtained e.g. 10 minutes of 3D MVC output in ~3 hours
It is long, but let's look realistically, what is happening:
1. decoding 3D-MVC input into planar YUV 420
2. conversion of each frame (3D thus 2x) from planar YUV 420 to pixel-based YUV or RGB (using internal Premiere routines to assure compatibility)
3. processing internally in Premiere, including e.g. color correction and sharpening, which I always use in my case
4. conversion of each final frame (3D thus 2x) from pixel-based YUV or RGB to planar YUV 420 (using internal Premiere routines to assure compatibility)
5. encoding planar YUV to output 3D MVC

Steps 2-4 are internal in Premiere and apparently represent big overhead.
Some independent measurement shows that step 1 itself is faster than real-time, and step 5 itself is almost real-time on i7.
So most of processing are in complexity of API and internal Premiere processing.

Yes, it is long, but taking the situation that we are working on final render, we can let it run over the night.

Still remember, Intel Media is the only freely available 3D MVC encoding engine, and produces really good quality (even when projected on 80' screen - this surprises me the most)

re Message "2.3 TB of storage was necessary "
This is misleading info from Premiere (calculated from uncompressed size of processed video), nevertheless, system doesn't need any extra temporary disk-space, all MVC-decoding and MVC-encoding is performed on-the-fly in memory. This was the reason to develop FRIM Import and FRIM Export: to avoid huge uncompressed files.

[BigPines]

Thanks for your responses. Yes, there definitely is a lot going on. Given the fact that no other software that I am aware of can decode MVC, modify it in complex ways per the edits on the fly and then re-encode it beautifully all without having multiple generational loss or involving huge lossless files, I think it is worth it. It sounds like my VM running on my quad-core i7 isn't doing too bad. BTW, I started the full-length film encode again yesterday morning. This time it didn't crash. It has been running for 25 hours and the progress bar says it is at 42%.

Since all this is being done in memory, would it speed things up to give the VM more memory?

Of interest, I went to Intel's site to download the SDK. Since I'm a software developer, I figured you never know when I may need something like this. I was surprised to find an OS X / Android version in the download area! I snagged it but it needs 10.9 to run and I am on 10.8 so I can't look at what it has in it yet. I hope the MVC functionality is in there for OS X but the installer for OS X was much smaller than the one for Windows so I'm not sure. Who knows, maybe an OS X native solution is possible after all.

I will report back on my experience with a full-length feature of an hour and 45 minutes once the encoding is finished. I will be doing several of these in the coming weeks so I am going to give this thing a good work-out.

[geheim]

Hi,
I am trying to mux some MVC-coded Video files with Scenarist BD. Encoding was done with FRIMEncode. In Mui Generator I disabled the Checkbox and now I can add the files succesfully to Scenarist. But every time I try to Mux I get this error:

[MUX] Can not write MUX file(s) : Error creating OMF files. Please retry.

This only happens after adding the MVC files from FRIMEncoder.

Any idea what is wrong with the files??

Thanks!!

[BigPines]

I'm not sure what the root issue is but unless you need complex menus or something, I suggest you use tsMuxeR to make your BD ISOs. I used to use Scenarist so I know it is complicated and finicky about what files it will accept. tsMuxeR has taken all that hassle out of my life and saved me tons of time. You should look into it if you just need a simple BD image. Someone else may have more info on your actual problem.

[BigPines]

Happy to report that nearly 64 hours after I started the encode, it finally finished. Wow, that took a long time. The film looks amazing though so I am happy. The export didn't follow my bitrate flags again but I am going to try another film soon and see if that issue seems to be source dependent.

[geheim]

I'm not sure what the root issue is but unless you need complex menus or something, I suggest you use tsMuxeR to make your BD ISOs. I used to use Scenarist so I know it is complicated and finicky about what files it will accept. tsMuxeR has taken all that hassle out of my life and saved me tons of time. You should look into it if you just need a simple BD image. Someone else may have more info on your actual problem.

Thanks for your answer!
It does in deed work when using tsmuxer. The problem is that I do need some menus. For example I like having the option choose between 2D and 3D output via menu. The menus I created with Scenarist are working and muxing flawlessly. The error only shows after adding the MVC files.
Perhaps anyone else has any clue why this error happens??

[videofan3d]

Happy to report that nearly 64 hours after I started the encode, it finally finished. Wow, that took a long time. The film looks amazing though so I am happy. ...


May I ask what you are doing with original BD-3D that you need to process them via Premiere? :)
If you are doing some visual edits, then clear - Adobe Premiere is professional-grade video editing SW.
But if you want it only recode (from whatever reason), then you can use much faster method: Avisynth + FRIM Source for decoding and FRIM Encode for encoding.
Output quality will be identical (FRIM Export and FRIM Encode use identical encoding engine) but output result will be achieved much faster avoiding all Premiere overheads.

Btw, you are probably the first user here who used FRIM Import + FRIM Export :)
Definitely the first one who did such extensive work and reported back - thanks.

[BigPines]

I am doing a few different kinds of things. Mainly, I edit content from films for my kids. My family gets to enjoy quality entertainment free from all the garbage Hollywood insists is crucial for brainwashing...er...realism. I know James Cameron would freak out to hear this but there isn't anything he can do about it since I am not doing it commercially. He can try to sue me like he has others if he wants but I don't think it will stick. ;) Sometimes, I do fan edits of films too. For instance, even though Peter Jackson made Legolas do something even more ridiculous with each Hobbit film, I don't have to endure it over and over again. Indiana Jones doesn't have to get shot three miles in a refrigerator propelled by a nuclear blast. (facepalm) The Star Wars prequels don't have to be dragged down by some of Anakin's over-the-top tantrums and embarrassing dialog. I also make fairly elaborate home movies. I plan to make some 3D home movies in the future. One of the things I insist on is quality. My sources are always ripped losslessly. My audio is always re-encoded lossless with DTS Master Audio. My video is always encoded at high bitrate and multi-generational loss is always avoided where possible. Now with your tools, my 3D edits will be as clean as my 2D edits!

A few of things I still need to work out in my quest for the ultimate quality and convenience:

1) VC-1 encoded source material is difficult to work with because Premiere doesn't like it. For now, I use x264 to encode it losslessly and then do my editing on that. I would like to figure out how to import VC-1 into Premiere without the step of large re-encodes that are time consuming. Perhaps Avisynth Importer can help here?
2) I recently purchased a media player that can accept H.265. I would like to start encoding all my finished videos (except 3D of course) in H.265 to retain quality and save hard drive space. I have a 44 TB RAID on my media server and I am running out of room! Perhaps DebugMode Frameserver and x265 can help here?
3) There are a couple of 3D BDs that don't necessarily need any editing which have their left and right eyes flipped for some reason. I can switch these each time I watch them on my media player but I'd rather not have to worry about doing that. Maybe Avisynth + FRIM Source for decoding and FRIM Encode for encoding would work here? Or maybe you have another idea?

Thank you again for the wonderful tools that make my life easier!

Mike

[videofan3d]

I am doing a few different kinds of things. ...

Cool :)

ad 1) VC-1
For VC-1 you can use similar .frim trick like for 3DMVC:

step 1: converting to proxy h264, e.g. using command
FRIMDecode -i::vc1 VC1.m2ts -ts -o - | FRIMEncode -i - -o::h264 VC1proxy.h264 -f 23.976 -w 1920 -h 1080 -vbr 12000 18000
and multipex it (tsMuxer) into VC1proxy.m2ts with WAVE converted audio

step 2: do all edits in Premiere with VC1proxy.m2ts

step 3: use VC1proxy.frim side-car file like you do for 3D


[Video]
codec=VC1
container=TS
filename=VC1.m2ts

[Audio]
; empty or WAV-audio

and use similar replacement-process like for 3D (but now only for 2D)

step 4: do final render in Premiere. Benefit = you will perform only one(!) recompression from VC-1 to e.g. h.264

ad 2) H.265:
DebugMode Frameserver and x265 will likely work (I have no exprerience with H.265 yet, for HD content x264 is already well proven, while H.265 is still not mature and not widely supported - yet... it will come)
DebugMode Frameserver will create virtual .avi, which you can (very likely) read by x265 directly, or indirectly by wrapping into Avisynth script.

ad 3) left and right eyes flipped
You can process it via recompression FRIMDecode + FRIMEncode with -swaplr option, or maybe it will be enough to remux it with txMuxer and check its option "Use base video for right eye" located on Blu-ray tab. Just need to test...

[r0lZ]

The problem of the left and right views inverted may be caused by a bug in your media player. Normally, there is a flag in the MPLS that tells the player if the views are in the standard order (left view first) or inverted. As far as I know (almost) all commercial 3DBDs that have the right view first have that flag set correctly. Therefore, if you see the images inverted on your TV, that means that the player doesn't obey the flag. Or that the information is lost somewhere between the player and the TV/projector/monitor. Anyway, try what videofan3d suggests and remux the original stream with the base view for right eye flag (without re-encoding the video). If the problem persists, that will confirm that your software or hardware is the culprit.

[BigPines]

Thanks guys. Using tsMuxeR to set the "Use base video stream for right eye" flag didn't fix the problem so the problem is the media player. That makes sense since all these discs play fine in my BD player. For now, I will ask the manufacturer of the media player to look into a fix. If they can't or won't fix it, I think I'll re-encode these. I have only run into three of these so far:

The Chronicles of Narnia: The Voyage of the Dawn Treader (2010)
The Hobbit: An Unexpected Journey (2012)
The Hobbit: The Desolation of Smaug (2013)

I am at a loss as to understand why these discs were even encoded this way.

[r0lZ]

I am at a loss as to understand why these discs were even encoded this way.
It is the responsibility of the director of the movie to select what he think is the best view for the 2D version. It is totally legit to select the right view instead of the left one, although IMO, most of the time, the two views are equivalent and can be considered as the main view without problem.

There are other examples of "right view first" 3DBDs. For example, all movies released by the Belgian animation studio nWave (Samy 1 and 2, The House of Magic...).

[BigPines]

Interesting. I fail to see how the difference between the two views would be material but these are artists we are talking about. It would just be nice to have a standard we could count on and it would also reduce complexity.

[r0lZ]

IMO, there is a de-facto standard. Most of the time, the left view is the base view. Also, currently, when a BD3D is converted to 3D Side-by-Side or Top&Bottom, the left view is (almost) always the first view (left or top). At least, it's what BD3D2MK3D does automatically, regardless of the base view of the original BD.

In the past, I have worked on 3D animation. Usually, the director places a single virtual camera and computes the whole movie in 2D. When he is happy with the result, the second virtual camera is created. To respect the de-facto standard, it should be placed to the right of the original camera, but it's not always possible. For example, it can be in a wall or behind an object during some shots. Therefore, it might be necessary to move the original camera a bit (and therefore changing slightly the original 2D version), or to place the second camera to the left. If the second solution is possible without having to move the original camera, I understand perfectly that it is chosen. I don't know exactly how live movies are shot in 3D, but I know that the double cameras are heavy and cumbersome. In some shots, it might be difficult to place that cameras such as both views give a perfect result, and the right view may be much better.

However, I agree that some directors (notably Ben Stassen at nWave) prefer the right view without a good reason. But again, they are free to decide what view is the base view.

Anyway, the industry has no interest in simplifying things for us. The BD players can perfectly play the 3D movies, regardless of the views order, and it's the only thing that they want. And the standard exists. It is based on the "right-view-first" flag. It's a pity that some players (or converters to SBS or T&B) do not respect it, but you can't blame the standard.

[BigPines]

Thanks and understood.

No, they have no interest in simplifying things for us. If anything, inverting the eyes could be seen as yet another layer of copy protection which is beneficial for them. I guess what I meant to say is I don't like the decision they made on the standard. I am an amateur photographer so I understand framing a little bit. The problem is, once you enter the realm of 3D, your sacred framing for one particular eye or the other goes out the window. The other thing is, the two views are so similar that most of the time it is simply immaterial which eye you watch in 2D because it is the same experience. I can see for consistency, you'd want to pick one eye or the other for setting up shots but that is it. I'll bet you could take 100 people who have only seen the left eye of a particular film and show them the right eye instead and nobody would even notice. People's displays introduce larger changes than watching one eye over the other. Most of the time when you look at the two frames right next to each other, it can be difficult to pick out the differences. I believe it is an unnecessary complication but that is just my humble opinion.

Anyway, thanks for your help. You taught me something about the way this is handled in BD players with the flag. The media player is at fault. I will avoid re-encoding if I can get the manufacturer to fix it. If not, I may just re-encode them. No harm done as the Hobbit films need fan edits anyway. ;)

[jmsmarcelo]

Hello,
Is possible add Chapter point in video on encoding?

[BigPines]

I am getting unexpected results with FRIM Encoder. I am trying to create a 3D test pattern to verify full resolution through the display chain. I created my test patterns in Premiere and exported them to two identical lossless yuv files. The yuv files play fine. I then used FRIM Encoder via the command line to encode the 3D video using the following: FRIMEncode -i video_L.yuv video_R.yuv -o::mvc 3D_Patterns.h264 -w 1920 -h 1080 -f 23.976 -vbr 28000 40000 -u 1

FRIM Encoder then says the output video is AVC which is a little strange but it produces an MVC H.264 file. The file however is distorted and unusable. I know these test patterns are probably torture for an encoder but that is the whole point of them. They ought to work, right?

The same YUV file encoded perfectly in 2D using x264 via Handbrake.

Exporting from Sony Vegas to MVC produced the same distortions as FRIM Encoder. What is going on here?

Original horizontal test pattern: https://drive.google.com/file/d/0B3-obtCH8dE8YTUwandCcFV2aGs/view?usp=sharing

3D encoded horizontal test pattern: https://drive.google.com/file/d/0B3-obtCH8dE8VnVfQlJvNmdmWG8/view?usp=sharing

UPDATE: It appears to be a problem with YUV. I re-exported the patterns from Premiere in Quicktime Animation Lossless and it re-encoded with Sony Vegas just fine. Does this make sense to anyone?

[BigPines]

jmsmarcelo, chapters are not part of the video stream. You need to add chapters into the container when you mux your audio and video together. tsmuxer can do this.

[videofan3d]

UPDATE: It appears to be a problem with YUV. I re-exported the patterns from Premiere in Quicktime Animation Lossless and it re-encoded with Sony Vegas just fine. Does this make sense to anyone?

Please check your YUV streams.
I don't know how did you convert .png into yuv, maybe you have there some kind of header - which should not be there for FRIM.

YUV stream must have size as multiple of 3110400 (exactly), i.e. 1920*1080 + 2 * 960*540 = pure sequence of planes Y and U and V.

[BigPines]

My YUV streams were exported from Premiere. The Premiere project had 1920x1080 PNGs in a 1920x1080 23.976fps project and the exported video was 1920x1080 23.976fps. I exported in Quicktime - Uncompressed YUV 8 bit 4:2:2. I would upload one of the YUVs but they are ~6GB. :(

Mediainfo:

Video
ID : 1
Format : YUV
Codec ID : 2vuy
Duration : 1mn 0s
Bit rate mode : Constant
Bit rate : 795 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 16.000
Stream size : 5.56 GiB (100%)
Language : English
Encoded date : UTC 2015-09-17 20:34:30
Tagged date : UTC 2015-09-17 20:34:35

Does this sound like it should have worked?

[videofan3d]

Uncompressed YUV 8 bit 4:2:2

Does this sound like it should have worked?

This is the issue: you have to have YUV 8 bit 4:2:0 (!)

FRIM (Intel Media) works only with chroma-subsampling 4:2:0 which is native for Bluray.

[jmsmarcelo]

jmsmarcelo, chapters are not part of the video stream. You need to add chapters into the container when you mux your audio and video together. tsmuxer can do this.

yes it is possible to add, for GOPs .. for not to give difference when put chapter.
in CineVision, HCEncoder, and etc. It has that option.

[videofan3d]

yes it is possible to add, for GOPs .. for not to give difference when put chapter.
in CineVision, HCEncoder, and etc. It has that option.

Yes, it is possible to force I-frame in FRIM Encoder:

-gopfile filename

where "filename" is text file describing requested I-frame structure e.g.:
9 I
40 I
55 I
etc.

Please note that some older versions of Intel Media libraries libmfxswNN.dll and libmfxhwNN.dll had a bug and didn't respect the forced I-frames.

[BigPines]

This is the issue: you have to have YUV 8 bit 4:2:0 (!)

FRIM (Intel Media) works only with chroma-subsampling 4:2:0 which is native for Bluray.

Thank you! I'll see if I can export the correct file from Premiere.

[videofan3d]

Thank you! I'll see if I can export the correct file from Premiere.

Keep on mind it must be 4:2:0 planar, i.e. Y-plane followed by U-plane and V-plane (both U a V are deduced by 2 in both x- and y-dimensions, therefore :2:0)

And no frame-header, just pure YUV-data-stream.

[jmsmarcelo]

Yes, it is possible to force I-frame in FRIM Encoder:

-gopfile filename

where "filename" is text file describing requested I-frame structure e.g.:
9 I
40 I
55 I
etc.

Please note that some older versions of Intel Media libraries libmfxswNN.dll and libmfxhwNN.dll had a bug and didn't respect the forced I-frames.


thanks!!:thanks:

[tartak]

videofan3d, are you going to update to Intel Media SDK 2015 Update 2.1? There are quite a few quality and performance improvements (plus official Windows 10 support) mentioned in Release Notes, but I am not sure how big the benefits really are. Is it just a matter of recompiling for you?

[videofan3d]

videofan3d, are you going to update to Intel Media SDK 2015 Update 2.1? There are quite a few quality and performance improvements (plus official Windows 10 support) mentioned in Release Notes, but I am not sure how big the benefits really are. Is it just a matter of recompiling for you?

Yes, I will check this in upcoming weeks whether it requires changes in code or not. Please have some patience with me :)
In the meantime, you can try to use core Intel libraries libmfxswNN.dll / libmfxhwNN.dll from new version - they should (or at least could :) ) be backward compatible.

[tartak]

Yes, I will check this in upcoming weeks whether it requires changes in code or not. Please have some patience with me :)
In the meantime, you can try to use core Intel libraries libmfxswNN.dll / libmfxhwNN.dll from new version - they should (or at least could :) ) be backward compatible.
Thanks!
I can confirm that dll's from Media SDK 2.1 work just fine with FRIMSource.

I think this AviSynth plugin makes your toolset the most flexible of the available options for 3D encoding. I would suggest a short wishlist to make it a good deal more convenient - if you find some time.
1) Make FRIMSource work with m2ts transport streams - then there would be no need to demux them first, we could work directly with the ripped blu-ray/image
2) Indexation system like in Donald Graft's plugins. Right now, even to find out the total number of frames, you need to fire DGIndexNV or something similar.

[videofan3d]

Thanks!
I can confirm that dll's from Media SDK 2.1 work just fine with FRIMSource.

I think this AviSynth plugin makes your toolset the most flexible of the available options for 3D encoding. I would suggest a short wishlist to make it a good deal more convenient - if you find some time.
1) Make FRIMSource work with m2ts transport streams - then there would be no need to demux them first, we could work directly with the ripped blu-ray/image
2) Indexation system like in Donald Graft's plugins. Right now, even to find out the total number of frames, you need to fire DGIndexNV or something similar.

ad 1) - m2ts.
This is already implemented, just use parameter FRIMSource(..., container="ts", ...)

ad 2) indexation - this is very difficult task (and Donald's knowledge of h.264 format is much bigger than mine :) )

[trevorjharris]

I see that Intel Media SDK 2016 is available. Please can someone tell me if i is compatable.

[r0lZ]

Just tested it, and it seems to have a bug, already reported to Donald Graft , for a previous version, here (http://rationalqm.us/board/viewtopic.php?f=5&t=324&start=60#p4352).

Note that FRIMSource can process the sample without problem. I don't know why.

Anyway, as far as I know, the only version without bugs of the libmfxsw32.dll is v6.14.11.28 released by Intel in November 2014. Several versions released in 2015 do have the "black frames" bug, and previous versions were unable to decode properly some frames of some rare 3D BDs (notably Pacific Rim and Ice Age 3). IMO, it is better to stick with v6.14.11.28. However, if you really want to try it, I can confirm that the new 2016 version (v7.15.10.28) is compatible with FRIMSource.

I have not tested the encoder.

[DarkCinema]

@videofan3d

r0lZ pointed me to Frimencoder for what I try to achieve.
I would like to create a MVC-3D with hardcodes subtitles using the 3D plane info from the 3D Bluray Disk.
Currently I am using BD3D2MK3D to create a FHD T&B video. Since KODI now supports MVC-3D on the Pi2 and on some Android devices I would like to create a high quality MVC-3D which works better on the android devices than the FHD T&B video. I need to hardcode the subs since there is currently no solution to display the 3D PGS subs correctly (even with the original 3D ISO).

Is there a method I could try using Frim?

[videofan3d]

@videofan3d

r0lZ pointed me to Frimencoder for what I try to achieve.
I would like to create a MVC-3D with hardcodes subtitles using the 3D plane info from the 3D Bluray Disk.
Currently I am using BD3D2MK3D to create a FHD T&B video. Since KODI now supports MVC-3D on the Pi2 and on some Android devices I would like to create a high quality MVC-3D which works better on the android devices than the FHD T&B video. I need to hardcode the subs since there is currently no solution to display the 3D PGS subs correctly (even with the original 3D ISO).

Is there a method I could try using Frim?

Hi,

FRIM Encoder will only encode to MVC-3D planar 3D input, so it depends on you what you feed it with.

I never did any subtitle hardcoding (I don't like it). But I guess there are some plugins for Avisynth which will embed srt into video. Thus you could (in theory) decode original 3D-MVC using FRIMSource, and embed srt into (for L-eye and also for R-eye). And then then encode it back to 3D-MVC using FRIM Encode.

The key-task will be to obtain and somehow decode 3d-plane information from the original MVC stream. Unfortunately, I don't know how it is stored there and how to decode it for horizontal shift of L- and R-eye srt (to achieve Z-plane offset of the subtitles - for good viewer experience). Sorry...

Remark: Even more interesting would be to embed it into new MVC stream, but this is what only very expensive MVC-3D encoders do.

[r0lZ]

The decoding of the original video streams and the 3D-planes can be made easily with BD3D2MK3D (with FRIMSource or DGMVCSource). The conversion of the subtitles to 3D is also automatically made by BD3D2MK3D after the demux operation. The final avisynth script can also hardcode the 3D subtitles (with the SupTitle plugin). However, currently, the output is either Full or Half SBS or T&B, or Full Frame-interleaved. I suppose that the frame-interleaved output is close to what DarkCinema wants to do, but currently the two views are encoded in AVC with x264.

DarkCinema wants a MKV with AVC and MVC streams. I suppose that computing the AVC and MVC streams with FRIMEncode (instead of a single interleaved AVC stream with x264) is possible. Can you confirm that FRIMEncode will accept the AVS script (with alternate frames for the left and right views) ? And do you know if that streams will be ready to be muxed with MkvMerge ? I don't know if they are compatible with the MKV container, or if only TS or M2TS is supported.

MakeMKV can create 3D-MKVs with AVC+MVC streams, but afaik it's a non-standard format, not officially supported by Matroska, and I don't know if MkvMerge is as tolerant. MakeMKV requires a 3D-BD as input, not AVC and MVC streams, and therefore DarkCinema can't use it.

Personally, I'm not really interested in adding the possibility to encode to MVC MKV in BD3D2MK3D, but if it's easy enough, I may do it.

[frank]

3D-MKV is compatible with Matroska, but the MVC is hidden.
You can remux the 3D output from MakeMKV with MKVtoolnix, the MVC is retained. But MKVmerge is not able to generate new 3D-MKVs from AVC and MVC.

The only player for 3D-MKV is the Stereoscopic Player from Peter Wimmer. 3D-subs are not well supported.
You can generate a simple 3D-Blu-ray from 3D-MKV with tsMuxeR to play on 3D standard players.

[r0lZ]

Thanks for the precision. So, if I understand correctly, there is no possibility to create a 3D-MVC MKV with MkvMerge only. That's a serious problem, because I don't want to rely on MakeMKV (not free, and no command line).

I have also studied the possibility to encode to AVC+MVC with FRIMEncode, but it seems that it doesn't accept a frame-interleaved 3D stream (or AVS script) as input. It supports only two different streams, or SBS or T&B input. It is difficult to decode the two original AVC and MVC streams from the 3DBD with two different AVS scripts (due to the impossibility to seek with FRIMSource or DGMVCSource), and anyway it's not at all the way BD3D2MK3D works currently. Therefore the 2 streams input for FRIMEncode is not a good solution for me. It is also currently impossible to hardcode the subtitles on full-SBS or full-TAB (due to the limitation to single frame HD of the subtitles formats), and I don't want to rewrite everything to be able to hardcode the two subtitle streams on each view one at a time, and then combine the two views to Full-SBS or TAB.

It is, however, possible to use the avs script currently created by BD3D2MK3D for Half-SBS or Half-T&B (with or without hardcoded subtitles), and change only the encoder command to output the two video streams. But the benefit of the full resolution will be lost, and the final MKV will have to be created manually with MakeMKV. IMO, that's not interesting at all.

Therefore, it appears that the solution to create full-AVC+MVC MKV is way too complicated to be easily implemented in BD3D2MK3D. And since the compatibility of the MVC MKV format is at least very limited, I don't think I'll implement it. Sorry, DarkCinema. I can try to help you to establish a manual workflow if you wish, but you will have to study and test the possibilities of each programs yourself, and be sure that the output will be compatible with your hardware. I don't have enough time and interest to do it entirely for you, since now I'm sure that I don't want to implement it in BD3D2MK3D.

@videofan3d: Sorry for squatting your thread!

[videofan3d]

I have also studied the possibility to encode to AVC+MVC with FRIMEncode, but it seems that it doesn't accept a frame-interleaved 3D stream (or AVS script) as input. It supports only two different streams, or SBS or T&B input.

FRIM Encode at the moment accepts "only" separate streams, SBS and TAB input. I didn't see a reason to implement frame interleaved format - I assumed it is possible to manipulate and create SBS from frame interleaved using proper Avisynth script. I'm I correct it is doable ? (question rather for Avisynth experts :) )

[videofan3d]

FRIM Encode at the moment accepts "only" separate streams, SBS and TAB input. I didn't see a reason to implement frame interleaved format - I assumed it is possible to manipulate and create SBS from frame interleaved using proper Avisynth script. I'm I correct it is doable ? (question rather for Avisynth experts :) )

Just to be clear:

frame interleave = frame alternation,

i.e.
1. frame in the stream is L1
2. frame in the stream is R1
3. frame in the stream is L2
4. frame in the stream is R2
etc.
Correct?
If there is a need, I will consider to implement it.

[frank]

Originally Posted by r0lZ:
So, if I understand correctly, there is no possibility to create a 3D-MVC MKV with MkvMerge only. That's a serious problem, because I don't want to rely on MakeMKV (not free, and no command line).right.

[sneaker_ger]

The only player for 3D-MKV is the Stereoscopic Player from Peter Wimmer.
LAV nightly + latest madVR added support yesterday.

[DarkCinema]

Many thanks guys for your replies on my (I assumed simple) question. Seems to be a bit complicated to accomplish.

I never thought a solution would come so soon, but after waited for more than 2 years for a replacement media player, for my Mede8er and A-400, that could playback 3D Blu-ray ISO or MVC-3D with correct subtitle depth, I now have a working replacement.

The RC2 firmware of the VTEN supports 3D subtitles for both ISO and MVC using original PGS subtitles. It displays them on a fixed depth (configurable in future FW) and works fine using the PGS subs. This means right and left placement is kept + depth.

So this means no re-encoding is needed anymore.

[r0lZ]

I assumed it is possible to manipulate and create SBS from frame interleaved using proper Avisynth script. I'm I correct it is doable ? (question rather for Avisynth experts :) )
Yes, it's possible. It's what BD3D2MK3D does.
I just don't want to have to modify completely my scripts just to be able to output another format, and currently they are built with the conversion to HALF-SBS or HALF-TAB at the very beginning, and then the 3D subtitles are hardcoded on top of the combined frames. It is a pity to have to resize them to half size just because subtitles cannot be hardcoded on full-SBS or full-TAB.
When FULL SBS or TAB is requested by the user, the frames are never combined, the subtitles are hardcoded on each view independently, and the output is frame interleaved.

Just to be clear:

frame interleave = frame alternation,

i.e.
1. frame in the stream is L1
2. frame in the stream is R1
3. frame in the stream is L2
4. frame in the stream is R2
etc.
Correct?
If there is a need, I will consider to implement it.
That's correct, and with BD3D2MK3D, the first frame will always contain the first frame of the left eye view. But I suppose that other scripts may use whatever is the base view as the first frame, and in (not so) rare cases, that can be the right view. Anyway, for the encoder, that should not change anything. The "base view" (AVC) must always be the first stream.

Since it seems that the MVC MKV format is not needed by DarkCinema any more and anyway I don't want to implement it, I don't need the change. But you might want to consider it anyway. That will be simpler to implement via an avisynth script, since currently FRIMSource and DGMVCSource both return frames alternation. It is a pity to have to combine them to full-SBS/TAB, since they will be cut again when converted to AVC/MVC. It's only a waste of time. But I repeat that I don't need that myself, so do it only if you wish and if it's simple enough.

[videofan3d]

...
But you might want to consider it anyway. That will be simpler to implement via an avisynth script, since currently FRIMSource and DGMVCSource both return frames alternation. It is a pity to have to combine them to full-SBS/TAB, since they will be cut again when converted to AVC/MVC. It's only a waste of time. But I repeat that I don't need that myself, so do it only if you wish and if it's simple enough.

I checked quickly and it is not too much work.

I will release FRIM 1.26 soon
- compiled with Intel Media 2016 libraries, so I will add this functionality to FRIMDecode and FRIMEncode (and FRIMSource).
No other changes are planned, Intel Media 2016 didn't bring any major functionality enhancement related to MVC.
(And practically, we all expect only continuous improvement in quality of encoding and performance :) )

[r0lZ]

OK, thanks anyway for your efforts.

I know that the newest Intel libs do not offer better MVC decoding because it is lossless and (afaik) bug free, but I was hoping that the encoder has been improved. It's a pity if it's not the case, because there is much room for improvement here. Anyway, it is always good to stick with the latest version.

[videofan3d]

FRIM 1.26 released

Changes:


Compiled with Intel Media SDK 2016
64-bit versions renamed to FRIMDecode64.exe, FRIMEncode64.exe, FRIMTranscode64.exe. This allows to keep all executables on the same place and avoid confusion when calling the.
FRIMEncode, FRIMDecode, FRIMSource: new option for frame-alternation input/output: -alt (similar to -sbs and -tab)

[r0lZ]

Thanks for the -alt option! :-)

[jdobbs]

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

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

[r0lZ]

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

[videofan3d]

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

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

[r0lZ]

You can download this sample (http://download.videohelp.com/r0lZ/tmp/DGMVCSource%20bug%20with%20libmfxsw32%20v6.15.6.2.7z) I did to test the black frames bug of DGMVCSource. Just comment out the 2 lines related to DGMVCSource and uncomment the two lines for FRIMSource, and change the path to the DLL.

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

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

[videofan3d]

You can download this sample (http://download.videohelp.com/r0lZ/tmp/DGMVCSource%20bug%20with%20libmfxsw32%20v6.15.6.2.7z) I did to test the black frames bug of DGMVCSource. Just comment out the 2 lines related to DGMVCSource and uncomment the two lines for FRIMSource, and change the path to the DLL.

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

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

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

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

without any issue!

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

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

[jdobbs]

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

[jdobbs]

@videofan3d

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

[videofan3d]

@videofan3d

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

Tested on Windows 7.

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

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

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

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

[jdobbs]

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

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

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

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

[videofan3d]

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

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

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

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

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

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

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

[jdobbs]

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

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

I re-tested it now quickly also on Windows 8.1 (64-bit) - no problem.
And also with FRIMSource64.dll (opening .avs with MPC_HC x64 via AviSynth+). Both again without obstacles.
Hard to say what is wrong until I reproduce the problem...I just tested it with AVISYNTH 2.6 and it works. As I'd mentioned, previous tests were using AVISYNTH 2.58. So the change you made using the AVS_linkage vector apparently makes if incompatible with earlier versions of AVISYNTH.

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

[videofan3d]

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

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

Good - so we found the root. Thanks!

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

[Eseninzhiv]

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

PS: video (http://www.youtube.com/watch?v=DT4nBVofLXg) made
Sef Thank you!

[Thalyn]

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

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

[jdobbs]

Try leaving your GPU on but enabling sw encoding.

[Thalyn]

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

[jdobbs]

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

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

[Thalyn]

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

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

[l33tmeatwad]

Any plans to port the AviSynth plugin to VapourSynth?

[BlackSharkfr]

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

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

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

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

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

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

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

Did I forget something ? Did I miss a parameter ?

[videofan3d]

Hello,
I bought a Sony BDP S4500 BluRay player with 3D capability...

Wow, interesting observations - I have never did any such research :)
Maybe other members of this forum will comment their experience with proper encoding parameters.

Just a comment to -vbr: it should have 2 parameters
-vbr bitRate maxRate

e.g. -vbr 10000 15000
the first is requested average bitrate,
the second is requested maximum bitrate.
Attention! It specifies bitrate of both (main and dependent) streams together! Not only for main stream!

Question: how exactly did you manage to play .m2ts file on your Sony BDP S4500 in 3D ? Does it play the .m2ts files in 3D directly from network storage or from USB - without having BDMV navigation structure?

[BlackSharkfr]

I did not set the maxbitrate value and it encoded fine.
As I said it was just a test.
I guess the maxrate becomes important if you want to use a much higher average rate, you have to make sure the maxrate matches the capabilities of the BluRay3D format.

I do not know what value is used by default if nothing is entered.

I could use the USB input, but I play my files through the network.
I store my video library on a Synology NAS, and I use the DLNA madia server application to share my audio and video library over my LAN which the Sony BDP-S4500 accesses over Ethernet. There is a different version of this player (BDP-S5500) which also has WiFi but it's more expensive... and I don't need Wifi since I wanted to use a wired connection from the very start.
The DLNA server app is configured to only serve the original files and never reencode.

The m2ts files appear like any other shared video : the displayed name is the "title" metadata. The actual file name mentionned only appears if the "title" metadata is missing, and the icon displays the file type (MPEG is drawn in the icon instead of MKV or MP4).
When I play the file, the BluRay player automatically activates the 3D mode. Just like with my side by side squashed mkvs (if the stereoscopic tag is properly set).

Note that I only tried to play the file in the m2ts container. I did not try to play it in an mkv container (I definitely should try that, I'm curious).
I also tried to add BluRay PGS subtitles in the m2ts : the player just refuses to load the video file.
I did not try SRT subs, I know they work fine in side by side mkvs, I'm curious to see if they work with MVC too (although the font chosen by Sony is really ugly)

One interesting thing to mention : there is a button on the remote to display technical information while playing a video (audio and video codec, number of audio channels and current audio and video bitrate).
When I play a BluRay disc : the video codec says "MVC".
But when I play the m2ts file it only reports AVC (even though it is actually playing the full MVC file in 3D).



I also noticed I cannot switch 3D off (can't play the base view in 2D only). I guess that's probably a bug on Sony's side. I should write to their tech support : they appear to care a lot for this little player : they update the firmware every tree months.

[r0lZ]

Given the symptoms described in your first post, I would suggest that the encoded AVC and/or MVC use a level incompatible with your players, but is flagged with a lower level. That may explain why the players accept to play the file, but fail to do it properly. However, I'm really not sure it's the correct explanation, because if I understand correctly, your hardware player plays it correctly. Usually, the hardware players are much more picky than the software players, and most software players can play AVC/MVC with the highest levels.

I don't know if FRIMEncode has a setting to control the level, but if it's the case, I would try to set it to level 4.1 (Blu-Ray compatible) or even below, and see if that solves the problem. Just a suggestion. I'm not sure that will work.

[BlackSharkfr]

I don't think the encoded level has anything to do with it since I know the software H264 decoders on my computer can easily decode level 5 which the BluRay player has a very strict limit at level 4.1 (it refuses to play the 3840x1080 side by side file, it does not even try).

My guess would be that Sony added extra filters in their player to 'improve" the picture : add extra deblocking if the player detects a lack of deblocking (mpeg 2, mpeg 4 asp, etc...) or an incorrect amount of deblocking in AVC/MVC.

It's just a guess based on experience with TVs vs computer monitors.
TVs tend to have lots of filters because they word all the time with very dirty sources (like low bitrate mpeg 2 HD broadcast).
I guess the same logic probably applies to consumer BluRay players.

[videofan3d]

I don't think the encoded level has anything to do with it since I know the software H264 decoders on my computer can easily decode level 5 which the BluRay player has a very strict limit at level 4.1 ...

I tend to agree. Setting level is only marking the stream, i.e. to announce that it complies with a norm, with relevant bitrate limit and resolution. But actual bitrate itself can be forced higher.

I personally use FRIMEncode only for my own 3D videos(i.e. not for ripping and recompressing of BD3D). And I don't care too much about diskspace, so I always use setting -vbr 28000 40000 giving average 28 mbit/s with maximum 40 mbit/s (this is even higher than what my source material has). And with this setting I didn't observe any artefacts neither in Stereoscopic Player, MPHC (in 2D mode only) nor on 3D plasma (Panasonic) nor on 3D projector (Optoma).

[r0lZ]

I tend to agree. Setting level is only marking the stream, i.e. to announce that it complies with a norm, with relevant bitrate limit and resolution. But actual bitrate itself can be forced higher.I know that. It's why I wrote "... MVC use a level incompatible with your players, but is flagged with a lower level". And the fact that the level written in the header does not necessarily reflect the real level is IMO the cause of many problems. I consider it as a very big bug (of most h264 encoders). BTW, there are mods of the x264 encoder that fixes that bug, and limit the bitrate according to the specified level. Anyway, it is a fact that currently, it is almost impossible to know exactly the level of a particular encoding if you don't know the command line that has been used. It's why I tend to suspect level problems.

I have had some playback problems (choppy playback and abrupt stops) with my TV when I encoded with x264 level 4.1 without specifying the max bitrate. The TV trust the level and tries to play the file anyway, but cannot do it properly. However, I agree that the level problem is probably not the cause of the bad decoding here. But what BlackSharkfr has noticed is so strange that there must be an explanation. I supposed that all decoders must decode a properly encoded movie (with a compatible level) properly. It appears that it's not the case (al least with h264 streams encoded with the Intel encoder). If the level is not the culprit, what could be the reason?

[Sharc]

.....I have had some playback problems (choppy playback and abrupt stops) with my TV when I encoded with x264 level 4.1 without specifying the max bitrate. .....
Both --vbv maxrate and --vbv-bufsize must be set Blu-ray compliant to avoid stutter during playback.

[BlackSharkfr]

If I did not miss any setting relative to the deblocking issue, the only possible explanation I can find is that intel simply did not think people would encode MVC at anything lower than BluRay bitrates, thus causing their encoder fall apart at *cough* "low bitrates" *cough* (10Mbps).

[videofan3d]

If I did not miss any setting relative to the deblocking issue, the only possible explanation I can find is that intel simply did not think people would encode MVC at anything lower than BluRay bitrates, thus causing their encoder fall apart at *cough* "low bitrates" *cough* (10Mbps).

I cannot comment nor judge if this statement is true or not :-)

But: If you want to have really working, realistic 3D, you MUST have big screen. And if I say big, I mean really something bigger than 80" (!). It is SIGNIFICANT visual difference in 3D perception once you move from small TV (50-55-65") to 3D projection (90-100-110"). Really, believe me.
And for big screen you need to have high quality signal, which implies you need to use Bluray 3D bitrates, i.e. something above 24 and more mbit/s.
I recommend not to save few GB (which costs nowadays only few bucks) but rather enjoy high quality 3D picture on big screen.

[sef]

:goodpost:

[BlackSharkfr]

If you want to have really working, realistic 3D, you MUST have big screen. And if I say big, I mean really something bigger than 80" (!). It is SIGNIFICANT visual difference in 3D perception once you move from small TV (50-55-65") to 3D projection (90-100-110"). Really, believe me.
And for big screen you need to have high quality signal, which implies you need to use Bluray 3D bitrates, i.e. something above 24 and more mbit/s.

I agree. 3D does look fantastic on a big screen.
I use a DIY passive dual-projector system with a 110" screen.

Even though files with higher bitrates do look best, I also have a lot of content with much lower bitrates that look perfectly acceptable. (Mostly YouTube sbs clips)
The thing is : x264 is so good a low bitrates (yes even YouTube's super fast settings), you get a shock when you switch to other less capable encoders.

I wanted to try MVC for 3 reasons :
1 was being able to play the same video both in 2D on the regular 2D monitor and 3D on the big screen without having to fiddle around with the pan/zoom controls of my media player (practicality)
2 was to take advantage of the alledged 30-50% nitrate advantage of MVC over AVC for 3D stereo. (File size)
3 Being able to play my full-resolution side by side clips on the BluRay player (I currently must use the computer to play them) (practicality again)

It turns out #2 is currently not achievable with free tools. I'll have to wait until some very nice person adds MVC encoding to x264. (I may have to wait a looooong time)

It turns out that

[sneaker_ger]

#2 You can probably squeeze more 3D compression out of x264 if you use frame sequential/interleaved encoding (--frame-packing 5). In principle it is similar to MVC.

[BlackSharkfr]

#2 You can probably squeeze more 3D compression out of x264 if you use frame sequential/interleaved encoding (--frame-packing 5). In principle it is similar to MVC.

I tried it when the feature was introduced, I obtained terrible results :
Not only there is very little software capable of playing this content (basically, only stereoscopic player),
not only did I obtain no bitrate reduction for the same quality setting,
but the picture was heavily distorted as x264 mis-interpreted parallax as extreme horizontal shaking motion : the farther in depth the objects in the scene are to the screen depth, the more blurry x264 would make them.

And finally I suspect frame sequential files to have a weakness to frame loss. If for whatever reason the player isn't capable of keeping an accurate frame count across the entire movie (let's say when seeking), you'll get a 50-50% chance of a stereoscopic eye-swap + 1-frame lag between the eyes.

I never tried it again, ever.
And I don't want to try again. The drawbacks just outweigh any benefit.

[Sharc]

....not only did I obtain no bitrate (file size) reduction for the same quality setting......
You can't expect a significant bitrate (file size) reduction just from the packing method because x264 does not produce a dependent MVC stream for the second view. The bitrate (file size) saving would be achieved by sharing the same I (reference) frames for the 2 views.
Even the Intel MVC encoder is not very strong regarding file size reduction for the dependent view. It is however still the only free MVC encoder which is available today AFAIK, and it produces reasonable quality at sufficiently high bitrates. So the choice is between intel (FRIM) MVC or x264 SBS/TB still. If low file size is the premium target, x264 SBS (or TB) is the choice IMHO.

[sneaker_ger]

You can't expect a significant bitrate (file size) reduction just from the packing method because x264 does not produce a dependent MVC stream for the second view. The bitrate (file size) saving would be achieved by sharing the same I (reference) frames for the 2 views.

The x264 devs say:
Tests consistently show that interleaved frame packing is by far the best way to compress 3D content.
It gives a ~35-50% compression benefit over separate streams or top/bottom or left/right coding.
http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=247f504d3c7ac64a87ed5a12bab0f6b99af5959c
Which is expected. AVC is not designed for any top-bottom/side-by-side optimization.

And finally I suspect frame sequential files to have a weakness to frame loss. If for whatever reason the player isn't capable of keeping an accurate frame count across the entire movie (let's say when seeking), you'll get a 50-50% chance of a stereoscopic eye-swap + 1-frame lag between the eyes.
x264 writes a SEI to every frame to mark the view so players don't have to keep count.

[BlackSharkfr]

The x264 devs say:

http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=247f504d3c7ac64a87ed5a12bab0f6b99af5959c
Which is expected. AVC is not designed for any top-bottom/side-by-side optimization.


x264 writes a SEI to every frame to mark the view so players don't have to keep count.

It looks like they made a few patches since the last time I tried this feature.
I'll need to try again to see if they corrected the issues.
By the way, I never tried frame sequential content on the Sony BluRay player.
I know for sure that Sony does have frame sequential support AVC in mp4 file working on the PlayStation3. I wonder if they implemented it in their BluRay players too.

[Sharc]

Isn't frame sequential packing one of the alternatives in the Blu-ray standard which is for whichever reason just not being used for commercial Blu-ray discs? If it's part of the standard, every player with the Blu-ray label should be able to play frame packed content. Maybe I am wrong ...?


Edit for clarification:
Blu-ray does not support frame sequential packing. It only supports MVC with 2 muxing formats:
- ssif structure based on 2 individual base and dependent .m2ts files
- muxing of the base and dependent streams into one single .m2ts file

tsMuxeR supports both principles.

[Sharc]

The x264 devs say:

http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=247f504d3c7ac64a87ed5a12bab0f6b99af5959c
Which is expected.
They expect an interleaved 3D source, if I read this correctly. What exactly is it? 2 independent source streams for left and right view? Or an AVC and MVC interleaved stream? The --frame-packing 5 just tells x264 how the stereo source is packed. I couldn't produce any watchable result so far with frame-packing 5, just a blocky picture for both 2D and 3D viewing with MPC-HC (2D) or Stereoscopic Player(3D). Not sure how they define the 35....50% file size reduction. Anyway, I probably misunderstand something ..... never mind :o

[BlackSharkfr]

I can't say for the BluRay formats.
MVC was all new and shiny designed specifically for BluRay3D.
It claimed significant bandwidth improvements over separate parallel streams. But parallel streams was never a popular format for distribution.

The most commonly used formats for distribution were interlaced video MPEG2 (from the few 3D DVDs released in this format) with the left and right views stored in the odd/even fields. And side by side for everything on the internet.

X264 frame-packing 5 expects a frame sequential video as input.
It's the same principle as interlaced 3D but with full-resolution progressive pictures.
1st frame is left eye, 2nd frame is right eye, 3rd frame is left, etc... (Typically provided by some avisynth script since I don't know any software that outputs frame sequential stereoscopic video.
The x264 team chose the name for this option very poorly since it adds to the already very confusing HDMI frame packing transmission format (only exists within the HDMI cable, not a file format, not a picture format)

[r0lZ]

It looks like they made a few patches since the last time I tried this feature.
I'll need to try again to see if they corrected the issues.
Have you noticed this ? :

Note that x264 will not do this optimization unless --frame-packing 5 is used to tell x264 that the source is interleaved 3D.

The blurry parallax problem you have experienced might be caused by the missing --frame-packing argument.

[Sharc]

I did a few more tests with x264 and --frame-packing 5, and muxing the frame packed .264 stream to .m2ts with tsMuxeR, setting level 4.1

Encoding:
- x264 encodes the interleaved (combined) source using 1-pass CRF mode, and exits finally with error code 1.
- tsMuxer muxes the encoded .264 stream to .m2ts without error, frame rate = double (47.952fps)

Playback:
- I can watch the 3D .m2ts correctly with bino
- Stereoscopic Player however swaps the views every about half second (??)
- The TV plays the left and right view sequentially (= jittery 2D)

So 3D re-encoding of 3D sources using x264 and --frame-packing 5 seems to work, but playback compatibility is poor (only the bino player works in my case).

Edit:
Some more info on 3D display and HDMI structures is found here:
http://www.spectracal.com/downloads/files/Website/Website%20Articles/Stereoscopic%203D%20Video%20in%20the%20Home.pdf

[BlackSharkfr]

Have you noticed this ? :

The blurry parallax problem you have experienced might be caused by the missing --frame-packing argument.

I did use that option. In fact the whole point was to try it when it was first introduced. But again.. That was a few years ago, I have not tried encoding anything with frame sequential storage and am not very interested by this format. (As far ad I'm concerend it's a dead end).
I am much more interested in MVC since it's an industry standard. And is supported by pretty much any BluRay3D player. (Including the one I have)

And I am pretty sure the next gen players will probably be able to do 1080p fullSBS HEVC because of all the 4K support.

[robl45]

Is there a guide on how to use this? I want to take makemkv mvc output and compress it for space savings. I understand that this tool appears to be the only way to do that, but I can't seem to a find a GUI for it or any instructions. I would simple like to take the makemkv mvc file and shrink it down with burned in subtitles. Is this possible?

[tijgert]

I read a lot of problems with this transcoder.
I use DVDfab to shrink 3D movies. The problem with that is that the output size can only be set at either BD25 or BD50 with some small disc size variations.
The workaround for this to get the proper output size is a little cumbersome but doable.

1. Rip the 3D movie with MakeMKV.
2. Extract largest audio file as single file as well.
3. Make BD ISO (or file structure) from movie with TSmuxer.
4. Load ISO (or file structure) with DVDfab and set output to BD25 and see what kind of % compression that gives.
5. If you need more compression to obtain your desired file size (animation can be squeezed a lot), mux the extra audio file with MKVtoolnix to moviefile from MakeMKV and make a new ISO with TSmuxer.
6. Repeat step 4 and then 5 until you get the compression ratio you need.
7. Encode.
8. From the encoded ISO extract the movie again with MakeMKV and only select 1 audio stream.

Presto. Smaller 3D movie at the size YOU want.

[robl45]

What do you do for step two to extract? And what do you do about subtitles?


I read a lot of problems with this transcoder.
I use DVDfab to shrink 3D movies. The problem with that is that the output size can only be set at either BD25 or BD50 with some small disc size variations.
The workaround for this to get the proper output size is a little cumbersome but doable.

1. Rip the 3D movie with MakeMKV.
2. Extract largest audio file as single file as well.
3. Make BD ISO (or file structure) from movie with TSmuxer.
4. Load ISO (or file structure) with DVDfab and set output to BD25 and see what kind of % compression that gives.
5. If you need more compression to obtain your desired file size (animation can be squeezed a lot), mux the extra audio file with MKVtoolnix to moviefile from MakeMKV and make a new ISO with TSmuxer.
6. Repeat step 4 and then 5 until you get the compression ratio you need.
7. Encode.
8. From the encoded ISO extract the movie again with MakeMKV and only select 1 audio stream.

Presto. Smaller 3D movie at the size YOU want.

[r0lZ]

You can extract the audio from the original BD with tsMuxeR, or from the MKV created at step 1 with mkvtoolnix and gMkvExtractGUI.

Unless you want to keep a lot of subtitle streams, they are light enough to be ignored for the computation of the final file size. Just include them in the MKV in step 1. IMO, the major drawback with that method is that the 3D-Planes are lost during the re-encoding, and therefore the subtitles will not appear at the correct depth.

[tijgert]

Extracting any single stream, be it subs, audio or video, can be done with tsMuxer, but also mkvextractgui (I believe there are two forks or something, 1.6.4.1 and 2.2.2.9).
All the original and important streams are ripped in the first pass with MakeMKV, so subs should be at proper depth.

Theoretically you could and any old stream to the mux to enlarge the file and influence the compression ratio, but using the same movie's stream avoids any type of mismatch with length or bitrate or resolution or what not.

[geheim]

Hi,
I have a problem encoding with FRIM. If I encode files with FRIM via commandline the output shows many artefacts on Stereoscopic Player and after muxing to BD with TSMuxer on my Sony BDP.
Does anyone have an idea what the problem could be??

This is an example command-line I use:

FrimDecode -ts -i:h264 00800_3D.m2ts -o \\.\pipe\bdrb.yuv -sw |FRIMEncode -alt 2 -i \\.\pipe\bdrb.yuv -viewoutput -o::mvc "L:\zzz\VID_00000.AVS.264" "L:\zzz\VID_00000.AVS.mvc" -sw -w 1920 -h 1080 -f 23.976 -u 3 -cpbsize 3372 -l 6 -profile high -level 4.1 -vbr 35000 35000 -gop 24 4 0 O -maxdpb 4

Is there any error??

The artefacts are in both base and dependent view, but mostly in dependent view. I don't know what I'm doing wrong.

Any help would be appreciated!
Thanks!

[r0lZ]

Artefacts were frequent in old versions of the Intel decoder. The bug is fixed now, but if you have the right CPU and you are using an old Intel driver, it might be the culprit. Try to update your drivers or switch to software mode.

Note that this applies to the decoder. I don't know if the encoder has or had the same problem. And, IIRC, the artefacts of the MVC decoder were present in the dependent view only.

[geheim]

Thanks @r0lZ!
I do not have an Intel CPU, therefore I'm already using Software mode.

Interesting is that FRIM works fine for me if I encode BD50 to BD25 with BD-Rebuilder. However it is also not working if I encode SBS MKV to MVC with BDRebuilder.
As I want to hardcode subtitles on my MVC encodes (in order to Keep depth), I can't use BDRebuilder.

I encode to Alternate MKV with hardcoded Subs using your great tool BD3D2MK3D and now I wanted to encode this file to MVC using FRIM. This gives me the artefacts, I tried both FrimSource and FRIMDecode and also DircectShowSource (via avs2yuv). Everything gives me those artefacts....

If anyone has any further ideas I'd really appreciate it :)

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

[MrVideo]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

I do not do virtual machines
Goodbye

[MrVideo]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Second attempt:
FRIMSource(codec="h265", filename=…"

Are you suggesting my using 32-bit AviSynth+?

[SpasV]

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]

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]

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]

Unfortunately, I cannot make FRIM works.


Mission_Imposssible_Ghost_Protocol.mkv

FRIM does not parse .mkv container...

[SpasV]

Sorry my absentmindedness.

The context is avs2yuv64.exe. It is avs2yuv-0.24bm5 - the last version.

When I use ffms2-2.23.1 as a source FFMS2(<"file_name.m2ts">, colorspace = "yuv420p10")
it works and the process displays the mesage:
encode-FFMS2.265.avs: 3840x2160, YUV420P10, 10-bits, progressive, 12500/473 fps, 3171 frames

When I use FRIMSource - FRIMSource(codec="h265", filename=<"file_name.m2ts">, cache=1, num_frames=24, platform="sw")
the mesage is:
avisynth 16-bit hack enabled
encode-FRIM.265.avs: 1920x2160, YV12, 10-bits, progressive, 24000/1001 fps, 24 frames

The same mesage I've got with ffms2-2.23.1 when I used the old avs2yuv64.exe version - avs2yuv-0.24bm3

[videofan3d]

Sorry my absentmindedness.

The context is avs2yuv64.exe. It is avs2yuv-0.24bm5 - the last version.

When I use ffms2-2.23.1 as a source FFMS2(<"file_name.m2ts">, colorspace = "yuv420p10")
it works and the process displays the mesage:
encode-FFMS2.265.avs: 3840x2160, YUV420P10, 10-bits, progressive, 12500/473 fps, 3171 frames

When I use FRIMSource - FRIMSource(codec="h265", filename=<"file_name.m2ts">, cache=1, num_frames=24, platform="sw")
the mesage is:
avisynth 16-bit hack enabled
encode-FRIM.265.avs: 1920x2160, YV12, 10-bits, progressive, 24000/1001 fps, 24 frames

The same mesage I've got with ffms2-2.23.1 when I used the old avs2yuv64.exe version - avs2yuv-0.24bm3

When using file.m2ts (i.e. TS-container), you have to add

FRIMSource(… ,container="ts",...)

For more FRIMSource details see FRIMSource_readme.pdf from distribution...


I'm not familiar with avs2yuv64.exe …

[SpasV]

All plugins are in place, obviously.
Intel/MediaSDKPlugin
C:\Programs\AviSynth+\FRIM_x64_version_1.29\x64\
With container="ts"

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)

[videofan3d]

All plugins are in place, obviously.

With container="ts"

Can you open your script encode-FRIM.265.avs directly using e.g. MPC-HC(x64) media player?
(You need to use some 64-bit media player which is capable to play Avisynth+ scripts. MPC-HC(x64) is able to do it).

If yes then script is correct and problem is somewhere in avs2yuv64.exe - this I cannot help...

If not, MPC-HC(x64) will show you error message to resolve...

[SpasV]

MPC-HC(x64), AvsPmod too, can play the scripts.
When playing FFMS2("file_name.m2ts", colorspace = "yuv420p10") there is a normal 3640x2160 picture.
When playing FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240) there is no picture.
https://imagez.to/i/Rbn3pw4t.png
with FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240, container="ts")
there is the Error message above when I've tried .mkv file.

but FRIMSource(codec="h265", filename="file_name.h265", cache=1, num_frames=240) plays and V: rawvideo, yuv420p, 3840x2140

[SpasV]

@videofan3d
Are you capable of developing an MVC encoder?

[videofan3d]

@videofan3d
Are you capable of developing an MVC encoder?

I'm not sure whether you read the first post of this thread
Free H.264 MVC 3D Encoder (http://forum.doom9.org/showthread.php?t=169651) ...

[videofan3d]

MPC-HC(x64), AvsPmod too, can play the scripts.
When playing FFMS2("file_name.m2ts", colorspace = "yuv420p10") there is a normal 3640x2160 picture.
When playing FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240) there is no picture.
https://imagez.to/i/Rbn3pw4t.png
with FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240, container="ts")
there is the Error message above when I've tried .mkv file.

but FRIMSource(codec="h265", filename="file_name.h265", cache=1, num_frames=240) plays and V: rawvideo, yuv420p, 3840x2140

Send me the script - I'll check it....

[SpasV]

Send me the script - I'll check it....
The scripts:
container not specified - no picture
FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240)

container="ts" - error
FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240, container="ts")

[SpasV]

As to "I'm not sure whether you read the first post of this thread
Free H.264 MVC 3D Encoder ..."
Sorry, I've missed the important part.

I've tried it and I would like to ask you some questions about:
(Better if there is a written instruction.)
- VBR - avg, maximum; obviously I can change them. But, working with x264, I prefer Constant QP with control over the maximum bitrate.
- are there other parameters avilable
- performance - with no more than 38% CPU load I've got 7 fps.

In general, the most information the better.

[videofan3d]

The scripts:
container not specified - no picture
FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240)

container="ts" - error
FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240, container="ts")

So it is only single command FRIMSource() ?
Than it shall work. You have to have something wrong in installation.

Try to check the following:

1. Install FRIM package into single directory, e.g. c:\FRIM
(and remove all other occurrences)
2. Add this directory to PATH
3. set this path into plugins64.reg and load to registry
4. test it first with some h.264 encoded file

[videofan3d]

As to "I'm not sure whether you read the first post of this thread
Free H.264 MVC 3D Encoder ..."
Sorry, I've missed the important part.

I've tried it and I would like to ask you some questions about:
(Better if there is a written instruction.)
- VBR - avg, maximum; obviously I can change them. But, working with x264, I prefer Constant QP with control over the maximum bitrate.
- are there other parameters available
- performance - with no more than 38% CPU load I've got 7 fps.

In general, the most information the better.

FRIMencode32.exe -help will show all options (and there are planty od them - you can play with them and find most suitable for you)

Performance: MVC encoding is heavy process, depending on CPU and also disk speed (using SSD will make it a bit faster). It operates with uncompressed video which is 6 MB per frame! If you have i5/i7, you can use -hw mode (install always latest GPU drivers)

[SpasV]

When I've tried x265 with 3840x2160 frames the CPU load was around 100% and the result was 0.7 fps.
I have 6-core 2 CPU @3.33 GHz 48 GB RAM machine, GeForce GTX 1050. Not shure if x265 used GPUs. Probably not.
HDD @150 MBps siquential read/write. I don't do encoding at all. Now, out of curiosity, I'm trying 3D Blu-ray reencode.

As to the FRIMSource() I'm happy with .264, .265 files.
At the beginning, I've used Intel's SDK plug-ins, later - FRIM's.

[SpasV]

@videofan3d
Is it possible for you to compile an MVC encoder using x265/244 encoder?
I'm not entirely happy with FRIM Encoder - its performance and parameters.

[videofan3d]

@videofan3d
Is it possible for you to compile an MVC encoder using x265/244 encoder?
I'm not entirely happy with FRIM Encoder - its performance and parameters.

You are missing the point:
- x265 is HEVC, it has no MVC - even not defined by norm specification
- x264 is only AVC, it has never ever implemented MVC.
- Intel Media SDK it likely the only free MVC encoder...

But you can purchase the professional one - from Sony... enjoy

[SpasV]

It seems my idea of mvc encoding dosn't work.
It is a cycle:
difference_view=left_eye (subtraction) right_eye;
encoding left_eye;
encoding difference_view;
something more;

Nevertheless I'm runnig SOFTWARE (C:\Programs\FRIM_x64_version_1.29\x64\libmfxsw64.dll)
-length 232608 -profile high -level 4.1 -u 1 -rf 16 -cqp 16 17 19 -Bpyramid on -o:mvc Avatar.h264
and
Processing started (maybe 48 hours ago)
Frame number: 163495
Probably 28 hours to go at 23% CPU load.
Not very bad, anyway.
I've tried two Video Editor software. They are terible with my test.
I doubt they could do 232,608 HD frames at all.

As to "you can purchase the professional one - from Sony..." I'm not a proffesional video encoder.
I, even, don't do Blu-ray re-encoding at all. I'm just trying mvc encoding because nobody does it in my tracker community and I would like to show them results from a working mvc encoder. They do half HD frame size re-encoding only.

Besides, there is a $10k mvc encoder and maybe cheaper.

[r0lZ]

It is a cycle:
difference_view=left_eye (subtraction) right_eye;
encoding left_eye;
encoding difference_view;
something more;
It's not so simple.

The main view (that can be the left or right view) is encoded in h264 (aka AVC). That's theoretically easy to do with x264, although there are specific constraints for a bly-ray.

It is right that the other view contains only the differences. It is called "dependent view" because it depends of the main view. But it is not encoded in h264/AVC like the main view. MVC is not just like AVC applied to a dependent view. I'm not a specialist, but I know that you cannot simply encode the differences in AVC, say with x264, to obtain the MVC stream. It's why it is necessary to use a complete AVC+MVC encoder. And currently, the only free encoder able to do that is the Intel MVC encoder. It is used internally by FRIM, and you cannot change that.

You cannot expect that somebody will spend years in developing alone a new MVC encoder simply because the Intel encoder is not perfect. That would require the work of a big team of very advanced programmers working during several years. Simply impossible, especially given the fact that there is already a free MVC encoder, and that the demand for such encoder is not really important.

[SpasV]

@r0lZ
Thanks for expresing your opinion about an idea for amateur mvc compressor development.

Besides, DVDFab offer a product - Geekit: MVC Codecs
"a professional toolkit specifically designed for those knowledgeable videophiles who have a geek-level enthusiasm for video editing".
It didn't work with my test.

[r0lZ]

Besides, DVDFab offer a product - Geekit: MVC Codecs
Hum, according to what I have read on the DVDFab site, their codec is only able to decode the original MVC streams from a 3D-BD. There is nothing to re-encode in MVC. And for a decoder, it is extremely expensive (75€), especially given the fact that the Intel MVC codec is free, its decoder part works perfectly, and you have the encoder also for free. IMO, buying the DVDFab decoder doesn't make sense.

[EDIT] No, I was wrong. The DVDFab MVC codec can encode in MVC. I don't know if the quality is good, but it remains that it is not free. And they explain that their codec is the only MVC codec available currently. That's not true, as you can use the Intel MVC codec for free.

[SpasV]

I don't know what their MVC codec do. I've tried to get something from it and the result was zero.
First, I wasn't satisfied from the decoder and using FRIMDecode I had two (L/R) raw files I put in mkv container with ffmpeg.
Every file (L/R.yuv and l/R.mkv) were playable.
Second, I've started their MVC encoder and it crashed.

[SpasV]

@videofan3d

Thank you very much for your work. :)
I've tried the MVC encoder and the first impression satisfies me.
I didn't do many test to determine suitable parameters for an encode.
With the idea to have high quality encode I chose at a glance
-u 1 -rf 16 -cqp 16 17 19 -Bpyramid on, so I got
Bitrate control CQP
QPI,QPP,QPB 16,17,19
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 1 (quality)

Then
Processing started
Frame number: 232608
Processing finished in 148433.81 seconds, which is 41:13:54.
The last result seems not very bad - 1.567 3Dfps

These, practically, random chosen parameters for QP:
QPI, QPP, QPB 16, 17, 19
turned out to be as used by the original encoder.
The file sizes, average bit-rate, bit-rate vs time are undistinguished compared to the source. Even the PSNR for every color channel is 100 dB.
Some examples.
encode:10,591 - 21,149 kbps
source: 10,608 - 21,166 kbps


Two screens from left eye frames #27,349 (00:19:00.681) where the bit-rate is about 34 Mbps.

https://thumbs2.imgbox.com/68/85/5EqIODCi_t.png (http://imgbox.com/5EqIODCi) https://thumbs2.imgbox.com/87/89/yEZCKFBo_t.png (http://imgbox.com/yEZCKFBo)

[Emulgator]

Even the PSNR for every color channel is 100 dB.
Would not have thought that. 100dB means fault level of 1/100.000 full scale,
so in a 8-bit world source and encode should be bit-identical. Are they ?

[SpasV]

Practically, yes.
Following this formula:
https://wikimedia.org/api/rest_v1/media/math/render/svg/fc22801ed1232ff1231c4156b589de5c32063a8a
where
https://wikimedia.org/api/rest_v1/media/math/render/svg/3a34719b4f391dba26b3e8e4460b7595d62eece4
In average, the total sum of absolute values for the differences between identical numbered pixels - sqrt(MSE) is
m.n*MAXi*(10 to power of -5) =1920*1080*255*0.00001= 5287.68
So, there could be almost 5,288 pixels out of 2,073,600 whose numbers differ by one, all others are bit-identical.
These are 0.0255%

[jamt]

@videofan3d Thanks for continuing to support this tool, I've been using it with great success for a couple years now.

I had a couple random questions that have been in the back of my mind for a long time. So not really that important but keep meaning to ask..

1) When transcoding from an MVC file the easiest way to do so (from the docs) is something like

FRIMDecode -i:mvc input.h264 input_depend.h264 -sbs -o - | FRIMEncode -sbs 2 -i - -o:mvc combined.h264 -w 1920 -h 1080 -f 23.976 -vbr 28000 40000


This uses sbs as an intermediate format; would tab work exactly the same? I always expected tab would be more efficient since it doesn't require merging & splitting every single scan line during the process, but wasn't sure if there was something special about this scenario leading the docs to recommend sbs.

2) Do you have any sense for whether it's safe to use MVC codec levels above 4.1 on typical devices these days? 3D blu ray discs are always encoded at 4.1; I assume this is some baseline support offered by BD players. But I'm not playing back on a BD player. I assume this would be chipset dependent, but there's basically no information easily available about this setting and device support that I can find, unlike for AVC. Just wondering if you had any ad-hoc experience with higher codec level different settings.

Thanks again!

[videofan3d]

@videofan3d Thanks for continuing to support this tool, I've been using it with great success for a couple years now.

I had a couple random questions that have been in the back of my mind for a long time. So not really that important but keep meaning to ask..

1) When transcoding from an MVC file the easiest way to do so (from the docs) is something like



This uses sbs as an intermediate format; would tab work exactly the same? I always expected tab would be more efficient since it doesn't require merging & splitting every single scan line during the process, but wasn't sure if there was something special about this scenario leading the docs to recommend sbs.

2) Do you have any sense for whether it's safe to use MVC codec levels above 4.1 on typical devices these days? 3D blu ray discs are always encoded at 4.1; I assume this is some baseline support offered by BD players. But I'm not playing back on a BD player. I assume this would be chipset dependent, but there's basically no information easily available about this setting and device support that I can find, unlike for AVC. Just wondering if you had any ad-hoc experience with higher codec level different settings.

Thanks again!

Hi,

thanks for appreciation :-)

Regarding SBS vs. TAB - yes, in this pipe you can use both: SBS as well as TAB. It is only how interim frames are tiled by decoder and then separated again by encoder. Result will be in both cases identical.

Regarding the levels: Technically, level (4.0, 4.1, etc. ) is only number which is written into the AVC stream, and you can theoretically fake it as you want.
But it is not good idea because level number might be (and I guess rather it IS) identified and recognized by particular AVC decoder which may use e.g. it for some buffer pre-settings.
Therefore it is wise to mark the output stream with correct level number according to selected bitrate.

I personally play 3D only from 3D-media player (i.e. not from Bluray-3D player) and I set bitrate around 40 mbit/s (for both base+dependent stream). I have no need to set it higher since my separate L,R video sources are 21 mbit/s at most.

[r0lZ]

Do you have any sense for whether it's safe to use MVC codec levels above 4.1 on typical devices these days?
Full-SBS and Full-TAB require level 5 or above, due to the buffer necessary to hold the double image, and possibly also to the high bitrate. Levels 5 and greater are not compatible with most Full-HD TV, but should be compatible with all UHD players.

Level 4.0 to 4.2 are sufficient for Half-SBS and Half-TAB. The advantage is that level 4.1 is fully compatible with all 3D TVs.

But as videofan3d wrote, the encoder may use the level provided via the command line only to write it in the header, regardless of the real level. It doesn't enforce the corresponding maximum bitrate and buffer sizes. (It's the case at least of the regular branch of x264. Not sure for FRIM.) However, x264 writes the correct level based of the actual max bitrate and buffer size if you DO NOT explicitly provide it. So, IMO, unless you want to encode with a very high bitrate, near the maximum supported by your equipment or a specific level, you should leave the encoder free to write the level it has really used due to the other encoding parameters.

[frank]

Here a fast working script without Avisynth.
First demux the 3D stream or use BD3D2MK3D. Put the two FRIM...exe into toolset folder.

set path=C:\Users\%username%\BD3D2MK3D\toolset;%path%
FRIMDecode64.exe -i:mvc MKV3D.track_1.264 MKV3D.track_1.mvc -alt -hw -o - | ^
FRIMEncode64.exe -alt 2 -i - -o:mvc film3d.264 -hw -d3d11 ^
-viewoutput -w 1920 -h 1080 -f 24000/1001 -icq 22 -profile high -level 4.1 ^
-gop 48 4 0 C -bPyramid off -length 156975 ^
-colorprim bt709 -colormatrix bt709 -colortransfer bt709
length = number of frames
icq = intelligent constant quality, use 20...26
I get about 60 fps!

The dependent mvc stream unfortunately has the same bitrate as the avc main stream. Intel media SDK cannot do it better. :rolleyes:
Normal is about 50 %. So the 3D feature doubles the stream size! Not very effective.

[frank]

@videofan3d
I have a Dell 9560 (Kaby Lake).
There are decoder issues in HW mode on some movies with DGMVCsource or old versions of FRIM. (The Marsian 3D, Geostorm 3D, look my examples -> BD3D2MK3D)
Same issue in BD Rebuilder with it's old FRIM version. The decoder hangs about 10 sec and then you get black frames.
But your latest version v1.29 compiled with SDK 2018 works! :)

So we thought the Intel SDK is the cause, and videoh (Donald G.) compiled his DGMVCsource with the latest SDK. But it doesn't work with this movies, same behavior.

Something else must have changed in your new version, because it works.
Do you have any idea what the cause is? Donald asked it.

[videofan3d]

@videofan3d
I have a Dell 9560 (Kaby Lake).
There are decoder issues in HW mode on some movies with DGMVCsource or old versions of FRIM. (The Marsian 3D, Geostorm 3D, look my examples -> BD3D2MK3D)
Same issue in BD Rebuilder with it's old FRIM version. The decoder hangs about 10 sec and then you get black frames.
But your latest version v1.29 compiled with SDK 2018 works! :)

So we thought the Intel SDK is the cause, and videoh (Donald G.) compiled his DGMVCsource with the latest SDK. But it doesn't work with this movies, same behavior.

Something else must have changed in your new version, because it works.
Do you have any idea what the cause is? Donald asked it.

Actually, I even didn't know there is some issue with decoding. (I personally don't decode/transcode original BD3D)
Therefore - I didn't change anything specific to fix it :)

In 1.29 I made changes mainly related to HEVC and also to include VPP unit into FRIMDecode.
To incorporate VPP I had to rework all internal loops there.
Probably - as positive side-effect of this - something has changed/improved what impacted the previous HW decoding - in positive manner.

It's good it happened :)
But to identify which particular line(s) of code affected it ... it is impossible to find out.
(Really, changes were quite big and spread over all decoding routines)

[videofan3d]

The dependent mvc stream unfortunately has the same bitrate as the avc main stream. Intel media SDK cannot do it better. :rolleyes:
Normal is about 50 %. So the 3D feature doubles the stream size! Not very effective.

Yes, I noticed this phenomenon already few years ago when started FRIM project.
I 3D-encoded the same content for L and R eye (i.e. practically 2D) and I expected that mvc-stream will be almost zero. And it didn't happen.

I also reported it to Intel Media SDK support, they recorded this issue ... and apparently didn't do anything with it.
Maybe they didn't succeed to solve it, maybe it had low priority. Anyway, nowadays when world has decline from 3D I guess they will NOT do any changes in 3D-MVC encoding...

[videoh]

In 1.29 I made changes mainly related to HEVC and also to include VPP unit into FRIMDecode.
To incorporate VPP I had to rework all internal loops there.
Probably - as positive side-effect of this - something has changed/improved what impacted the previous HW decoding - in positive manner. Thanks for the info, videofan3d. I'll probably have to rebase my code off the latest Intel sample code. Or I may just let it be, as you seem to have things covered very well with FRIMSource().

[r0lZ]

Hi Videofan3D.

A BD3D2MK3D user has reported a problem with FRIMSource here (https://forum.doom9.org/showthread.php?p=1869947#post1869947). It seems that with some 3DBD using the unusual view order (base view = right view instead of left), FRIMSource is unable to return the two 3D views correctly. According to the tests the user did, it returns two times the same view, or, if you swap the left and right views in the avisynth script, it returns the two views, but in inverted order. It's very strange. Note that DGMVCSource doesn't have that problem.

Can you have a look ? Perhaps there is something wrong in the script generated by BD3D2MK3D, but it worked fine previously.

Thanks in advance!

[videofan3d]

Hi Videofan3D.

A BD3D2MK3D user has reported a problem with FRIMSource here (https://forum.doom9.org/showthread.php?p=1869947#post1869947). It seems that with some 3DBD using the unusual view order (base view = right view instead of left), FRIMSource is unable to return the two 3D views correctly. According to the tests the user did, it returns two times the same view, or, if you swap the left and right views in the avisynth script, it returns the two views, but in inverted order. It's very strange. Note that DGMVCSource doesn't have that problem.

Can you have a look ? Perhaps there is something wrong in the script generated by BD3D2MK3D, but it worked fine previously.

Thanks in advance!

Could you please send me examples - which BD3D are affected? I will try it.
And also snippet of the script which BD3D2MK3D is using.

Thanks

[r0lZ]

AFAIK, all BDs with the inverted views are affected, notably the Boss Baby, Shrek the Third and Epic. I did my test with the Boss Baby. I will try to cut a sample of the movie...
In the meantime, here is the script:

LoadPlugin("D:\Tcl\work\BD3D2MK3D\toolset\FRIMSource.dll")
interleaved = FRIMSource("mvc", "00600.track_4113.264", "00600.track_4114.mvc", layout = "alt", num_frames = 2000, cache = 2, platform = "")
right = SelectEven(interleaved)
left = SelectOdd(interleaved)
StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))

I know that it is possible to return directly a Full-SBS or Full-TAB image, with the layout option, but BD3D2MK3D requires two different streams, for technical reasons. I haven't tried the direct method.

[r0lZ]

And here is the sample: FRIMSource inverted views bug sample.7z (http://download.videohelp.com/r0lZ/tmp/FRIMSource inverted views bug sample.7z)

[videofan3d]

And here is the sample: FRIMSource inverted views bug sample.7z (http://download.videohelp.com/r0lZ/tmp/FRIMSource inverted views bug sample.7z)

Funny defect :-) (it is there for several years)

I will issue bugfix next weekend.

[r0lZ]

Funny defect :-) (it is there for several years)

I will issue bugfix next weekend.
Yes, I wonder why nobody has noticed it !
Thanks in advance for the update.
BTW, perhaps it is also time to use the new Intel libs.

[videofan3d]

Yes, I wonder why nobody has noticed it !
Thanks in advance for the update.
BTW, perhaps it is also time to use the new Intel libs.

Here is bugfix for FRIMSourceNN.dll (https://drive.google.com/file/d/1GTjAQ659QtWtUBqEfa9n07ErrGI9L_JR).
Would be good if you could independently test it.

(I will provide full release once I complete integration of latest Intel Media libraries 2018R2.1 )

[r0lZ]

Thanks, and sorry for the late reply.

I have just tested the new DLL, with two movies. One has the common views order, and the other has the right-view as AVC stream. Both give the correct 3D effect. It's perfect, but note that I have tested only the 32-bit DLL with the layout="alt" mode and with the software platform. However, I'm pretty sure that the bug is fixed, and I don't think that new bugs have been introduced. So, unless you really think that more testing is necessary, you have my green light to integrate the new Intel libs and release it officially. If you want more testing, please let us know what tests you need.

Thanks again!

[videofan3d]

Thanks, and sorry for the late reply.

I have just tested the new DLL, with two movies. One has the common views order, and the other has the right-view as AVC stream. Both give the correct 3D effect. It's perfect, but note that I have tested only the 32-bit DLL with the layout="alt" mode and with the software platform. However, I'm pretty sure that the bug is fixed, and I don't think that new bugs have been introduced. So, unless you really think that more testing is necessary, you have my green light to integrate the new Intel libs and release it officially. If you want more testing, please let us know what tests you need.

Thanks again!

Fix is independent on HW or SW platform - defect was purely in my code, after obtaining L+R frame from Intel library. Actually, the particular code section is now even clearer and simpler than before.
I checked also SBS and TAB - and seemed to be fine as well.

Version with new Intel libs uploaded (2019-04-16).

[mindsong]

I don't think this is necro-ing a thread - I hope not, as it seems like the right place to ask/archive this info.

I'm struggling with a latest-version-based FRIMEncode<-AVISynth script effort that could be caused by any number of setup errors on my side, so perhaps it would be best to post my simplest example and see if the problem is more widespread, or just my environment, before I pursue it with the gory details.

Could someone with a stable/working FRIMEncode/AVISynth environment try this simple AVIsynth script that generates a basic/short test 3840x1080 SBS stream for encoding into a base.avc+dep.mvc file pair?

AVISynth Script (MyScript.AVS) - creates a simple 100 frame SBS stream:

L = ColorBars(1920,1080,"YV12")
L = KillAudio(L)
L = Info(L)

R = ColorBars(1920,1080,"YV12")
R = KillAudio(R)
R = Info(R)

V = StackHorizontal(L,R)
V = Trim(V,0,-100)
# redundant, but...
V = ConvertToYV12(V)
return(V)


FRIMEncode command:

FRIMencode32 ^
-avi ^
-i MyScript.avs ^
-sbs 2 ^
-viewoutput ^
-o:mvc 01_base.avc 01_dependent.mvc ^
-u 1

It's intended to be as *minimal* as possible, with the real script/workflow doing something that's actually meaningful... (real mpeg2 interlaced 3D -> MVC-3D)

Does this basic sequence work for anyone else, w any specific FRIM and toolset versions? Should it be able to, or have I missed something simple (some import or ...?) ?

I'm using an up-to-date W10 x64 system with a current x86 FRIM/AVISynth/Intel/codec toolchain and I'm seeing a colorspace mismatch. I've tried with a current x64 workflow to the same effect, so any test that works is welcomed, if it's possible. It seems like something FRIMencode is trivially able to do, so I'm wondering what I'm missing.

I'm fairly competent with these tools and environment, so I've got variations, various tool versions, specs, samples, variations, that I can share to ID my specifics, and maybe we can then pursue the fix to my puzzle, but fixing *my* workflow only makes sense if we know that this *can* work at all in anyone's stable environment - so this seems like a safe/easy place to start.

I'd appreciate if anyone could take this quick test for a spin and share their results - or perhaps correct some basic assumptions I'm making as I go down this path.

I've really done a bunch of research and experiments on getting this to work, so any help is truly appreciated at this point.

Cheers, and thanks in advance,

--ms

[videofan3d]

AVISynth Script (MyScript.AVS) …..

FRIMEncode command: … 01_base.avc

… I'm seeing a colorspace mismatch.


I opened MyScript.avs (as defined above) using MPC-HC
and then 01_base.avc (created as defined above) also using MPC-HC...

But honestly - I see identical colorbars on screen.
No visual difference.

So what is the problem?

[mindsong]

hello videofan3d,

Thanks for the reply (and for your great work on this project).

In your short reply, you've confirmed that my system is (still) not configured correctly. Most folks in here are working with a different data-flow (BD-3D to standalone MVC-3D), so I wanted to check to see if my simple test/approach was working for others before hitting up the thread with a "it doesn't work" assertion... Apparently it does work... :)

For me, the 'parts' all seem to be working on their own, but FRIMEncode isn't seeing my simple (or slightly more complex) AVISynth output as I420 and exits before it creates the avc/mvc pair - the error has been mentioned before and most folks have been able to fix their issues. I've read enough to see that the system setup is as likely (or more likely) to be a source of problems as the final FIRM/Intel step, so I wanted to be sure my ultimate target was viable (simple AVS script to avvc/mvc). Thanks for verifying that.


In gory detail, for those that might 'see' my problem, and future readers who go down this debugging path:

As I assumed (and still do) that the problem *is* my system, so my resolution efforts follow:

1) I've worked to match my x86/x64 toolchains with 'proper' (bitwise) versions of the AVISynth, ffdshow/VFW, FRIM, and Intel MSDK as a foundation. (everything is x86 for now)

2) I've then checked to be sure my simple AVS script is viable (it renders fine using AVIsynth 2.60 and AviSynth+ in 32-bit Vdub2, WMP, MPC-HC, and ffmpeg's avs renderer to both pipes and files)

3) I've done everything I know how to ensure that the AVS script outputs are YV12/I420 AVI streams and files, using Vdub2 and ffmpeg - files and pipes show lossless 4:2:0 YV12 or I420 content at various resolutions and framerates. The files/streams/pipes seem to play well enough on the above players and media-info/ffprobe indicate appropriate content/formats

4) I'm pretty certain that my ffdshow layer is causing the issue in the pipeline, but after hacking at that for a day, thought I'd ask some smarter folks to be sure my approach was/is plausible and that the script/workflow wasn't missing some obvious understanding ("of course that doesn't work!..." kind of thing).

5) with ffdshow(-tryout from sourceforge ffdshow_rev4533_20140929_clsid.exe) , the default install (32bit) with the default settings and the VFW decode "RGB raw video" set to "all-supported", I get the mentioned error from the above FRIMEncode32.exe command and script:


ERROR: Cannot get I420 frame from input avi-file MyScript.avs
Frame was written in default format to file MyScript.avs.error.bmp


and the bmp file that is produced *looks correct* (double-wide colorbars), so I assume that the AVISynth framework is operating properly (I have removed/disabled *all* of my avisynth plugins to ensure no side-effects/conflicts)

Also - when run *without* the "-avi" option, my FRIMEncode32.exe is able to run, ingest, process, and output a avc/mvc pair (660K.avc - 654k.mvc - mvc should be 520k-ish?) from an AVI file created from the above AVS script (~600 M avi for the 100 frames) using vdub2 (latest).

For good reason, I think the output is correct but not useful (the input file looks fine in WMP, but the avc file has sliding/blocky content from the FRIM/Intel stage (in WMP), and a tsmuxer m2ts from the pair plays, but also looks 'wrong' in the same way (no errors in the tsmuxer stage).

I assume FRIMEncode is expecting raw video and my AVI has repeating/confusing header/frame info that causes this corruption/sliding image effect. Probably doing the right thing. It only processes 50 frames (of 100).

If I run the command *with* the "-avi" switch, I get the same I420 related error message.



Infile specs (generated from vdub2 with the above AVS script):


General
Complete name : C:\Users\mindsong\Desktop\at\I420_3840x1080.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 593 MiB
Duration : 4 s 167 ms
Overall bit rate : 1 194 Mb/s
Writing application : Lavf58.29.100

Video
ID : 0
Format : YUV
Codec ID : I420
Codec ID/Info : 8 bit Y plane followed by 8 bit 2x2 subsampled U and V planes.
Duration : 4 s 167 ms
Bit rate : 1 194 Mb/s
Width : 3 840 pixels
Height : 1 080 pixels
Display aspect ratio : 3.556
Frame rate : 24.000 FPS
Compression mode : Lossless
Bits/(Pixel*Frame) : 12.000
Stream size : 593 MiB (100%)



FRIM Command that processes this file (with funky output avc/mvc files (size = 660K.avc - 654k.mvc) :


FrimEncode32 -i I420_3840x1080.avi -sbs 2 -viewoutput -o:mvc b.avc d.mvc -w 3840 -h 1080 -dsth 1080 -dstw 1920 -u 4

FRIM Encoder version 1.30 - Win32 (build: Apr 16 2019)
- based on Intel(R) Media SDK

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

Input format I420

Encoder AVC

Input picture:
Resolution 3840x1088
PAR 0:0
Structure Progressive
Crop X,Y,W,H 0,0,3840,1080
Frame rate 23.976
Output picture:
Resolution 1920x1088
PAR 0:0
Structure Progressive
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control CBR
bitrate 3572
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 4 (balanced)

Processing started
Frame number: 50
Processing finished in 3.00 seconds


(and adding the -avi option causes the process to fail with the mentioned I420 colorspace format error.)


So I believe that my FRIM (1.30) tools are not able to ingest my (seemingly) I420 4.2.0 lossless AVI streams, and probably due to my ffdshow/VFW/raw-video conduit setup.

I saw mention earlier in this thread of the ffdshow version being an issue for someone. Is there a preferred version/source (x64 and x32) of ffdshow? (or any of the tools that I'm using?)

Again, I may be missing something *really* basic and have no idea that I'm overlooking something - Are the above steps (toolchain, tests, workflow) rational for what I'm trying to do?

Of course I can provide samples and config screenshots if they would help!

Thanks again for all insights and advice!

cheers,

mindsong

[videofan3d]

ERROR: Cannot get I420 frame from input avi-file MyScript.avs
Frame was written in default format to file MyScript.avs.error.bmp


…

If I run the command *with* the "-avi" switch, I get the same I420 related error message.


Hi,

Yes, FRIMEncode assumes flat YUV files (I420 or YV12, i.e. chroma 4:2:0) because this is what underlaying Intel Media SDK can encode. (unfortunately 4:2:2 is not implemented there but this is another story)

I added -avi option long time ago, primarily for output from Adobe Premiere using DebugMode frame server (this was long before I wrote FRIMExport.prm).

Yes, -avi + Avisynth together need somehow ffdshow in the chain. Frankly speaking - configuration of all these Windows filters is magic - you never know what you have in the system and how they impact/influence each other.

Just play with it and try to find working combination.
These two links (mentioned in the past in this thread) may bring some advise
http://forum.doom9.org/showthread.php?p=1655564&highlight=ffdshow#post1655564
http://forum.doom9.org/showthread.php?p=1663488&highlight=ffdshow#post1663488

Good luck! :)

[mindsong]

Thanks! I will continue to experiment.

I am more comfortable now, knowing that amidst these 'magical' system dataflow path variables (codecs, etc.), that my goals with FRIM are plausible. If I learn anything specific, I will share the knowledge here.

lurking questions for me (to anyone/everyone):

For AVI files,

- what versions of ffdshow are folks working with? There are a number of versions and forks. Is anyone using clsid's latest to good effect, or is there a agreed-upon favorite older version that 'just works'.

- x86 or x64 - are folks working with avi files with the x86 versions, or does the x64 toolchain work too?

- avisynth+ ... or some previous version (w avi files...)

Any other tidbits that have haunted users in their setups are welcomed.

Thanks again videofan3d!

be well,
--ms

[mindsong]

Still trying:

Cranked up a VM with a raw W7, and both the completely minimal x86/x64 toolchains - frim/intel/ffdshow/avisynth - x86/x64 isolated

No luck - same I420 issue.

The reason I revisit this thread, is when the FRIM tools start and run the many tested avisynth variants and fails to 'see' the output, even though the error process indicates that the avisynth is *working*, because a valid BMP file is created when the error occurs - it seems like AVIsynth is properly starting and working, but not 'sharing' its results with the FRIM tools. How to test this?

I wonder if perhaps there's an environment setting I've missed - perhaps not in the fddshow side, but maybe in a temp-file location, named-pipe setup (I haven't used them), or maybe some 'assumed' avisynth plugin/routine that tries to send the output to FRIMENcode, but fails if that plugin/script isn't available, etc. (I've removed all plugins - my testing AVIsynth is 'naked' - is this OK?)

I've used the frim (1.30) -debug modes, but there is no magic window into how FRIM starts avisynth, and how it gathers and then passes the stream data to the Intel conversion engines. Just the proper BMP on error. It feels so close to working.

Another angle I've experimented with is using ffmpeg's avisynth mode to generate outputs that I think should be readable to my FRIM tools. The files also look reasonable to my eye (media-info/ffprobe), but aren't handled any better (or differently) as uncompressed YUV4:2:0 AVIs, and I don't know how to generate a transport stream (3840x1080 sbs) output that makes FRIMencode happy. I've tried many of the raw outputs and get 600M files from ffmpeg for the MyScript.avs script above, but none of them generate the output I'm hoping for (or expecting).

Questions:

- is there any way to 'see' the avisynth output as FRIMencode sees it, and perhaps see a proper media-info AVS patterns am I looking for

- is there a way to use an ffmpeg/avs script to generate an uncompressed transport stream (rather than an AVI file), that FRIMencode can 'see' and use with less 'resistance'?

- lastly, is the I420 error coming from FRIMEncode, or the Intel engine w FRIMEncode is just passing it on? Is there a way I can directly test the Intel setup with these various raw test files and verify my Intel setup?

(Maybe FRIM is working perfectly and my Intel stuff is partially broken - it *seems* to be working, so I'm not looking there (yet)).

Thanks a bunch for any feedback!

--ms

[videofan3d]

Questions:

- is there any way to 'see' the avisynth output as FRIMencode sees it, and perhaps see a proper media-info AVS patterns am I looking for

- is there a way to use an ffmpeg/avs script to generate an uncompressed transport stream (rather than an AVI file), that FRIMencode can 'see' and use with less 'resistance'?

- lastly, is the I420 error coming from FRIMEncode, or the Intel engine w FRIMEncode is just passing it on? Is there a way I can directly test the Intel setup with these various raw test files and verify my Intel setup?



Q: is there any way to 'see' the avisynth output as FRIMencode sees it
A: FRIM uses old native Windows API from vfw.h: AVIFileOpen(), AVIFileGetStream(), ... , AVIFileRelease()
Thus all AviSynth magic is hidden to it somewhere in background

Q: is there a way to use an ffmpeg/avs script to generate an uncompressed transport stream (rather than an AVI file), that FRIMencode can 'see' and use with less 'resistance'?
A: indeed, ffmpeg can produce raw video in requested format, check its help for all options

(only principle description, but working)

ffmpeg -i inputfile -pix_fmt yuv420p -vcodec rawvideo -an outputfile.yuv

where outputfile.yuv will be in YV12 or I420 (I'm not exactly sure, they differ only by order of UV, VU respectively)

Now, you can connect ffmpeg to FRIM using pipes

ffmpeg -i inputfile -pix_fmt yuv420p -vcodec rawvideo -an pipe:1.yuv | FRIMencode32 -i - -o:h264 output.h264 -w 1920 -h 1080 -f 23.976 [and other FRIM encoding options]

Optionally you could use also named pipes, which is a bit more tricky. The abobe stdout-stdin pipe works as well.

Q: lastly, is the I420 error coming from FRIMEncode, or the Intel engine w FRIMEncode is just passing it on? Is there a way I can directly test the Intel setup with these various raw test files and verify my Intel setup?
A: This error is coming from FRIM, when it requests video stream in I420 chroma format using AVIStreamGetFrameOpen(). When it fails, you get this bitmap.

[videofan3d]

FRIM version 1.31 released

All - build with Intel Media SDK 2019 R1 and MS Visual Studio 2017

FRIMTranscode:
- h265 (HEVC) codec added
- plugin support added with optional parameters:
-iguid decode-GUID-code
-iplugin full-decode-plugin-path-name
-oguid encode-GUID-code
-oplugin full-encode-plugin-path-name

FRIMSource:
- HEVC decoding uses 10-bit processing with AviSynth+

FRIMImport:
FRIMExport:
- HEVC decoding/encoding uses 10-bit processing with Adobe Premiere

[r0lZ]

Thanks, videofan3d !

[SpasV]

Thank you videofan3d for your work.

I am on setting FRIM version 1.31 and couldn't resolve the problem I have. It is seen below - FRIMDecode generates colorless stream.

https://thumbs2.imgbox.com/1d/e8/6FMB94Wl_t.png (http://imgbox.com/6FMB94Wl) https://thumbs2.imgbox.com/18/19/5afxOq57_t.png (http://imgbox.com/5afxOq57)

Command line:
"D:\Program Files\FRIM\x64\FRIMDecode64" -i:h265 "Rambo Last Blood 2019.h265" -o frim(1240).yuv -start 1240 -length 653 -sw

FRIM Decoder version 1.31 - Win64 (build: Mar 8 2020)
- based on Intel(R) Media SDK

Media SDK impl SOFTWARE (D:\Program Files\FRIM\x64\libmfxsw64.dll)
Media SDK version 1.28
Memory type System
Async depth 4

Decoder HEVC

Input picture:
Resolution 3840x2160
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,0,0
Frame rate 23.976
Output picture:
Resolution 3840x2160
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,3840,2160
Frame rate 23.976

Output format P010

Processing started
Frame number: 653
Processing finished in 69.70 seconds

Notes:

The peculiarities:
CPU: Ryzen 3900X, Graphics: NVIDIA 1660S


FRIMDecode64() works the same way without option sw


EDIT
There should be a general problem.
Here is an illustration with FRIMEncode
https://thumbs2.imgbox.com/d6/0c/MAg8jBp7_t.png (http://imgbox.com/MAg8jBp7) https://thumbs2.imgbox.com/9c/49/rJ09OZLU_t.png (http://imgbox.com/rJ09OZLU)