[x264-devel] Re: [PATCH] add pps_id option and define sps_id and pps_id as uint8_t

Loren Merritt lorenm at u.washington.edu
Wed Jan 31 23:30:04 CET 2007


On Wed, 31 Jan 2007, Limin Wang wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> * Loren Merritt <lorenm at u.washington.edu> [2007-01-31 04:35:24 -0700]:
>
>> On Wed, 31 Jan 2007, Limin Wang wrote:
>>
>>> The patch try to allow user configure sps_id and pps_id with different
>>> value.
>>> In addition, by the specs, sps_id range is from 0 to 31, pps range is from
>>> 0 to 255, so replace int with uint8_t type. Please review it.
>>
>> Just because the range happens to be 0..255 is no reason to use uint8_t
>> over int, it's a reason to explicitly boundscheck.
>
> Both id should be >=0, so it can be defined as unsigned. In addition, they're
> less than 256, so define as int8_t. Then we don't need do extra check for int
> may <0, or >255.

That just means that if you type --sps-id 256, it will silently use 0 
instead.

>> And unless you can provide a reason to do otherwise, I'll just restrict
>> the range to 0..31 and continue using one parameter for both ids.
>
> Now x264 support one SPS and PPS only, so it's ok in this case. If we want
> to support more than one SPS and PPS, then it's too limited to configure the
> both ids the same. I'm also confused why specs limit sps_id and pps_id
> to different range, any good reason?

I don't know why they need different ranges (since there's no penalty for 
having unused numbers), but I can guess why you'd expect more PPSs than 
SPSs. SPS contains properties of the decoded stream. PPS contains all the 
settings that only the codec itself needs to know. So I'd expect multiple 
SPSs only if you're concatenating video from different sources, but PPS 
could change within each source if different scenes have different optimal 
settings. (Ok, so the segregation isn't that perfect, but the idea 
stands.)

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