GCKMediaControlChannel.approximateStreamPosition stops updating after 3 seconds, on streaming mp4.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Transcode / create a streaming mp4. (ie. mp4 file with many intermediate 
moof packets).
2. Whilst still transcoding /creating the mp4, host the streaming mp4 on a HTTP 
(206 Partial Content) capable server.
3. Setup GCKMediaInformation with contentType as GCKMediaStreamType.Live.
4. Cast the file's URL via GCKMediaControlChannel.loadMedia(... )
5. Create a NSTimer on the UI main queue to monitor and display the 
GCKMediaControlChannel.approximateStreamPosition.
6. Whilst playing the GCKMediaControlChannel.approximateStreamPosition is 
updated until the 3rd second. (ie 1, 2, 3 is reported "accurately")
7. On the third second it stops updating.
8. Once the file has finished writing, the 
GCKMediaControlChannel.approximateStreamPosition jumps to an "accurate" value. 
(I suspect this is due to the moov packet being updated on the file).

What is the expected output? What do you see instead?
Expected output.
An more approximately playback value for 
GCKMediaControlChannel.approximateStreamPosition when a streaming mp4 is played.
Actual output.
An approximate playback value for 
GCKMediaControlChannel.approximateStreamPosition when a streaming mp4 is played 
only until the 3rd second.
When the file has finished writing to disk for the URL casted. The 
GCKMediaControlChannel.approximateStreamPosition reports a more accurate value.

What version of the product are you using? On what operating system?
Yosemite / iOS SImulator /iOS 8.1.2 / Swift

Please provide any additional information below.
As the variable is marked approximate. This could be considered an enhancement.

Original issue reported on code.google.com by samson1...@gmail.com on 13 Jan 2015 at 10:29

[GoogleCodeExporter]

Can you check the value of the 'playerState' property of GCKMediaStatus at 
these times? If it is not GCKMediaPlayerStatePlaying, then the stream position 
will not advance. It could be that the receiver is reporting a buffering state 
and that's why it stops advancing.

Original comment by mlind...@google.com on 13 Jan 2015 at 9:59

[GoogleCodeExporter]

Thank you for responding quickly again!

I monitor the playstate as well and I can see that for a live mp4 stream it is 
always /mainly buffering although the content is also playing.

So what you are saying sounds like the API is working according to what you 
expect, but from an user experience point of view it might be less than ideal.

For example, if I start streaming a 5 min mp4.
1. For the first few moments while the request has been sent and the content is 
being requested. I can see the Paused state reported for a few moments (which I 
believe has already been reported as an issue)
2. Then for the first few seconds, while the content is being played I can see 
the Playing state. The approximateStream position is also updating, with values 
1, 2, 3 seconds.
3. Then after that, while the content is being played and buffered at the same 
time I can see the Buffering state. The approximatelyStream position is not 
updated. (So on my UI my progress bar is stuck)
4. At times when I wait for the whole file to be played back I can suddenly see 
at the 3-4min mark my progress bar suddenly jump to a more accurate time of 
playback. (I assume my file has finished transcoding and now a complete mp4 
with moov packet written, while the content is being streamed)

You can imagine that for those few minutes after the initial 3 seconds the 
actual playback progress on the UI isn't consistent with what is reported by 
the API.

I hope that helps. Thanks again.

Original comment by samson1...@gmail.com on 14 Jan 2015 at 1:39

[GoogleCodeExporter]

A small addition that might help. I am using the default receiver app.

Original comment by samson1...@gmail.com on 14 Jan 2015 at 2:47

[GoogleCodeExporter]

Please modify your mp4 to set the moov box at the beginning and see if you can 
reproduce the issue. If yes, please provide your receiver logs. Set up debug 
logging by: cast.receiver.logger.setLevelValue(cast.receiver.LoggerLevel.DEBUG);

Original comment by na...@google.com on 14 Jan 2015 at 10:37

• Changed state: NeedInfo

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thank you for responding.

All my generated mp4 files have the moov packets the beginning of the . At the 
moment I am only using the default receiver app and haven't even looked into 
that area. I will try to set something up and send the appropriate logs.

Original comment by samson1...@gmail.com on 15 Jan 2015 at 1:07

[GoogleCodeExporter]

Apologies for the delay. I have recently got a custom receiver working. It has 
been useful in debugging my application. But more importantly related to this 
issue.

I misreported the issue. Apologies, with my tests that I have reported here I 
do indeed put the moov at the end of the file.

On another note a little bit related to this issue. Could you direct me to the 
best place to raise this question with the googlesdk team?

Could you tell me what is the use of GCKMediaInformation.Live? And does it 
support (officially or unofficially support) an endless mp4 file (unknown 
length), live feed from a live source? (I have something almost working, 
barring Chromecast's response to my HTTP response headers, e.g. Content-Range, 
Content-Length...)

Original comment by samson1...@gmail.com on 23 Jan 2015 at 12:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thank you for updating the issue appropriately. Please raise your coding 
specific queries here: https://plus.google.com/communities/115742157569103585450

Original comment by na...@google.com on 23 Jan 2015 at 6:35