On Fri, Jun 6, 2014 at 7:28 AM, Anton Khirnov <an...@khirnov.net> wrote: > > On Thu, 5 Jun 2014 13:00:12 -0400, Andrew Stone <and...@clovar.com> wrote: >> av_metadata_updated checks all metadata dictionaries and checks to see >> if any option named "metadata" was set inside the context; if it was, >> the value is merged into current context metadata. >> >> Rather than maintaining a list of metadata changes and presenting them to >> applications, applications must poll the changes to show updates. Typically, >> this data is only used for display, so updating displayed information with >> identical information should be acceptable. >> >> References: >> https://lists.libav.org/pipermail/libav-devel/2014-May/059933.html >> --- > > After some thinking about this, I can't help thinking that this versioning > scheme is an overkill for what you're doing. > > Adding version to dicts looks highly tailored to this specific use case and > not > likely to be useful for anything else. > > And on the demuxer level what you're interested in is not the actual numerical > difference between versions (since it does you no good to know that the > metadata > changed multiple times), but simply whether metadata changed or not. For > that, a > single-bit flag (per each metadata dict) is enough. The demuxer (or the > protocol) can always set or clear it, since it knows whether metadata changed > or > not.
While this is certainly doable, I'm not sure what you really gain by making it a single bit: (1) the compiler will most likely pad it anyway (2) the application will have no way of determining if a dict has changed as this function will have to reset the flag. As for having the demuxer/protocol set the flag, it's nice for it to be set on any change, rather than pushing that logic down onto all demuxers/protocols. > As a side bonus, it will also avoid a full copy of the dict on each update > check. Metadata is only copied when it's present, then it's cleared, so it doesn't do a copy on each update check. _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
