Something is weird with pts vs dts

Bug

Current Behavior

I'm not exactly sure what the root cause of this is, but the TSDemuxer output is doing very odd things with pts when decoding my local HDHomeRun stream.

pts and dts track comparably at first, but randomly pts will jump wildly, eventually capping out at close to the maximum int value.

Here is some example output of the decoded packets at a jump point (note the pts vs dts values)

{
  data: Uint8Array(3692) [
      0,   0,   1,   0,   5, 159, 255, 251, 184,   0,   0,   1,
    181, 129,  33,  19, 148,   0,   0,   0,   1, 178,  71,  65,
     57,  52,   3, 212, 255, 252, 128, 128, 253, 128, 128, 250,
      0,   0, 250,   0,   0, 250,   0,   0, 250,   0,   0, 250,
      0,   0, 250,   0,   0, 250,   0,   0, 250,   0,   0, 250,
      0,   0, 250,   0,   0, 250,   0,   0, 250,   0,   0, 250,
      0,   0, 250,   0,   0, 250,   0,   0, 250,   0,   0, 250,
      0,   0, 250,   0,   0, 255,   0,   0,   1, 178,  68,  84,
     71,  49,  65, 250,
    ... 3592 more items
  ],
  pts: 783093,
  dts: 780090,
  frame_ticks: 3003,
  program: 1,
  stream_number: 1,
  stream_id: 224,
  type: 1,
  content_type: 2,
  frame_num: 45
}
{
  data: Uint8Array(4446) [
      0,   0,   1,   0,   6,  95, 255, 251, 184,   0,   0,   1,
    181, 129,  18,  19, 148,   0,   0,   0,   1, 178,  71,  65,
     57,  52,   3, 212, 255, 252, 128, 128, 253, 128, 128, 250,
      0,   0, 250,   0,   0, 250,   0,   0, 250,   0,   0, 250,
      0,   0, 250,   0,   0, 250,   0,   0, 250,   0,   0, 250,
      0,   0, 250,   0,   0, 250,   0,   0, 250,   0,   0, 250,
      0,   0, 250,   0,   0, 250,   0,   0, 250,   0,   0, 250,
      0,   0, 250,   0,   0, 255,   0,   0,   1, 178,  68,  84,
     71,  49,  65, 250,
    ... 4346 more items
  ],
  pts: 4920870,
  dts: 786096,
  frame_ticks: 3003,
  program: 1,
  stream_number: 1,
  stream_id: 224,
  type: 1,
  content_type: 2,
  frame_num: 47
}

After the jump, pts sits at 4920870 for a while until it jumps again to 1080269556 and then again to another high, capping at 2147279797 (close to int max)

There are a few paths forward:

1) switch to dps which in this isntance is more stable, though I would want to think about what the meaningful difference between dps and pts are before doing this. 2) Debug the stream / potentially patch TSDemuxer.

I'm worried about the implications of the true debug, since the issue could even be with the HDHomeRun stream somehow (firmware update happened recently).

Logging some output from TSDemuxer at the point in which pts explodes:

Stream {
  program: 1,
  id: 1,
  type: 1,
  stream_id: 224,
  content_type: 2,
  dts: 4851852,
  has_dts: true,
  first_pts: 186342,
  last_pts: 4860861,
  has_pts: true,
  frame_ticks: 3002,
  frame_num: 1402,
  payload: {
    buffer: [
      [Uint8Array],
      [Uint8Array],
      [Uint8Array],
      [Uint8Array],
      [Uint8Array]
    ],
    buflen: 906,
    pts: 4851852,
    dts: 4848850,
    frame_ticks: 1
  }
}

PTS AND DTS
Stream {
  program: 1,
  id: 1,
  type: 1,
  stream_id: 224,
  content_type: 2,
  dts: 4860861,
  has_dts: true,
  first_pts: 186342,
  last_pts: 21894215,
  has_pts: true,
  frame_ticks: 9009,
  frame_num: 1403,
  payload: {
    buffer: [
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array],
      ... 156 more items
    ],
    buflen: 47022,
    pts: 4860861,
    dts: 4851852,
    frame_ticks: 3002
  }
}

I notice a few things, though I don't know if these are symptomatic of the issue

The buffer in the offending output has 200 items
There are 3002 frame ticks (instead of 1)
The buflen is 47022 vs 906

I don't know if this is related, but I'm also getting occasional errors from the demuxer:

RangeError: Offset is outside the bounds of the DataView
    at DataView.getUint8 (<anonymous>)
    at demux_packet (/Users/slifty/Dropbox/Code/NodeJS/tvkitchen/appliances/node_modules/ts-demuxer/dist/index.js:401:13)
    at TSDemuxer.process (/Users/slifty/Dropbox/Code/NodeJS/tvkitchen/appliances/node_modules/ts-demuxer/dist/index.js:484:23)
    at Transform._transform (/Users/slifty/Dropbox/Code/NodeJS/tvkitchen/appliances/packages/core/lib/AbstractVideoIngestionApplian)
    at Transform._read (_stream_transform.js:191:10)
    at Transform._write (_stream_transform.js:179:12)
    at doWrite (_stream_writable.js:454:12)
    at writeOrBuffer (_stream_writable.js:436:5)
    at Transform.Writable.write (_stream_writable.js:327:11)
    at Socket.ondata (_stream_readable.js:708:22)
error Command failed with exit code 1.

Indeed when I catch the error around that line (if (mem.getUint8(ptr) !== 0x47) {), ptr is negative.

Further looking into the values right after the failure process I see

                console.log("---")
                console.log(ptr) // -112
                console.log(offset) // -112
                console.log(PACKET_LEN) // 188
                console.log(remainder) // -112
                console.log(this.ptr) // 8304
                console.log(datalen) // 8304
                console.log(len) // 8192

I also tied swapping out the HDHomeRun, which is running older firmware, and that does actually seem to improve the PTS calculations.

It's not clear to me if the PTS issues are related to the overflow issues, but it does look more and more like there may be a bug in the demuxer. The demux project is dead right now, which means I may end up needing to fork it / release under TVK with a patch.

Running the stream JUST through ffmpeg (e.g. curl 192.168.1.94:5004/auto/v10.1 | ffmpeg -i - -codec copy out470.t) reveals a ton of corrupt packets. This isn't ideal (and I suspect is related to the antenna), but it is also something that TVK should be able to handle without blowing up in various ways.

This StackOverflow answer shows that it's possible to have ffmpeg just drop corrupt packets by adding -err_detect aggressive -fflags discardcorrupt.

The tradeoff might be that content might drop from a stream entirely which could have some basic data, but I feel that's worth it if it means we can rely on the content that's there.

I tried adding those flags to the ingestion appliance and so far it seems to have prevented either issue from manifesting. For now I am inclined to pursue that as the fix. If this manifests again some day (or it turns out that dropping the packets is causing some other trouble) then I suppose we will want to dive into the above work a bit more.

tvkitchen / appliances

Something is weird with pts vs dts #94

Bug

Current Behavior