search

lihaosky / google-cast-sdk

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

Uncaught InvalidStateError: in media_player.js when casting hls streams #372

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.Stream hls streams from IIS server with CORS enabled to chromecast using 
default media player app.
2. After the first chunk is transferred, the second chunk retrieval is 
cancelled with error "1.  Uncaught InvalidStateError: An attempt was made to 
use an object that is not, or is no longer, usable. media_player.js:104"
3. the hls streams are transcoded output of Transport stream. The video codec 
is H.264 and Audio codec is AAC.

What is the expected output? What do you see instead?
Expect playback, but got an error "1.  Uncaught InvalidStateError: An attempt 
was made to use an object that is not, or is no longer, usable. 
media_player.js:104"

What version of the product are you using? On what operating system?
using latest chromecast version and sender app is default media player app on 
chrome browser with cast extension on windows pc. receiver app is custom 
receiver app based on default media player app

Please provide any additional information below.
Other hls streams playback fine. Not sure what  this error means and looking 
for info on how to debug this further. Attached are logs and hls chunks which 
fail to playback.

Original issue reported on code.google.com by ckam...@gmail.com on 5 Sep 2014 at 1:55

Attachments:

GoogleCodeExporter commented 9 years ago 
The error happens because Chrome video pipeline rejects the stream due to 
multiple PMTs in the segment:

https://code.google.com/p/chromium/codesearch#chromium/src/media/formats/mp2t/ts
_section_pat.cc&q=%22pmt_pid_count%20%3E%201%22&sq=package:chromium&l=88

Original comment by vadi...@google.com on 8 Sep 2014 at 10:14

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Thanks for the response. The stream has only 1 PMT in the 
segment.Program_number 0 in PAT is reserved for Network PID in MPEG and SIT PID 
in DVB-ARIB spec. So if Chrome video is compliant with MPEG, it should not 
confuse the PID for program_number 0 with PMT PID. For test purposes I 
regenerated the stream with only PMT and it works fine. 
I looked at the code provided in the link above. The logic to determine PMT PID 
count seems to be based on the section length rather than looking at the actual 
program and PMT PID. This will not hold good if there are other programs in the 
PAT. Is there a plan to fix this logic?

Original comment by ckam...@gmail.com on 8 Sep 2014 at 11:48

GoogleCodeExporter commented 9 years ago 
If you dump the segment you provided in the repro with dvbsnoop like this:

dvbsnoop -s ts -nph -tssubdecode -if 1.ts

there appears to be a second PMT in ts packet 391.

Original comment by vadi...@google.com on 9 Sep 2014 at 12:09

GoogleCodeExporter commented 9 years ago 
This behavior is by design and is in the Chromium.

Original comment by anad...@google.com on 9 Sep 2014 at 9:39

GoogleCodeExporter commented 9 years ago 
thanks for the response. We modified our code to ensure there is only 1 PMT in 
the segment.

Original comment by ckam...@gmail.com on 9 Sep 2014 at 10:59