[FFmpeg-devel] [PATCH 2/4] cbs_h265: Add PTL parsing for Main 10 Still Picture profile

[Mark Thompson]

On 30/10/18 19:51, James Almer wrote:
> On 10/27/2018 6:39 PM, Mark Thompson wrote:
>> This was added in the 2018 version of the standard.
>> ---
>>  libavcodec/cbs_h265_syntax_template.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/libavcodec/cbs_h265_syntax_template.c b/libavcodec/cbs_h265_syntax_template.c
>> index d4e4f7b1c2..e43f3caf99 100644
>> --- a/libavcodec/cbs_h265_syntax_template.c
>> +++ b/libavcodec/cbs_h265_syntax_template.c
>> @@ -130,6 +130,11 @@ static int FUNC(profile_tier_level)(CodedBitstreamContext *ctx, RWContext *rw,
>>                  fixed(24, general_reserved_zero_34bits, 0);
>>                  fixed(10, general_reserved_zero_34bits, 0);
>>              }
>> +        } else if (profile_compatible(2)) {
>> +            fixed(7, general_reserved_zero_7bits, 0);
>> +            flag(general_one_picture_only_constraint_flag);
>> +            fixed(24, general_reserved_zero_35bits, 0);
>> +            fixed(11, general_reserved_zero_35bits, 0);
> 
> Fun get_bits() constrain :p

Maybe I can call it a feature not to spam 44 bits in one line of trace output :)

> It may be worth looking at enabling CACHED_BITSTREAM_READER. get_bits()
> can read up 32 bits with it, and it may be faster overall.

ff_cbs_read_unsigned() already calls get_bits_long()...

Wrt faster, maybe?  I haven't really thought about that much because it's generally good enough, and I think any gains will be relatively limited given that we probably spend more time ensuring that nothing is going wrong than actually reading the bits themselves.

>>          } else {
>>              fixed(24, general_reserved_zero_43bits, 0);
>>              fixed(19, general_reserved_zero_43bits, 0);
>>
> 
> LGTM.
Applied both.

Thanks,

- Mark