x264 constant bitrate coding

video264 · 16th February 2011, 06:53

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 · 16th February 2011, 07:14

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 · 16th February 2011, 08:24

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 · 16th February 2011, 09:32

Quote:

Originally Posted by video264

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 · 16th February 2011, 09:35

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 · 16th February 2011, 10:21

Quote:

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

x264 can do that too though, if you're in an insane enough situation to require it (read: writing a VNC application/Onlive clone)

Blue_MiSfit · 16th February 2011, 10:32

@Dark_Shikari:

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

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

Code:

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

Derek

kieranrk · 16th February 2011, 12:51

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

This might provide what you're looking for.

Mug Funky · 17th February 2011, 04:19

@ 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 · 17th February 2011, 04:55

Quote:

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

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 · 18th February 2011, 02:35

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 · 18th February 2011, 04:33

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/44853241..._output_ts.JPG

Blue_MiSfit · 18th February 2011, 07:51

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 · 18th February 2011, 17:18

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 · 19th February 2011, 05:49

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 · 19th February 2011, 06:08

Quote:

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

"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 · 21st February 2011, 03:21

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 · 21st February 2011, 04:23

Quote:

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

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?

16th February 2011, 06:53	#1 \| Link
video264 Registered User Join Date: Jan 2011 Posts: 5	x264 constant bitrate coding 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?

16th February 2011, 07:14	#2 \| Link
skampy Registered User Join Date: Feb 2011 Posts: 16	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. Last edited by skampy; 16th February 2011 at 07:23.

16th February 2011, 09:35	#5 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 5,989	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 __________________ These are all my personal statements, not those of my employer :)

16th February 2011, 10:32	#7 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 5,989	@Dark_Shikari: Very true! Am I on the right track by specifying single frame VBV? (Example for 24p at 3mbps REAL OMG CBR) Code: --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 Derek __________________ These are all my personal statements, not those of my employer :) Last edited by Blue_MiSfit; 16th February 2011 at 10:34.

16th February 2011, 12:51	#8 \| Link
kieranrk Registered User Join Date: Jun 2009 Location: London, United Kingdom Posts: 707	http://forum.doom9.org/showthread.php?p=1478432 This might provide what you're looking for. __________________ Authoring Professional Blu-rays with x264 - Open Broadcast Encoder

16th February 2011, 08:24	#3 \| Link
video264 Registered User Join Date: Jan 2011 Posts: 5	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.

17th February 2011, 04:19	#9 \| Link
Mug Funky interlace this! Join Date: Jun 2003 Location: i'm in ur transfers, addin noise Posts: 4,555	@ 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! __________________ sucking the life out of your videos since 2004

18th February 2011, 02:35	#11 \| Link
video264 Registered User Join Date: Jan 2011 Posts: 5	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?

18th February 2011, 04:33	#12 \| Link
video264 Registered User Join Date: Jan 2011 Posts: 5	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/44853241..._output_ts.JPG

18th February 2011, 07:51	#13 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 5,989	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 __________________ These are all my personal statements, not those of my employer :) Last edited by Blue_MiSfit; 18th February 2011 at 07:56.

18th February 2011, 17:18	#14 \| Link
kieranrk Registered User Join Date: Jun 2009 Location: London, United Kingdom Posts: 707	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? __________________ Authoring Professional Blu-rays with x264 - Open Broadcast Encoder Last edited by kieranrk; 18th February 2011 at 17:35.

19th February 2011, 05:49	#15 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 5,989	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 __________________ These are all my personal statements, not those of my employer :)

21st February 2011, 03:21	#17 \| Link
video264 Registered User Join Date: Jan 2011 Posts: 5	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.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode