On date Saturday 2024-03-09 19:56:49 -0600, Marth64 wrote: > Following up on this from December 2023. I simplified the content and > hopefully addressed the feedback. > > Signed-off-by: Marth64 <mart...@proxyid.net> > --- > doc/bitstream_filters.texi | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi > index e06de1a73a..61539d2473 100644 > --- a/doc/bitstream_filters.texi > +++ b/doc/bitstream_filters.texi > @@ -213,6 +213,21 @@ To remove all AUDs, SEI and filler from an H.265 stream: > ffmpeg -i INPUT -c:v copy -bsf:v 'filter_units=remove_types=35|38-40' OUTPUT > @end example > > +To remove all user data from a MPEG-2 stream, including Closed Captions: > +@example > +ffmpeg -i INPUT -c:v copy -bsf:v 'filter_units=remove_types=178' OUTPUT > +@end example > + > +To remove all SEI from a H264 stream, including Closed Captions: > +@example > +ffmpeg -i INPUT -c:v copy -bsf:v 'filter_units=remove_types=6' OUTPUT > +@end example > + > +To remove all prefix and suffix SEI from a HEVC stream, including Closed > Captions and dynamic HDR: > +@example > +ffmpeg -i INPUT -c:v copy -bsf:v 'filter_units=remove_types=39|40' OUTPUT > +@end example > +
Not against, but I'm not super convinced this is super useful as it does not really explain what these values come from. Probably it would be more useful a table, or even better make the parser somehow expose the supported types with the meaning (this would enable having e.g. a symbolic type "cc" abstracting the containter format). OTOH I agree thius would provide some practical examples, therefore I'll apply while we have no smarter way to expose the logic in a more effective way. Thanks. _______________________________________________ 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".
