Exponential golomb encoding fixes about h264bitstream HOT 3 CLOSED

@spiderkeys I'm glad you're using (and modifying) h264bitstream! Let's see if we can get to the bottom of this issue, I'd like to merge your changes if possible.

In the current master, it looks like bs_write_ue can handle any size up to 32 bit, due to the following code that calculates lengths from the 8-bit table:

        if (v >= 0x01000000)
        {
            len = 24 + len_table[ v >> 24 ];
        }
        else if(v >= 0x00010000)
        {
            len = 16 + len_table[ v >> 16 ];
        }
        else if(v >= 0x00000100)
        {
            len =  8 + len_table[ v >>  8 ];
        }

However, your bs_write_ue (not the _big version) only has this:

    bs_write_u( b, x264_ue_size_tab[ val + 1 ], val + 1 );

which would be expected to fail for any val > 0x100. Also x264_ue_size_tab is now called len_table.

I think this has been in master since ebf37e8.

Could you let me know which version of the library your fork is based on?

from h264bitstream.

This appears to be fixed since 0.1.6. Please reopen if you still see this problem in the latest version. Thanks!

from h264bitstream.

Sorry, I missed your previous comment!

I compared your latest version to my modified version and they produced identical SPS and PPS results, so it looks like everything is good!

from h264bitstream.