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