> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Mittwoch, 16. April 2025 12:53
> To: FFmpeg development discussions and patches <ffmpeg-
> de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
>
> Hi softworkz
>
> On Wed, Apr 16, 2025 at 02:52:21AM +0000, softworkz . wrote:
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> > > Michael Niedermayer
> > > Sent: Mittwoch, 16. April 2025 03:34
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > > decode_str() did advance
> > >
> > > On Wed, Apr 16, 2025 at 01:29:02AM +0000, softworkz . wrote:
> > > [...]
> > > > > > This will cause deserialization errors for many people in
> the
> > > world
> > > > > > who are processing FFprobe data.
> > > > >
> > > > > As said, ffprobe should not produce troublesome output
> >
> > First of all, any patch MUST NOT introduce behavior that goes
> > against our own specifications.
> >
> > From avformat.h:
> >
> > /**
> > * @defgroup metadata_api Public Metadata API
> > * @{
> > * @ingroup libavf
> > * The metadata API allows libavformat to export metadata tags to a
> client
> > * application when demuxing. Conversely it allows a client
> application to
> > * set metadata when muxing.
> > *
> > * Metadata is exported or set as pairs of key/value strings in the
> 'metadata'
> > * fields of the AVFormatContext, AVStream, AVChapter and AVProgram
> structs
> > * using the @ref lavu_dict "AVDictionary" API. Like all strings in
> FFmpeg,
> > * metadata is assumed to be UTF-8 encoded Unicode. Note that
> metadata
> > * exported by demuxers isn't checked to be valid UTF-8 in most
> cases.
> > *
> > * Important concepts to keep in mind:
> > * - Keys are unique; there can never be 2 tags with the same key.
> This is
> > * also meant semantically, i.e., a demuxer should not knowingly
> produce
> > * several keys that are literally different but semantically
> identical.
> > * E.g., key=Author5, key=Author6. In this example, all authors
> must be
> > * placed in the same tag.
> > * - Metadata is flat, not hierarchical; there are no subtags. If
> you
> > * want to store, e.g., the email address of the child of
> producer Alice
> > * and actor Bob, that could have
> key=alice_and_bobs_childs_email_address.
> > * - Several modifiers can be applied to the tag name. This is done
> by
> > * appending a dash character ('-') and the modifier name in the
> order
> > * they appear in the list below -- e.g. foo-eng-sort, not foo-
> sort-eng.
> > * - language -- a tag whose value is localized for a particular
> language
> > * is appended with the ISO 639-2/B 3-letter language code.
> > * For example: Author-ger=Michael, Author-eng=Mike
> > * The original/default language is in the unqualified
> "Author" tag.
> > * A demuxer should set a default if it sets any translated
> tag.
> > * - sorting -- a modified version of a tag that should be used
> for
> > * sorting will have '-sort' appended. E.g. artist="The
> Beatles",
> > * artist-sort="Beatles, The".
> >
> >
> > Especially:
> >
> > * E.g., key=Author5, key=Author6. In this example, all authors
> must be
> > * placed in the same tag.
> >
> > I think, this tells very clearly how it's gotta be and how not.
>
> This is written by me 16 years ago
> and it made sense at the time. Our APIs did not support multiple
> values per
> key.
> The API supports multiple values per key since 9 years. Using said API
But it wasn't enabled for metadata, only the recombs patch enabled that, no?
(but, see next message)
sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
