Conversation
|
@dsparano. Thanks for reporting this issue and proposing a fix! Do you have a small ts sample that you can add in a unit test like those in the TsExtractorTests that exposes this issue and provides testing support for your change? |
|
This pr has bug |
|
@microkatz I just committed the added unit test, and not sure how this PR ended up closed (!) could you re-open it? @FongMi the url above doesn't seem to point to anything useful, if you can fix the url I'm happy to debug |
|
@dsparano. Unfortunately I cannot reopen the pull-request. The button is not available to click. Perhaps create a new pull request? |
|
Looks like github doesn't like a force push, even a non history rewriting one :( which is what sourcetree did for me, anyway opening another one... |
|
@FongMi http://altitcon2.3cx.hk:9991/stream/channel/b7992c06aba8ebfc87e21cda43d287d1 seems to be playing fine for me on this branch |
When playing H264 video from a TS container, it seems the BUFFER_FLAG_KEY_FRAME in addition to being set on the actual IDR frames, is also wrongly set on each frame immediately preceding the IDR one.
In more detail the root cause seems to be the following. In streams with AUD, the consume at the beginning of the PES, on the AUD NAL, calls endNAlUnit() on the previous NAL (NAL_UNIT_TYPE_NON_IDR) and since randomAccessIndicator is set, this causes treatIFrameAsKeyframe to be true and so sampleIsKeyframe to be set while still on the previous sample (outputSample has not been called yet). The following NAL unit (SPS) causes endNAlUnit() to be called on the SampleReader for the AUD NAL which calls outputSample on the previous sample with sampleIsKeyframe wrongly set.
The proposed solution, with this PR, is to pass the randomAccessIndicator parameter in SampleReader in the startNalUnit() instead of the endNalUnit() and have it as a class variable in the SampleReader. With this change the randomAccessIndicator would only depend on the PES the current NAL belongs to and the issue described above would be resolved.