On 13/10/17 12:31, Michael Niedermayer wrote:
> On Fri, Oct 13, 2017 at 01:23:34PM +0200, Michael Niedermayer wrote:
>> On Thu, Oct 12, 2017 at 12:35:35AM +0100, Mark Thompson wrote:
>>> On 11/10/17 23:34, Michael Niedermayer wrote:
> [...]
>>>>> +
>>>>> +/**
>>>>> + * Coded bitstream unit structure.
>>>>> + *
>>>>
>>>>> + * A bitstream unit the smallest element of a bitstream which
>>>>> + * is meaningful on its own. For example, an H.264 NAL unit.
>>>>
>>>>> + *
>>>>> + * See the codec-specific header for the meaning of this for any
>>>>> + * particular codec.
>>>>> + */
>>>>> +typedef struct CodedBitstreamUnit {
>>>>> + /**
>>>>> + * Codec-specific type of this unit.
>>>>> + */
>>>>> + CodedBitstreamUnitType type;
>>>>> +
>>>>
>>>>> + /**
>>>>> + * Pointer to the bitstream form of this unit.
>>>>> + *
>>>>> + * May be NULL if the unit currently only exists in decomposed form.
>>>>> + */
>>>>> + uint8_t *data;
>>>>
>>>> whats a "bitstream form" ?
>>>> is that the bitstream itself? if so why is it called "bitstream form"
>>>
>>> It is a bitstream form appropriate for direct parsing (for H.264/H.265,
>>> rbsp, so unescaped).
>>
>> Thats a bit surprising.
>>
>> Wouldnt a API that uses the unmodified bitstream be more clear and
>> simpler ?
>> Or an explicit parameter that specifies if the input has been
>> unescaped already.
>
> disregard this, i realize now you just spoke about the field in the
> struct and not the interface, which i presume works with normal
> data as stored in containers
Correct. This is the intermediate form between the internal split/read or
write/assemble - a user of the API is not expected to touch it unless they are
doing something very sophisticated.
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
