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

[GoogleCodeExporter]

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:

• 1.png
• 2.png

[GoogleCodeExporter]

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

Attachments:

• 3.png

[GoogleCodeExporter]

Can you provide a sample stream for us to test?

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

• Changed state: NeedInfo

[GoogleCodeExporter]

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]

[deleted comment]

[GoogleCodeExporter]

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]

Any news here?
I have the same issue!

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

[GoogleCodeExporter]

We are looking into the issue.

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

• Changed state: Acknowledged

[GoogleCodeExporter]

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]

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

• Changed state: Done

[GoogleCodeExporter]

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]

Yes, that was the conclusion our engineers reached.

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

[GoogleCodeExporter]

Thanks for replay and help.

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

[GoogleCodeExporter]

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]

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]

[deleted comment]

[GoogleCodeExporter]

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]

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]

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

[GoogleCodeExporter]

Hi Jonathan, we have adjusted timestamp for DTS and PTS on a hls streams, but 
it still fails when playing 22.ts. Could you help see that is this streams 
still wrong at the same chromium code?

Streams link:
https://drive.google.com/file/d/0ByoZJAoAfH7MZU5jSkRMX29mcUU/view?usp=sharing

Original comment by newfun....@gmail.com on 22 Jun 2015 at 7:06

[GoogleCodeExporter]

Hi Jonathan, is there any update on this stream? Thanks.

Original comment by newfun....@gmail.com on 25 Jun 2015 at 6:02

[GoogleCodeExporter]

Hi Jonathan, could you please help see the stream is still return at the same 
line?  
This is really important for us to develop google cast app and promote 
chromcast.
Thanks. 

Original comment by newfun....@gmail.com on 16 Jul 2015 at 11:34

[GoogleCodeExporter]

I'll let you know as soon as we're finished testing it.

Original comment by jonathan...@google.com on 16 Jul 2015 at 4:14