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

[Tomas Härdin]

mån 2024-07-01 klockan 16:51 +0200 skrev Anton Khirnov:
> 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 at 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 at 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?

*cough* lavu/eval.* *cough*

But yeah there's probably no way to make everyone happy with something
like this. In practice plenty of users maintain their own forks to
cover their own obscure use-cases

/Tomas