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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
