-
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
TS Extractor: Fix problem with corrupt last PCR in recordings #9100
Conversation
Some recorded TV shows are picking up a corrupt value for last PCR in the file. The result is that the recording only plays for a few seconds. In the example provided, the duration came out as a large negative number, and the file played for a few seconds and then reported playback as complete. The logic in TsDurationReader searches backwards in the file looking for a valid PCR. Either it is picking up a corrupt value or it is mis-interpreting other data as if it was a PCR. The fix searches for two PCR values and performs a sanity check to ensure they are within valid range before accepting the value. If they are not valid, it continues searching until it finds valid values.
Sample file that shows the problem |
Hi. Sorry that I took so long to check this. What bothers me a bit with this fix is that it is not backward compatible. For the same value of
That is not what I observe in our demo app. With the stream you provided, the duration is indeed incorrect (it is displayed as -7:10:26), but the video plays until the end (during 02:01). Do you observe the same things as me with the demo app? In other words, is this fix only about displaying the correct duration? |
My code attempted to change audio channel and that caused playback to end. Also skipping back or forward may cause playback to end. The original error reporter said that they could not skip forward or back. |
We have found a bug in the duration reader. Thanks for sharing the problematic media with us. Once we fix internally and push to github, your stream will work as expected. Explanation: The duration reader doesn't synchronize to the transport stream. It just checks for they existence of a sync byte, which can happen at any point in the stream. So the fix is only assuming a packet starts if we can find 5 consecutive 5 bytes, as per the transport stream specification. Please see the commit that will appear below for more details. |
Also, I'll use this issue to track the problem, so that we don't need to file a fresh one. |
#minor-release Issue: #9100 PiperOrigin-RevId: 384962258
#minor-release Issue: #9100 PiperOrigin-RevId: 384962258
Thank you for fixing this. My pull request was more a workaround than a fix, since I do not understand the details of the TS stream. |
@bennettpeter have you tested the fix by any chance? EDIT: Thanks for your contribution, though! It's still a valid approach. |
I have not tested it yet. I will integrate the new version into my app in the next few days, test it and post the result here. Should the pull request be kept open unitil I have tested and confirmed? |
No, that's ok. We usually close after the fix is in place. You can file a fresh issue if you run into any further problems. |
I upgraded my app to the new release 2.14.2 , which includes this fix. I have tested it and it is working perfectly. Thank you! |
Some recorded TV shows are picking up a corrupt value for last PCR in the
file. The result is that the recording only plays for a few seconds. In
the example provided, the duration came out as a large negative number,
and the file played for a few seconds and then reported playback as complete.
The logic in TsDurationReader searches backwards in the file looking
for a valid PCR. Either it is picking up a corrupt value or it is
mis-interpreting other data as if it was a PCR.
The fix searches for two PCR values and performs a sanity check to
ensure they are within valid range before accepting the value. If they
are not valid, it continues searching until it finds valid values.