Re: [FFmpeg-devel] [RFC] Documenting metadata keys, informative (non-copied) metadata

["Tomas Härdin" <git@haerdin.se>]

tis 2025-02-18 klockan 18:35 +0100 skrev Marvin S.:
> 
> 
> On 18 Feb 2025, at 17:56, Tomas Härdin wrote:
> 
> > tor 2025-02-13 klockan 12:54 +0100 skrev Tomas Härdin:
> > > Hi
> > > 
> > > In the samples_md5 patch discussion Michael wanted the proposed
> > > key
> > > to
> > > be documented. But it turns out we don't have any documentation
> > > for
> > > metadata keys! So I'm starting this thread to talk about it. I
> > > reckon
> > > we create a new file called doc/metadata_keys.texi with a table
> > > listing
> > > keys and where they can appear (format, stream, frames), sorted
> > > by
> > > name, with a brief description of each one. Any keys that require
> > > more
> > > detailed documentation we could add sections for.
> > > 
> > > Another issue raised was that some metadata keys shouldn't be
> > > carried
> > > over automatically to muxers. In the samples_md5 thread it was
> > > pointed
> > > out by Andreas that we don't want to mux that in AIFF. It was
> > > also
> > > pointed out that it stops being valid if the audio is cut. This
> > > isn't
> > > the first time I've come across cases where we don't want
> > > metadata to
> > > be copied, so I'm taking the opportunity to propose informative
> > > output-
> > > only metadata could reside in their own namespace. I propose
> > > info:
> > > for
> > > that, so info:samples_md5 in this specific case, or maybe just
> > > info:md5. HEVC frames could similarly have such metadata applied.
> 
> In reference to the AVDictionary patches (it was an attachment so I
> can
> not comment inline):
> 
> IMHO such handling doesn't belong in an abstract container class.
> 
> It is surprising behaviour that a dictionary cares about
> how the keys look (beyond the case-sensitive handling).
> 
> I am not saying this isn't useful but I do not think it belongs in
> AVDictionary directly.

Fair enough. Having a separate internal function for it removes the
need for the flag as well

/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".