search

mmeitine / google-cast-sdk

Automatically exported from code.google.com/p/google-cast-sdk
1 stars 0 forks source link

Cast m3u8 to chromecast which streams has massive lag #561

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Cast a m3u8 streams to chromecast by my developing android app
2. m3u8 file and .ts extension segment files are at my local server (Not CORS 
problem)
3. It will start to cast streaming. But lag happened at some ts segment.
4. The time cost is high that is observed via chrome develeoper mode. Please 
see pictures as attached.

What is the expected output? What do you see instead?
1. It should stream smoothly with no lag. I used other player to stream such as 
MX player works fine. 
2. Chromecast streams this m3u8 with massive lag.

more message is as attached

What version of the product are you using? On what operating system?
Streaming server : Mac os 10.10.2
Receiver : Style receiver and custom receiver have same problem.
cast_receiver.js : 2.0.0 version
media_player.js: 1.0.0 version

Please provide any additional information below.
1. The "Time" cost pictures is as attached.
2. Sample stream link: 
https://drive.google.com/file/d/0ByoZJAoAfH7Md2pOd0ZEWHBmbmc/view?usp=sharing

Original issue reported on code.google.com by newfun....@gmail.com on 13 Apr 2015 at 6:41

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Make an adjustment, VLC streams this sample fine, not MX player.

Original comment by newfun....@gmail.com on 13 Apr 2015 at 12:20

GoogleCodeExporter commented 9 years ago 
Hi, there is another sample that has same problem that some position will be 
stuck.
The url link is: 
https://drive.google.com/file/d/0ByoZJAoAfH7MajdaYVZDUmpFMGs/view?usp=sharing

Original comment by newfun....@gmail.com on 13 Apr 2015 at 4:15

GoogleCodeExporter commented 9 years ago 
What do you mean when you say "the time cost is high"? Have you experienced 
this issue when using the sample apps?

Original comment by jonathan...@google.com on 13 Apr 2015 at 11:23

GoogleCodeExporter commented 9 years ago 
Hi, yes.

Sample receiver and style receiver both have the same problem which will be
stuck at some position.

And I had tested again, the Time and Latency is reduced.
But it still be stuck.

So maybe root cause is not high Time and Latency cost to happen stuck.

You can try the two samples using custom apps and style apps to see the
streams on screen, they always stuck at same position.
2015年4月14日 上午7:23於 <google-cast-sdk@googlecode.com>寫道：

Original comment by newfun....@gmail.com on 14 Apr 2015 at 12:41

GoogleCodeExporter commented 9 years ago 
Can you provide receiver side MPL debug console logs?

Original comment by jonathan...@google.com on 15 Apr 2015 at 1:17

GoogleCodeExporter commented 9 years ago 
Hi,thanks for replay. Logs are as attched.
test2.log is for 
https://drive.google.com/file/d/0ByoZJAoAfH7Md2pOd0ZEWHBmbmc/view?usp=sharing

test3.log is for 
https://drive.google.com/file/d/0ByoZJAoAfH7MajdaYVZDUmpFMGs/view?usp=sharing

test_akb.log is for 
https://drive.google.com/file/d/0ByoZJAoAfH7McjZTUkJyYmNORVE/view?usp=sharing

Original comment by newfun....@gmail.com on 15 Apr 2015 at 2:19

Attachments:

GoogleCodeExporter commented 9 years ago 
Based on these logs, what exactly is the issue and where does it happen in the 
logs you provided?  The logs indicate that the video element currentTime is 
progressing and MPL maintains about 20 seconds of future data in the source 
buffer.

Original comment by vadi...@google.com on 15 Apr 2015 at 5:24

GoogleCodeExporter commented 9 years ago 
Hi. test3 stream is obivious lag.

When I use VLC player to watch this video, it seems to be fluent on TV screen.
But use chromecast to stream test3, it's not fluent. 

For test3, It exactly starts to lag at first ts segment, subsequently every ts 
segment seem to be lag on TV screen. And audio sounds fine.
For example, you can observe the mouse cursor moving in video that is lag.

Any other possibilities will cause the lag? Such as information metadata of 
stream is not completed, or bitrate is too high/low?

Original comment by newfun....@gmail.com on 16 Apr 2015 at 1:34

GoogleCodeExporter commented 9 years ago 
Hi, I record a video to show stream test3 sample on VLC and chromecast.
https://drive.google.com/file/d/0ByoZJAoAfH7MLWRMb084YmRDYms/view?usp=sharing

Left is played by chromecast, right is played by VLC. Chromecast is obvious lag.

Original comment by newfun....@gmail.com on 16 Apr 2015 at 8:55

GoogleCodeExporter commented 9 years ago 
Hi, is there any progress on this issue?

Original comment by newfun....@gmail.com on 21 Apr 2015 at 1:38

GoogleCodeExporter commented 9 years ago 
We're looking into it.

Original comment by jonathan...@google.com on 21 Apr 2015 at 8:50

GoogleCodeExporter commented 9 years ago 
Hi, any news update?
May I help doing something?

Original comment by newfun....@gmail.com on 15 May 2015 at 7:42

GoogleCodeExporter commented 9 years ago 
i am also seeing similar issue, does it have to do with the format of the m3u8?

Original comment by hc...@bitcasa.com on 10 Jun 2015 at 3:47

GoogleCodeExporter commented 9 years ago 
Hi Jonathan, is there any update on this issue? It has been complained by 
Chromecast users and developers. Please kindly give us an update. Thanks!

Original comment by scch...@gmail.com on 10 Jun 2015 at 11:41

GoogleCodeExporter commented 9 years ago 
Our engineers noticed low framerate when playing the stream on Chromium with 
software video/audio decoding on a desktop and confirmed that it plays smoothly 
on VLC. FFmpeg plays smoothly, but complains about invalid timestamps in the 
stream. The issue might be due to the input stream but we will need to 
investigate further to get a definitive answer, although we cannot say when 
that will be. Thank you for your continuing patience.

Original comment by jonathan...@google.com on 11 Jun 2015 at 11:57

GoogleCodeExporter commented 9 years ago 
here are some logs from our server, i see that chrome cast is requesting the 
segments way later then it should be.  does it not prefetch/buffer a few 
segments in advance?

=[16:28:40] all.m3u8  (c->s: 269ms|pt: 38ms|resp: 1ms|= 308ms) 1115.00 b/s

=[16:28:40] native.m3u8  (c->s: 404ms|pt: 54ms|resp: 6ms|= 464ms) 21533.50 b/s

+[00:00:00] native.ts [00:00:00-00:00:10] (c->s: 1093ms|pt: 673ms|resp: 46ms|= 
1812ms) 17682.09 b/s
+[00:00:02] native.ts [00:00:10-00:00:20] (c->s: 1742ms|pt: 126ms|resp: 41ms|= 
1909ms) 18306.93 b/s
+[00:00:04] native.ts [00:00:20-00:00:30] (c->s: 2134ms|pt: 149ms|resp: 79ms|= 
2362ms) 9972.25 b/s
+[00:00:19] native.ts [00:00:30-00:00:41] (c->s: 43ms|pt: 139ms|resp: 529ms|= 
711ms) 1710.65 b/s
+[00:00:34] native.ts [00:00:41-00:00:52] (c->s: 50ms|pt: 219ms|resp: 718ms|= 
987ms) 2082.26 b/s
+[00:00:48] native.ts [00:00:52-00:01:03] (c->s: 69ms|pt: 141ms|resp: 325ms|= 
535ms) 2697.06 b/s
+[00:01:03] native.ts [00:01:03-00:01:13] (c->s: 36ms|pt: 217ms|resp: 836ms|= 
1089ms) 1965.56 b/s
+[00:01:22] native.ts [00:01:13-00:01:27] (c->s: 38ms|pt: 201ms|resp: 824ms|= 
1063ms) 2412.62 b/s
+[00:01:36] native.ts [00:01:27-00:01:38] (c->s: 43ms|pt: 151ms|resp: 455ms|= 
649ms) 2353.29 b/s
+[00:01:47] native.ts [00:01:38-00:01:52] (c->s: 48ms|pt: 196ms|resp: 765ms|= 
1009ms) 1838.34 b/s
+[00:02:19] native.ts [00:01:52-00:02:12] (c->s: 43ms|pt: 186ms|resp: 649ms|= 
878ms) 2221.67 b/s
+[00:02:42] native.ts [00:02:12-00:02:22] (c->s: 94ms|pt: 125ms|resp: 283ms|= 
502ms) 2316.76 b/s
+[00:02:59] native.ts [00:02:22-00:02:32] (c->s: 65ms|pt: 135ms|resp: 432ms|= 
632ms) 1977.25 b/s
+[00:03:00] native.ts [00:02:32-00:02:42] (c->s: 992ms|pt: 120ms|resp: 37ms|= 
1149ms) 19498.49 b/s
+[00:03:14] native.ts [00:02:42-00:02:53] (c->s: 41ms|pt: 155ms|resp: 534ms|= 
730ms) 2138.23 b/s
+[00:04:35] native.ts [00:02:53-00:03:04] (c->s: 50ms|pt: 167ms|resp: 577ms|= 
794ms) 2366.93 b/s
+[00:06:12] native.ts [00:03:04-00:03:18] (c->s: 43ms|pt: 146ms|resp: 349ms|= 
538ms) 2639.79 b/s
+[00:06:31] native.ts [00:03:18-00:03:31] (c->s: 39ms|pt: 259ms|resp: 347ms|= 
645ms) 2572.12 b/s
+[00:06:55] native.ts [00:03:31-00:03:42] (c->s: 59ms|pt: 120ms|resp: 323ms|= 
502ms) 2585.71 b/s
+[00:07:10] native.ts [00:03:42-00:03:54] (c->s: 41ms|pt: 146ms|resp: 374ms|= 
561ms) 2141.12 b/s

Original comment by hc...@bitcasa.com on 12 Jun 2015 at 6:16

GoogleCodeExporter commented 9 years ago 
Hi Jonathan, do you have any test tools that is open source which can debug hls 
streams just for chromecast? 
Maybe we can just play streams via the tool at runtime to find root cause more 
detail.

Original comment by newfun....@gmail.com on 15 Jun 2015 at 2:11

GoogleCodeExporter commented 9 years ago 
Test tool +1, please help, this issue has been pending for quite a while, 
thanks.

Original comment by scch...@gmail.com on 16 Jun 2015 at 12:42

GoogleCodeExporter commented 9 years ago 
FFmpeg (ffprobe/ffplay) and dvbsnoop may prove useful to you.

Original comment by jonathan...@google.com on 16 Jun 2015 at 11:50

GoogleCodeExporter commented 9 years ago 
Hi jonathan, we have a hls video sample that is still stuck.
But we have adjusted the timestamp to right format.

https://drive.google.com/file/d/0ByoZJAoAfH7MUk1sNDA2LVJ6b3M/view?usp=sharing

Could you help see why it's still stuck?
Does it still have invalid timestamps? Or where it will happen in chromecast 
source code to contribute to this status?
Maybe we can know something is wrong to modify the stream.
Thanks.

Original comment by newfun....@gmail.com on 24 Aug 2015 at 10:14

GoogleCodeExporter commented 9 years ago 
Does that video play without any issues for you on VLC?

Original comment by jonathan...@google.com on 25 Aug 2015 at 6:22

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Yes, vlc play this video without any issue.

Original comment by newfun....@gmail.com on 26 Aug 2015 at 3:00

GoogleCodeExporter commented 9 years ago 
After further investigation, it seems that the delta DTS between two frames is 
bigger than the value defined by W3C (> 2*last_frame_duration), so the player 
drops some frames, which causes the stream to lag. Playing the same video on 
Chromium results in the same problem, so special logic would need to be added 
in order to handle this situation. Please note that VLC is much more forgiving 
of stream issues and is specifically built to try to work around any errors in 
the stream. Therefore, even if a stream plays well on VLC, that doesn't 
necessarily mean that it will play the same way on Chromecast. Changing this 
ticket to a feature request to better support these types of streams.

Original comment by jonathan...@google.com on 11 Sep 2015 at 6:43

GoogleCodeExporter commented 9 years ago 
Thanks for your replay.

Original comment by newfun....@gmail.com on 14 Sep 2015 at 3:01

GoogleCodeExporter commented 9 years ago 
@Jonathan can you share the W3C document as reference? I am interested this 
topic too.
thanks!

Original comment by dogm...@gmail.com on 16 Sep 2015 at 10:23

GoogleCodeExporter commented 9 years ago 
Please see http://www.w3.org/TR/media-source/ and search for "last frame 
duration".

Original comment by jonathan...@google.com on 16 Sep 2015 at 6:15