sync_byte error freezes demuxer

[dbussert]

If the demuxer hits a sync_byte that is not 0x47 it will freeze the video and be unable to progress demuxing the next packets. This is what's seen in chrome dev console. The MPEG-TS source is doing some weird stuff to the stream, padding/fragmenting the UDP payload to not be exactly a multiple of 188 bytes.

In a scenario where this.first_parse_ is false, then offset is 0 but this code will break and return a 0 offset, and the demuxer will be stuck trying to read the sync_byte that is not 0x47 infinitely.

if (sync_byte !== 0x47) {
                Log.e(this.TAG, `sync_byte = ${sync_byte}, not 0x47`);
                break;
            }

[Itrasis]

I had the same issue using FFmpeg and sending via UDP to my server, try to add pkt_size=1316 at the end of the url

udp://[adress]:[port]?pkt_size=1316

[yaruno]

I ran to a similar issue while transporting mpegts over websocket protocol. It seems that sometimes the data packets get lost and then the sync byte is no longer where it should be, but the mpegts.js seems to have a convenience function on ts demuxer class to find it: probe function. You could try to use it in similar fashion as I did to confirm where the correct sync byte is on the received chunk. This seemed to handle my issues related to sync bytes.