fix: Tolerate misaligned TS files

All TS packets are expected to start with the sync byte 0x47, and
TS files are expected to start at the start of a packet. Because of
that, we assumed that any TS file that did not start with the sync
byte of 0x47 is invalid.
However, it is possible that a TS file might not start on a sync
byte... perhaps the first few bytes got cut off, for some reason?
In those cases, it would be better to just drop that cut-off first
packet, instead of entirely rejecting the TS file.
This CL changes the HLS parser to keep looking forward for the
length of a few packets for the first sync byte, when parsing TS
files to try to find their start time.

Closes shaka-project#3580

Change-Id: I0bace4b3a84398e09046828d749f3f025dfad26f

lib/hls/hls_parser.js

@@ -2350,6 +2350,12 @@ shaka.hls.HlsParser = class {
       reader.rewind(1);
     };
 
+    // We will look a few packet-lengths forward to find the first sync byte.
+    // Note that we are using this method on what is already a subset of the
+    // file (the first |shaka.hls.HlsParser.START_OF_SEGMENT_SIZE_| bytes), so
+    // we can't look too far ahead to begin with.
+    let syncByteScanLength = Math.min(reader.getLength() - 188, 5 * 188);
+
     // TODO: refactor this while loop for better readability.
     // eslint-disable-next-line no-constant-condition
     while (true) {
@@ -2358,8 +2364,16 @@ shaka.hls.HlsParser = class {
 
       syncByte = reader.readUint8();
       if (syncByte != 0x47) {
+        if (syncByteScanLength > 0) {
+          // This file could have started with a cut-off TS packet. Scan forward
+          // until we find a sync byte.
+          syncByteScanLength -= 1;
+          continue;
+        }
         fail();
       }
+      // If we've found a sync byte, stop scanning forward for future packets.
+      syncByteScanLength = 0;
 
       const flagsAndPacketId = reader.readUint16();
       const packetId = flagsAndPacketId & 0x1fff;