Free H.264 MVC 3D Encoder

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