Improve MPEG-TS seeking support

ebr11 commented 5 years ago

Issue description

Not sure if this is a bug or incompatibility with a particular stream or other issue but seeking in a .TS file does not work in the new version.

Reproduction steps

Play the following test content in the Demo app and the seek buttons will not be enabled. When played in our app using Exo 2.9.1 any attempt to seek appears to try to do it but ends up just going back to the start of the video. This is what has always happened when attempting to seek .TS files.

The Release Notes don't appear to state that it is required but we did try setting DefaultExtractorsFactory.setConstantBitrateSeekingEnabled(true) with no effect.

Link to test content

https://www.dropbox.com/s/3270h1gbnebgchy/WBTV%203%20News%20at%204pm%202018_11_12_16_00_00.ts?dl=0

Version of ExoPlayer being used

2.9.1

Device(s) and version(s) of Android being used

Tested on Xiaomi Mi 3 running Android 8.0.

A full bug report captured from the device

Unable to capture at this time.

ojw28 commented 5 years ago

Increasing TsDurationReader.DURATION_READ_PACKETS fixes this. I tried 300 and that was enough. It's unclear how that value was chosen, and whether we should just increase it or do something more complicated. If we increase it, we probably need to increase TsBinarySearchSeeker.TIMESTAMP_SEARCH_PACKETS as well.

ojw28 commented 5 years ago

@botaydotcom - Was that value chosen to be an arbitrary value we thought was big enough? Or was there more logic to it than that :)?

ebr11 commented 5 years ago

Confirmed!

Thanks very much!

majidebrahimii commented 5 years ago

@ojw28 @ebr11 How use TsDurationReader.DURATION_READ_PACKETS and TsBinarySearchSeeker.TIMESTAMP_SEARCH_PACKETS for fix bug? Can you give me an example code?

ebr11 commented 5 years ago

Hi. As indicated above, just set those values to 300 instead of their current 200.

majidebrahimii commented 5 years ago

@ebr11 Hi. I use version 2.9.1 but unknown this line code: TsDurationReader.DURATION_READ_PACKETS = 300 How did you do it?

ojw28 commented 5 years ago

@sarabellaa You need to have the ExoPlayer code checked out as source. There is no API that you can use to modify the values.

ojw28 commented 5 years ago

Things we should look at to fix this properly:

Possibly increasing the values of TsDurationReader.DURATION_READ_PACKETS and TsBinarySearchSeeker.TIMESTAMP_SEARCH_PACKETS. We might want to look at the PsExtractor equivalents as well, although it's hard to determine that the existing values are unsuitable without seeing some sample media. This may only be an intermediate solution.
Using a larger search window when reading the last timestamp than when reading the first timestamp or timestamps in the middle of the stream during seeking. In the first of these cases it's expensive to make the window larger (assuming http, you need to close the connection and establish a new one). In the second and third cases it's cheap to make the window larger (just keep reading from the existing connection). So it quite probably makes sense to treat them slightly differently.
Look at whether BinarySearchSeeker.calculateNextSearchBytePosition is as good as it could be. In particular the way confidenceInterval works. Ideally this code would shift the search position so that the target timestamp is expected to fall in the middle of the window that's expected to be searched. confidenceInterval doesn't really do this (it's kind of a fudge). Doing it properly might reduce the number of positions that need to be searched during a seek.

majidebrahimii commented 5 years ago

@ojw28 Thankful. Yes, I saw it in Sample code and I was looking for access. Do not provide a new version that solved this problem?

ojw28 commented 5 years ago

A fix will be provided in a future release. We do not have a timeline for this at this point in time.

majidebrahimii commented 5 years ago

@ojw28 Thankful. I will wait for the new version and fix the problem.

ojw28 commented 5 years ago

Fixed in dev-v2.

ojw28 commented 5 years ago

Actually, I'll leave this open to track further improvements as mentioned above. Also, it's still possible that we may not enable seeking for some high bitrate streams, if even the increased constants aren't sufficient.

ojw28 commented 5 years ago

Example of content that's still not seekable: http://video.a045.ottcn.com/ftp_upload/data/video/hdhbzsj100300409.ts

AquilesCanta commented 5 years ago

Yet another piece of content: https://drive.google.com/file/d/1gjsd8qPEd41M3TpUBjGuL-3ZstfZaDZR/view?usp=sharing

rehmanmuradali commented 5 years ago

I want to use seeking forward and backward in radio stream live. the content type is audio/mpeg. Is this stream is supported for seeking in exoplayer ? Stream : http://149.56.195.94:8322/bolpunjabiradio

andrewlewis commented 5 years ago

@rehmanmuradali This issue relates to MPEG-TS specifically. I've replied to your question on #5909. Please don't cross-post.

abdelaziz-mahdy commented 2 years ago

i face the same problem in version 2.17.0

do i have to apply some values to get the video to seek correctly?

for the duration i used MediaMetadataRetriever to retrive it and it works correclty

but the video can not be seeked (every time i seek it just goes to the start) also DefaultExtractorsFactory.setConstantBitrateSeekingEnabled(true) didnt work

meanwhile the video plays perfecty fine

my problems are

duration = 0
video can not be seeked

abdelaziz-mahdy commented 2 years ago

i converted the ts file to mkv file using ffmpeg now everything works as expected and the conversion takes maximum 5 sec using this command ffmpeg -i "file.ts" -map 0 -c copy "file.mkv"

google / ExoPlayer