Free H.264 MVC 3D Encoder

[Cedvano]

Here the link : 00278.ssif (http://ns5.freeheberg.com/~cedvano/00278.ssif)

[tymoxa]

1. I use eac3to to extract left and right
2. I use FRIMDecode and FRIMencode with pipe for convert
-> Result wrong files because wrong YUV


It's OK for me with this scheme and your sample:
http://savepic.ru/4817123m.jpg (http://savepic.ru/4817123.jpg)

Try this line:
FRIMDecode mvc -i input_L.h264 -i input_R.h264 -o \\.\pipe\test.yuv | FRIMEncode.exe mvc -i \\.\pipe\test_L.yuv -i \\.\pipe\test_R.yuv -viewoutput -o output.avc -o output.mvc -w 1920 -h 1080 -f 23.976 -u 4 -cpbsize 3570 -vbr 30000 40000 -l 6 -profile high -level 4.1 -gop 24 4 0 O

[Cedvano]

With this line, I've the same problem.

Have you compare the YUV files.

It's not all the ssif, I wait for more tests.

[videofan3d]

videofan3d

1. I use eac3to to extract left and right
2. I use FRIMDecode and FRIMencode with pipe for convert
-> Result wrong files because wrong YUV-length

1. I use eac3to and CombineMVC with pipe for 1 file
2. I use FRIMDecode and FRIMencode with pipe to convert
-> Result good file - both L- and R-yuv are of the same length

Can you correct FRIMDecode for the first soluce ?

Thanks

Hi, problem is identified, fix is in progress.

Next release FRIM 1.15 will be available on ~Thursday

[Cedvano]

Hi, problem is identified, fix is in progress.

Next release FRIM 1.15 will be available on ~Thursday

Yes, great ! Thanks.

[videofan3d]

HD4000 hardware decode + hardware encode .

Would be interesting to see if -sw and -hw give the same results. I.e. to encode very short video with the same conditions (bitrate, GOP, slices, ...) using -hw and then -sw.
@colinhunt: Could you conclude such test? ;)

[colinhunt]

Would be interesting to see if -sw and -hw give the same results. I.e. to encode very short video with the same conditions (bitrate, GOP, slices, ...) using -hw and then -sw.
Could you conclude such test? ;)
I actually ran a few tests to see why I got terrible encodes out of using the -hw option. Turns out the output is total garbage if Decoder uses -hw. Encoder can use either -vbr or -labrc with -hw, and the output is fine as long as decoding is done in software. I can run more tests if you give me a list of what you'd like to see.

[videofan3d]

I actually ran a few tests to see why I got terrible encodes out of using the -hw option. Turns out the output is total garbage if Decoder uses -hw. Encoder can use either -vbr or -labrc with -hw, and the output is fine as long as decoding is done in software. I can run more tests if you give me a list of what you'd like to see.

This is interesting - and strange.
Decoding is much simpler than encoding, and I'd expect to get the same results, the same YUV file for both -sw and -hw, byte to byte identical!
(Btw, I compared Intel Media SW decoder output with JM H.264/AVC Reference Decoder from http://iphome.hhi.de/suehring/tml/, and they are really 100% identical - that's good)

For encoding - in theory - if GPU is given the same parameters as CPU, it should be also identical.
But I can imagine that GPU routines have different implementation than corresponding C-routines in SW mode. Which will lead to different DCT encoding and resulting .h264 videofile will be different (but visually it should be similar).

Would be nice (I believe interesting for everyone) if you could upload 10-20 second sample of HD video (~16 mbit) encoded with same parameters in -sw and -hw mode. :)

[colinhunt]

Would be nice (I believe interesting for everyone) if you could upload 10-20 second sample of HD video (~16 mbit) encoded with same parameters in -sw and -hw mode. :)
I will, once I've cleared my current workload. It'll be a few days.

[videofan3d]

Hi,

FRIM 1.15 is available.

Changes:

FRIM Encoder 1.15
- avi/avs encoding - reports now a bit more detailed error information.
- new feature: CQP bitrate control mode added: [ -cqp QPI QPP QPB ]

FRIM Decoder 1.15
- fixed bug with wrong YUV-file length of decoded MVC
- new feature: MVC - both output filenames (L,R) can be specified by user

FRIM Transcoder 1.15
- added detailed parameters/options like in FRIM Encode (!)
- added base+dependent input for MVC

[tymoxa]

videofan3d
Thanks a lot!
Is possible to limit maximum bitrate in CQP mode? Like:
-cqp QPI QPP QPB maxrate

[Sharc]

Hi,

FRIM 1.15 is available.

Changes:

FRIM Encoder 1.15
- avi/avs encoding - reports now a bit more detailed error information.
- new feature: CQP bitrate control mode added: [ -cqp QPI QPP QPB ]

FRIM Decoder 1.15
- fixed bug with wrong YUV-file length of decoded MVC
- new feature: MVC - both output filenames (L,R) can be specified by user

FRIM Transcoder 1.15
- added detailed parameters/options like in FRIM Encode (!)
- added base+dependent input for MVC

Wow! :thanks:

[frencher]

Hi,

FRIM 1.15 is available.

Changes:

FRIM Encoder 1.15
- avi/avs encoding - reports now a bit more detailed error information.
- new feature: CQP bitrate control mode added: [ -cqp QPI QPP QPB ]

FRIM Decoder 1.15
- fixed bug with wrong YUV-file length of decoded MVC
- new feature: MVC - both output filenames (L,R) can be specified by user

FRIM Transcoder 1.15
- added detailed parameters/options like in FRIM Encode (!)
- added base+dependent input for MVC

Yeah, very nice update videofan3d ;)

One idea of CMD Line for use avstoyuv with FRIMEncode:
avs2yuv.exe (Script.avs) > FRIMEncode.exe

Same problem of black frames with (Left.mkv and Right.mkv = AVC) idea :confused:
L = DirectShowSource("H:\Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("H:\Right.mkv", audio=FALSE, video=TRUE)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V

[videofan3d]

Same problem of black frames with (Left.mkv and Right.mkv = AVC) idea :confused:
L = DirectShowSource("H:\Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("H:\Right.mkv", audio=FALSE, video=TRUE)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V

Please try to modify your script:

L = DirectShowSource("H:\Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("H:\Right.mkv", audio=FALSE, video=TRUE)
L=ShowSMPTE(L,size=100)
R=ShowSMPTE(R,size=100)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V

What do you see on output?

[Cedvano]

Thank you very much Videofan3d.

Edit: FRIMTRanscode does not support Pipe ?

[videofan3d]

FRIMTRanscode does not support Pipe ?

No. Core Intel Media routines read video-bitstream twice (for header detection, and then for processing itself). This disables using pipes which are unidirectional by their nature.

Neither FRIMDecode cannot have pipe on its input, and FRIMEncode on its output.

[videofan3d]

Btw. named pipes can be used also on local network between computers. In principle you could use:

Computer 1 named e.g. comp001:

FRIMDecode h264 -i input.h264 -o \\.\pipe\pipeA


and then start on Computer 2 another session:

FRIMEncode h264 -i \\comp001\pipe\pipeA -o output.h264



(I couldn't test it having no network at home...)

[frencher]

Please try to modify your script:

L = DirectShowSource("H:\Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("H:\Right.mkv", audio=FALSE, video=TRUE)
L=ShowSMPTE(L,size=100)
R=ShowSMPTE(R,size=100)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V

What do you see on output?

Hi videofan3d,

I have tested your version 1.15 with AVS:
L = DirectShowSource("Left.mkv", audio=FALSE, video=TRUE)
R = DirectShowSource("Right.mkv", audio=FALSE, video=TRUE)
L = ShowSMPTE(L,size=100).ShowFrameNumber(x=50,y=80,size=30)
R = ShowSMPTE(R,size=100).ShowFrameNumber(x=50,y=80,size=30)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V
and
"FRIMEncode.exe" mvc -i "3D.AVS" -avi -sbs 2 -viewoutput -o "H:\L.h264" -o "H:\R.h264" -w 1920 -h 1080 -f 23.976 -b 40000 -u 7

Here is what gives me FRIMencode and x264 with same AVS script

Download: FRIMEncode VS x264.rar (http://ul.to/zwlh1jsc)

Thanks for works and interest ;)

[videofan3d]

Hi videofan3d,

I have tested your version 1.15 with AVS:
...
L = ShowSMPTE(L,size=100).ShowFrameNumber(x=50,y=80,size=30)
R = ShowSMPTE(R,size=100).ShowFrameNumber(x=50,y=80,size=30)
V = StackHorizontal(L,R)
V = V.ConvertToYV12()
Return V



This is strange - I don't understand it.

In parallel I created and encoded a synthetic clip using FRIM Encode 1.15 a with length 20 (!) minutes:


ClipLength=28800
L=Blankclip (length=ClipLength, width=1920, height=1080, fps=23.976, color=16711680)
R=Blankclip (length=ClipLength, width=1920, height=1080, fps=23.976, color=255)
L=ShowSMPTE(L)
R=ShowSMPTE(R)
StackHorizontal(L,R)
ConvertToYV12()


... and succesfully - no glitch on left nor right eye.
I'm using Avisynth version 2.60 (alpha "whatever") - because of ffmpeg 2.1

Please try to arrange the same test - I'd like to understand where is problem...

[frencher]

This is strange - I don't understand it.

In parallel I created and encoded a synthetic clip using FRIM Encode 1.15 a with length 20 (!) minutes:


ClipLength=28800
L=Blankclip (length=ClipLength, width=1920, height=1080, fps=23.976, color=16711680)
R=Blankclip (length=ClipLength, width=1920, height=1080, fps=23.976, color=255)
L=ShowSMPTE(L)
R=ShowSMPTE(R)
StackHorizontal(L,R)
ConvertToYV12()


... and succesfully - no glitch on left nor right eye.
I'm using Avisynth version 2.60 (alpha "whatever") - because of ffmpeg 2.1

Please try to arrange the same test - I'd like to understand where is problem...

FIXED
Avisynth 2.5.8 stable version have some problem with YUV.
Now fixed with AviSynth 13-09-18 2.6.0 Alpha 5 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) works perfectly. :cool:
I recode full lenght of large video for test :rolleyes:

It's possible to add x frame of total frame, remaining time, percentage, etc... ?

Thanls for your big works.

[HWK]

FIXED
Avisynth 2.5.8 stable version have some problem with YUV.
Now fixed with AviSynth 13-09-18 2.6.0 Alpha 5 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) works perfectly. :cool:
I recode full lenght of large video for test :rolleyes:

It's possible to add x frame of total frame, remaining time, percentage, etc... ?

Thanls for your big works.

It's kind of funny I had same problem when I used avisynth, color info in yuv file was messed up. However when I used raw yuv file it worked without any issues. I also tried with pipe and it worked as well. Only thing i notice is vbr go too much under size. I have to do more checking on that.

To conclude I would like to say thank you to videofan3d and Intel for making it possible for the masses and off course to those who find bugs in program.

[videofan3d]

FIXED
Avisynth 2.5.8 stable version have some problem with YUV.
Now fixed with AviSynth 13-09-18 2.6.0 Alpha 5 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) works perfectly. :cool:


Apparently it is some bug in Avisynth or VFW API (or both in coincidence).

Anyway, I'll try to workaround it by slightly different reading of AVI/AVS in 3D mode. In next release....

[Cedvano]

FRIMTranscode can output 2 separates files ? If no, can you put this function ?
Thanks for your answer.

[frencher]

Apparently it is some bug in Avisynth or VFW API (or both in coincidence).

Anyway, I'll try to workaround it by slightly different reading of AVI/AVS in 3D mode. In next release....

Very good news :thanks:

[videofan3d]

FRIMTranscode can output 2 separates files ? If no, can you put this function ?
Thanks for your answer.

Not at this moment.
But tsMuxer 2.1.8 already accepts combined AVC+MVC, so it is not any practical limitation.

[Cedvano]

Not at this moment.
But tsMuxer 2.1.8 already accepts combined AVC+MVC, so it is not any practical limitation.

Yes, but you think that the same quality ?
And for the frame number, how work the "point" ?

[videofan3d]

Yes, but you think that the same quality ?
And for the frame number, how work the "point" ?

Not sure I understand your question.

tsMuxer is only multiplexing elementary streams, without modifying it. No impact to "quality".
combined AVC+MVC is only "mixed" separated AVC and MVC, technically shuffled "NAL units" in certain sequence.
It doesn't matter if you will mux BD-structure from separated AVC and MVC, or from combined AVC+MVC. result is the same. You can easily test it.

[Cedvano]

Thanks for your answer, I thought it was best to go through YUV. After which testing is the same.

I only regret that displays "points" instead of the number of frames.

[videofan3d]

I only regret that displays "points" instead of the number of frames.

FRIM Transcoder operates in multisession (which is in general independednt multi-processing), thus number of frames is not relevant, each session is different.... (and one small hint: each dot is 100 encoded frames ;) )

Btw. multisession via -o::sink and -i::source is great for bitrate quality comparison. You can create several outputs with different bitrate or gop structure in one batch and then easily compare results.

[trevorjharris]

Cannot get it to work with the latest version of avisynth.

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

yuv raw files work fine

[frencher]

Cannot get it to work with the latest version of avisynth.

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

yuv raw files work fine

FIXED
Avisynth 2.5.8 stable version have some problem with YUV.
Now fixed with AviSynth 13-09-18 2.6.0 Alpha 5 (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/) works perfectly. :cool:
Try this

[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

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 Pacific_Rim_AVC.264 -o Pacific_Rim_MVC.264 -w 1920 -h 1080 -f 23.976 -u 1 -cpbsize 3570 -l 6 -vbr 19540 60000 -profile high -level 4.1 -gop 24 4 0 S -maxdpb 4

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

[Cedvano]

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.

Me, I have see increase size with version 1.15.

Can I have your calcul for Bitrate ?

[HWK]

Me, I have see increase size with version 1.15.

Can I have your calcul for Bitrate ?

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.

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



23.3 GB
Here are my calculation result

Subtitle + DTS 7.1 Audio = 2.82GB
Subtitle + DTS 7.1 Audio + Muxinng Overhead = 4.68

23.3 - 4.68 = 18.62 GB Video


2H, 11M, 17S video bit-rate = 20304kbps after factoring in overhead.

20304Kbps

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.

[Sharc]

@HWK
in my maths:
18.62GB = 19'067MB = 19'524'485kB = 156'195'881kbit
video duration = 7'877 sec
156'195'881kbit/7'877sec = 19'829kbit/s

[HWK]

@HWK
in my maths:
18.62GB = 19'067MB = 19'524'485kB = 156'195'881kbit
video duration = 7'877 sec
156'195'881kbit/7'877sec = 19'829kbit/s

You are right, I just checked encoder values indeed correct (19540, leave some room for error) But text file where I put all the information some how manage to get higher number.

Still resize is an issue for me, I am still trying to figure out why.

[Cedvano]

It's strange, I don't have this problem. I use Bitrate Calculator GPL and All my video are correct. (with max bitrate 48000)

[Sharc]

Still resize is an issue for me, I am still trying to figure out why.
I don't know the details of the Intel encoder, but perhaps encoder saturation comes into play at these high bitrates?
I have not seen undersize for my (usually much lower) bitrates.

[HWK]

I don't know the details of the Intel encoder, but perhaps encoder saturation comes into play at these high bitrates?
I have not seen undersize for my (usually much lower) bitrates.

I am thinking you are right, I also have mainconcept MVC encoder and every time I encode with it, target size is reached. Also I set bitrate 30928Kbps, but during preview I notice it is averaging around 15 Mbps or so with change in bitrate much more drastic than other encoders and maybe this might explain what is happening.

After all it's doing in VBR so may be that is expected from encoder :cool:

[HWK]

It's strange, I don't have this problem. I use Bitrate Calculator GPL and All my video are correct. (with max bitrate 48000)

I use Bitrate Calculator GPL as well and for some reason things are different, well I guess change is good thing :D
Also you do know you can go up to 60000 max rate combined, I use all the time and encoder is smart enough to split bitrate correctly. For example base view bitrate never go above 40Mbps, peaks not included.

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

[HWK]

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"

It failed for me as well, I also tried with avisynth with 2.6.0 Alpha 5. I just use pipe and for me it works very well.

[HWK]

I don't know the details of the Intel encoder, but perhaps encoder saturation comes into play at these high bitrates?
I have not seen undersize for my (usually much lower) bitrates.

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.

[Cedvano]

I've test with BRAVE and I would like 18GB and I have 16,2 GB.

[HWK]

I've test with BRAVE and I would like 18GB and I have 16,2 GB.

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.

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

[HWK]

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

[swallace]

@HWK

Just out of curiosity: does changing the GOP length, or leaving it at default, have any effect on the output bitrate?

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

[HWK]

@HWK

Just out of curiosity: does changing the GOP length, or leaving it at default, have any effect on the output bitrate?

Yes, it does. If it is open gop it will increase compression efficiency and less bitrate is need to achieve same quality.