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 14th February 2007, 15:33   #1  |  Link
DocAliG
MPEG Member
 
Join Date: Oct 2006
Posts: 39
Straight CBR mode

Hi all,

As i started to use x264, i've tested some parameters to obtain a straight CBR encoded video. But the result has been quite different, the instant bitrate is not really straight.

I was wondering if i missed something in the RD alg. or simply if x264 has not been designed for straight CBR.
In the first case: can you enlight me?
In the second case, i was wondering (yes, again) if something has been schedule for this or if it's an opened issue left for the good will....

Thank you all,

Doc.
DocAliG is offline   Reply With Quote
Old 14th February 2007, 19:24   #2  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
VBV is working.
If you mean, frames don't all have exactly the same size, then x264 doesn't try to do that and I don't know any other modern codecs that support it either, because it's just not useful.

Last edited by akupenguin; 14th February 2007 at 19:52.
akupenguin is offline   Reply With Quote
Old 14th February 2007, 20:54   #3  |  Link
DarkZell666
aka XaS
 
DarkZell666's Avatar
 
Join Date: Jun 2005
Location: France
Posts: 1,122
Quote:
i've tested some parameters to obtain a straight CBR encoded video
Which parameters exactly ? Apart from turning --qcomp and --ratetol right down to 0, there isn't much you can do.

Setting --vbv-maxrate and --vbv-bufsize to the same value as your target bitrate would help (though I'm not too sure about the buffer's size meaning in fact ).

Anyhow, as akupenguin said, this will only size of the frames in order to use <your_bitrate_here> kbits per second, not <your-bitrate-here>/<video_fps> kbits per frame.

Edit: setting --qpstep to a higher value (ex: 10) will help you get closer to CBR, but is likely to be useless or lead to useless artifacts.
__________________

Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS
DarkZell666 is offline   Reply With Quote
Old 15th February 2007, 16:14   #4  |  Link
DocAliG
MPEG Member
 
Join Date: Oct 2006
Posts: 39
Quote:
Originally Posted by akupenguin View Post
VBV is working.
If you mean, frames don't all have exactly the same size, then x264 doesn't try to do that and I don't know any other modern codecs that support it either, because it's just not useful.
Ahhh.... Sometimes, applications require such (i agree) strange constraint. I know that the first goal is to store, but x264 is such a good codec (also because avc/h264 is a very good norm, eh eh), that people wants to use it for any applications.

On the other hand, some modern codecs do have straight CBR.... I won't go into details here.
Thanks anyway for the tips. I'll try, and, if it's not sufficient, implement my own strange RDO mode


Doc.
DocAliG is offline   Reply With Quote
Old 15th February 2007, 16:23   #5  |  Link
DocAliG
MPEG Member
 
Join Date: Oct 2006
Posts: 39
Quote:
Originally Posted by DarkZell666 View Post
Which parameters exactly ? Apart from turning --qcomp and --ratetol right down to 0, there isn't much you can do.

Setting --vbv-maxrate and --vbv-bufsize to the same value as your target bitrate would help (though I'm not too sure about the buffer's size meaning in fact ).
Thank you DarkZell666, the vbv options are precisely what i tried to use.... anyway, even when we try to get closer to a straight CBR line, it seems that locally, the bitrate still varying quite much.

Thanks anyway, i'll try the --qstep to higher values.

Doc.
DocAliG is offline   Reply With Quote
Old 15th February 2007, 21:53   #6  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
But why would you want a "straight CBR line", and are you sure it's varying more than you asked it to?
akupenguin is offline   Reply With Quote
Old 16th February 2007, 12:54   #7  |  Link
DocAliG
MPEG Member
 
Join Date: Oct 2006
Posts: 39
Quote:
Originally Posted by akupenguin View Post
But why would you want a "straight CBR line", and are you sure it's varying more than you asked it to?
Actually, when i say "straight CBR line" is to avoid "saw" behavior, because my application is working on particular network that makes everything above a given line quite costly. And it's always better to use the available bitrate at 100%. But in my case, not 105%. And because the given bitrate is not that much, i don't want to use it 95%..... In other words, optimize the global video encoding from the beginning to the end to have "the best" or at least, "one of the possibily best" tradeoff that's possible to have. I've checked some IEEEs, but still, i think the best way is to ask first, and get dirty after. No need to re invent the wheel....

From my point of view, this type of encoding will become more and more popular.... And would promote a little more x264.

When i tried to use x264 with very constrained vbv parameters, the encoder behavior starts to be fuzzy, non logic. it can over/under consumes bits which still looks like a very constrained VBR than a purely CBR.

If you can find some minutes just to estimate the time it would take to modify x264 source to achieve such RDO mode, that would be a great help for me....

Anyway, thank you again,

BR,
Doc.
DocAliG is offline   Reply With Quote
Old 16th February 2007, 13:49   #8  |  Link
kwtc
Registered User
 
Join Date: Sep 2004
Location: Yvelines
Posts: 30
What you are asking for is CBR. In CBR, if you start streaming at the right moment (depends on your vbv settings), you will always be able to stream (no underflow) at the given bitrate (no overflow).
kwtc is offline   Reply With Quote
Old 16th February 2007, 14:07   #9  |  Link
DarkZell666
aka XaS
 
DarkZell666's Avatar
 
Join Date: Jun 2005
Location: France
Posts: 1,122
The bottom line is here:
Quote:
because my application is working on particular network that makes everything above a given line quite costly.
But the streaming process and the encoding process isn't the same thing at all. Streaming a simili-CBR video stream at constant bitrate (say 64kBytes/s over a 512kbps ADSL line) is better than wanting to encode the video at precisely 20,48 bits/frame and streaming it as-is. You'll have to explain a bit more of your restrictions if you want further advice, since your case is rather particular.
__________________

Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS
DarkZell666 is offline   Reply With Quote
Old 16th February 2007, 16:49   #10  |  Link
DocAliG
MPEG Member
 
Join Date: Oct 2006
Posts: 39
to kwtc: yes, that's exactly what i'm asking. CBR. And my case it's true, is rather particular.
Let's forget encoding and decoding for a while. Let's focus on network. If the network have no tolerance to sending data faster, or supporting more date, not because it's limited, but more likely because any supplementary bit you have to transmit above the given line costs a lot, then, you have to take advantages of all the resources available, without losing anything. That's where the CBR mode is relevant. And after getting a constrained encoded content with x264, passed it through the instant bitrate graph, it is clear that the sometimes, the rate is under the line, sometimes, above. My question is on this behavior.


Quote:
Originally Posted by DarkZell666 View Post
The bottom line is here:

But the streaming process and the encoding process isn't the same thing at all.
True. But i've never mentioned anything about streaming, did i ?....


Quote:
Originally Posted by DarkZell666 View Post
Streaming a simili-CBR video stream at constant bitrate (say 64kBytes/s over a 512kbps ADSL line) is better than wanting to encode the video at precisely 20,48 bits/frame and streaming it as-is. You'll have to explain a bit more of your restrictions if you want further advice, since your case is rather particular.
I know, and i would really like to expose everything to be much more clearer than just generic. But no choices

Let's say, it's not streaming, it's a particular network (i didn't say anything, but clues...) that requires a straight CBR. And i would rather stream something using x264 as it, because it's a great encoder, and much more efficient that way, but it's simply not feasible. The only way to have this "simulated CBR" is to encode the video in constrained chunks (with vbv options). That's not efficient..... But that's the only way to not pass the (dead) line

Doc
DocAliG is offline   Reply With Quote
Old 16th February 2007, 17:03   #11  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
The problem is, you don't know what CBR ( as defined by the standard ) is.

CBR doesn't mean every frame will have the same size. CBR means that, provided you can buffer a definite amount of data prior to stream it, you can stream that data at a perfect constant rate, without the buffer to empty nor fill completely.

CBR in x264 allows the buffer to empty, but should prevent it from filling.
__________________
Manao is offline   Reply With Quote
Old 16th February 2007, 17:26   #12  |  Link
DocAliG
MPEG Member
 
Join Date: Oct 2006
Posts: 39
Quote:
Originally Posted by Manao View Post
The problem is, you don't know what CBR ( as defined by the standard ) is.

CBR doesn't mean every frame will have the same size.
Oh, did i say that? ... Indeed. I really do know what CBR is.

Quote:
Originally Posted by Manao View Post
CBR means that, provided you can buffer a definite amount of data prior to stream it, you can stream that data at a perfect constant rate, without the buffer to empty nor fill completely.
CBR in x264 allows the buffer to empty, but should prevent it from filling.
Yes, the idea is here. We can be more schematic by imagine data as water....

Doc.
DocAliG is offline   Reply With Quote
Old 16th February 2007, 17:32   #13  |  Link
kwtc
Registered User
 
Join Date: Sep 2004
Location: Yvelines
Posts: 30
Quote:
Originally Posted by DocAliG View Post
When i tried to use x264 with very constrained vbv parameters, the encoder behavior starts to be fuzzy, non logic. it can over/under consumes bits which still looks like a very constrained VBR than a purely CBR.
Well, perhaps x264's CBR has some bugs ?

If not (I mean if it complies to the H.264 standard), then it is what you need. There is no need to add other strange CBR modes.
kwtc is offline   Reply With Quote
Old 16th February 2007, 20:22   #14  |  Link
Hellworm
Registered User
 
Join Date: Aug 2005
Posts: 132
That x264 is locally (for a few frames) above or below your desired bitrate doesn't mean that it will consume more or less bandwidth than you requested it. Over period of multiple frames the bitrate is as you want it, so if you (to be absolutely secure to to not get over your limit) restrict the bandwidth of your streaming application to a hard limit, it is no Problem to recieve the stream with the appropriate buffer size (that you specified at the encoder end).
Thats what the buffer is for: to smooth out the local fluctuations in the bitrate, so that you practically send a pure cbr stream.
Hellworm is offline   Reply With Quote
Old 16th February 2007, 20:37   #15  |  Link
DarkZell666
aka XaS
 
DarkZell666's Avatar
 
Join Date: Jun 2005
Location: France
Posts: 1,122
DocAliG: you'll have to show a graph of what bitrate distribution you get with your settings (since it isn't constant enough for you), and compare it to another graph which represents what you're expecting (you'll have to invent that one).

Doesn't each second of video consume <bitrate> kbits ? All you keep on saying is "this is not CBR, this is not what I want". What are you really expecting ? You don't seem to be expecting CBR but some other obscurely restricted bitrate distribution that you aren't capable of explaining with technical words. And what other use of a network could you possibly be studying/deploying if it isn't for streaming or distributed encoding ? It doesn't even matter but you're sort of turning down every attempt to understand what you're going on about. If you want help you'll have to make sure everyone understands what you mean first.

Actually, how are you measuring the obtained bitrate ? If by any chance you're using ffdshow's overlayed informations, the bitrate value it shows isn't what I would call accurate.
__________________

Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS
DarkZell666 is offline   Reply With Quote
Old 16th February 2007, 20:41   #16  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
Quote:
Originally Posted by DarkZell666 View Post
Doesn't each second of video consume <bitrate> kbits ?
That isn't guaranteed either, though it will be close if you set the buffer to smaller than 1 second.
With a 1 second buffer, 1 second of video could use twice the max bitrate, while still being VBV compliant. i.e. the client's buffer is full before and empty afterwards.

Last edited by akupenguin; 16th February 2007 at 20:44.
akupenguin is offline   Reply With Quote
Old 17th February 2007, 08:43   #17  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,175
If you set the buffer to 1/framecount*bitrate, would that force all frames to be equal size? (Or neglegible difference at least.)
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. ~ Ed Howdershelt
foxyshadis is offline   Reply With Quote
Old 17th February 2007, 08:48   #18  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
That would be bitrate / framecount, and yes it would. However, I doubt x264 would have the required accuracy ( meaning, it would do its best, but its best would mean the CPB to be violated almost on every frames ).

And, the only use of such a short CPB is low delay. He doesn't care about low delay, so he must set the CPB as big as possible, buffer the data, and send it at a constant rate.
__________________
Manao is offline   Reply With Quote
Old 17th February 2007, 08:55   #19  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,175
I know, I was just wondering if I was interpreting the values right. At first I was looking for an argument to specify the averaging delay, until I realized that buffer size encompasses that and it just has to be set right. Thanks.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. ~ Ed Howdershelt
foxyshadis is offline   Reply With Quote
Old 17th February 2007, 09:06   #20  |  Link
DarkZell666
aka XaS
 
DarkZell666's Avatar
 
Join Date: Jun 2005
Location: France
Posts: 1,122
Quote:
Originally Posted by akupenguin View Post
That isn't guaranteed either, though it will be close if you set the buffer to smaller than 1 second.
With a 1 second buffer, 1 second of video could use twice the max bitrate, while still being VBV compliant. i.e. the client's buffer is full before and empty afterwards.
Basically this means that setting the buffer size to half a second (<bitrate>/2 ?) solves his problem imho.
__________________

Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS
DarkZell666 is offline   Reply With Quote
Reply

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 13:07.


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