[x264-devel] patch for: alignment problem on sparc (maybe others 32bit archs, too)

[Jason Garrett-Glaser]

On Fri, Mar 6, 2009 at 3:30 AM, Chris Fensch <cf-x264 at fens.ch> wrote:
> Hi,
>
>> This is not an appropriate fix.  The bitstream pointer itself should
>> always be aligned, and if it is not, the bitstream writer should be
>> modified to ensure that it is.
>
> Well, I do agree to some extend. The fix does not affect architectures that
> can cope with unaligned memory access (such as x86), but allows to x264 to
> run on machines which are not that flexible. As such it fixes the symtoms
> but not the cause: The problem is caused by the current implementation of:
>
> /* Write the rest of cur_bits to the bitstream; results in a bitstream no
> longer 32/64-bit aligned. */
> static inline void bs_flush( bs_t *s )
>
> I, unfortunately, do not know enough about the underlying semantics of the
> bitstream writer and feel not confident of submitting a patch that changes
> the semantics. I see one possible solution (but that changes the semantics):
>
> Instead of writing cur_bits to the bitstream, just change i_left in such a
> way that it is byte aligned and shift the bits in cur_bits by the same
> amount. The resulting bitstream should be the same, if cur_bits is written
> to the bitstream at later point. Of course, if no further bits are written
> to the bitstream, then that write might never happen...
>
> Maybe the person who wrote the current implementation of bs_flush can fix
> this method in a way that the semantics is preserved.

There are a few solutions I can think of:

1) Separate bs_flush into two functions.  One is called in the case
that the bitstream is actually finished (and thus we *want* all the
bits to be dumped to the bitstream, and the pointer left unaligned, as
it will never be written to again).  The other is called otherwise.

2) Have bs_flush leave the appropriate data in cur_bits... *and* write
it to the bitstream as well, to take care of both cases.  The problem
with this is that it either leaves p_end incorrect, which I can't
think of a nice way around.

3) Require bs_init to be re-called after every bs_flush if we need to
write to the bitstream again.

Dark Shikari