[FFmpeg-devel] [PATCH] avformat: add option to parse/store ID3 PRIV tags in metadata.

[Richard Shaffer]

On Wed, Jan 17, 2018 at 11:38 AM, wm4 <nfxjfg at googlemail.com> wrote:

> On Wed, 17 Jan 2018 11:10:26 -0800
> Richard Shaffer <rshaffer at tunein.com> wrote:
>
> > [...]
> > I'm also not sure if an option for compatibility is needed. It's
> > > probably fine to prefix the name with something (maybe "id3v2_priv."?),
> > > and always export it.
> > >
> >
> > I guess my thought was that users of ffmpeg/ffprobe might have some
> > scripting or programming around the metadata API, such as dumping
> metadata
> > with -f ffmetadata and then mapping it to a stream later. In those cases,
> > this change might suddenly cause behavior that they weren't expecting.
>
> That's probably a lost cause. The "metadata" the FFmpeg API is full of
> container specific things and rather arbitrary. I don't think it
> matters to invent and export a few new keys.
>
> What needs to be assured is that the entry names can't clash with
> generic tag names (there's a list in avformat.h), which is why I
> suggested adding a prefix to the name.
>
> Although if metadata entries are very long (like big binary blobs)
> there might be a problem. I don't know what's the use of those priv
> tags though.
>

The tags that I have seen are short. However, most ID3v2 frames have a
maximum length of 256MB, even text information frames. If it is a concern,
we should probably implement a limit for ID3 tags generally.

>
> > Maybe that would be mitigated to some degree if we could also map
> > 'id3v2_priv' back to PRIV tags on output. That would actually address a
> use
> > case that I have and would be super from my standpoint. I'll work on
> > implementing that. Please let me know if you have additional thoughts.
>
> Probably makes sense.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>