On Thu, Jun 12, 2014 at 9:02 PM, Luca Barbato <[email protected]> wrote:
> On 12/06/14 20:02, Andrew Stone wrote:
>> What are you guys thinking? I'm seeing the cleanest solution as being:
>>
>> * Remove av_metadata_updated() and move any metadata copying/change
>> detection into read/seek
>> * The application will then have to check metadata dicts for updates
>>
>> From the proposed changes, I'm seeing the following problems:
>>
>> 1) Dropping versioning from AVDict and changing to a flag would result
>> in problems when multiple things want to watch metadata.
>>
>> 2) Dropping versioning from AVDict and setting a flag in
>> AVFormatContext, AVStream, etc would require modifications to each
>> demuxer to know about the flags and when to set them. It's been
>> mentioned that modifying AVDict with a version just seems too
>> single-use for living in a generic structure, but off the top of my
>> head, the following use versions/some form of change tracking for hash
>> tables: glib, Java, Python, C#, objective-c. This is, I think, a
>> fairly-normal pattern that is actually kinda nice to have around.
>
> I'm not against the version approach and I like better the idea of
> setting it on read since it is a well defined checkpoint.
>
> How the version field is used in those scenarios? Probably we could
> learn from them a little more.
>
> Thanks a lot for helping us improving Libav =)
>
> lu

For all the implementations, I know that the version is primarily used
for iterators; that is, while iterating a dict, the version is checked
after each round to ensure that there have been no modifications to
it, otherwise iteration fails. Unfortunately, none of them expose a
way of checking if a dict has changed based on the version, though
doing so would be as simple as implemented here. So not much to learn
:-\

I'll pull together a modified patch tomorrow that we can all mull over.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to