Uses correct index for playlist URL

[stevemayhew]

The TrackSelection API returns two indexes, the index of the selected
track (getSelectedIndex()) and the index in the TrackGroup. The HlsChunkSource
and HlsSampleStreamWrapper should only work with the later.

Actually the getSelectedIndex(), current selected track index is really only useful on
the API to determine if there is a valid selection or not. The index is
really internal to TrackSelection

[stevemayhew]

I'm closer to a full fix for issue #2882 Implementing this helps, but changes are needed to fully support this:

1. proper track selection to use i-Frame tracks (working on this myself)
2. support for enabling this and using it in the DefaultTimeBar with DPAD (streamer/STB use case)
3. support for DefaultTimeBar trickplay seek with touch interface

I can upload a patch or a test only branch (no pull request) with hacked in changes to support the STB use case (no way ready to merge anywhere, but we can talk about it).

Using that patched code I see (with an AmLogic based streamer, similar hardware to GoogleTV):

0.0 12-07 16:55:15.083 20260 20260 D EventLogger: positionDiscontinuity [eventTime=43.94, mediaPos=17.14, window=0, period=0, reason=SEEK, PositionInfo:old [mediaItem=0, period=0, pos=15148], PositionInfo:new [mediaItem=0, period=0, pos=17142]]
5.0 12-07 16:55:15.088 20260 20260 D EventLogger: state [eventTime=43.94, mediaPos=17.14, window=0, period=0, BUFFERING]
30.0 12-07 16:55:15.113 20260 20260 D EventLogger: positionDiscontinuity [eventTime=43.97, mediaPos=17.15, window=0, period=0, reason=SEEK_ADJUSTMENT, PositionInfo:old [mediaItem=0, period=0, pos=17142], PositionInfo:new [mediaItem=0, period=0, pos=17150]]
34.0 12-07 16:55:15.117 20260 20260 D EventLogger: loading [eventTime=43.97, mediaPos=17.15, window=0, period=0, true]
70.0 12-07 16:55:15.153 20260 20260 D EventLogger: renderedFirstFrame [eventTime=44.01, mediaPos=17.15, window=0, period=0, Surface(name=null)/@0x7adc65a]
72.0 12-07 16:55:15.155 20260 20260 D EventLogger: state [eventTime=44.01, mediaPos=17.15, window=0, period=0, READY]
123.0 12-07 16:55:15.206 20260 20260 D EventLogger: loadCompletedMedia [eventTime=44.06, mediaPos=17.15, window=0, period=0, trackId: 3 load-duration: 96ms codecs: avc1.64001F start(dur): 65198/2002 offset/len: 5608604/203980 uri: http://...CCURStream_video_MultiPortMulticast2_1633564800-CCUR_iframe.tsv]

With this code change I see < 100ms from DPAD press to rendered frame, almost a "visual" trickplay experience.

@ojw28 Feel free to assign #2882 to me if you want, we can talk about how to add it to the demo maybe in that bug or I can open a pull request with some of the first steps.

@kim-vde Sorry if I didn't follow the coding guidelines/pattern for HLS module. I'll try and follow the pattern more closely next time and add you to the review, where we will welcome requests to fix it so it matches our code too. We have a significant amount of coding effort that we forward port from r2.12 (were we are sadly stuck for a while) to dev-v2 to share it back with Google, it makes it easier for us to move forward in versions if the code doesn't change too much from our original commits. I have no problem following any pattern / style your team prefers.

[stevemayhew]

Here's the branch with test code to show this working at the application level:

https://github.com/TiVo/ExoPlayer/tree/x-experimental-scrub-demo-code

Steps are:

1. Select content for the main demo with iFrames (you can use bipbop, or anything else with 2 second or less iFrames)
2. Use manual track selection to select one or more iFrame only tracks manually (excluding others) and disable sound
3. Set the player in pause (playWhenReady off)
4. Select the timebar and use the D-DPAD left / right to scrub

I tested using a GoogleTV (Google Chromecast)

Depending on how your iFrames are authored rapid scrolling can cause very irregular frame rates (this is because of the way the Extractor commits NALs)