Catch up playback problem, questions

[alfonsoramosa]

Exoplayer 2.2.0
Device: Nexus player
Android 7.1.1

I'm trying to play Smooth Streaming Rolling Buffer CatchUp (CDN buffer) assets with Exoplayer.
The time reference for the chanks is not starting at 0, as happens with VOD assets, but for example at 14931911990078373, see manifest example:

<SmoothStreamingMedia MajorVersion="2" MinorVersion="0" TimeScale="10000000" Duration="15020292799">
<StreamIndex Type="audio" QualityLevels="1" TimeScale="10000000" Language="nor" Subtype="AACL" Name="audio_nor" Chunks="751" Url="QualityLevels({bitrate})/Fragments(audio_nor={start time})">
<QualityLevel Index="0" Bitrate="96000" CodecPrivateData="1190" SamplingRate="48000" Channels="2" BitsPerSample="16" PacketSize="4" AudioTag="255" FourCC="AACL"/>
<c t="14931911990078373" d="20053333"/>
<c d="20053334"/>
...

I'm having some problems in the Exoplayer wrapper, as it's expecting position received and passed to SimpleExoPlayer in the interval (0, duration), but for this asset it's in the interval (14931911990078373, 14931911990078373+duration), affected methods are:

player.getCurrentPosition();
player.seekTo(positionMs);

My questions are:

1. Is it correct to receive current position player.getCurrentPosition() in the interval (14931911990078373, 14931911990078373+duration)? I mean, this position is relative to the manifest time or to the asset duration?
2. If I need to do this "translation" in the wrapper, how can I get the starting time for the first chunk to use it in the wrapper?

[ojw28]

Have you read the Javadoc for Timeline, Window and Period, and getCurrentPosition? They describe the model used in some detail:

http://google.github.io/ExoPlayer/doc/reference/com/google/android/exoplayer2/Timeline.html
http://google.github.io/ExoPlayer/doc/reference/com/google/android/exoplayer2/ExoPlayer.html#getCurrentPosition--

Please let us know whether you're able to answer your question, or whether you're still stuck. If still stuck, perhaps you could provide a concrete example of specific calls that are not working as you expect.

[alfonsoramosa]

I will try to explain what I need and the problems that I'm having with this special kind of content:

• Get the playback position to display it, for example, if Exoplayer has been playing the content for 1 minute and 25 seconds, I would like to display 01:25
• To do that, I'm getting the current position, with player.getCurrentPosition()
• That's working fine when the time reference for the SS chunks starts at 0 (most of the contents), for 1 minute 25 seconds, player.getCurrentPosition() is returning 85000
• With rolling buffer catch up, that's not working. For example, for the content described in my first post, player.getCurrentPosition() is returning (14931911990078373+85000) when it has been playing for 1 minute and 25 seconds.
• To fix that, I need to subtract from this value the time reference of the first chunk, so I need to obtain that value.
• I have tried to get this value using the Window and the Period, but it's not working.

Timeline.Window w1 = new Timeline.Window();
player.getCurrentTimeline().getWindow(player.getCurrentWindowIndex(), w1);

Timeline.Period p1 = new Timeline.Period();
player.getCurrentTimeline().getPeriod(player.getCurrentPeriodIndex(), p1);

I have checked, during the playback, all the fields where I think I can get the value I need, but I can't find it. Only the duration is available for the Period and the Window

The timeline is an instance of SinglePeriodTimeline
player.getCurrentTimeline().getPeriodCount() -> 1
player.getCurrentTimeline().getWindowCount() -> 1

p1.getPositionInWindowMs() -> 0
w1.getDefaultPositionMs()) -> 0
w1.windowStartTimeMs -> TIME_UNSET
w1.presentationStartTimeMs -> TIME_UNSET
w1.getPositionInFirstPeriodMs() -> 0
w1.positionInFirstPeriodUs -> 0
player.getCurrentTimeline().isEmpty() -> false
player.isCurrentWindowSeekable() -> true

[alfonsoramosa]

Hi,

@ojw28 can you please provide some help with this issue (my previous post).

BR,
Alfonso

[ojw28]

If you just want elapsed time, couldn't you just time this yourself at the application level? I don't think you need any player support to do this.

[ojw28]

Beyond that, it's hard to advise what to do without access to a test stream that's setup in the way you describe.

[alfonsoramosa]

Hi,

@ojw28 What I need is to get the currentPosition in the interval (0, duration). That works perfectly with other contents.
With this contents, I'm getting the currentPosition for example in the interval (14931911990078373, 14931911990078373+duration) and I have no way to translate it to something in the interval (0, duration)

I'm getting the currentPosition within ExoplayerWrapper method:
public long getCurrentPosition() {
return player.getCurrentPosition();
}

In my first post, you have an example of the manifest

Thanks,
Alfonso

[ojw28]

It's unclear whether this:

Get the playback position to display it, for example, if Exoplayer has been playing the content for 1 minute and 25 seconds, I would like to display 01:25

and this:

What I need is to get the currentPosition in the interval (0, duration).

are the same thing. They sound like different things to me, so it's still quite unclear what you're asking for. In the Timeline Javadoc I think you probably have a case that corresponds to the third diagram (live stream with limited availability). Is that correct? If so, are you trying to get:

1. The position relative to the start of the window. This value will normally not get larger over time, since the window is moving at the same rate as playback. This is what I'd expect to be delivered by getCurrentPosition.
2. The position relative to the start of the broadcast. Value will get larger over time, and will start at a value equal to approximately the time that the live stream has been running for.
3. Something else.

Are you trying to get (1), but seeing that getCurrentPosition isn't giving you that? I think we need working test content to assist. A small snippet of a manifest is not sufficient for us to help in an efficient way. Please provide working test content.

[alfonsoramosa]

Hi @ojw28

Dont' know if there is a case in the TimeLine Javadoc that describes exactly what I'm trying to do. I will tray to explain more in detail and see if you have any suggestion.

• I have a live stream, with a buffer in the CDN, (7 days buffer).
• I'm also using this buffer directly for the catch-up assets (Rolling buffer catch up).
• I'm creating manifests for these assets pointing directly to the buffer. These manifests are "static", these assets are not live content.
• The only difference between this manifests and other manifests for VOD content is that the time reference for the chunks is not starting at 0 (for the first chunk), but at, for example, 1495177957001577 (epoch us).
• The player UI must display the playback position, starting at 00:00 (as for VOD assets).
• player.getCurrentPosition() is returning epoch us, for example, after 10 seconds playback 1495177957001577+10000000
• I need to translate from that to the position in the video, that is 10 seconds in the previous example.
• To do that translation, I need the time reference (epoch) for the first chunk, that Exoplayer is getting from the manifest, that is 1495177957001577.
• I have checked all the possibilities with the period and the window, but I have not found a way of doing it, and here is where I need your help.

Thanks,
Alfonso

[ojw28]

Ah, so the problem is that you have a VOD manifest that's actually just a static snapshot of a previously broadcast (and possibly still ongoing) live stream. The timestamps in the VOD manifest don't start at t=0 for this reason, but you want positions reported as though they do. Is that correct?

Please provide working test content, and we'll take a look at figuring out how to do this. We're not going to investigate without. Thanks.

[alfonsoramosa]

Hi @ojw28,

that's correct. I'm not doing that with ongoing assets, just with ended assets.
I will tray to find a content that you can use to test it (without DRM).

BR,
Alfonso

[ojw28]

It's somewhat ambiguous from the SmoothStreaming specification exactly how this use case is supposed to work. That said, we were definitely doing some things wrong with the timeline construction. I've made some changes and now you should see the window position advancing from 0 as you expect. Please give it a try by using the latest from the dev-v2 branch!