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

[Tomas Härdin]

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

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

> 
> Can it be propagated within the InputStream?

This is what my earlier patch ([PATCH] ffmpeg: Add -copystreamid) did,
grabbing them from ist->st->id

/Tomas