In the javascript api for HTML5 video there is a canPlayType method to check if something is playable or not. However I've noticed that on the Chromecast this function doesn't quite cover everything. On several occasions playing local content with the app I'm working on I'll get an error saying that it is not playable, but if I take off my error checking which uses canPlayType then I have no issues. I'm curious if anyone has nailed down a good way to figure out supported content other than simply checking strings against a list that we create using the supported media types from https://developers.google.com/cast/supported_media_types
The response to HTMLMediaElement.canPlayType()is supposed to be accurate and reliable. If you see any inaccuracy there on Chromecast devices, please file a bug with the appropriate information, thanks.
Related
I have one problem regarding MediaInfo.Builder of Google Cast. I used following code:
MediaInfo mediaInfo = new MediaInfo.Builder("http://shoutcast2.index.uz.zgora.pl:8000")
.setStreamType(MediaInfo.STREAM_TYPE_LIVE)
.setContentType("audio/mpeg")
.build();
But Cast player is not working at all. The reason is, that URL leads to SHOUTCAST. Apparently, the problem is in content type. Could somebody advise which contentType to use for shoutcast streams, or at least provide some workaround for this?
Thank you.
Instead of http://shoutcast2.index.uz.zgora.pl:8000/, use http://shoutcast2.index.uz.zgora.pl:8000/;. Note the semicolon on the end.
SHOUTcast servers are going to look for Mozilla in the User-Agent request header, as a way of detecting a browser vs. a media player. If the server thinks the client is a browser, it will send the admin page rather than the stream. By passing ; in the request URI, the SHOUTcast server will use the user agent string of MPEG OVERRIDE and will send the actual stream data.
You should also know that SHOUTcast isn't truly HTTP compatible. It's close enough that it will probably work, but may stop working in the future. Icecast is one of several better alternatives.
Brad's solution worked for me. Just added a slash and a semicolon after the port. I also changed the content type from audio/mpeg to audio/mp3. My working code looks like this.
MediaInfo mediaInfo = new MediaInfo.Builder("http://shoutcast2.index.uz.zgora.pl:8000/;")
.setStreamType(MediaInfo.STREAM_TYPE_LIVE)
.setContentType("audio/mp3")
.build();
I am trying do play songs from soundcloud, which is working fine for one exception: when the response handler is called, the download of the file is allready complete. I'd like to start playing the file directly after the download started, but i have no clue how to access the data before the response handler gets called. Accessing the data ln the progress handler would be nice, but i need a hint on how to do it.
If you write your own download code using NSURLConnection and
initWithRequest:delegate:startImmediately:, the delegate methods (e.g.
connection:didReceiveData:) will be called as the data becomes available.
You risk running out of data if you try to play the sound as it is downloaded. You should probably implement a buffering system where you download enough extra data for several seconds of playback before you start playing. That way you can smooth over short "stutters" in the download.
I suggest you at least two options to perform what you want:
1. AVPlayer supports playing a file from http. If you download a static file - you can just ask a player to stream over http.
2. You can download a small chunks of file (5 MB at once, for example) and append them to the result file or write directly into memory buffer. You can download a file chunk of specified size by just adding a Content-Range header with an offset you need. (see RFC, 14.16 Content-Range for more specific info). This method requires server to support partial downloads, but in nowadays it is harder to find a sever that does not support this =) Alamofire easily allows you to do that.
I just started using Chromecast SDK today and got bit confused with its APIs and samples given in the web.
What I am trying to do is to send some messages to the Chromecast so it will display them on the big screen. I am going to use Chrome API with HTML5/JS/CSS.
Most examples (https://github.com/pjjanak/chromecast-hello-world/blob/master/sender/index.html , http://nerdwin15.com/2013/10/chromecast-development-part-one-chrome-sender/) in the web uses new Cast.Api() in the sender and uses an Activity in doing so. But I could not find a reference to a Cast.Api in the Chrome API. Most Google references deal with Media and I am not sure whether I have to use them. So to sum up, following are the questions I have (Sorry! I did read the API and developer guide but I am still clueless).
Do I have to write a custom receiver to show text on TV screen. Can't I survive default receiver, chrome.cast.media.DEFAULT_MEDIA_RECEIVER_APP_ID
Is handling multimedia files different from displaying text on the Chromecast or can I set the mime type to text/html and send a text stream (doesn't work for me at the moment)
Are those examples on the web uses a deprecated way of sending data to chromecast?
Thanks in advance,
Ish
Ok I think I found the answer from following documents,
https://developers.google.com/cast/docs/receiver_apps
https://github.com/googlecast/CastHelloText-chrome/blob/master/chromehellotext.html
Will try them and let you all know!
Following example page is very useful for anyone who try writing chromecast apps
https://github.com/googlecast
I'm not sure how you fared, but here are some quick responses to your questions.
Yes, you have to write a custom receiver if you want to do anything other than sending images, audio, or video to the Chromecast. You can see a list of supported media Default Media Receiver here: https://developers.google.com/cast/docs/media
Yes (see above), it requires a custom receiver, which will also require your own appId and I'm pretty sure a custom namespace.
To my knowledge, all of the examples up on https://github.com/googlecast should be relevant, but I am working on a few wrappers to try to simplify getting up and running with custom Chrome Sender and Receiver apps. You can check them out here: https://github.com/googlecast Let me know if those help, and if you have any feedback to share.
I hope you've already figured all this stuff out, but if not hopefully this is useful.
I kick off 5 uploads (of varying size) via the BackgroundTransferService. I have the following questions about the way it works:
It seems that on the emulator it does 2 uploads at a time. Is this how it works on the actual device? Can I programmatically change this behavior?
Can I count on the uploads going out in the order that I submitted them? I seem to be getting conflicting results in my testing.
When I inspect the BackgroundTransferService in my application, does it contain requests from other apps as well or just mine?
Do I need to reconnect events for all the BackgroundTransferRequest objects when coming back from being tombstoned? What about coming back from being reactivated?
Do I need to disconnect events from the BackgroundTransferRequest when I remove it from the BackgroundTransferService.Requests collection?
When I try to upload a non-existing URL:Port (on the localhost), the TransferStatus is reported as WaitingForNonVoiceBlockingNetwork. The upload never actually completes/fails. Is this how it is on the device? Should I remove the request when it encounters this TransferStatus?
You cannot influence the behaviour of the BTS. If you don't like the way it works you can write the transfer functionality as part of your own application but then you have to handle running in the background yourself.
There is no guarantee on sequence.
The BTS may be handling requests from other apps but you won't be able to see the details. Requests() will only return details for your app.
Surely a quick test will tell you this.
It's good practice to.
Have you checked the TransferError property whe you reach this situation? This is a perfectly valild status in other situations and so you shouldn't treat this as a automatic fail.
I'm attempting to port over an Internet Explorer plugin to Firefox, but I'm not sure where to look for what I need.
Basically I need to be able to filter all content that is received by the browser with a certain Content-Type header. I tried implementing a stream converter, and this works, but only for the top-level document in the page, frame, or iframe. I had the same problem with IE, and getting around it was really hacky, and since I would ideally like this to be cross platform I would really like to be able to do this in Firefox without resorting to vtable hacks.
The content is served compressed with a proprietary compression format. So I need to receive the data, decompress it, and change the Content-Type back to what the original uncompressed file should have.
If there is a way to just filter all data received, that would probably be acceptable, I could handle parsing the header myself.
Thanks
I think I may have found what I needed. I came across this link which is used for tracing HTTP calls: http://blues.ath.cx/firekeeper/resources/http_tracer.html
There seems to be some problems with the JavaScript implementation for some reason, and I'm not a JavaScript guru to figure it out, but I've implemented it in C++ and initial results suggest that I should be able to modify it for my needs.
Basically we're replacing the nsIHttpProtocolHandler service with our own implementation, which keeps a reference to the initial implementation. When a call is made to the service, we just proxy it over to the saved original implementation. Then we provide our own implementation of nsIHttpChannel and nsIStreamListener which we use as proxies too.
Again we proxy most of the calls back off to the original handlers. But in OnDataAvailable, instead of passing the data on to the underlying nsIStreamListener, we save it using nsIStorageStream. Then in OnStopRequest, after we've gotten all of the data, we can decompress it and then call OnDataAvailable on the original handler, followed by OnStopRequest.
It has worked on some small simple tests so far, but I'll have to put it through some more rigorous tests... I'll also have to figure out if I can do the same thing with HTTPS.
The biggest problem I see at the moment is that it relies on some unfrozen interfaces such as nsIHttpChannelInternal. Can't be helped though as far as I can tell, and my version compatibility requirements are pretty small, so I can live with it if I have to.
In the meantime, if anybody has any other suggestions, I'm all ears :D