Hi, On Sat, Oct 22, 2011 at 9:26 AM, Ronald S. Bultje <[email protected]> wrote: > On Tue, Oct 4, 2011 at 5:52 PM, Luca Barbato <[email protected]> wrote: >> On 10/4/11 9:48 PM, Justin Ruggles wrote: >>> Do you mean side_data as-in, still use AVDictionary to store the info >>> but make metadata one of the types of side_data a decoder can export >>> into the AVFrame? >> >> yes, btw if we plan to use AVDict for anything intensive we might consider >> making it a little faster. > > I'm a little confused now, side_data is an array and dict is a dict, > so now we have both an array and a dict? What else do we intend to > store in it? We're using side_data[] in AVPacket because AVDict is too > heavy, right? If we're using dict anyway, then using side_data[] is > not really useful. > > (I should probably look at what we're going to store in here, it > should based on that be either a dict or a side_data[], not both.)
Quick look, I really think dict was fine to begin with. I'm not sure what else we intend to store here where a buffer is fine, but I really think the original patchset was fine (the one just introducing a dict here), and we can continue with that. Yes, dict may not be ideal, but it's not like we're going to be using this in cases where performance is an absolute killer (like, say, h264), because there is no frame-associated metadata there anyway. Even if there is, it doesn't exist at the per-frame level, but only at the per-framegroup-level (e.g. once every 10 seconds), and then it doesn't mater anymore. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
