On 1/13/2026 6:50 AM, Nicolas Gaullier via ffmpeg-devel wrote:
> 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 ?

Yes, it will be part of the PR. The current code in the PR exports each 
frame separately, exactly as it was muxed, when an entire TU should be 
exported instead. That's what the parser will handle.

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