Closed GoogleCodeExporter closed 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
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
[deleted comment]
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
Any news here?
I have the same issue!
Original comment by b95505017
on 23 Mar 2015 at 4:56
We are looking into the issue.
Original comment by jonathan...@google.com
on 23 Mar 2015 at 9:54
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
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
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
Yes, that was the conclusion our engineers reached.
Original comment by jonathan...@google.com
on 15 Apr 2015 at 12:01
Thanks for replay and help.
Original comment by newfun....@gmail.com
on 15 Apr 2015 at 2:22
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
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
[deleted comment]
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
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
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
Original issue reported on code.google.com by
newfun....@gmail.com
on 16 Mar 2015 at 9:42Attachments: