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

[James Almer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2442 bytes --]

On 1/7/2026 10:25 AM, Christophe Gisquet via ffmpeg-devel 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

Muxing was removed from the PR, so that should not be an issue. 
Supposedly, the existing draft is being used by some content deliver 
services, but I'm not sure how widespread is support for it out there.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org