added seeking capability for mpeg-ts

[amoussawi]

As you know mpegts doesn't have a structure for seeking, but one could be built using PCR value, and it appeared that VLC uses it for seeking while playing local mpegts files. Seeking here could only be achieved using seekTo() function and not with the mediacontroller because you still need the duration of the stream, but you can still build up your own mediacontroller that suits your application and use seeking accordingly.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[amoussawi]

I signed it!

[googlebot]

CLAs look good, thanks!

[ojw28]

I really don't buy that this is worth doing. If the media is under your control and you want to allow seeking, you should really use a more appropriate container format.

If the media isn't under your control then it's a little more debatable, but I'm not sure that this is a priority for us; it's unclear what the actual use case is where a user is trying to play their own MPEG-TS stream, or whether we want to go out of our way to support it. If I were to guess, I think this kind of use case would make up a tiny fraction of total ExoPlayer use.

[amoussawi]

I have control on the media, but I'm working on a live streaming case where I could benefit a lot from mpegts, and I don't want to add much overhead by integrating dash or hls, and as you said this case might make up a tiny fraction of exoplayer powerful use.

[ojw28]

What benefits do you obtain from using mpegts, exactly?

[amoussawi]

like starting playback from the middle of the stream without the need of some previous packets, which I guess none of the other container formats supports it unless it's segmented as in dash.

[ojw28]

But you can't actually start playback efficiently from a specified position in middle of the stream, since MPEG-TS isn't efficiently seekable. The exception to this rule would be if you have some server-side magic where you can specify the start position using a query parameter in the request, or similar, but given this pull request I'm guessing that's not the case for your setup.

DASH, SmoothStreaming and HLS all solve exactly this problem by segmenting the media into chunks and providing manifests that index the chunks in a seekable way. Moving to one of these (preferably DASH) is the correct way to achieve what you're trying to do. What are the benefits of your mpegts solution v.s. moving to DASH, or is it just a matter of implementation complexity / having to do some work?

[amoussawi]

sure I can't start exactly from a specific position, but the precision error is tolerable, and no there's no query in my case, it's just like plug and play.
Integrating dash in my case adds so much complexity, using mpegts does what I really need no more, and actually I spent some time playing with dash and I find it really powerful but it will add so much complexity.

[ojw28]

Fair enough. This isn't something we'll be supporting though. In general, if you want seeking, you should use a streaming technology that's designed to support it, as opposed to using an unsuitable technology and then papering over the cracks in the client players.

[amoussawi]

no problem. I guess keeping TsExtractor simple is better but I just wanted to share it so that developers who might be in great need of using mpegts to know that seeking could be implemented and they could benefit from this code.