Improve MPEG-TS seeking support

[ebr11]

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]

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]

@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]

Confirmed!

Thanks very much!

[ojw28]

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.

[ojw28]

Fixed in dev-v2.

[ojw28]

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]

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

[AquilesCanta]

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

[abdelaziz-mahdy]

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

1. duration = 0
2. video can not be seeked

[abdelaziz-mahdy]

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"