[x264-devel] rbsp_alignment_zero_bit

[Ludrao]

Well I did a little more digging, and I found out something quite funny...
I believe that this magic stuff is actually a kind of watermarking. i_frame is 
just used as a regularly increasing counter so you can select each one bit of 
the magic number 0x35a4e4f5.
To confirm this you can actually print the trailing bits of each slices, and 
you'll find out that there are always in the form of a sequence of 0 (standard 
way of representing rbsp_alignment_zero_bits) or sequence of 0 followed by a 
single 1.


For instance my traces give me that: (look the the trailing bit "value")

GlobalPicNumber 1, slice_type 7, slice_num 0, frame_num 0, POC 0, field_pic_flag 
0, Size :1280x720
trailing bits error: used bits: 100601, total bits: 100608
nb of trailing bits: 7, value: 0x1
GlobalPicNumber 2, slice_type 5, slice_num 0, frame_num 1, POC 2, field_pic_flag 
0, Size :1280x720
nb of trailing bits: 5, value: 0x0
GlobalPicNumber 3, slice_type 5, slice_num 0, frame_num 2, POC 8, field_pic_flag 
0, Size :1280x720
trailing bits error: used bits: 34831, total bits: 34832
nb of trailing bits: 1, value: 0x1
GlobalPicNumber 4, slice_type 6, slice_num 0, frame_num 3, POC 4, field_pic_flag 
0, Size :1280x720
nb of trailing bits: 7, value: 0x0
GlobalPicNumber 5, slice_type 6, slice_num 0, frame_num 3, POC 6, field_pic_flag 
0, Size :1280x720
trailing bits error: used bits: 9974, total bits: 9976
nb of trailing bits: 2, value: 0x1
GlobalPicNumber 6, slice_type 5, slice_num 0, frame_num 3, POC 16, 
field_pic_flag 0, Size :1280x720
trailing bits error: used bits: 42284, total bits: 42288
nb of trailing bits: 4, value: 0x1
GlobalPicNumber 7, slice_type 6, slice_num 0, frame_num 4, POC 10, 
field_pic_flag 0, Size :1280x720
trailing bits error: used bits: 17321, total bits: 17328
nb of trailing bits: 7, value: 0x1
GlobalPicNumber 8, slice_type 6, slice_num 0, frame_num 4, POC 12, 
field_pic_flag 0, Size :1280x720
trailing bits error: used bits: 17435, total bits: 17440
nb of trailing bits: 5, value: 0x1
GlobalPicNumber 9, slice_type 6, slice_num 0, frame_num 4, POC 14, 
field_pic_flag 0, Size :1280x720
nb of trailing bits: 3, value: 0x0
GlobalPicNumber 10, slice_type 5, slice_num 0, frame_num 4, POC 24, 
field_pic_flag 0, Size :1280x720
nb of trailing bits: 6, value: 0x0
GlobalPicNumber 11, slice_type 6, slice_num 0, frame_num 5, POC 18, 
field_pic_flag 0, Size :1280x720
trailing bits error: used bits: 15310, total bits: 15312
nb of trailing bits: 2, value: 0x1


Add up the last trailing bit and you get the magic number...


I believe that adding watermarking is fine (when you may need to know who use 
you software...), however it is better when it respect the standard...

So I politely ask the mastermind that is behind this nice piece of code to 
remove this line:
	cb->i_low |= (0x35a4e4f5 >> (h->i_frame & 31) & 1) << 10;
So that this wonderful codec implement respectfully the standard ;-)

Thanks for your commitment !

Ludrao

Le Tuesday 24 March 2009, Deepak Singh a écrit :
> I too found this bug around two months back....
> I informed too....I also agree that it is not critical error but should be
> resolved.
>
> I already gave thought on it..and I feel the magic number (0x35a4e4f5) in
> the below line
>
> cb->i_low |= (0x35a4e4f5 >> (h->i_frame & 31) & 1) << 10;
>
> from function x264_cabac_encode_flush is the issue.
> I couldn't figure out the relation between the magic number and the
> h->i_frame.
>
>
>
> 2009/3/24 Ludrao <ludh264 at ludrao.net>
>
> > Hi all,
> >
> >
> > I found h264 streams encoded with x264 that has a bizare sequence of
> > trailing bits.
> >
> >
> > This is linked to section 7.3.2.11 of the standard:
> >
> >
> > 7.3.2.11 RBSP trailing bits syntax
> > rbsp_trailing_bits( ) {
> > rbsp_stop_one_bit /* equal to 1 */
> > while( !byte_aligned( ) )
> > rbsp_alignment_zero_bit /* equal to 0 */
> > }
> >
> >
> > This seems no always to be respected ?
> > For instance I found a stream where the last byte of the slice was 0x81.
> > The stream is using CABAC encoding.
> >
> >
> > I have done some checking, it happens to be the case in a lot of streams
> > encoded with x264.
> >
> >
> > This is not really a big deals since I can just ignore the trailing bits,
> > but still...
> >
> >
> > Maybe I am missing something in the spec ?
> >
> >
> > Regards,
> >
> >
> > Ludrao
> >
> >
> >
> >
> > _______________________________________________
> > x264-devel mailing list
> > x264-devel at videolan.org
> > http://mailman.videolan.org/listinfo/x264-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20090324/5871d24e/attachment.htm>