Re: [FFmpeg-devel] [PATCH] ffmpeg: Carry streamid as metadata key 'id'

[Anton Khirnov <anton@khirnov.net>]

Quoting Tomas Härdin (2024-04-16 16:12:13)
> tis 2024-04-16 klockan 09:52 -0300 skrev James Almer:
> > On Tue, Apr 16, 2024 at 9:38 AM Anton Khirnov <anton@khirnov.net>
> > wrote:
> > 
> > > Quoting Tomas Härdin (2024-04-12 11:40:47)
> > > > This idea could be extended to other fields not presently
> > > > considered to
> > > > be metadata, that would be handy to treat as such.
> > > > 
> > > > I use the key "id" because ffprobe outputs id= for streamid.
> > > > Another
> > > > option could be to collect these types of metadata that go into
> > > > AVStream fields under a namespace like FFMPEG: or AVSTREAM: or
> > > > something, then delete all of them using AV_DICT_IGNORE_SUFFIX
> > > > near the
> > > > end of of_open() since they're for internal ffmpeg use.
> > > > 
> > > > The FATE change is just because av_dict() changes the order of
> > > > things
> > > > when elements are deleted.
> > > > 
> > > > /Tomas
> > > > 
> > > > From 7799f1b2eb8ab02e58118565f3e889fbe0d568a7 Mon Sep 17 00:00:00
> > > > 2001
> > > > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= <git@haerdin.se>
> > > > Date: Fri, 12 Apr 2024 10:34:12 +0200
> > > > Subject: [PATCH] ffmpeg: Carry streamid as metadata key 'id'
> > > > 
> > > > This allows using -map_metadata and -metadata to copy/set
> > > > streamids
> > > (PIDs).
> > > 
> > > I dislike this patch, metadata is the wrong place for such
> > > information.
> 
> Seems like a matter of taste to me, but maybe I'm missing something

It's not just a matter of taste - it's happened several times already
that people (ab)used metadata to carry structured information and then
it turned out it was a bad idea and we had to change it to a real API.

Metadata really should only be used for unstructured user-facing
information like title/author/etc.. It's a terrible mechanism for other
usecases, because it's an implicit API hidden from the compiler, with no
type information, stability guarantees, deprecation mechanisms, etc. Not
to mention it forces users to parse and serialize strings, which is a
massive pain and a constant source of bugs, especially in C.

> In the very common case where users want to copy PIDs from inputs to
> outputs, implementing -map_streamid seems a bit silly. Consider also
> the case where the user wants to copy codec and bitrate from some
> source stream, such as when filtering audio. It would be nice if such
> operations were handled by a common mechanism. Call it -map_params
> perhaps

How long until ffmpeg CLI options are turing complete?

-- 
Anton Khirnov
_______________________________________________
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".