Free H.264 MVC 3D Encoder

[Sharc]

Originally Posted by jdobbs

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]

Originally Posted by 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.

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]

Originally Posted by videofan3d

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]

Originally Posted by colinhunt

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

Originally Posted by videofan3d

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]

Originally Posted by 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)

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

[videofan3d]

Originally Posted by trevorjharris

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

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

[colinhunt]

Originally Posted by Cedvano

version 1.04

Thanks!

[Sharc]

Originally Posted by 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)

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]

Originally Posted by colinhunt

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]

Originally Posted by videofan3d

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.

[frencher]

Originally Posted by 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)

Cool interest update

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]

Originally Posted by Cedvano

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]

Originally Posted by 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.

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.