View Full Version : Free H.264 MVC 3D Encoder
videofan3d
30th October 2013, 10:33
(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
30th October 2013, 11:49
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
30th October 2013, 11:53
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
30th October 2013, 11:58
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
30th October 2013, 12:00
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
30th October 2013, 12:03
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
30th October 2013, 12:06
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
30th October 2013, 12:10
- .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
30th October 2013, 12:49
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
30th October 2013, 12:55
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
30th October 2013, 13:05
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
30th October 2013, 15:40
Same here using AVI, YUV , AVS
always get
Error: Unknown codec
FRIMEncode h264 –avi -i bars.avs -o bars.h264 -b 24000
tymoxa
30th October 2013, 16:58
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
30th October 2013, 19:09
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
30th October 2013, 21:56
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
30th October 2013, 22:29
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
30th October 2013, 22:34
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
30th October 2013, 22:48
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
30th October 2013, 23:20
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
30th October 2013, 23:23
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
30th October 2013, 23:24
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
30th October 2013, 23:32
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
30th October 2013, 23:33
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
31st October 2013, 20:17
So if I want to test this, how do I get from a BD3D to a file I can feed to the encoder?
HWK
31st October 2013, 20:38
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
31st October 2013, 21:11
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
31st October 2013, 23:22
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
31st October 2013, 23:55
Rapid package for test (http://ul.to/d74yc5mw) ;)
tymoxa
1st November 2013, 00:09
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
1st November 2013, 00:46
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
1st November 2013, 01:13
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
1st November 2013, 02:48
Why dont use FRIMTranscode.exe with both output: output_L.h264 and output_R.h264
tymoxa
1st November 2013, 09:48
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
1st November 2013, 11:22
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
1st November 2013, 12:15
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
1st November 2013, 13:34
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
1st November 2013, 14:30
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
1st November 2013, 18:30
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
1st November 2013, 18:39
tymoxa provide me combined AVC+MVC track example. I am going to support such tracks in tsMuxeR during weekend.
videofan3d
1st November 2013, 18:45
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
1st November 2013, 21:11
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
2nd November 2013, 11:02
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
3rd November 2013, 21:32
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
4th November 2013, 21:30
: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
4th November 2013, 22:37
: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
4th November 2013, 23:43
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
4th November 2013, 23:49
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
4th November 2013, 23:58
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
5th November 2013, 01:08
OK
Recode in progress of two large videos for test, i send my report when i done ;)
HWK
5th November 2013, 03:28
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
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.