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

["Tomas Härdin" <git@haerdin.se>]

mån 2024-04-15 klockan 21:33 -0300 skrev James Almer:
> On 4/15/2024 9:30 PM, Michael Niedermayer wrote:
> > On Mon, Apr 15, 2024 at 10:35:44AM +0200, Tomas Härdin wrote:
> > > lör 2024-04-13 klockan 01:25 +0200 skrev Michael Niedermayer:
> > > > On Fri, Apr 12, 2024 at 11:40:47AM +0200, Tomas Härdin wrote:
> > > > > 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
> > > > 
> > > > >   fftools/ffmpeg_demux.c              |    5 +++
> > > > >   fftools/ffmpeg_mux_init.c           |   56
> > > > > ++++++++++++++++++++++++++----------
> > > > >   tests/ref/fate/matroska-stereo_mode |    6 +--
> > > > >   3 files changed, 49 insertions(+), 18 deletions(-)
> > > > > cd526b2292b6d7e3fb5739a04cf17fbe5f207f16  0001-ffmpeg-Carry-
> > > > > streamid-as-metadata-key-id.patch
> > > > >  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).
> > > > > ---
> > > > >   fftools/ffmpeg_demux.c              |  5 +++
> > > > >   fftools/ffmpeg_mux_init.c           | 56
> > > > > +++++++++++++++++++++----
> > > > > ----
> > > > >   tests/ref/fate/matroska-stereo_mode |  6 ++--
> > > > >   3 files changed, 49 insertions(+), 18 deletions(-)
> > > > 
> > > > breaks:
> > > > 
> > > > ./ffmpeg -i ~/videos/mm-short.mpg -vstats_file /tmp/vstats -
> > > > bitexact
> > > > -map 0:1 -map 0:1 -map 0:2 -threads 6 -vcodec libx264 -vcodec
> > > > libx264
> > > > -pass 1 -b:v:0 300k -b:v:1 900k -passlogfile:v:1 /tmp/video2 -
> > > > passlogfile:v:0 /tmp/video1 -t 1 -y -ab 128k  /tmp/x.ts
> > > > 
> > > > [mpegts @ 0x558d5e3b2140] Duplicate stream id 480
> > > 
> > > It's hardly strange if you map the same stream to the output
> > > twice that
> > > you get duplicate streamids
> > 
> > ok but asking for a stream to be mapped twice is a valid case.
> > Ideally FFmpeg should not fail, it should resolve all parameters
> > within what is valid.
> > It could fail if the user explcicitly asks for invalid parameters
> > ...
> 
> mpegts muxer could change the duplicate id for a free one. Afaik the 
> field is documented as being modifiable by muxers. It could also do
> it 
> internally.

That sounds like business logic that belongs further up than in a
muxer. That way more muxers that depend on st->id benefit from it.
ffmpeg_mux_init.c could warn about it and make up unique id's. Default
values could be passed upward via AVOptions

/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-request@ffmpeg.org with subject "unsubscribe".