> > > +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-requ...@ffmpeg.org with subject "unsubscribe".
