[cpruijsen]

Summary

TransportParseStream.parsePat now reads section_number and last_section_number at payload[6] and payload[7]. After parsePsi skips pointer_field, those fields are at payload[6] and payload[7], not [7] and [8], so the old read was one byte too late (ISO/IEC 13818-1 2.4.4.3). parsePmt already uses the same PSI header indexing (payload[5] = current_next_indicator).

pmtPid at payload[10]/[11] is unchanged. That matches the reporter and the spec; the in-tree PAT fixture already depended on it.

A QUnit case copies the shared PAT fixture and sets distinctive section numbers. The fixture zeros both fields, which hid the off-by-one against last_section_number / program_number.

Fixes #432.

Decision

Only the two section-number indexes change. That matches the issue, the spec, and parsePmt. Nothing in this repo reads the section fields today (ElementaryStream's PAT handler is empty), but they are still emitted on the PAT data event.

The alternative is to skip a leading program_number == 0 (NIT) when selecting pmtPid, or to stop attaching the unused section fields. Can switch to skipping NIT entries or dropping the unused fields.

Test plan

• npx qunit test/dist/bundle.js --filter "parses section_number and last_section_number from the PAT" fails on the old indexes (actual 5 and 0) and passes with this change
• npx qunit test/dist/bundle.js --filter "MP2T TransportParseStream" (9 tests)
• npx qunit test/dist/bundle.js (338 passed, 4 skipped)
• Existing transmux of a real HLS TS still finds the PMT (PID path unchanged)

[cpruijsen]

Closing this. Not something I'm going to keep current.