[x264-devel] rbsp_alignment_zero_bit

[Deepak Singh]

Hi Loren,

Thanks for the reply.

But Still for my understanding I didn't get answers of my other questions...

1) Could you tell me where we are adding the end_of_slice
(rbsp_stop_one_bit) flag.

2) In function void x264_cabac_encode_flush( x264_t *h, x264_cabac_t *cb )

cb->i_low |= (0x35a4e4f5 >> (h->i_frame & 31) & 1) << 10;


Why this is related to frame number and what is this magic number
'0x35a4e4f5'.
As per my understanding the standard 'i_low' has no relation with frame
number.

3) on the same function() the line
 cb->i_low |= 1;

I am NOT getting why we are doing this.Is this end_of_slice flag?

It will be very helpful if you could explain it.

Thanks in advance...

On Wed, Nov 12, 2008 at 12:03 AM, Loren Merritt <lorenm at u.washington.edu>wrote:

> On Tue, 11 Nov 2008, Deepak Singh wrote:
>
> > While using x264 code  I found that  "rbsp_alignment_zero_bit" at the end
> of
> > the slice sometimes coming rbsp_alignemnt_zero_bit = 1, and sometimes
> > rbsp_alignemnt_zero_bit = 0 while Only allowable value is 0.
>
> Then you're misparsing where the slice ends. rbsp_alignment_zero_bit is
> not merely required to be 0, it's syntactically impossible to make it any
> other value. The last 1 and any 0s thereafter are the rbsp_trailing_bits,
> and all data before that is part of the payload.
> The whole point of rbsp_trailing is so that you can know (to single-bit
> precision) where the payload ends. If there were another way to know which
> bit is the last bit, the standard wouldn't have included rbsp_trailing.
>
> --Loren Merritt
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>



-- 
Regards,
Deepak Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20081112/ea03acc9/attachment.htm