Free H.264 MVC 3D Encoder

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