[FFmpeg-devel] [PATCH 0/1] fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED

Stefano Sabatini stefasab at gmail.com
Tue Jan 2 22:01:03 EET 2024


On date Tuesday 2024-01-02 11:34:40 +0000, Kieran Kunhya wrote:
> On Tue, 2 Jan 2024 at 11:27, Stefano Sabatini <stefasab at gmail.com> wrote:
> 
> > On date Monday 2023-12-18 19:06:10 +0000, Kieran Kunhya wrote:
> > > On Mon, 18 Dec 2023 at 14:59, Petr Matousek <
> > petr.matousek at comprimato.com>
> > > wrote:
> > >
> > > > Before this patch being applied the ffprobe just tells the user whether
> > > > the H.26[45] User Data Unregistered SEI message is present in the frame
> > > > side data
> > > > or not. After the patch being appliend it also dumps the contents of
> > the
> > > > data
> > > > similar way as for the other already supported frame side data types.
> > > >
> > > > Petr Matousek (1):
> > > >   fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED
> > > >
> > >
> >
> > > I don't think ffprobe should be dumping potentially large amounts of
> > random
> > > SEI data to the terminal. Some encoders use this space for their own data
> > > and it's annoying to see it spam the terminal.
> >
> > I'm not super concerned by this, since you can filter out the required
> > information. Also I don't see other viable alternatives to show this
> > information (moving this to metadata would require decoding).
> >
> 

> How are you able to filter between different types of unregistered SEI?

At the moment you can opt-in what must be shown (opt-out is not an
option). But from the point of view of the side data, probably there
is no way to filter that out depending on the type. But this can be
done later by processing the data (which is mostly the point of the
output generated by ffprobe).

This is the OP use case after all:
|We needed to verify that our implementation of the MISB ST 0604 produces
|correct contents of the SEI data. Using ffprobe for that was very useful as we
|were able to pair the SEI data with other frame data like the PTS etc.

> This is yet another thing that needs to be done with the API 

I don't understand what you mean by "the API". Provided that the API
exposes the information about the side data type, but not much else at
this level, you still would probably need to postprocess the
data.

> and not the CLI (something this project is unable to understand).

What is exposed by the API is exercised by the CLI (which is a good
thing for scripting and for testing).


More information about the ffmpeg-devel mailing list