Hi,
On Tue, Apr 12, 2011 at 3:44 AM, Luca Barbato <[email protected]> wrote:
> On 04/09/2011 03:59 PM, Kostya Shishkov wrote:
>> This implementation should work fine with multiple side information types
>> present.
>
>> + uint8_t **side_data;
>> + int *side_data_sizes;
>> + int *side_data_types;
>> + int side_data_elems;
>
> Undecided if a
>
> AVSideData {
> void *data
> int data_type
> }
>
> AVSideData *side_data;
> int side_data_elems;
>
> Is nicer since everything is ordered even if looking up is slower.
> Probably your solution is overall better. Patch Ok.
Why is it slower? The thing is, it saves a malloc. Not necessarily
important, but still quite nice.
struct {
uint8_t *data;
int size;
int type;
} side_data[];
int num_side_datas;
Suddenly you only need 1 big malloc plus 1 per chunk, instead of 3 big
mallocs (one for datas[], one for sizes[], and one more for types[])
plus 1 per chunk.
Also, API-wise it makes sense to have av_packet_new_side_data() return
the newly allocated side_data[] chunk, because then the caller can
directly write into it without having to obtain it first. Same for
av_packet_get_side_data(), it should probably take a third argument
int *size which the function can fill in to the size, prevents having
to loop twice, and I don't see why people would ever want the data
without the size.
Other than that I think this looks good.
Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
