-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore the flow of Transport Stream packets if synchronisation is lost #1083
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
I signed it! |
CLAs look good, thanks! |
For me this issue surfaced only when using UDP as the transport. When a TS packet sent by the server is spread across two UDP packets, and one of the UDP packets is lost (which happens quite often since UDP is a lightweight unreliable transport) the TSExtractor goes out of sync. An incomplete TS packet rather than being discarded is fed with wrong bytes from another TS packet. On the server side the fix is to set the UDP payload packet size to a multiple of 188 bytes ( I set it to 7*188 = 1316 bytes). That way even if a UDP packet gets lost, we do not end up with an incomplete TS packet. This worked for me and I never got the issue with TSExtractor again. On the client side I tested the fix by Algrid, and it works even If the server is not configured to send UDP packets of consistent size. This approach should possibly be expanded so that on any error detected in the current TS packet the extractor should rollback to the sync bit of this TS packet and search for the next sync bit from there. |
# Conflicts: # library/src/main/java/com/google/android/exoplayer/extractor/ts/TsExtractor.java
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
CLAs look good, thanks! |
# Conflicts: # library/src/main/java/com/google/android/exoplayer/extractor/ts/TsExtractor.java
In my case it fixed problems with MPEG2 TS over HTTP. |
…r lost sync. Issue: #1332 Issue: #1101 Issue: #1083 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=125659191
I believe we've fixed this in |
For some reason TsExtractor can get a TS packet with wrong length and all the following packets become shifted by several bytes which completely breaks the video playback. This code restores the synchronisation if it's possible.
See: #90