Skip to main content

assembly of sections that span multiple packets

2 replies [Last post]
michael_sanjose
Offline
Joined: 2009-03-02

Are there any known issues in the RI regarding the assembly of MPEG sections that span multiple packets? We're currently investigating some section data being passed up from the stack that looks suspicious.

We have a single section that spans two packets:

Packet #1 is composed of:

sync_byte: 71 (0x47)
transport_error_indicator: 0
payload_unit_start_indicator: 1
transport_priority: 0
PID: 1770 (0x6EA)
transport_scrambling_control: 0
adaptation_field_control: 1
continuity_counter: 1
pointer_field: 0x00

followed by the following section data:

table_id: 227 (0xE3)
section_syntax_indictor: 0
private_indicator: 1
reserved: 0
section_length: 183 (0xB7)
<180 bytes of section data>

Packet #2 is comprised of the 3 remaining section bytes from the first packet, followed by the beginning of a separate section:

sync_byte: 71 (0x47)
transport_error_indicator: 0
payload_unit_start_indicator: 1
transport_priority: 0
PID: 1770 (0x6EA)
transport_scrambling_control: 0
adaptation_field_control: 1
continuity_counter: 2
pointer_field: 0x03

<3 remaining bytes from section #1, followed by the first 180 bytes of the next section>

When this section is finally retrieved from the stack by one of our Xlets, the data is slightly incorrect. Rather than read the 3 remaining bytes from packet #2, it appears that the pointer_field was incorrectly interpreted as part of section #1's payload rather than an offset pointer to the start of section #2.

This suggests there's a problem somewhere in the pipeline where the payload_unit_start_indicator isn't correctly used to denote the presence of the optional pointer_field byte.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
greg80303
Offline
Joined: 2008-07-03

We did work on an issue in the last release that involved problems with our section assembler. I need Marcin or Steve to comment more on the work they did and if it could be related to the issues seen by the poster.

michael_sanjose
Offline
Joined: 2009-03-02

Further investigation indicated the problem was in the section assembler. We've submitted a patch and logged the bug under:

https://ocap-ri.dev.java.net/issues/show_bug.cgi?id=98

It appears to be a separate (but very similar) issue from the section assembler bug that was previously addressed, but that's for Marcin or Steve to verify.