Hi, On Fri, Apr 29, 2011 at 12:45 PM, Clément Bœsch <ubi...@gmail.com> wrote: > On Fri, Apr 29, 2011 at 07:27:26AM +0200, Vladimir Pantelic wrote: >> On 04/28/2011 05:10 PM, Ronald S. Bultje wrote: >> >Hi, >> > >> >On Thu, Apr 28, 2011 at 3:05 PM, Clément Bœsch<ubi...@gmail.com> wrote: >> >>This patch allows users to be notified about track switch on a continuous >> >>audio stream. The A-V statusbar mess up a bit the printing sometimes, I >> >>don't know how I should handle that. Also, I wonder if there is an >> >>performance issue looping on every metadata that often. >> > >> >Seems like a case where introducing a "metadata_changed" message >> >somewhere would help. Maybe in AVPacket.side_data? :-). > > This is not really simple to handle when you are in the metadata scope: > metadata functions don't have access the AVPacket, it would require a few > changes. > >> >> since metadata can change out-of-band, what pkt would you attach it to? >> >> why not make a simple counter in metadata that increases on each change, >> then users don't have to md5sum it to know if it was modified? > > I tried that, but it would require an API modification, and actually it > does not work for a simple reason: the metadata allocation is completely > destroyed and a new one is created on track switch. So you might have the > same amount of "update count" (which is actually the same value as the > count field) while it's total different values. > > But, the good news is that since it's a different pointer, we can just > based the code on this. Of course, this is assuming all other continuous > streams demuxers won't add new fields and purges the old ones, but it > looks improbable because of the complexity. > > New simpler patch attached.
Not that I'm completely against this patch, after all it's only metadata (don't take that badly Anton), but the update wouldn't reflect when it took effect. I think that is what side_data is for. In fact, I believe metatadata should be moved entirely into side-data when it updates midstream, just like palettes. Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
