Live smooth stream quality drops despite sufficient bandwidth

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use the CastMediaPlayerStreamingDRM receiver. Modify mpl.js so that it 
recognizes live smooth manifest URLs containing '.isml/', and not only '.ism/'. 
Alternatively use the attached mpl.js (which also outputs quality level 
debugging information).
2. Start the following live stream: 
http://hls.akamai.tv2.no/wzlive3/_definst_/smil:FT.isml/Manifest
3. Observe video quality.

What is the expected output? What do you see instead?

Despite good bandwidth and getting the highest quality on on demand streams 
with a similar bitrate setup, live playback quality most often drops to 
mediocre or bad.

For both the mentioned example stream, and other live streams we have tried, we 
can't get the Chromecast to play/stick to the best video qualities in its 
adaptive bitrate selection.

Experiments with using the override for mediaHost.getQualityLevel(streamIndex, 
qualityLevel), shows that enforcing the higher qualities (by returning indexes 
for the highest bitrates), works just fine in a lot of cases. So the bitrate 
selection in the media player library seems to be too pessimistic for live 
streams. 

This problem makes Chromecast an undesired option for watching live content, 
and it should be unnecessary since the Chromecast plays on demand smooth 
streams excellently under same conditions. A Silverlight player streaming 
through the same wifi also have no problems with our live streams.

Original issue reported on code.google.com by tore...@vimond.com on 15 Apr 2014 at 2:27

Attachments:

• mpl.js

[GoogleCodeExporter]

I can see that you already have adjusted for the '.isml' issue, so please 
disregard step 1.

Original comment by tore...@vimond.com on 15 Apr 2014 at 2:33

[GoogleCodeExporter]

Hi. 

Please let us know whether you've been able to confirm the live smoothstreaming 
quality drop as well?

TV 2 Norway currently has Chromecast support in production for its users on 
Android apps & Silverlight support for PC/Mac and we plan on launching for iOS 
soon as well. It's still early adopters out there but we feel a real demand for 
a great live streaming TV experience and as the quality is today, it's not 
optimal and does create support for us.

Best Regards

Tanja Thuesen, Prod. Dev. Manager TV 2 Sumo
https://sumo.tv2.no/

Original comment by tanja.th...@gmail.com on 29 Apr 2014 at 1:50

[GoogleCodeExporter]

We have created an internal issue; as soon as I hear back any update, I will 
update this ticket.

Original comment by anad...@google.com on 4 May 2014 at 7:42

[GoogleCodeExporter]

Thank you!

Original comment by tanja.th...@gmail.com on 5 May 2014 at 7:23

[GoogleCodeExporter]

toreik@
We need the logs (and potentially a stream) to see what is happening. First, we 
do not distinguish between live vs vod in our algorithm that selects or changes 
bitrate. The log file should show what bandwidth we calculated which then would 
explain the change in bitrate. We are somewhat conservative in our algorithm 
but not to an extent that would cause a big issue. At the same time, developers 
have the ability to use their own algorithm for making bitrate selection.

Please provide your logs.

Original comment by anad...@google.com on 5 May 2014 at 7:29

• Changed state: NeedInfo

[GoogleCodeExporter]

After more testing today, I have found what's triggering this bug: The bitrate 
drop behavior occurs when we specify Number.POSITIVE_INFINITY as the 
initialTime in the Player.load method.

We have been including this argument for all live streams, in order to ensure 
that any DVR-enabled streams play from the live position. This is according to 
what's mentioned in the FAQ at https://developers.google.com/cast/docs/player.

If we omit POSITIVE_INFINITY, the adaptive bitrate selection works completely 
fine.

I suggest you do some tests with the stream URL mentioned in my first post, and 
a receiver that specifies the infinity argument in the mentioned method call. 
In my tests, the bitrate dropping is very easy to observe.

Until you have fixed this, we will circumvent the bug by omitting the infinity 
argument and avoid enabling DVR for our live streams.

Original comment by tore...@vimond.com on 6 May 2014 at 3:08

[GoogleCodeExporter]

Let me just add that I get the same result when using "Infinity", which you 
actually recommend, instead of "Number.POSITIVE_INFINITY".

Original comment by tore...@vimond.com on 6 May 2014 at 3:21

[GoogleCodeExporter]

We've made improvements to this in MPL 0.7. Can you re-test on the newer 
version and let us know if you are still experiencing this issue?

Original comment by and...@google.com on 8 Oct 2014 at 4:52

[GoogleCodeExporter]

Thanks for your follow-up. We have already tested 0.7 and later MPL releases 
without being able to see a satisfying fix to this.

We ended up implementing our own adaptive bitrate manager.

Original comment by tore...@vimond.com on 15 Oct 2014 at 9:26

[GoogleCodeExporter]

Closing as this is resolved.

Original comment by and...@google.com on 21 Oct 2014 at 11:48

• Changed state: Done