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 email@example.com http://ffmpeg.org/mailman/listinfo/ffmpeg-devel