On Fri, Dec 8, 2017 at 10:06 AM, Jacob Trimble <modma...@google.com> wrote:
> On Tue, Dec 5, 2017 at 5:22 PM, Derek Buitenhuis
> <derek.buitenh...@gmail.com> wrote:
>> On 12/6/2017 12:36 AM, Jacob Trimble wrote:
>>> Would a 0-length array work?  Otherwise I would need to have it be a
>>> 1-length array and have to account for that when calculating the size
>>> to allocate; it would also require a comment to ignore the size of the
>>> array.
>> Aren't 0-length arrays a GNU extensions? If so, I would gather that it
>> probably is not OK in a public header, either.
> Yeah.
>> I'm not entirely sure what way we prefer nowadays, but you can see
>> we've had side data with variable length members before with e.g.
>> AV_PKT_DATA_QUALITY_STATS, but that doesn't have a struct associated
>> with it. I'm hoping someone more up to date with the side data stuff
>> can chime in with a suggestion on what our current best practices
>> are for it.
> I would prefer to avoid requiring the app to "parse" the side data, using a
> plain struct would be better.  I've updated the patch to include my other plan
> of allocating a larger bock and having the struct followed by the subsample
> array.
> I have also renamed the file, I think the mailing list rejected my attachment
> before since gmail sent the MIME type as text/x-patch.  Hopefully with the
> .txt extension gmail will send the correct MIME type.

Ping.  Is this something that can be pushed?  I have the implementation for
mov almost ready.  I think having this info exposed would be something that
would be really useful for the project.
ffmpeg-devel mailing list

Reply via email to