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

[Nicolas Gaullier via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

On 1/12/26 22:05, James Almer via ffmpeg-devel wrote:
> On 1/12/2026 1:31 PM, Nicolas Gaullier via ffmpeg-devel wrote:
>> On 12/28/25 19:45, Jun Zhao via ffmpeg-devel wrote:
>>> 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
>>>
>>> Add functions to parse AV1 OBUs in MPEG-TS start code format
>>> (0x000001 prefix). This is needed for AV1 streams from MPEG-TS
>>> containers per AOM AV1 in MPEG-2 TS specification.
>>
>> I have some questions around aligned PES and start codes; please correct
>> me if I am wrong.
>>
>> Start codes: it seems to me current PR autodetects start codes, which
>> means if a stream miss them, it would still be successfully decoded.
>> This is possible because, additionally, AV1 requires aligned PES (which
>
> Where does the spec say that?

3.4 : "All the PES shall have data_alignment_indicator set to 1. Usage 
of *data_stream_alignment_descriptor* is not specified and the only 
allowed *alignment_type* is 1 (Access unit level)."

But anyway, at the end, it does not matter if packet repacking is to be 
implemented just afterwards as you say (if I catch it correctly, it will 
be required for muxing).

> like that. We're reading a file and trying to make sense of its
> contents. What other readers can or can't do is irrelevant.

I understand your point, that makes it clear and it is ok if everybody 
is comfortable with that.

> I already wrote an implementation for Temporal Unit assembly in
> av1_parser, but I'm waiting until all is said and done, and probably an
> actual sample is provided.

This makes me think of a latest very specific question but again, I 
could be mistaken - correct me if am wrong - after this PR 21307, an 
out-of-spec stream with missing start codes will be playable (frames 
split at PES boundaries), but later on, once packet repacking 
implemented, it wont be (frames split by looking for start codes) ? In 
case I get this right, maybe the future merge of PR 21307 would have to 
be delayed until your complementary work is also ready to be merged at 
the same time ?

Nicolas

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