On Wed, Jan 17, 2018 at 11:38 AM, wm4 <nfx...@googlemail.com> wrote: > On Wed, 17 Jan 2018 11:10:26 -0800 > Richard Shaffer <rshaf...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
