lihaosky / google-cast-sdk

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

Cast a m3u8 streaming will throw "Fatal Error: code = 1" when cast certain .ts segment #530

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Cast a m3u8 streaming 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 smoothly, but sometimes It will throw error 
message randomly when cast certain .ts extension file. 

What is the expected output? What do you see instead?
Uncaught TypeError: Converting circular structure to JSON
window.mediaManager.onError
X.Ka
g.Ka
wb
tb
(anonymous function)
...
...
...
Fatal Error: code = 1

more message is as attached

What version of the product are you using? On what operating system?
Streaming server : Mac os 10.10.2
Custom Receiver : (cast-custom-receiver) 
https://github.com/googlecast/cast-custom-receiver
cast_receiver.js : 2.0.0 version
media_player.js: 1.0.0 version

Please provide any additional information below.

Original issue reported on code.google.com by newfun....@gmail.com on 16 Mar 2015 at 9:42

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by newfun....@gmail.com on 16 Mar 2015 at 9:46

Attachments:

GoogleCodeExporter commented 9 years ago
Can you provide a sample stream for us to test?

Original comment by jonathan...@google.com on 18 Mar 2015 at 1:16

GoogleCodeExporter commented 9 years ago
Below is the sample link:
https://drive.google.com/file/d/0ByoZJAoAfH7MX1F4b2hRa3cyM28/view?usp=sharing

You can access playlist.m3u8 to start streaming.  Thanks.

2015-03-18 9:16 GMT+08:00 <google-cast-sdk@googlecode.com>:

Original comment by newfun....@gmail.com on 18 Mar 2015 at 2:54

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
For this sample case, it always throws error like pictures as attached when 
deal with 1426645644segment_v00009.ts.

Original comment by newfun....@gmail.com on 18 Mar 2015 at 4:15

GoogleCodeExporter commented 9 years ago
Any news here?
I have the same issue!

Original comment by b95505017 on 23 Mar 2015 at 4:56

GoogleCodeExporter commented 9 years ago
We are looking into the issue.

Original comment by jonathan...@google.com on 23 Mar 2015 at 9:54

GoogleCodeExporter commented 9 years ago
Hi, is there any update about this issue?
Is it possible that media_player lib need some metadata information which ts 
file doesn't have? 

Original comment by newfun....@gmail.com on 8 Apr 2015 at 9:02

GoogleCodeExporter commented 9 years ago
The custom receiver sample app has been updated with exception handling when 
trying to stringify a JSON object. The Chrome media pipeline requires the 
stream to have monotonically increasing timestamps. It seems this isn't case 
with the stream since it fails here: 
https://code.google.com/p/chromium/codesearch#chromium/src/media/base/stream_par
ser.cc&sq=package:chromium&rcl=1428579286&l=86

Original comment by jonathan...@google.com on 9 Apr 2015 at 6:31

GoogleCodeExporter commented 9 years ago
Hi,so you mean the root cause is maybe because of the ts segment does not have 
monotonically increasing timestamps?

Original comment by newfun....@gmail.com on 10 Apr 2015 at 10:58

GoogleCodeExporter commented 9 years ago
Yes, that was the conclusion our engineers reached.

Original comment by jonathan...@google.com on 15 Apr 2015 at 12:01

GoogleCodeExporter commented 9 years ago
Thanks for replay and help.

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

GoogleCodeExporter commented 9 years ago
I have question about this issue, in this case, 
    if (last_decode_timestamp != kNoDecodeTimestamp() && ts < last_decode_timestamp)
        return false;
Does last_decode_timestamp mean DTS(Decode Time Stamp) which will be sent to 
decoder? If that's the case, why does that need to be monotonously increased 
order?  If stream contains B frame, the order might be changed.

thanks~

Original comment by dogm...@gmail.com on 16 Apr 2015 at 8:32

GoogleCodeExporter commented 9 years ago
It's part of the MSE specification. Please see 
http://www.w3.org/TR/2015/CR-media-source-20150331/ (search for "monotonically 
increasing").

Original comment by jonathan...@google.com on 18 Apr 2015 at 2:53

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Hi Jonathan,

I'm still confused, if the media contain B Frame, how does dts be monotonically 
increased? http://goo.gl/SklnNX This picture can explain what I mean, or did I 
miss something? thanks~

Original comment by dogm...@gmail.com on 20 Apr 2015 at 2:49

GoogleCodeExporter commented 9 years ago
Our streams are transferred over TCP, so they are guaranteed to be in the 
correct order. Even if the stream has B frames, the frames should be in 
increasing DTS (decode time stamp) order. However, their PTS (presentation time 
stamp) might be different from DTS. So for streams with B frames, PTS might not 
be monotonically increasing, but DTS should still be monotonic. 
http://dranger.com/ffmpeg/tutorial05.html has an example that I think you will 
find useful.

Original comment by jonathan...@google.com on 22 Apr 2015 at 6:10

GoogleCodeExporter commented 9 years ago
thanks for your explanation, the picture I provided use opposite way to 
describe which let me confused. We'll use ffprobe to check and make sure all 
frames are correctly arranged.

Thanks!

Original comment by dogm...@gmail.com on 25 Apr 2015 at 2:00