There seems to be two different issues:
1) stream contains lot of broken TS packets (MDAPI in use or bad signal).
This issue can be fixed by allowing TsReader to scan the TS file for longer amout of data to detect the video content. CDeMultiplexer:tart() should be modified to allow that to happen. I see no risks in that (could only cause longer stall for video playback startup when the file is invalid)
2) Something funky with the A/V sync code or timestamps
TsReader tries to correct the A/V sync compensation after the TS clip is played a bit. I cannot fix this since I don't know enough how current A/V sync code in TsReader works. Hopefully Ambass has some time to check this later.
I'm currently posponing the issue to RC4 since Ambass is really busy with non-MP related things.
1) stream contains lot of broken TS packets (MDAPI in use or bad signal).
This issue can be fixed by allowing TsReader to scan the TS file for longer amout of data to detect the video content. CDeMultiplexer:tart() should be modified to allow that to happen. I see no risks in that (could only cause longer stall for video playback startup when the file is invalid)
2) Something funky with the A/V sync code or timestamps
TsReader tries to correct the A/V sync compensation after the TS clip is played a bit. I cannot fix this since I don't know enough how current A/V sync code in TsReader works. Hopefully Ambass has some time to check this later.
I'm currently posponing the issue to RC4 since Ambass is really busy with non-MP related things.