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.patchAdd 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 (whichWhere 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 -- [email protected] To unsubscribe send an email to [email protected]
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
