[FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> softworkz .
> Sent: Mittwoch, 16. April 2025 00:59
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Michael Niedermayer
> > Sent: Mittwoch, 16. April 2025 00:50
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > decode_str() did advance
> >
> > On Tue, Apr 15, 2025 at 07:59:00PM +0000, softworkz . wrote:
> > [...]
> >
> > > - The representation of multi-values - both, internally and when
> > >   outputting as probe data - is a de-facto standard
> >
> > The external handling in formats is specified in the corresponing
> > specifications. ";" is certainly not correct for formats which
> > natively support multiple values per key.
> >
> > Internally, if you have a data structure that represents multiple
> > authors, you certainly do not set it to one author and a string
> > with a bunch of semicolons seperating multiple authors
> >
> > Title: "Smile ;)"
> > Author "Smily Face ;)"
> >
> > is not 2 Titles and not 2 Authors and software that cannot handle
> that
> > should not be used as reference IMHO
> >
> > That said, anything that works is fine with me,
> >
> > But internally it will be better to use a representation that is
> > universal, generic and simple, ";" may seem to be that but only
> > as long as you do nothing with it and dont care about corner cases
> >
> > Ill leave this ";" question to everyone else, i have a backlog
> > of quite a few things i need to work on
> 
> This is not a great outcome, because "leaving everyone else" means
> nothing will happen.
> 
> At least revert the rcombs patch until there's a conclusion, because
> it really makes things worse than better with regards to FFprobe
> output.
> This will cause deserialization errors for many people in the world
> who are processing FFprobe data.
> 

Besides, the patch had been submitted 3 years ago, there hasn't been 
any review and the merge was totally unexpected.

Thanks
sw