Audio startup latency higher with V2 than V1

[gbansal103]

Issue description

After integrating ExoPlayer2, First song start play time (Tap song to actual song play time) increased compare to ExoPlayer1. We are using following Sources for Streaming: a) CacheDataSource (Cache size = 100 MB) b) HLSMediaSource c) Also we have implemented Secondary Player to keep next song buffer and cache to support instant play for next song. d) DEFAULT_MIN_BUFFER_MS = 30000; DEFAULT_MAX_BUFFER_MS = 60000; DEFAULT_BUFFER_FOR_PLAYBACK_MS = 1000; DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS = 5000; e) Cache directory structure involve one more depth level. As our cache Directory goes like this "media_cache/TrackID"

Reproduction steps

Keep a playlist of some HLS songs. Tap on any song at the first time. It takes longer time than usual.

Link to test content

There is no specific test content for the same. For any HLS media this issue should be produced. Although we are playing some bollywood / hollywood HLS media files which are retrieved from server.

Version of ExoPlayer being used

'com.google.android.exoplayer:exoplayer-core:r2.4.1' 'com.google.android.exoplayer:exoplayer-hls:r2.4.1'

Device(s) and version(s) of Android being used

We tested in Android 4.4, 5.0 and 6.0 , all OS have this behaviour

A full bug report captured from the device

We have sent the bugreport to dev.exoplayer@gmail.com

[tonihei]

The increased start time might have multiple reasons. How did you compare the two version? It would be helpful to use the same set-up and parameters for both versions to see which part actually influences the result. For example, have you tried not to use the CacheDataSource? Also I suspect that side loading the next song in another player may decrease the performance and effective network throughput. ExoPlayer2 has a ConcatenatedMediaSource and a DynamicConcatenatingMediaSource which handle pre-buffering and seemless transitions for you. You might want to consider using these instead.

[gbansal103]

We have analytics data for average playback time for the users for earlier version of the app. Earlier it was around 1.5- 2 seconds and now it is around 2.5 - 3 seconds. (including all networks) DefaultLoadControl parameters are same for both the versions. ** We start Secondary media player only when we receive onPrepared for current song. But actually on Prepared is received late to us. So this issue seems less related with secondary media player.

Using ConcatenateMediaSource, seamless transitions only occur when it goes for auto-next but if user clicks the next button to switch the song then it does not have pre-buffer song. Also during debug I found that createDataSource is called thrice every time when a song item clicked and in between it is taking considerable time about in total 4 seconds in 2G network.

[tonihei]

Pre-loading the next item to allow seemless switching to next playlist item is something we should support internally. I added a new issue to track this (#3327).

The method createDataSource is used internally to set-up the data source and it's correctly called thrice: once for CacheDataSource, once for DefaultDataSource and once for DefaultHttpDataSource. That doesn't mean there's any computational or network overhead or duplication involved.

Not sure how easy you can test this, but it would be helpful to measure the timings locally on the same device to allow better comparison and also to find the problem more easily. For example, does disabling the cache make any difference? Does it help not to start the second player at onPrepared?

Also, just to make sure:

• Can you tell us in which methods/callbacks you start and stop your time measurements?
• When you say the parameters of DefaultLoadControl are the same - does this include the two parameters DEFAULT_BUFFER_FOR_PLAYBACK_MS and DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS which were part of the ExoPlayer factory in v1?

[gbansal103]

Please find the comparison history of song play time as below with different iterations. (wifi - 100MBPS)

Iteration 1 (in sec) : ExoPlayer1 : 1.253 ExoPlayer2(with Cache) : 1.702 ExoPlayer2(without Cache) : 1.499

Iteration 2 (in sec) ExoPlayer1 : 0.748 ExoPlayer2(with Cache) : 1.298 ExoPlayer2(without Cache) : 1.011

Iteration 3 (in sec) ExoPlayer1 : 0.905 ExoPlayer2(with Cache) : 1.261 ExoPlayer2(without Cache) : 1.057

Iteration 4 (in sec) ExoPlayer1 : 1.047 ExoPlayer2(with Cache) : 1.171 ExoPlayer2(without Cache) : 1.044

Iteration 5 (in sec) ExoPlayer1 : 0.927 ExoPlayer2(with Cache) : 1.457 ExoPlayer2(without Cache) : 0.847

This is sequence of events in which we have calculated the time of song play.

10-08 08:33:17.076 : Song Clicked 10-08 08:33:17.448 : State is playWhenReady=false, playbackState=preparing 10-08 08:33:17.468 : State is playWhenReady=true, playbackState=preparing 10-08 08:33:18.051 : State is playWhenReady=true, playbackState=buffering 10-08 08:33:18.328 : Play load time is 953, Track 10-08 08:33:18.329 : State is playWhenReady=true, playbackState=ready

About the parameters, I mentioned them from **

com.google.android.exoplayer2.DefaultLoadControl

** file in which we only modified DEFAULT_BUFFER_FOR_PLAYBACK_MS from 2500 to 1000, other parameters are same as defined in above file.

[tonihei]

I did some similar tests and can confirm your observation:

• ExoPlayer2 needs +100-200ms until playback starts on average (without cache), although my observations were really noisy. Also, repeating the same process multiple times drastically reduces the execution time (due to JVM optimizations), but the general difference between v1 and v2 remains.

• When I added the CacheDataSource, the initial startup time increased by another 300-400ms due to the I/O operations needed to set-up the cache. However, multiple runs with cache reduced the start-up time well below the time needed for ExoPlayer v1 - which isn't surprising because I was now able to use the cached data.

So using the cache is a trade-off between a small initial set-up time and increased speed and saved data later on. It probably depends on whether you're expecting your songs to be played twice.

For the general increase in start-up time even without cache, I think it's just due to the increased complexity and more supported features in ExoPlayer v2 which result in more code and thus increased execution time without being able to pinpoint a specific culprit at the moment. This likely needs further investigation and I'll leave this issue open and mark it as a bug. Our aim is definitely not to increase the start-up time when using v2.

[JeanCarlosChavarriaHughes]

Hello @tonihei or @gbansal103 ,

Can you please confirm if the bug is still present in release 2.8.4 ? I tested with the parameters mentioned above and with other set of values and achieved a good time reduction, but want to confirm if you this is a real bug that needs fixing.

Commented Values:

DEFAULT_MIN_BUFFER_MS = 30000; DEFAULT_MAX_BUFFER_MS = 60000; DEFAULT_BUFFER_FOR_PLAYBACK_MS = 1000; DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS = 5000;

Best Values in my end.

DEFAULT_MIN_BUFFER_MS = 15000; DEFAULT_MAX_BUFFER_MS = 60000; DEFAULT_BUFFER_FOR_PLAYBACK_MS = 2500; DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS = 15000;

[tonihei]

@JeanCarlosChavarriaHughes I don't think that is related to the issue above. This issue is more about the difference in start up time between ExoPlayer v1 and v2. The values you changed should be the same in v1 and v2 in order to compare the performance.

[gbansal103]

agree with tonihei.

On Thu, Sep 20, 2018 at 1:06 PM tonihei notifications@github.com wrote:

@JeanCarlosChavarriaHughes https://github.com/JeanCarlosChavarriaHughes I don't think that is related to the issue above. This issue is more about the difference in start up time between ExoPlayer v1 and v2. The values you changed should be the same in v1 and v2 in order to compare the performance.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/ExoPlayer/issues/3326#issuecomment-423073492, or mute the thread https://github.com/notifications/unsubscribe-auth/AfB1XU3cKIKvROq0ztKNKIwq3U1X4fmMks5uc0V1gaJpZM4PwCWK .

-- Visit TIMESPRIME.com https://www.timesprime.com/?utm_source=Promotion&utm_medium=Signature&utm_campaign=Email_TIL_Signature_130918  to avail special 20% discount on annual subscription. Now pay Rs. 799 for the first year to enjoy Gourmet Passport by Dineout, Gaana Plus, TOI Plus and amazing benefits from Uber, PVR, Big Basket, Ixigo and many more! 

(Offer valid till 30th Sept'18 only)

[ojw28]

@tonihei - V1 is so old at this point that tracking this as a relative comparison probably doesn't make a lot of sense at this point (it's likely also becoming harder to checkout the V1 branch and just open it in Android Studio, without having to jump through manual upgrade hoops). If we're going to keep this issue open, can we just define some absolute latency measurements that we're targeting for a couple of relevant scenarios?

It's also possible that V1 is no longer any slower. @kim-vde 's extractor sniffing order optimisations should have improved startup latency for progressive audio playbacks, for example.

[tonihei]

Closing this issue now as obsolete.

As explained in the post above, there isn't really any value in comparing with v1 anymore. The start time in the scenario above is heavily influenced by the cache usage and likely the number of classes loaded for the initial cold start also influences the actual start up time. There is certainly value in reducing start-up time as far as possible, but we also haven't received any other complains about excessive time spent during start-up since. So as long as we don't have a concrete indication that time is spent doing unnecessary things, the current state doesn't need to be changed.