[FFmpeg-devel] [PATCH 1/2] lavc/bsf: add general documentation

[James Almer]

On 3/16/2022 8:36 AM, Anton Khirnov wrote:
> Quoting James Almer (2022-02-22 18:09:59)
>>
>>
>> On 2/22/2022 3:27 AM, Anton Khirnov wrote:
>>> Also, place the BSF api docs in their own doxygen group.
>>> ---
>>>    libavcodec/bsf.h | 23 ++++++++++++++++++++++-
>>>    1 file changed, 22 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/bsf.h b/libavcodec/bsf.h
>>> index 8c5355d186..ba8b48f222 100644
>>> --- a/libavcodec/bsf.h
>>> +++ b/libavcodec/bsf.h
>>> @@ -30,7 +30,28 @@
>>>    #include "packet.h"
>>>    
>>>    /**
>>> - * @addtogroup lavc_core
>>> + * @defgroup lavc_bsf Bitstream filters
>>> + * @ingroup libavc
>>> + *
>>> + * Bitstream filters transform encoded media data without decoding it. This
>>> + * allows e.g. manipulating various header values. Bitstream filters operate on
>>> + * @ref AVPacket "AVPackets".
>>> + *
>>> + * The bitstream filtering API is centered around two structures:
>>> + * AVBitStreamFilter and AVBSFContext. The former represents a bitstream filter
>>
>> Could use @ref here and below, too.
> 
> That happens automatically when you write a struct name.
> 
>>
>>> + * in abstract, the latter a specific filtering process. Obtain an
>>> + * AVBitStreamFilter using av_bsf_get_by_name() or av_bsf_iterate(), then pass
>>> + * it to av_bsf_alloc() to create an AVBSFContext. Fill in the user-settable
>>> + * AVBSFContext fields, as described in its documentation, then call
>>> + * av_bsf_init() to prepare the filter context for use.
>>> + *
>>> + * Submit packets for filtering using av_bsf_send_packet(), obtain filtered
>>> + * results with av_bsf_receive_packet(). When no more input packets will be
>>> + * sent, submit a NULL AVPacket to signal the end of the stream to the filter.
>>
>> The doxy for av_bsf_send_packet() states the packet must be "empty",
>> meaning either "NULL, or pkt->data is NULL and pkt->side_data_elems
>> zero", so probably mention the same here so it's consistent.
> 
> The idea here is to provide a quick overview of the API rather than be
> exhaustive. In retrospect I regard allowing both NULL and "empty packet"
> (for some quite nontrivial definition of empty, given side-data-only
> packets) as a mistake, allowing only NULL would be cleaner and less
> confusing.

Ok, LGTM then.