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. |
14th February 2007, 15:33 | #1 | Link |
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. |
14th February 2007, 19:24 | #2 | Link |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
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. |
14th February 2007, 20:54 | #3 | Link | |
aka XaS
Join Date: Jun 2005
Location: France
Posts: 1,122
|
Quote:
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 |
|
15th February 2007, 16:14 | #4 | Link | |
MPEG Member
Join Date: Oct 2006
Posts: 39
|
Quote:
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. |
|
15th February 2007, 16:23 | #5 | Link | |
MPEG Member
Join Date: Oct 2006
Posts: 39
|
Quote:
Thanks anyway, i'll try the --qstep to higher values. Doc. |
|
16th February 2007, 12:54 | #7 | Link | |
MPEG Member
Join Date: Oct 2006
Posts: 39
|
Quote:
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. |
|
16th February 2007, 13:49 | #8 | Link |
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).
|
16th February 2007, 14:07 | #9 | Link | |
aka XaS
Join Date: Jun 2005
Location: France
Posts: 1,122
|
The bottom line is here:
Quote:
__________________
Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS |
|
16th February 2007, 16:49 | #10 | Link | ||
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:
Quote:
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 |
||
16th February 2007, 17:03 | #11 | Link |
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.
__________________
|
16th February 2007, 17:26 | #12 | Link | ||
MPEG Member
Join Date: Oct 2006
Posts: 39
|
Quote:
Quote:
Doc. |
||
16th February 2007, 17:32 | #13 | Link | |
Registered User
Join Date: Sep 2004
Location: Yvelines
Posts: 30
|
Quote:
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. |
|
16th February 2007, 20:22 | #14 | Link |
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. |
16th February 2007, 20:37 | #15 | Link |
aka XaS
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 |
16th February 2007, 20:41 | #16 | Link |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
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. |
17th February 2007, 08:48 | #18 | Link |
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.
__________________
|
17th February 2007, 08:55 | #19 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
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.
|
17th February 2007, 09:06 | #20 | Link | |
aka XaS
Join Date: Jun 2005
Location: France
Posts: 1,122
|
Quote:
__________________
Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|