[x264-devel] Re: [Ian Caulfield <ian.caulfield at gmail.com>] Patch for HD DVD bitstream compliance

bond b-o-n-d at gmx.net
Sun Jan 7 20:45:18 CET 2007


This seems to create HRD and SEIs fine :)

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?

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 or HDDVD compliance is wanted...

either way, thanks for this patch!


----- Original Message ----- 
From: "Lists administration" <videolan at lists.videolan.org>
To: <x264-devel at videolan.org>
Sent: Sunday, January 07, 2007 3:12 PM
Subject: [x264-devel] [Ian Caulfield <ian.caulfield at gmail.com>] Patch for HD 
DVD bitstream compliance


> The deleted attachment is at:
>    <http://lists.videolan.org/attachs/20070107/x264_hrd.patch>
>
> ----- Forwarded message from Ian Caulfield <ian.caulfield at gmail.com> -----
>
> Date: Sat, 6 Jan 2007 21:01:07 +0000
> From: Ian Caulfield <ian.caulfield at gmail.com>
> To: x264-devel at videolan.org
> Subject: Patch for HD DVD bitstream compliance
> X-Spam-Status: No, score=-4.7 required=5.0 tests=HTML_10_20,HTML_MESSAGE,
> RCVD_BY_IP,SPF_HELO_PASS,UNIFIED_PATCH autolearn=failed version=3.0.3
>
> Hi,
>
> I've attached a patch to add the ability to encode NAL HRD parameters into 
> the
> output bitstream, allowing the streams produced by x264 to be imported 
> into
> Scenarist HD. The patch changes three things:
>
> - encode NAL HRD info in bitstream if b_nal_hrd is set
> - move the version info SEI header after the SPS and PPS headers (required 
> for
> Scenarist to identify the stream as an H264 ES)
> - 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)
>
> The cpb_initial_removal_delay calculation is currently a bit of a fudge - 
> I
> wasn't sure of the correct way to work out the value, but using the time 
> it
> will take to fill the VBV buffer to vbv_buffer_init at vbv_max_bitrate 
> seems to
> produce sane looking figures...
>
> As this is my first patch for x264, I welcome any comments, even critical 
> ones
> :)
>
> Thanks,
> Ian
>
>
>
> ----- End forwarded message -----
>
> -- 
> Lists administration <videolan at lists.videolan.org>
>
> -- 
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.16.3/614 - Release Date: 2.1.2007 
> 14:58
>
> 

-- 
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