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

Improve MPEG-TS seeking support #5097

Open
ebr11 opened this issue Nov 12, 2018 · 19 comments
Open

Improve MPEG-TS seeking support #5097

ebr11 opened this issue Nov 12, 2018 · 19 comments
Assignees

Comments

@ebr11
Copy link

ebr11 commented Nov 12, 2018

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.

@ebr11 ebr11 changed the title New MPEG-TS searching New MPEG-TS seeking Nov 12, 2018
@ojw28
Copy link
Contributor

ojw28 commented Nov 12, 2018

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 ojw28 added the bug label Nov 12, 2018
@ojw28 ojw28 changed the title New MPEG-TS seeking MPEG-TS seeking doesn't work for high bitrate streams Nov 12, 2018
@ojw28
Copy link
Contributor

ojw28 commented Nov 12, 2018

@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
Copy link
Author

ebr11 commented Nov 12, 2018

Confirmed!

Thanks very much!

@majidebrahimii

This comment has been minimized.

@ebr11

This comment has been minimized.

@majidebrahimii

This comment has been minimized.

@ojw28

This comment has been minimized.

@ojw28
Copy link
Contributor

ojw28 commented Nov 13, 2018

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

This comment has been minimized.

@ojw28

This comment has been minimized.

@majidebrahimii

This comment has been minimized.

ojw28 added a commit that referenced this issue Nov 14, 2018
This is a precursor for fixing the ref'd issue. These classes are
well tested, so the tests passing should give you reasonable
confidence I didn't break anything :).

Issue: #5097

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221435824
ojw28 added a commit that referenced this issue Nov 14, 2018
- Increase the search window size to fix TS seeking for problematic
  media we've had provided to us.
- As per my comments on the issue, we should look at doing more here
  to better fix the problem. This will solve the worst of the
  immediate problem, however.
- The memory usage is non-trivial, particularly with the increased
  search window size. I've made the allocations only live whilst
  determining duration and seeking to address this. I've done the same
  for PS just for consistency.

Issue: #5097

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221449988
@ojw28
Copy link
Contributor

ojw28 commented Nov 16, 2018

Fixed in dev-v2.

@ojw28 ojw28 closed this as completed Nov 16, 2018
@ojw28 ojw28 reopened this Nov 16, 2018
@ojw28
Copy link
Contributor

ojw28 commented Nov 16, 2018

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 ojw28 added enhancement and removed bug labels Nov 16, 2018
@ojw28 ojw28 changed the title MPEG-TS seeking doesn't work for high bitrate streams Improve MPEG-TS seeking support Nov 16, 2018
ojw28 added a commit that referenced this issue Nov 28, 2018
This is a precursor for fixing the ref'd issue. These classes are
well tested, so the tests passing should give you reasonable
confidence I didn't break anything :).

Issue: #5097

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221435824
ojw28 added a commit that referenced this issue Nov 28, 2018
- Increase the search window size to fix TS seeking for problematic
  media we've had provided to us.
- As per my comments on the issue, we should look at doing more here
  to better fix the problem. This will solve the worst of the
  immediate problem, however.
- The memory usage is non-trivial, particularly with the increased
  search window size. I've made the allocations only live whilst
  determining duration and seeking to address this. I've done the same
  for PS just for consistency.

Issue: #5097

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221449988
@ojw28
Copy link
Contributor

ojw28 commented Dec 19, 2018

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

@AquilesCanta
Copy link
Contributor

@rehmanmuradali

This comment has been minimized.

@andrewlewis

This comment has been minimized.

@abdelaziz-mahdy
Copy link

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
Copy link

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"

@ojw28 ojw28 assigned rohitjoins and unassigned ojw28 Jul 12, 2022
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

8 participants