Skip to content
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

Automatically detect when FLAG_ALLOW_NON_IDR_KEYFRAMES and FLAG_DETECT_ACCESS_UNITS are needed in the TS extractor #7560

Open
LSDsl opened this issue Jun 28, 2020 · 12 comments

Comments

@LSDsl
Copy link

LSDsl commented Jun 28, 2020

Demo app show buffering progress, length of video and show progress during play. But all this with black screen.

test file http://212.237.34.148/test.ts
test hls http://212.237.34.148/test2.m3u8

@kim-vde
Copy link
Contributor

kim-vde commented Jun 29, 2020

It seems the problem comes from the TS file. This file has an H.264 video stream and an MP2 audio stream.

The video stream should be supported. I will investigate why this specific video is not played.

To play the audio stream, you should use the FFMEG ExoPlayer extension (see Supported formats page).

@AquilesCanta
Copy link
Contributor

You should check out the FAQ: Why do some MPEG-TS files fail to play?.

@kim-vde
Copy link
Contributor

kim-vde commented Jun 29, 2020

This content has AUD NAL units but doesn't have IDR frames. Setting the flag FLAG_ALLOW_NON_IDR_KEYFRAMES fixes the issue (see HlsMediaSource.Factory.setExtractorFactory() and DefaultHlsExtractorsFactory).

@LSDsl
Copy link
Author

LSDsl commented Jun 29, 2020

Not it work (with FLAG_ALLOW_NON_IDR_KEYFRAMES ). But may be better add some help info in logs in this situation? Ty

@LSDsl LSDsl closed this as completed Jun 29, 2020
@ojw28
Copy link
Contributor

ojw28 commented Jun 29, 2020

@kim-vde @AquilesCanta - The flags might remain useful to force certain behaviours on, but would it be possible to do something more intelligent by default so that specifying the flags is required for fewer cases?

For example, I suspect that we could have a default behaviour where we start off detecting access units the expensive way, and switch to the cheap way as soon as we see an AUD in the stream. This would make FLAG_DETECT_ACCESS_UNITS unnecessary, except in weird edge cases where there are some AUDs, but they're not everywhere they should be, which I doubt this ever happens. It might be possible to do something similar for FLAG_ALLOW_NON_IDR_KEYFRAMES as well.

@ojw28 ojw28 reopened this Jun 29, 2020
@kim-vde
Copy link
Contributor

kim-vde commented Jun 30, 2020

I think it should indeed be feasible. I'll mark the issue as an enhancement to keep track of this improvement.

@kim-vde kim-vde changed the title Black screen on HLS playing and no errors. Same with one part of HLS. Automatically detect when FLAG_ALLOW_NON_IDR_KEYFRAMES and FLAG_DETECT_ACCESS_UNITS are needed in the TS extractor Jun 30, 2020
@AquilesCanta
Copy link
Contributor

I think the DETECT_ACCESS_UNITS flag can be removed using the following rules:

  • Assume one access unit per PES packet. I think there's only one exception to this rule: A single TS packet containing an entire PES packet. I seem to remember finding this rule in every TV standard (only H.264).
  • Use SEI NAL units as access unit delimiters too.

Re allowing non-idr sync frames, the number of reported issues decreased (I think) with the introduction of the detection of the random access indicator. But after some research I haven't found a way of avoiding the allowing of non-IDR key frames for the provided stream, which doesn't seem to include any TS-level information about sync frames.

@devathul
Copy link

Hello , Do you have an ETA for enhancement to reduce the usage of FLAG_ALLOW_NON_IDR_KEYFRAMES and FLAG_DETECT_ACCESS_UNITS?
Thanks

@kim-vde
Copy link
Contributor

kim-vde commented Nov 2, 2020

I am afraid not. All I can say is that we haven't planned to work on that in the following months.

@devathul
Copy link

@kim-vde Just checking if it's possible to add this feature request?

@kim-vde
Copy link
Contributor

kim-vde commented Jun 15, 2021

I am afraid we still don't have plans to work on this in the near future. What you can do is implement the fix in a pull request and we will look at it.

@wazerstar
Copy link

wazerstar commented Mar 11, 2022

An update to this?
This seems to effect tuners like https://www.silicondust.com are using for mpeg-ts, I have finally figured out that its exoplayer being the root cause!

Worth note that its randomly whenever it keeps getting in endless buffering state with black screen.

If any dev's need samle let us know :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants