Synchronous data has no payload in processed stream

[dbussert]

I have a MPEG-TS video with 2 data pids, one is synchronous and one async. The async is processed by mpegts-demuxer correctly and provides a payload, but the synchronous never has a payload (and I've verified through other tools there is one). The packet output looks like this

Stream {
  program: 1,
  id: 2,
  type: 0,
  stream_id: 252,
  content_type: 0,
  dts: 886033149,
  has_dts: true,
  first_pts: 885961077,
  last_pts: 886033149,
  has_pts: true,
  frame_ticks: 3003,
  frame_num: 125,
  payload: null
}

I've verified the same behavior in a video with only H.264 video and a synchronous data PID. Any idea why the payload is always null for synchronous data?

[slifty]

I'll take a look!

Would you be able to share a video file and a code snippet that exhibits this problem? That'll make it a bit easier for me to debug.

[dbussert]

I will try to find a video I can share. Is there an email I can send to? I've been digging in and I believe it's because of this block, which does not write a payload for unknown types. The type is 0 for this PID, TSDuck calls it Metadata in PES Packets.

if (s.stream_id && s.content_type !== _constants.MEDIA_TYPES.unknown) {
    const packet = s.write(mem, ptr, len, pstart, copy);
    if (packet) cb(packet);
  }

I added the 0x00 type into the getMediaType function, and now it will output a payload, but the payload isn't quite what I'm expecting. There's fragments and duplicates of the same payload being emitted. Possibly some parsing isn't quite right.

[slifty]

Sure thing -- email is my github handle and I use gmail (being cryptic to avoid the spam bots, though it's probably a lost cause).

[dbussert]

sent, lmk if you received

[slifty]

@dbussert got it! I'm wrapping up a deadline today but hoping to be able to dig in by the end of the week.

[dbussert]

hey, any chance to look at this? I've modified my packaged to allow payloads on type 0, but I imagine there is a more valid fix you might know of

[slifty]

@dbussert I apologize profusely for disappearing -- I hit a series of consecutive deadlines that pulled me away.

I'm glad you have solved this locally for the short term, but you're right this warrants trying to find the most correct solution (and patching the package). Just wanted to let you know I'm still planning to take this on (and wanting to confirm that you do indeed have a temporary solution that has unblocked you)