x264 constant bitrate coding

[video264]

I need to create CBR stream in TS format. Firstly, I use x.264 to generate .mp4 file with CBR setting, then using TSmuxR to add in PCR info and packet into TS format. However, I found instead of stable bitrate, the output stream bitrate varies second by second.

I know CBR setting is very old question but I still need guidance. Is it something wrong during TS mux phrase?

[skampy]

Why would you want to encode a video with a constant (ie. unchanging) bit rate (unless it were simply a series of static images/backgrounds)? Are you talking about QP mode which targets a constant 'quality' instead? Or are you confusing 1 or 2 pass VBR which targets an average bit rate?

Don't quote me on this, but if you want to do that use 1 or 2pass mode and set qcomp to 0.

[video264]

Hi skampy, why CBR? simply because I will use the stream in broadcasting application (although broadcasting gradually allow VBR to be used in live transmission, while CBR still being the mainstream).

In x.264 setting, I used to write command line as follows:
x264 --tff --interlaced --bitrate 6999 --vbv-maxrate 6999 --vbv-bufsize 6999 --pass 1 -o blablabla xxxx

The encode result shows bitrate variation is small, however, once I remux into TS, the video bitrate become dynamic/variant (checking by TS analyser).

Something must be going wrong either in x264 or TS muxer.. I understand there is no absolute CBR in h.264, what I request for is just small variation which can be treat as CBR.

thanks.

[LoRd_MuldeR]

Hi skampy, why CBR? simply because I will use the stream in broadcasting application

Then you don't want CBR, but VBV.

In this scenario the VBV-Maxrate will be defined by your network bandwidth, VBV-BuffSize will be defined by the size of the buffer of the playback device/software...

[Blue_MiSfit]

Hi video264,

A few thoughts - but take these with a grain of salt. I didn't write the code. This is just how I understand it.

1) CBR in x264 is not "true" CBR - in the sense of every frame being the same size. Instead, when you set bitrate, maxrate, and bufsize to equal values, x264's VBV model will guarantee that over a period of one second, your bitrate will be no more than the given value.

2) If you must "fill the mux" so to speak, then you can add --nal-hrd cbr, which will pad the stream.

3) I'd strongly suggest you don't use tsmuxer. It's not remotely compliant. obe-vod is a fantastic new piece of kit that combines x264 with a validated ts muxer, provided by libmpegts

Cheers,
Derek

[Dark Shikari]

Hi video264,

A few thoughts - but take these with a grain of salt. I didn't write the code. This is just how I understand it.

1) CBR in x264 is not "true" CBRx264 can do that too though, if you're in an insane enough situation to require it (read: writing a VNC application/Onlive clone) :p

[Blue_MiSfit]

@Dark_Shikari:

Very true! Am I on the right track by specifying single frame VBV?

(Example for 24p at 3mbps REAL OMG CBR)

--bitrate 3000 --vbv-maxrate 3000 --vbv-bufsize 125 --nal-hrd cbr


If I recall correctly, one of the nice consequences in doing so is that you bring overall latency way down... right? Not quite up to --tune zerolatency, of course ;)

Oh, also, @video264: it's x264, not x.264 :devil:

Derek

[kieranrk]

http://forum.doom9.org/showthread.php?p=1478432

This might provide what you're looking for.

[Mug Funky]

@ kierank: the speed control has officially blown my mind.

now i just need to set --preset placebo and set the speed to whatever my needs are.

now quality can actually be determined by CPU speed :)

would it be possible to include a mode that allowed muxing only without encoding? or would that be better served by libmpegts and i should be patient?

great work!

[kieranrk]

@ kierank: the speed control has officially blown my mind.

now i just need to set --preset placebo and set the speed to whatever my needs are.

now quality can actually be determined by CPU speed :)

would it be possible to include a mode that allowed muxing only without encoding? or would that be better served by libmpegts and i should be patient?

great work!

The preset is ignored in speedcontrol mode because speedcontrol has hardcoded presets. I wouldn't recommend using it unless you're particularly in need of it. It just happens to be there because I'm using the same libx264 for VoD and realtime.

From what I gather it isn't possible to make a spec compliant mux without having buffering data from the encoder or derived from an incoming transport stream that is being remuxed. This is because of a bug in the MPEG-TS spec that were fixed quite a long time after publication. Having said that it's unlikely to cause a problem in the real world but I have seen one example that failed on a stream analyzer because the analyzer was using the bugged version of the spec.

[video264]

Hi Derek,

Thanks for your answer, I am ready to have a try on obe-vod beta v0.2!

BTW, regarding to Frame-packing option is x264, has it been accepted by DVB as part of its 3DTV Phrase 1 standards?

[video264]

Hi Derek, Kieranrk
Using obe-vod beta 0.2 with command line (modified bitrate based on command example from obe wiki for 1080p/25):
------------------------------------
obe-vod input.avs --fps 25/1 --profile high --level 4.0 --fake-interlaced --no-interlaced --nal-hrd fakevbr --vbv-maxrate 6900 --vbv-bufsize 2500 --bitrate 6900 --keyint 12 --weightp 1 --open-gop normal --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --pass 1 -o NUL

obe-vod input.avs --fps 25/1 --profile high --level 4.0 --fake-interlaced --no-interlaced --nal-hrd fakevbr --vbv-maxrate 6900 --vbv-bufsize 2500 --bitrate 6900 --keyint 12 --weightp 1 --open-gop normal --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --pass 2 --ts-muxrate 7500000 --ts-cbr --ts-type dvb -o out.ts
-------------------------------------
Results:
Variation of output bitrate is still significant. Setting 6.9Mb/s, output vary from 6.5Mb/s to 7.5Mb/s.
Using same clip, benchmarking with MainConcept reference 1.6, output bitrate is rather flat, keep at 6.95Mb/s.

Any suggestion to make it stable? Thanks!

Bitrate analysis result using TS analyzer:
captured picture can be downloaded from:
http://rapidshare.com/files/448532412/obe-vod_output_ts.JPG
http://rapidshare.com/files/448532412/obe-vod_output_ts.JPG

[Blue_MiSfit]

Try adding --ts-cbr.

Can you post that image somewhere else?

What exactly are you trying to accomplish? x264 is vbv compliant so if you specify a maxrate, x264 will never exceed this number of bits in any given second.

If you absolutely must have a perfectly flat bitrate (i.e. each frame the same exact size), then you need single frame VBV... I think. :) I'm not an expert in this regard.

What kind of application is this for?

Derek

[kieranrk]

If you want strict CBR with stuffing in the video layer you need to replace "--nal-hrd fakevbr" to "--nal-hrd fakecbr". However, it is recommended to stuff at the transport stream layer with --ts-cbr.

The underlying H.264 stream is VBV and HRD compliant with your settings. However, at the transport stream layer the muxer is allowed to make use of the available bitrate a little. Could you tell me if there are any other warnings in your analyzer?

[Blue_MiSfit]

I'd always wondered if there was a distinction between stuffing at the video level and the transport level.

Can you explain the distinction between --nal-hrd fakecbr/fakevbr versus cbr/vbr? I'm quite curious!

Derek

[kieranrk]

I'd always wondered if there was a distinction between stuffing at the video level and the transport level.

Can you explain the distinction between --nal-hrd fakecbr/fakevbr versus cbr/vbr? I'm quite curious!

Derek

"fake" doesn't actually write any HRD syntax elements apart from an empty buffering period sei. This allows easier ts muxing and is what most "pro" encoders do.

[video264]

Hi Derek, "--ts-cbr" was indeed in the command line.

Hi Kieranrk, I try with "--fakecbr", the symptom is same. The variation of output bitrate is still wide (+/- 1.1Mb/s). I am using "--nal-hrd fakecbr" and "--ts-cbr" together, it should be OK right? these two options are not mutual exclusive, right?

I am using Tektronix MTS430 TS analyzer, there is no warning message for TR101290 level1&2 compliance check except the bitrate variation.

[kieranrk]

Hi Derek, "--ts-cbr" was indeed in the command line.

Hi Kieranrk, I try with "--fakecbr", the symptom is same. The variation of output bitrate is still wide (+/- 1.1Mb/s). I am using "--nal-hrd fakecbr" and "--ts-cbr" together, it should be OK right? these two options are not mutual exclusive, right?

I am using Tektronix MTS430 TS analyzer, there is no warning message for TR101290 level1&2 compliance check except the bitrate variation.

This is the first analyzer to complain about this but I can try to fix it if you want.

It really hinges on what is being referred to as CBR:

The underlying video stream. --nal-hrd fakecbr this makes the underlying video stream strict CBR.

The rate at which the video stream is delivered to the T-STD. I always thought this could vary somewhat as long as the buffers didn't over or underflow. No other analyzers or devices have complained about this so far but I will make it and option to turn or off.

The overall transport stream itself can be CBR which is what --ts-cbr does.

What is the particular clause of TR101290 it is complaining about?
Could you also try muxing some CBR audio (such as ac3) and see what the analyzer says about that?