From: "Tomas Härdin" <git@haerdin.se> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: add h264_mp4toannexb bitstream filter if needed when muxing h264 Date: Sat, 24 Feb 2024 12:38:42 +0100 Message-ID: <3d02da5b295e4849c2323bcf2ded273c783853ed.camel@haerdin.se> (raw) In-Reply-To: <29f39ed4-a2d3-e675-6b9a-2e54f6bec09f@passwd.hu> > > > +static int mxf_check_bitstream(AVFormatContext *s, AVStream *st, > > > const AVPacket *pkt) > > > +{ > > > + if (st->codecpar->codec_id == AV_CODEC_ID_H264) { > > > + if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x0000001 && > > > + AV_RB24(pkt->data) != 0x000001) > > > + return ff_stream_add_bitstream_filter(st, > > > "h264_mp4toannexb", NULL); Regardless of the comments below, this is wrong. ST 381-3 says this: > The byte stream format can be constructed from the NAL unit stream by > prefixing each NAL unit with a start > code prefix and zero or more zero-valued bytes to form a stream of > bytes. Note the wording is "zero or more", not "zero or one". The correct way to do this is to inspect byte 14 of the EC UL, per section 8.1 of ST 381-3. > > > I sent the very same patch long ago [1]. Tomas Härdin opposed it > > [2], > > [3], because he sees stuff like this as hack. No, I oppose it because it is potentially against spec. The MXF ecosystem is bad enough as it is without us encouraging out-of-spec behavior. Any behavior we put in to handle out-of-spec behavior should be limited by Identification. But even that would be making our responsibility what is really the responsibility of companies making broken MXF muxers. /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".
next prev parent reply other threads:[~2024-02-24 11:39 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-23 0:19 Marton Balint 2024-02-23 1:26 ` Andreas Rheinhardt 2024-02-23 19:55 ` Marton Balint 2024-02-24 11:38 ` Tomas Härdin [this message] 2024-02-24 14:13 ` Andreas Rheinhardt 2024-03-05 23:14 ` Marton Balint 2024-03-06 21:59 ` Tomas Härdin 2024-03-08 1:27 ` Marton Balint
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3d02da5b295e4849c2323bcf2ded273c783853ed.camel@haerdin.se \ --to=git@haerdin.se \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git