Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 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?
video264 is offline   Reply With Quote
Old 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.
skampy is offline   Reply With Quote
Old 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.
video264 is offline   Reply With Quote
Old 16th February 2011, 09:32   #4  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,151
Quote:
Originally Posted by video264 View Post
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 16th February 2011, 09:35   #5  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,745
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
Blue_MiSfit is offline   Reply With Quote
Old 16th February 2011, 10:21   #6  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,688
Quote:
Originally Posted by Blue_MiSfit View Post
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)
Dark Shikari is offline   Reply With Quote
Old 16th February 2011, 10:32   #7  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,745
@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

Last edited by Blue_MiSfit; 16th February 2011 at 10:34.
Blue_MiSfit is offline   Reply With Quote
Old 16th February 2011, 12:51   #8  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
http://forum.doom9.org/showthread.php?p=1478432

This might provide what you're looking for.
kieranrk is offline   Reply With Quote
Old 17th February 2011, 04:19   #9  |  Link
Mug Funky
interlace this!
 
Mug Funky's Avatar
 
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
Mug Funky is offline   Reply With Quote
Old 17th February 2011, 04:55   #10  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
Quote:
Originally Posted by Mug Funky View Post
@ 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.
kieranrk is offline   Reply With Quote
Old 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?
video264 is offline   Reply With Quote
Old 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
video264 is offline   Reply With Quote
Old 18th February 2011, 07:51   #13  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,745
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

Last edited by Blue_MiSfit; 18th February 2011 at 07:56.
Blue_MiSfit is offline   Reply With Quote
Old 18th February 2011, 17:18   #14  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
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?

Last edited by kieranrk; 18th February 2011 at 17:35.
kieranrk is offline   Reply With Quote
Old 19th February 2011, 05:49   #15  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,745
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
Blue_MiSfit is offline   Reply With Quote
Old 19th February 2011, 06:08   #16  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
Quote:
Originally Posted by Blue_MiSfit View Post
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.
kieranrk is offline   Reply With Quote
Old 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.
video264 is offline   Reply With Quote
Old 21st February 2011, 04:23   #18  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
Quote:
Originally Posted by video264 View Post
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?

Last edited by kieranrk; 21st February 2011 at 05:02.
kieranrk is offline   Reply With Quote
Reply

Tags
cbr, mux, tsfile

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:29.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.