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 <an...@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?= <g...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
