Straight CBR mode

[DocAliG]

Originally Posted by Sergey A. Sablin

It still looks for me like you're mixing different buffers.
DPB is a decoded picture duffer and no one here is talking about it. This buffer is used for reference pictures and has nothing to do with any bitrate, transmission etc.
CPB is a coded picture buffer - the buffer used in decoder to keep arrival data which is waiting it's decoding time.

It's just simply not comparable. Just because x264 and the JM are two different codecs, built in two different ways.

Originally Posted by Sergey A. Sablin

JM has neither strict HRD compilance nor CBR as it doesn't write any padding. JM neither write HRD parameters, so to verify stream you have to manage all parameters by yourself.

JM should have only CBR. And should have HRD compliance as well.

Originally Posted by Sergey A. Sablin

And finally rate control which produce random CPB size is useless, since you need definitely known size to transmit your data through network and to correctly decode signal on fixed function chip decoders. There is no other way to think it - user has to specify coded picture buffer size, stream rate and initial delay and encoder using rate control has to produce stream with required parameters, else it is not RC - it is BS.

That's why NAL has been created. But it's true that in JM, user has to define everything by himself. That's sometimes quite tough.

[Sergey A. Sablin]

Originally Posted by DocAliG

It's just simply not comparable. Just because x264 and the JM are two different codecs, built in two different ways.

they're quite comparable as these two are just two different implementations of same ISO/ITU-T specification named MPEG-4 part 10 AVC/H.264. You are talking absolutely odd things.

Originally Posted by DocAliG

JM should have only CBR. And should have HRD compliance as well.

maybe it should but there is no any overflow prevention (using filler SEI), so if it is even CBR than it is not compliance with HRD model. I dont see any underflow checking either.

Originally Posted by DocAliG

That's why NAL has been created. But it's true that in JM, user has to define everything by himself. That's sometimes quite tough.

NAL units have nothing to do with HRD and any rate control. It is just packetizing.

[DocAliG]

Originally Posted by Sergey A. Sablin

they're quite comparable as these two are just two different implementations of same ISO/ITU-T specification named MPEG-4 part 10 AVC/H.264. You are talking absolutely odd things.

A norm is made to describe a BITSTREAM and a DECODER. Never to describe an encoder. You can think of any encoding you want, providing that the bitstream is made correctly and the reference decoder can decode it. I don't know who is talking odd things, but....

Originally Posted by Sergey A. Sablin

NAL units have nothing to do with HRD and any rate control. It is just packetizing.

I know. I was just reacting to your sentence : "...since you need definitely known size to transmit your data through network..." that's why i've said : that's why NAL has been created. To adapt the stream and prepare it for the network. Or at least one reason why.

[squid808]

DocAliG: DPB (Decoded Picture Buffer) is part of the H.264 decoder specification and has nothing to with rate control. And this is the meaning of DPB in JM. You are, indeed, talking very odd things.

[DocAliG]

Originally Posted by squid808

DocAliG: DPB (Decoded Picture Buffer) is part of the H.264 decoder specification and has nothing to with rate control. And this is the meaning of DPB in JM. You are, indeed, talking very odd things.

I wrote "The DPB is the "mbuffer.c" file in the JM.". Never talked about rate control having a link with DPB. Thanks.

[squid808]

Originally Posted by DocAliG

I wrote "The DPB is the "mbuffer.c" file in the JM.". Never talked about rate control having a link with DPB. Thanks.

Ok. That makes me kind of curious about how your sentence "The DPB is the "mbuffer.c" file in the JM." is related to this thread?

[DarkZell666]

And CBR modifies QP within a frame, so it's even closer.

Ooops I had almost forgotten that one, it makes my point less valid than I thought And I'll take it that by CBR you meant "ABR + activated vbv" too ^^ (you almost scared me off ).

[DocAliG]

After a great help from Manao (and akupenguin), we finally sorted this CBR problem out (or at least, i understood why x264 is working this way ).

For those who have interest in CBR, the vbv is only compliant on single pass mode, which has been verified by Manao small patch, (and the little tool i used to provide the curves). When using two passes or more, the x264 vbv is no more compliant, but that's not a problem, because the gain in CBR on several passes would be negligible.

If i have some spare time, i'll try to implement this compliance for 2 passes, just to check if this can slightly increase the quality (by curiosity....). Some bitrates are so small that just a small enhancement can make the difference.

A big Thank again to Manao and to akupenguin for your time.