Free H.264 MVC 3D Encoder

[HWK]

Originally Posted by Sharc

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

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

[Sharc]

Originally Posted by HWK

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]

Originally Posted by Sharc

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]

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

Originally Posted by HWK

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.

Originally Posted by HWK

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.

Originally Posted by HWK

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.

Originally Posted by videofan3d

Regarding bitrate:

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

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

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

Originally Posted by HWK

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 Basically it is the workflow which I am using is issue over here.

[Cedvano]

You double the bitrate ?

[Sharc]

Originally Posted by HWK

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]

Originally Posted by Cedvano

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]

Originally Posted by trevorjharris

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

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

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]

Originally Posted by jdobbs

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]

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

I couldn't manage it as well , 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]

Originally Posted by jdobbs

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

Originally Posted by jdobbs

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]

Originally Posted by Sharc

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]

Originally Posted by Sharc

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

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.

[HWK]

Originally Posted by jdobbs

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

Originally Posted by jdobbs

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

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

[jdobbs]

Originally Posted by HWK

Jdobbs, Prehaps this post applies to your problem as well

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]

Originally Posted by HWK

Jdobbs, Prehaps this post applies to your problem as well

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

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

[HWK]

Originally Posted by jdobbs

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]

Originally Posted by frencher

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