[FFmpeg-devel] Re: [PATCH] av1_in_ts_v2 (PR #21307)

[mypopy--- via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

On Wed, Jan 7, 2026 at 9:26 PM Christophe Gisquet via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
> Hi,
>
>
> Le dim. 28 déc. 2025, 19:46, Jun Zhao via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> a écrit :
>
> > PR #21307 opened by Jun Zhao (mypopydev)
> > URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21307
> > Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21307.patch
> >
> > This patch series V2 adds support for carrying AV1 video streams in MPEG-2
> > Transport Stream
> > containers, following the AOM "Carriage of AV1 in MPEG-2 TS" specification.
> >
> >   Key Features
> >
> >   - MPEG-TS Muxer: Converts AV1 from Section 5 (low overhead) format to
> > start code format,
> >   where each OBU is prefixed with a 0x000001 start code. Includes
> > Registration Descriptor ('AV01')
> >   and AV1 Video Descriptor (0x80) in PMT.
> >   - MPEG-TS Demuxer: Identifies AV1 streams by stream_type 0x06 (private
> > data) and
> >   Registration Descriptor. Outputs AV1 data in start code format.
> >   - av1_tstosection5 BSF: Converts AV1 from MPEG-TS start code format back
> > to Section 5
> >   format for compatibility with other containers and decoders.
> > Automatically inserted when
> >   remuxing to MP4, MKV, FLV, IVF, and raw OBU files.
> >   - Decoder Support: Both libdav1d and libaom decoders can directly decode
> > AV1 in start code format.
> >
>
> I haven't followed that AoM activity in a very long time, but from what I
> remember, there was a big reason why it remained a draft, as there was no
> consensus/decision possible for some of the features (maybe start code).
>
> I think the previously mentioned wisdom that ffmpeg shouldn't generate
> files that could end up not being spec-compliant, should be applied here as
> well. Ie maybe delay merging this until there is clear indication the
> implemented features are no longer subject to change.
>
> Note that for RTP, it was more about being lost in limbo, with little
> interop (ie between vendors) really possible, and with a global agreement
> on all classical points. I don't think what was merged in ffmpeg ended up
> non-spec compliant, but it could be argued it was out of luck.
>
> Mostly my 2 cents,
> Regards,
> Christophe

My perspective is as follows:

As James Almer pointed out in his response, the current merge request
has already removed the muxer component, so there won't be any
compatibility issues, even if the specification is still in draft
status.
AV1 in TS is already being utilized in certain scenarios, and we also
need an implementation to validate this specification concurrently.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org