On 5/15/2017 4:47 AM, Mark Thompson wrote:
> On 15/05/17 02:25, James Almer wrote:
>> On 5/14/2017 6:24 PM, Mark Thompson wrote:
>>> Also add a namespace prefix.
>>> ---
>>>  libavcodec/h264.h              | 12 ++++++++++++
>>>  libavcodec/h264_sei.c          | 14 +++++++-------
>>>  libavcodec/h264_sei.h          | 14 +-------------
>>>  libavcodec/vaapi_encode_h264.c |  6 +++---
>>>  4 files changed, 23 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/libavcodec/h264.h b/libavcodec/h264.h
>>> index eb3805c06..ae6b3577d 100644
>>> --- a/libavcodec/h264.h
>>> +++ b/libavcodec/h264.h
>>> @@ -44,4 +44,16 @@ enum {
>>>      H264_NAL_AUXILIARY_SLICE = 19,
>>>  };
>>>  
>>> +/* SEI message types */
>>> +enum {
>>> +    H264_SEI_TYPE_BUFFERING_PERIOD       = 0,   ///< buffering period 
>>> (H.264, D.1.1)
>>> +    H264_SEI_TYPE_PIC_TIMING             = 1,   ///< picture timing
>>> +    H264_SEI_TYPE_FILLER_PAYLOAD         = 3,   ///< filler data
>>> +    H264_SEI_TYPE_USER_DATA_REGISTERED   = 4,   ///< registered user data 
>>> as specified by Rec. ITU-T T.35
>>> +    H264_SEI_TYPE_USER_DATA_UNREGISTERED = 5,   ///< unregistered user data
>>> +    H264_SEI_TYPE_RECOVERY_POINT         = 6,   ///< recovery point (frame 
>>> # to decoder sync)
>>> +    H264_SEI_TYPE_FRAME_PACKING          = 45,  ///< frame packing 
>>> arrangement
>>> +    H264_SEI_TYPE_DISPLAY_ORIENTATION    = 47,  ///< display orientation
>>> +};
>>
>> Why? They were in a standalone SEI specific header, so why move them
>> here? You're not untangling anything by moving them here, and saving one
>> include line per file doesn't seem like a good reason to me.
> 
> It gets included in cbs_h2645.c, which will contain H.265 SEI stuff as well 
> (that part isn't yet done).  Only the SEI types are wanted, not anything else 
> in the file.
> 
> Alternative approach would be to add the namespace prefix to everything else 
> in h264_sei.h which doesn't currently have it (actually looking, all that is 
> is the pic_struct enum immediately below) - would you prefer that?

That'd be better, yes. Thanks.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to