rbsp_alignemnt_zero_bit

[drmpeg]

What's there to prove? If you take the hack out in /common/cabac.c, the Tektronix Cerify stops complaining.


void x264_cabac_encode_flush( x264_t *h, x264_cabac_t *cb )
{
cb->i_low += cb->i_range - 2;
cb->i_low |= 1;
cb->i_low <<= 9;
cb->i_queue += 9;
x264_cabac_putbyte( cb );
x264_cabac_putbyte( cb );
cb->i_low <<= -cb->i_queue;
cb->i_low |= (0x35a4e4f5 >> (h->i_frame & 31) & 1) << 10; /* giant hack here, remove this line for compliance */
cb->i_queue = 0;
x264_cabac_putbyte( cb );

while( cb->i_bytes_outstanding > 0 )
{
*(cb->p++) = 0xff;
cb->i_bytes_outstanding--;
}
}


Ron

[sneaker_ger]

What's there to prove?

You prove a spec violation by providing a relevant part of the spec to make your point, not by showing some error message of a random verifier.

Interesting comment in that cabac.c line, btw...

[drmpeg]

The Tektronix Cerify costs about $20,000 with the H.264 option. That seems not so "random" to me.

I put that comment in the source code I posted to point out the hack. Maybe you can show us the part of the specification that line implements.

Ron

[kieranrk]

The Tektronix Cerify costs about $20,000 with the H.264 option. That seems not so "random" to me.


I'll let you figure out the right one: http://yourlogicalfallacyis.com/


I put that comment in the source code I posted to point out the hack. Maybe you can show us the part of the specification that line implements.


The definition of the alignment bit has already been discussed at length.

[Dark Shikari]

I work with very expensive analyzers every day; they are incredibly buggy and have lots of false positives in their analysis. I might go so far as to say that they are actually the buggiest pieces of video software I've ever seriously worked with; (everything from constant crashes to integer overflows in image reconstruction, incorrect implementations of direct prediction, improper handling of large DQPs, broken POC handling...). Unfortunately, the only real way to make serious use of these is to mentally keep track of their bugs and try to work around them or ignore them.

Regardless of the specific topic of this thread, I would not trust any analyzer for being expensive.

[drmpeg]

If I post the traces from the JM decoder, will you guys believe the results?

Ron

[Dark Shikari]

JM is not an analyzer, so it's not at all suitable for testing whether a stream is compliant. It will error out on many valid streams and accept many invalid streams (and unfortunately I know this from too much experience...).

At this point it seems more spec-lawyering than anything else. Since I'm not very good at this, I'll trust what other (better) developers conclude. x264 is open source, so if you interpret the spec's language differently to say that x264 is incorrect, then feel free to change the appropriate lines in x264 to match.

[drmpeg]

So the only way to get to the bottom of this is to get Oliver Stone involved? ;)