On date Tuesday 2024-01-02 11:34:40 +0000, Kieran Kunhya wrote: > On Tue, 2 Jan 2024 at 11:27, Stefano Sabatini <stefa...@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.matou...@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). _______________________________________________ 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".
