[x264-devel] Re: Patch for Scenarist HD compatibility

Loren Merritt lorenm at u.washington.edu
Mon Jan 8 01:53:20 CET 2007


On Sat, 6 Jan 2007, Ian Caulfield wrote:

> - fix a small bug in bitstream_write (on x86 a right shift of more than 32
> bits actually shifts by the shift amount mod 32, rather than returning 0)
>
> --- common/bs.h (revision 616)
> +++ common/bs.h (working copy)
> @@ -185,7 +185,10 @@
>  }
>  else
>  {
> -     *s->p = (*s->p << s->i_left) | (i_bits >> (i_count - s->i_left));
> +     if( (i_count - s->i_left) >= 32 )
> +         *s->p = (*s->p << s->i_left);
> +     else
> +         *s->p = (*s->p << s->i_left) | (i_bits >> (i_count - s->i_left));
>       i_count -= s->i_left;
>       s->p++;
>       s->i_left = 8;

Not a bug. i_count is the number of bits passed in i_bits, which is a 
uint32_t, thus i_count<=32. i_left>0 because whenever it is 0 we increment 
the bitstream pointer and refill it. So the shift can't exceed 31.

bs_align_10 doesn't look right. shouldn't you use bs_rbsp_trailing 
instead?

> - move the version info SEI header after the SPS and PPS headers 
> (required for Scenarist to identify the stream as an H264 ES)

Bugs should be fixed where the bug is. This is a bug in Scenarist, so out 
of principle I won't work around it in x264.


On Sun, 7 Jan 2007, bond wrote:

> one question: why is there the need to explicitely enable writing the
> HRD nal info?  wouldnt it be better to simply always write this when VBV
> is used?

The standard says: if nal_hrd_parameters is present, then the SEIs must 
also be present. I wouldn't mind it if just the nal_hrd_parameters could 
be tied to the usage of VBV, but the SEIs impose a measurable bitrate 
overhead so they should not be automatically enabled.

> also wouldnt it be better to let the user instead enable/disable whether
> he wants the SEIs in the bitstream? they might be useful or not wanted
> independant of whether VBV is used

These SEIs don't contain any information other than about VBV, so it
would just be wrong to put them in a non-VBV-compliant stream.

> or HDDVD compliance is wanted...

The whole patch is independent of whether HDDVD compliance is wanted. It
just adds a feature that Scenarist requires, because Scenarist is too
lazy to implement its own VBV model. (hint: a smart muxer does _not_
need to know what VBV parameters the stream was encoded with, it only
needs to know what VBV parameters the decoder wants)

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html



More information about the x264-devel mailing list