Open GoogleCodeExporter opened 9 years ago
[deleted comment]
Make an adjustment, VLC streams this sample fine, not MX player.
Original comment by newfun....@gmail.com
on 13 Apr 2015 at 12:20
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
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
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
Can you provide receiver side MPL debug console logs?
Original comment by jonathan...@google.com
on 15 Apr 2015 at 1:17
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:
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
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
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
Hi, is there any progress on this issue?
Original comment by newfun....@gmail.com
on 21 Apr 2015 at 1:38
We're looking into it.
Original comment by jonathan...@google.com
on 21 Apr 2015 at 8:50
Hi, any news update?
May I help doing something?
Original comment by newfun....@gmail.com
on 15 May 2015 at 7:42
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
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
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
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
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
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
FFmpeg (ffprobe/ffplay) and dvbsnoop may prove useful to you.
Original comment by jonathan...@google.com
on 16 Jun 2015 at 11:50
Original issue reported on code.google.com by
newfun....@gmail.com
on 13 Apr 2015 at 6:41Attachments: