Related
was thinking about this possibly being a sweet setup hopefully miracast will be implemented into the device or possible being implemented into xbmc having that along the airplay option on xbmc enabled would make this a pretty sweet device
i purchased(preordered one) but I was hoping it would be more so like a media center device kinda like google tv but no hdmi out so no google tv overlay. But if I could use this to do miracast with my 4.2 sgs3 and whenever friends come over can use xbmc to allow them to do airplay that would be really cool
reason i bring up miracast support is because supposedly is supported in tegra 3
i've been trying to figure/find out how you go about setting up a miracast server but the documentation doesn't seem to exist not saying that i have the ability to implement but i wouldn't mind taking a look into it
thoughts?
This is more of a question for xbmc team. I suggest you provide that feedback on their forum. There was a talk of xbmc supporting miracast but no eta.
Sent from my GT-I9305 using xda premium
As long as it supports PLEX, I am sold!
Keland44 said:
was thinking about this possibly being a sweet setup hopefully miracast will be implemented into the device or possible being implemented into xbmc having that along the airplay option on xbmc enabled would make this a pretty sweet device
i purchased(preordered one) but I was hoping it would be more so like a media center device kinda like google tv but no hdmi out so no google tv overlay. But if I could use this to do miracast with my 4.2 sgs3 and whenever friends come over can use xbmc to allow them to do airplay that would be really cool
reason i bring up miracast support is because supposedly is supported in tegra 3
i've been trying to figure/find out how you go about setting up a miracast server but the documentation doesn't seem to exist not saying that i have the ability to implement but i wouldn't mind taking a look into it
thoughts?
Click to expand...
Click to collapse
I've heard the documentation costs around $200 and that might not even be all of it. Or I might be pulling that number out of air, don't remember where I saw that, but did find this:
http://forum.xbmc.org/showthread.php?tid=147320
I am more interested in seeing the Android Transporter Player ported to Ouya, except that they haven't released their source code on the sending side yet...
https://github.com/esrlabs/AndroidTransporterPlayer
https://www.youtube.com/watch?v=lyoZoNA8U24
~Troop
I'm not from familiar with Miracast. All I know is what the Wiki page said. It really reads like DNLA. And from my experience, this has been something that can be app dependent. Since I have no experience with Miracast, I don't know if it's full mirroring or just certain apps.
That said, Miracast may just be work versus just installing individual apps. Unless there is something in the application code for specific devices, if you side load an APK, it should run on the Ouya. Doesn't mean it will run well or look correct. Thus, you may be able to just side load XBMC. I know I'll try it with Plex, Netflix, Hulu, various sports--MLB, NHL, NBA, etc--and so on.
I couldn't figure out what the end result you were suggesting about friends coming over and their mobile devices.
lovekeiiy said:
I'm not from familiar with Miracast. All I know is what the Wiki page said. It really reads like DNLA. And from my experience, this has been something that can be app dependent. Since I have no experience with Miracast, I don't know if it's full mirroring or just certain apps.
That said, Miracast may just be work versus just installing individual apps. Unless there is something in the application code for specific devices, if you side load an APK, it should run on the Ouya. Doesn't mean it will run well or look correct. Thus, you may be able to just side load XBMC. I know I'll try it with Plex, Netflix, Hulu, various sports--MLB, NHL, NBA, etc--and so on.
I couldn't figure out what the end result you were suggesting about friends coming over and their mobile devices.
Click to expand...
Click to collapse
I believe Miracast is primarily for screencasting - ie it just mirrors what is on the device's screen onto the TV or whatever is receiving. And I believe the previous poster was saying that it would be nice if it is easy to screencast from your phone to the TV and allow visiting friends to be able to easily screencast their content as well - so if one person has a video they want to show everyone, it's not a hassle to pull it up on the big screen. I think this is what a lot of us want.
~Troop
Trooper_Max said:
I believe Miracast is primarily for screencasting - ie it just mirrors what is on the device's screen onto the TV or whatever is receiving. And I believe the previous poster was saying that it would be nice if it is easy to screencast from your phone to the TV and allow visiting friends to be able to easily screencast their content as well - so if one person has a video they want to show everyone, it's not a hassle to pull it up on the big screen. I think this is what a lot of us want.
~Troop
Click to expand...
Click to collapse
yea this is exactly what i'm lookin for been keeping an eye on it have google alerts set up for pretty much anytime miracast is being searched on the net to possibly find any tidbit of info that might be helpful with this. thanks Troop
video streaming
Hi all. Bit late to the party but my ouya comes tomorrow
Assuming no problems on sideloading why not just use
twonky. Been using for ages bouncing files between my
nas drive, xperia s, xoom2 and Xbox. Even adhoc with
android.......jus puttin it out there..... It's spot on even with
playlists and web streams.
I would love to see a physical remote used with the chromecast. I feel that is a major item missing when it comes to controlling a set top box. This wouldn't be all that helpful with casting, but for netflix/hulu use and other apps it would be great. I like having dedicated/physical buttons for things.
Not sure where to begin on this journey. Anyone else feel the same way I do?
Possible options:
WiiMote - Bluetooth?
Keyboard - bluetooth
Is this someones attemp at a wiimote + chromecast?
https://code.google.com/p/chromecas...entation/ABI/testing/sysfs-driver-hid-wiimote
Don't know what you'd control with that.
You can use a wiimote/dualshock 3 with your android device to control YouTube, if that's what you mean.
Sent from my XT907 using xda premium
Leraeniesh said:
Don't know what you'd control with that.
You can use a wiimote/dualshock 3 with your android device to control YouTube, if that's what you mean.
Click to expand...
Click to collapse
I think they're after a physical implementation of RemoteCast
Closest thing I can think of would be to see if RemoteCast's dev would support some kind of paired Bluetooth controller like a Wiimote, but its function would still be tied to a phone/tablet somewhere.
If Chromecast does well, I wouldn't be surprised if Google releases some firmware that enables the Bluetooth part of its WiFi chip and sells us a remote and/or provides Bluetooth functionality in the SDK. But first things first, they need to release the SDK...
I would be much more interested in some IR Control myself...
Not just for when I'm using the Chromecast but for when I'm not as well.
If implemented it could automatically change your TV to the chromecast input when you cast something to Chromecast and when your not casting it would allow the Chromecast to serve as a conduit to using your tablet/phone as a full IR remote for your TV, Set Top Boxes and whatever else you have at your Home Entertainment system.
Asphyx said:
I would be much more interested in some IR Control myself...
Not just for when I'm using the Chromecast but for when I'm not as well.
If implemented it could automatically change your TV to the chromecast input when you cast something to Chromecast and when your not casting it would allow the Chromecast to serve as a conduit to using your tablet/phone as a full IR remote for your TV, Set Top Boxes and whatever else you have at your Home Entertainment system.
Click to expand...
Click to collapse
Mine already changes the channel and turns the TV on if it's off.
Unless you have an unusual setup, all you need to do is enabled HDMI-CEC in your TV's settings, and make sure Chromecast has power when the TV is off (if you want it to turn the TV on).
IR would be quite complicated, mainly because something has to receive the IR and process it.
You'd probably be better off getting a network-enabled IR receiver/blaster like the GlobalCache GC-100 to do network-triggered IR blasting.
bhiga said:
Mine already changes the channel and turns the TV on if it's off.
Unless you have an unusual setup, all you need to do is enabled HDMI-CEC in your TV's settings, and make sure Chromecast has power when the TV is off (if you want it to turn the TV on).
IR would be quite complicated, mainly because something has to receive the IR and process it.
You'd probably be better off getting a network-enabled IR receiver/blaster like the GlobalCache GC-100 to do network-triggered IR blasting.
Click to expand...
Click to collapse
I don't have that option on my TVs...
As for receiving IR.... no not what I am asking...Just for the chromecast to SEND IR and act as the globalcache device does.just on the Tx side.
I don't want to use a IR remote I want to be able to control the Home Ent system (Ir devices) via my Tablet. All I need is Tx for that and if CC had a mini plug for IR transmitter lead and some IR emitter circuitry it could do it. IR Codes would be set via the Tablet App.
Asphyx said:
I don't have that option on my TVs...
As for receiving IR.... no not what I am asking...Just for the chromecast to SEND IR and act as the globalcache device does.just on the Tx side.
I don't want to use a IR remote I want to be able to control the Home Ent system (Ir devices) via my Tablet. All I need is Tx for that and if CC had a mini plug for IR transmitter lead and some IR emitter circuitry it could do it. IR Codes would be set via the Tablet App.
Click to expand...
Click to collapse
Ahh, I see. Well, I was working within the constraints of what could potentially be done with software development and existing hardware.
Adding an IR minijack to Chromecast is well outside of that.
bhiga said:
Ahh, I see. Well, I was working within the constraints of what could potentially be done with software development and existing hardware.
Adding an IR minijack to Chromecast is well outside of that.
Click to expand...
Click to collapse
Yes but I'm already thinking towards Chromecast II! LOL
Or would they call it Chromecast 2014 like they did with the Nexus by adding rear facing camera and LTE! LOL
Asphyx said:
Yes but I'm already thinking towards Chromecast II! LOL
Or would they call it Chromecast 2014 like they did with the Nexus by adding rear facing camera and LTE! LOL
Click to expand...
Click to collapse
I'm hoping more along Chromecast 2015 - at least give the current one a full year before making it obsolete!
bhiga said:
I'm hoping more along Chromecast 2015 - at least give the current one a full year before making it obsolete!
Click to expand...
Click to collapse
Maybe we both should just hope we get rid of the whitelist before 2020! LOL
Doesnt have to be an IR remote. Could be wireless like on the Roku, or bluetooth like on the Wii.
An IR blaster on the ChromeCast would be helpful for learning remotes, so you could have 1 remote to control all of your devices.
I just prefer the physical feel of a remote. Not having to fumble around looking for capacitive buttons.
Im trying to find a cheap alternative to a Roku 3.
$35 Chromecast + remote would be cheaper than $75+ for the R3.
Why the hell do you need a physical remote when its all network based anyways? IR remote is not needed for any of the apps and an IR remote wouldn't handle all advances functions seamlessly anyways. What do you want an apple TV remote which is about worthless and constantly getting lost anyways? Perhaps and hdmi-cec network based remote might be cool but HDMI cec is still wonky though its a lot better than a few years ago.
sent from my sm-9005.
Asphyx it might be that it is not named HDMI-CEC as the diffrent vendors like to call it there own name. Here is a list over the most well known names of HDMI-CEC and it is something that have been in flat screens the last 5-6 years now so as long your tv is not older then that you should have it.
Code:
Branding Vendor
Anynet Samsung
BRAVIA Sync Sony
KURO Link Pioneer
NetCommand Mitsubishi
REGZA-LINK Toshiba
RIHD Onkyo
SimpLink LG
I am just hoping for more implementation of HDMI-CEC. I would like to use the atual tv remote to play/pause or fast fwd etc. I would also like the ability to NOT turn on the tv when i fire up google music. Now if it could turn on my receiver that would be great
ParanoidDK said:
Asphyx it might be that it is not named HDMI-CEC as the diffrent vendors like to call it there own name. Here is a list over the most well known names of HDMI-CEC and it is something that have been in flat screens the last 5-6 years now so as long your tv is not older then that you should have it.
Code:
Branding Vendor
Anynet Samsung
BRAVIA Sync Sony
KURO Link Pioneer
NetCommand Mitsubishi
REGZA-LINK Toshiba
RIHD Onkyo
SimpLink LG
Click to expand...
Click to collapse
Yes but I'm almost certain that standard was made more recently than the TV I have...
I pretty much have a first Gen HDTV and believe the CEC Protocal was not part of HDMI 1.1
It wasn't available until HDMI 1.2a if I'm not mistaken.
I could check for a firmware upgrade but merely changing the channel on the TV to Chromecast is only part of what I would like it to do.
I suppose I will have to spring for the $200 IRoverIP blaster to get it.
scoobdude said:
I am just hoping for more implementation of HDMI-CEC. I would like to use the atual tv remote to play/pause or fast fwd etc.
Click to expand...
Click to collapse
Many would find that handy - so it is a bit strange that it has not yet been implemented. One reason might be that the chromecast team want to emphasise that a remote is not necessary and that controlling using a mobile device is preferable. I guess that it will be added down the road (just like the delete button was added to gmail).
Arne S said:
Many would find that handy - so it is a bit strange that it has not yet been implemented. One reason might be that the chromecast team want to emphasise that a remote is not necessary and that controlling using a mobile device is preferable. I guess that it will be added down the road (just like the delete button was added to gmail).
Click to expand...
Click to collapse
Actually the most likely reason is they wanted to keep the cost down at it's current $35 and adding any IR or extra CEC support would have driven the price up another 10-20 dollars.
These things we are hoping for may all show up whenever Chromecast II comes along.
Right now they are competing with Miracast dongles that can be had for around the same price point.
I think the target with this initial version was to do Miracast better because it can work over wired networks as well and frees the device that initializes the stream to do other things..
Not possible with Miracast!
Asphyx said:
Actually the most likely reason is they wanted to keep the cost down at it's current $35 and adding any IR or extra CEC support would have driven the price up another 10-20 dollars.
Click to expand...
Click to collapse
The chromecast is already using some CEC functions so additional HW would be probably not be required to implement support for using the TV remote to control the dongle.
Arne S said:
The chromecast is already using some CEC functions so additional HW would be probably not be required to implement support for using the TV remote to control the dongle.
Click to expand...
Click to collapse
Big difference between adding a Transistor or two to a chip that will make a contact to switch to the current input or Power On than it is to put an entire set of them that can do much more complex functions. Just the TV compatibility alone would add to the price.
I agree it should be possible to do easily but these things all need to be added to the silicon which would make it cost more.
This is SOP for any new device you're trying to get adopted. The Next gen will probably add a ton of things to inspire upgrading to it.
Remember the Nexus7 (2012) came with no Rear Facing Camera or LTE to keep the price down as well....
Fast Forward to 2013 and Nexus 7 (2013) has BOTH included!
This version we have now is a proof of concept device, Gets us hooked and serves as a starter platform to get 3rd Party support for it's innovative streaming methods.
And now that is done so the 3rd parties can start making it useful while Google thinks up what the next generation can do that the first gen doesn't do but probably should!
Just a matter of time of you ask me...And don't be surprised to see some Chromecast functionality built into your smart TV that has the full blown IR and CEC support your looking for.
Here is a list of all the functions CEC does most of which have no useful application regarding Chromecast until such time as they decide using Chromecast as an IP Remote device is something they really want to do. And most are not applicable other than play stop and pause.
One Touch Play allows devices to switch the TV to use it as the active source when playback starts (Currently Supported I believe)
System Standby enables users to switch multiple devices to standby mode with the press of one button
Preset Transfer transfers the tuner channel setup to another TV set
One Touch Record allows users to record whatever is currently being shown on the HDTV screen on a selected recording device
Timer Programming allows users to use the electronic program guides (EPGs) that are built into many HDTVs and set-top-boxes to program the timer in recording devices like PVRs and DVRs
System Information checks all components for bus addresses and configuration
Deck Control allows a component to interrogate and control the operation (play, pause, rewind etc.), of a playback component (Blu-ray or HD DVD player or a Camcorder, etc.) (This is what your looking for I sure wouldn't mind having this)
Tuner Control allows a component to control the tuner of another component
OSD Display uses the OSD of the TV set to display text
Device Menu Control allows a component to control the menu system of another component by passing through the user interface (UI) commands
Routing Control controls the switching of signal sources (Currently Supported)
Remote Control Pass Through allows remote control commands to be passed through to other devices within the system (I want THIS!)
Device OSD Name Transfer transfers the preferred device names to the TV set
System Audio Control allows the volume of an AV receiver, integrated amplifier or pre-amplifier to be controlled using any remote control from a suitably equipped device(s) in the system (You and I would BOTH like this!)
Asphyx said:
Big difference between adding a Transistor or two to a chip that will make a contact to switch to the current input or Power On than it is to put an entire set of them that can do much more complex functions. Just the TV compatibility alone would add to the price.
I agree it should be possible to do easily but these things all need to be added to the silicon which would make it cost more.
Click to expand...
Click to collapse
That might be. I do not know. The Chromcast is powered by the Marvel Armanda 1500-mini chip which is also used in other devices. I do not know what CEC capabilities this chip has but according to its documentation it supports HDMI v1.4 while CEC was introduced in v1.3. I think that both the fact that this is a "standard" chip also used in other devices and the fact that it uses HDMI v1.4 points in the direction that the HW in the Chromecast dongle supports more CEC functions than the ones currently exposed.
Hey im new to this chromecast. I can see my chrome browser on the pc but not on android, how can I do that? Sijce here are very experienced users oj chromecast can someone describe the full working potentials this device has?
Sent from my GT-N8013 using xda app-developers app
You cant do squat with Chrome on Android yet for some odd reason.
Tab casting from Chrome uses the host CPU to re-encode the video and stream it to the Chromecast on-the-fly. Tablet and phone CPUs don't have enough processing power. That's why there's no Chromecast extension for Chrome on your portable device.
Well that sucks bc there is possibilities with this chromecast. I downloaded the allcast and obviously updated my google services. I cast a picture and it doesnt show normal, shows rotated to the left. Can you cast from the gallery vids and photos?
Sent from my GT-N8013 using xda app-developers app
The man problem is the fact that Android Chrome does not support Chrome Apps and Extensions.
Something I'm told Google is working on...
Asphyx said:
The man problem is the fact that Android Chrome does not support Chrome Apps and Extensions.
Something I'm told Google is working on...
Click to expand...
Click to collapse
Yea they better be working on it, this has been out couple months now they need to update more
Sent from my GT-N8013 using xda app-developers app
Google is working on a way to mirror your android screen to the chromecast and we know this because on kitkat roms theres an option to cast screen but isn't quite working yet. Its only been coded in but thats it.
Sent from my SPH-L710 using Tapatalk
tooblackforjack said:
Google is working on a way to mirror your android screen to the chromecast and we know this because on kitkat roms theres an option to cast screen but isn't quite working yet. Its only been coded in but thats it.
Click to expand...
Click to collapse
KitKat roms have Miracast, a different protocol.
Supported by HTC and Samsung since 2012 with their private dongles.
Not new, sorry.
EarlyMon said:
KitKat roms have Miracast, a different protocol.
Supported by HTC and Samsung since 2012 with their private dongles.
Not new, sorry.
Click to expand...
Click to collapse
Yeah ik, i was just informing in case he didn't know sorry.
Sent from my SPH-L710 using Tapatalk
EarlyMon said:
KitKat roms have Miracast, a different protocol.
Click to expand...
Click to collapse
Yes, but Google has renamed it to Cast Screen. Clearly, they will be adding support for casting to Chromecasts directly inside of Android. Otherwise, renaming it to match the Chromecast nomenclature makes no sense.
bozzykid said:
Yes, but Google has renamed it to Cast Screen. Clearly, they will be adding support for casting to Chromecasts directly inside of Android. Otherwise, renaming it to match the Chromecast nomenclature makes no sense.
Click to expand...
Click to collapse
Because MiraCAST isn't confusing enough?
I'm aware that a number of blogs not familiar with Miracast are spreading that rumor. I think it's wishful thinking but we'll see, won't we?
http://www.howtogeek.com/177145/wir...ed-airplay-miracast-widi-chromecast-and-dlna/
http://readwrite.com/2013/11/07/android-kitkat-developers-users
A side note, Android 4.4 KitKat devices can now be certified by the Wi-Fi alliance as being Miracast compatible. That is a big step for Android in being able to stream content from a device to a television by supporting more streaming standards. Now only if the Chromecast supported Miracast.
Click to expand...
Click to collapse
http://www.androidpolice.com/tags/miracast/
So, you believe that WiFi Direct is coming to the existing Chromecast?
Or that in addition to Miracast, they'll be providing a second protocol for phones, with a server (like Koush did)? And people will be able to figure out the two casting options on their devices?
I think that it's far more likely that rather than put both protocols on a phone or into the existing Chromecast, it's more likely that DIAL support plus Miracast *might* appear in a Chromecast 2.
Miracast dongles already exist, it's February and the SDK libraries still aren't out, and in July, Chromecast will be a year old.
Apple TV costs $100 with this feature, a Belkin Miracast dongle is $80, an HTC Media Link HD is $100, the Samsung Allshare Cast Hub was a hundred, is $65 on Amazon now.
It's possible that Google is going to pump this in to the existing Chromecast for the faithful for free, but I'm just not feeling it.
Either way, so far KitKat includes Miracast, not DIAL.
EarlyMon said:
Or that in addition to Miracast, they'll be providing a second protocol for phones, with a server (like Koush did)? And people will be able to figure out the two casting options on their devices?
I think that it's far more likely that rather than put both protocols on a phone or into the existing Chromecast, it's more likely that DIAL support plus Miracast *might* appear in a Chromecast 2.
...
It's possible that Google is going to pump this in to the existing Chromecast for the faithful for free, but I'm just not feeling it.
Either way, so far KitKat includes Miracast, not DIAL.
Click to expand...
Click to collapse
First part:
Since it's (Android) device mirroring functions appear to be in the SDK, but are limited only to OEM developers, my best-guess is that what we'll see is any Chromecast device mirroring will have to be "cooked" into a ROM rather than a loose bit (makes sense - that's how Samsung's AllShare Cast works too).
Hopefully the UX engineers win and make it so the Screen Mirroring option at least combines Google Cast and Miracast device options together, rather than having separate options for Screen Mirroring (Miracast) and Screen Mirroring (Google Cast).
Second part:
Yeah, not going to hold my breath. As I keep saying, screen mirroring is not the core competency of Chromecast.
bhiga said:
First part:
Since it's (Android) device mirroring functions appear to be in the SDK, but are limited only to OEM developers, my best-guess is that what we'll see is any Chromecast device mirroring will have to be "cooked" into a ROM rather than a loose bit (makes sense - that's how Samsung's AllShare Cast works too).
Hopefully the UX engineers win and make it so the Screen Mirroring option at least combines Google Cast and Miracast device options together, rather than having separate options for Screen Mirroring (Miracast) and Screen Mirroring (Google Cast).
Click to expand...
Click to collapse
Both together sounds like a bit much, but it's possible.
Samsung is likely going their own way.
http://www.slashgear.com/samsung-an...ultiscreen-and-overlay-capabilities-28303309/
Second part:
Yeah, not going to hold my breath. As I keep saying, screen mirroring is not the core competency of Chromecast.
Click to expand...
Click to collapse
Agree.
If you ask me any attempt to make CCast work like a Miracast would be a big waste, Even a downgrade!
No need for Direct Connection for Mirroring as Mirror over IP is far more flexible and less problematical. Not to mention requires no special software support like Miracast does. If they really wanted Miracast type direct mirroring all it would take is some additions to the rom cause hardware wise, the CCast has everything it needs
It may not be part of why the CCast was developed but I don't see Google being as smart as they are leaving that market open to Miracast dongles when they know full well the only thing inhibiting CCast from doing it (and better) is their lack of developing an App that does it for Mobile...
As for the Casting support in the SDK for OEM use I suspect that is more generic in nature and just an exposure of the display system to support Miracast, Perhaps CCast Mirroring and any other 2nd screen tech that comes down the pipe.
I think mirroring feature is a bit overrated myself, it's good for an audience but not for an operator's use.
It's easier to do than what CCast is trying to do because there is no need for a control protocol...Just a simple transcoder for Video and Audio the rest is all done on the Master Display device.
As for that Samsung option I don't expect it to take off due to proprietary concerns. It's meant for Samsung SmartTVs and I bet LG and Sony won't support it. Samsung would be better off building that capability directly into the TV itself.
DIAL is still in its infancy and I expect the protocol to expand as support and adoption of it grows...
Whatever lessons they learned from Chromecast I expect to be addressed whenever they get around to making the second gen CCast.
Wired Networking or at minimum 5Ghz Wireless support is to be expected as would a more robust Video playback Compatibility.
It's not likely that any app that adds CCast support is going to remove it in the future which means as the Apps list grows so too does the chance we have of seeing this supported without the need for a dongle at all.
TV over the Web will work the way it was supposed to and remove the biggest hurdle to achieving full IPTV to date...
The Navigation and Channel Guide no one could figure out how to do....
And who knew the Web Browser was the answer all along.
Samsung is still the largest supplier of flat screen TVs in North America, is it not?
Besides, they've never been shy about adding interfaces to support the future. I have a Samsung TV with a specialized iPod interface as proof. (And I believe that the article did say clearly that Samsung was going to build the new casting into their TVs.)
And none of the TV makers think twice about adding fragmenting features, and Samsung certainly doesn't for their mobile devices.
As for the claim that it's just about making a mobile app and declaring victory for screen casting, you might want to review the API changes that have been evolving for months.
Doing that without library support and not differentiating DRM vs non-DRM cast calls may seem simple to you but it doesn't to me.
Last published, Netflix and YouTube accounted for over 50% of North American broadband traffic.
Screen casting may be an emerging market, or it could just be a flash in the pan.
EarlyMon said:
Samsung is still the largest supplier of flat screen TVs in North America, is it not?
Besides, they've never been shy about adding interfaces to support the future. I have a Samsung TV with a specialized iPod interface as proof. (And I believe that the article did say clearly that Samsung was going to build the new casting into their TVs.)
And none of the TV makers think twice about adding fragmenting features, and Samsung certainly doesn't for their mobile devices.
As for the claim that it's just about making a mobile app and declaring victory for screen casting, you might want to review the API changes that have been evolving for months.
Doing that without library support and not differentiating DRM vs non-DRM cast calls may seem simple to you but it doesn't to me.
Last published, Netflix and YouTube accounted for over 50% of North American broadband traffic.
Screen casting may be an emerging market, or it could just be a flash in the pan.
Click to expand...
Click to collapse
Well I guess Samsung is the largest supplier of Flat Screens in NA just like Apple is the biggest supplier of Smart Phones in NA...
Until you realize combine all the NOT Samsung Models into an US vs THEM and they are not the Majority by any means...Same with Apple vs Android as opposed to Apple vs Samsung itself.
As for the DRM you forget that DIAL doesn't care and leaves using or not using up to the content provider. It's there if you want it and if not you only have to support the DIscover and Launch capabilities.
Is Sony (who owns a majority of content compared to Samsung) going to cut out DIAL for Samsung's proprietary system?
Doubtful!
And since the CCast and DIAL supports ANY TV with HDMI input it has a far better chance of being adopted as a standard than Samsung's device is.
IMO most of the current desire for screencasting is really a "backup plan" for content that is currently not supported via DIAL. "___ isn't supported so I want to mirror my screen/tab."
So the mainstream correct solution would be to get the desired content providers on-board with Google Cast.
That would leave non-"canned" content for screen mirroring (games in a second screen model, general browsing, presentations, Skype, etc).
I'd love to see a native Skype for Chromecast using the microphone and controls on my tablet/phone with video on the TV but keeping it in sync might be nontrivial engineering on the Skype end.
Asphyx said:
As for the DRM you forget that DIAL doesn't care and leaves using or not using up to the content provider. It's there if you want it and if not you only have to support the DIscover and Launch capabilities.
Click to expand...
Click to collapse
I can only invite you, again, to look at the actual casting API rather than rely on assumptions.
It's NOT the same as that last July and it absolutely, positively does recognize casting DRM content.
Start here -
https://groups.google.com/a/chromium.org/forum/m/#!topic/apps-dev/emlKA4C-c90
And then Google for what's happened since, along with Koush's commentaries.
Is Sony (who owns a majority of content compared to Samsung) going to cut out DIAL for Samsung's proprietary system?
Doubtful!
And since the CCast and DIAL supports ANY TV with HDMI input it has a far better chance of being adopted as a standard than Samsung's device is.
Click to expand...
Click to collapse
Did you even read the article to discover that Samsung is using a superset of DIAL and support by Sony, LG, and Panasonic TV sets is expected?
---------- Post added at 04:14 PM ---------- Previous post was at 04:07 PM ----------
bhiga said:
IMO most of the current desire for screencasting is really a "backup plan" for content that is currently not supported via DIAL. "___ isn't supported so I want to mirror my screen/tab."
So the mainstream correct solution would be to get the desired content providers on-board with Google Cast.
That would leave non-"canned" content for screen mirroring (games in a second screen model, general browsing, presentations, Skype, etc).
Click to expand...
Click to collapse
Have you checked out what Vbukit is planning on supporting with Chromecast?
Pretty interesting, I think.
Not sure about getting Skype sorted out.
It seems like every time Skype updates, it's a step backwards, but that's just my off-topic opinion.
EarlyMon said:
Have you checked out what Vbukit is planning on supporting with Chromecast?
Pretty interesting, I think.
Not sure about getting Skype sorted out.
It seems like every time Skype updates, it's a step backwards, but that's just my off-topic opinion.
Click to expand...
Click to collapse
Yes, Vbukit is a little rough around the edges, but I can definitely see it being useful for presenters and educators especially.
Agree with you on Skype...
Back on-topic, there isn't a lot of technical copyright/DRM concern regarding casting anything you see on the screen - after all, if you can see it on the screen, you've seen it already. It's just that the legal types are not technical, highly likely to make crazy conclusions and assumptions, and get paid no matter what they do - so it's in their best interest to make issue of little things. I've personally seen warnings from the copyright hunters complete with ISP traces down to the router endpoint too, so they are watching and waiting to pounce.
I still hope an optimized device mirroring comes as something deeper within the Android OS itself.
Something akin to RemoteX in the Windows space, which is a "remote render" or offload of the graphic drawing functions. Anything that's not reliant upon a local bitmap could be rendered on Chromecast, rather than sent as large/inefficient bitmap data or CPU-intensive compressed data. That would make some "twitchy" games playable, especially if Chromecast has enough memory/storage to cache bitmaps that it does end up needing. Full-screen video, of course, doesn't benefit, nor does typical FPS games since the entirety of the screen is being updated with bitmaps.
For fun, I played a video on my phone and watched it on my computer (no audio) via TeamViewer. It took me back to the early 90's.
We've waited for apps and other optimized content this long, let's see what Google delivers.
Content providers have been successfully inhibiting HDMI and MHL output from their apps running on Android devices.
I believe that the casting API changes may have them in mind, but that's pure conjecture on my part.
I think it's ridiculous but so long as people check the boxes and agree to the terms of service, they're free to enforce it.
Hello XDA Developers,
I need some to developers to build an app.
The idea as that to add the network media devices (XBMC, Upnp..) to the list of Cast To.
Example -
You are watching a video using Youtube app.
You press the cast button (It will show the list of all network media devices)
You cast the video to XBMC
XBMC plays it on your TV or Monitor
Now use Youtube app as the remote for the playback
Thank You.
quappic said:
Hello XDA Developers,
I need some to developers to build an app.
The idea as that to add the network media devices (XBMC, Upnp..) to the list of Cast To.
Example -
You are watching a video using Youtube app.
You press the cast button (It will show the list of all network media devices)
You cast the video to XBMC
XBMC plays it on your TV or Monitor
Now use Youtube app as the remote for the playback
Thank You.
Click to expand...
Click to collapse
Not sure that can be done via an App I think it is all incorporated into the Media Router library of Android.
It might be possible to hack that and replace it or make the changes to a custom rom using that library though.
Asphyx said:
Not sure that can be done via an App I think it is all incorporated into the Media Router library of Android.
It might be possible to hack that and replace it or make the changes to a custom rom using that library though.
Click to expand...
Click to collapse
Libraries are inside the apps... so I dont think custom rom will affect it! (I may be wrong... not so knowledgeable about ROMs)
But I guess we can use the Xposed Framework's hook method to access it... And change it to search for all devices.... (Easier said then done!)
I need help to pinpoint that function in the Media Router Library....
quappic said:
Libraries are inside the apps...
Click to expand...
Click to collapse
Not in this case...That library is part of Android itself and Apps can use it but it is not in the app itself.
The app merely calls to that android library.
Asphyx said:
Not in this case...That library is part of Android itself and Apps can use it but it is not in the app itself.
The app merely calls to that android library.
Click to expand...
Click to collapse
I did find a app called 'Cast to Upnp/Dlna for GMusic' which seems to do the job..
It also claims that it will show network devices also in the cast to list in Chrome... (When you play using play music and chrome... I dosent work for me though... But works through the app.)
I guess it emulates upnp devices to be Chromecast.
Anyhow dismantled the apk. But could not make sense..
its too complicated due to obfuscated code! I am stuck here! :/
quappic said:
I did find a app called 'Cast to Upnp/Dlna for GMusic' which seems to do the job..
It also claims that it will show network devices also in the cast to list in Chrome... (When you play using play music and chrome... I dosent work for me though... But works through the app.)
I guess it emulates upnp devices to be Chromecast.
Anyhow dismantled the apk. But could not make sense..
its too complicated due to obfuscated code! I am stuck here! :/
Click to expand...
Click to collapse
Perhaps I am not understanding what you want...
It's easy to make an app that can include those other targets in an app but it's not possible to have that work in other apps Cast menu.
AT least not that I know of.
If anyone could do this it would be Koush who makes Allcast and supports what your looking for.
Asphyx said:
Perhaps I am not understanding what you want...
It's easy to make an app that can include those other targets in an app but it's not possible to have that work in other apps Cast menu.
AT least not that I know of.
If anyone could do this it would be Koush who makes Allcast and supports what your looking for.
Click to expand...
Click to collapse
How to include them in an app?
If we find it how to add those targets then...
We can use Xposed to add that to other cast apps too! (For now...)
Koush made allcast as an regular which is no use in this situation :/
You need the developers for those apps to support the feature...Only they can change how their own app works.
In the meantime check out BubbleUPnP out as it does what you want AND transcodes provided you have a PC to run the Server software on.
It will allow you to select just about any target device on your network that supports DLNA, UPnP and DIAL.
Asphyx said:
You need the developers for those apps to support the feature...Only they can change how their own app works.
In the meantime check out BubbleUPnP out as it does what you want AND transcodes provided you have a PC to run the Server software on.
It will allow you to select just about any target device on your network that supports DLNA, UPnP and DIAL.
Click to expand...
Click to collapse
As the casting uses another library (here Mediarouter of v7 android support library) to search for the chromecast devices.... We can use Xposed to hook the search method (hypothetically) and make it search for Upnp devices too...
I am aware of BubblePnP (same developer as of Cast to UPNP/DLNA for GMusic app)
But it dose not serve the propose.....
Like when you are watching a youtube you can simply cast it to XBMC and control the playback through the youtube app (Thats the feature I want)
But when you use BubblePnP we share a youtube video link (Non-Streaming) which then the upnp looks up using youtube plugin for it (Not every device have that plugin) then they play (their is also chance that it cant play it... restrictions for example.... even though you can play it on your mobile)
I guess the best step would be study the mediarouter library to check things out!
Let me disassemble the Google Play Music app and try to look how does it cast....
quappic said:
As the casting uses another library (here Mediarouter of v7 android support library) to search for the chromecast devices.... We can use Xposed to hook the search method (hypothetically) and make it search for Upnp devices too...
I am aware of BubblePnP (same developer as of Cast to UPNP/DLNA for GMusic app)
But it dose not serve the propose.....
Like when you are watching a youtube you can simply cast it to XBMC and control the playback through the youtube app (Thats the feature I want)
But when you use BubblePnP we share a youtube video link (Non-Streaming) which then the upnp looks up using youtube plugin for it (Not every device have that plugin) then they play (their is also chance that it cant play it... restrictions for example.... even though you can play it on your mobile)
I guess the best step would be study the mediarouter library to check things out!
Let me disassemble the Google Play Music app and try to look how does it cast....
Click to expand...
Click to collapse
I agree completely with the goal and feature, I'm just not sure you can hijack 3rd party calls to the Media Router library, insert the extra device search (or enable the ones that are there) and have them display in some App that has JUST CCast support to display DLNA targets as well.
If anyone is capable of that I would suspect he posts here! LOL
I would ask Koush Ditta about the viability...
But I wasn't shooting down the idea, just the notion that you could hack or patch the device to list those targets for any app that uses the Cast menu.
Asphyx said:
I agree completely with the goal and feature, I'm just not sure you can hijack 3rd party calls to the Media Router library, insert the extra device search (or enable the ones that are there) and have them display in some App that has JUST CCast support to display DLNA targets as well.
Click to expand...
Click to collapse
Sounds very hacky.
The flip-side, and I think what they mentioned, was to have a "middleman" piece that emulates a Chromecast, similar to how BubbleUPnP Server can pull stuff from other sources on behalf of a DLNA/UPnP receiver.
Problem is, all the Chromecast emulators (LeapCast, CR Cast, CheapCast) seem to have been broken by the enhanced signing security in the Cast SDK 2.0
Asphyx said:
I agree completely with the goal and feature, I'm just not sure you can hijack 3rd party calls to the Media Router library, insert the extra device search (or enable the ones that are there) and have them display in some App that has JUST CCast support to display DLNA targets as well..
Click to expand...
Click to collapse
CCast supported apps can send DLNA targets as they just send a streaming URL (According to log of Play Music...)
Anyway I disassembled the Play Music app. Great thing is that code is not obfuscated... But need a lot of work to understand the code...
@bhiga I did not understand completely!
But as far as I understood (may be wrong) is that you are saying to emulate a DLNA device as a chromecast, right?
But cant devices like XBMC directly get the streaming URL and stream it? (Confused) :/
quappic said:
CCast supported apps can send DLNA targets as they just send a streaming URL (According to log of Play Music...)
Anyway I disassembled the Play Music app. Great thing is that code is not obfuscated... But need a lot of work to understand the code...
@bhiga I did not understand completely!
But as far as I understood (may be wrong) is that you are saying to emulate a DLNA device as a chromecast, right?
But cant devices like XBMC directly get the streaming URL and stream it? (Confused) :/
Click to expand...
Click to collapse
Can maybe if they wanted to...But some like PLEX do not.
And I don't see anyway to hack into and get Plex to show DLNA targets in that menu by hijacking the calls to the Media router...
Truth is the Media router should do this already and perhaps it even does and the apps that are using are limiting the list on their end...
---------- Post added at 07:19 PM ---------- Previous post was at 07:11 PM ----------
bhiga said:
Sounds very hacky.
The flip-side, and I think what they mentioned, was to have a "middleman" piece that emulates a Chromecast, similar to how BubbleUPnP Server can pull stuff from other sources on behalf of a DLNA/UPnP receiver.
Click to expand...
Click to collapse
Yes it is rather hacky...What might be possible is something along what y2cast did which would instead of making a CCast a DLNA target did the opposite.
I know full well it is possible to get a listing of all devices (DLNA and CCAST) in an App...Allcast does this and Bubble finds these devices as well.
But thats because the developers of those apps had the good sense to put the code needed to get those listings.
Now you know I never say anything code related is impossible but in this case I find it hard to see how you could get an app whose developer did not have this foresight to code it in themself, to start displaying devices they had no intention of streaming to.
While both devicxe types may use linkage to stream the linkage used is VERY VERY different where a CCast sends a link to load a Player with Parameters and the other merely sends a link to the source media.
That would have to be accounted for in the App itself as the media router does none of that work for you that I know of.
quappic said:
CCast supported apps can send DLNA targets as they just send a streaming URL (According to log of Play Music...)
Anyway I disassembled the Play Music app. Great thing is that code is not obfuscated... But need a lot of work to understand the code...
@bhiga I did not understand completely!
But as far as I understood (may be wrong) is that you are saying to emulate a DLNA device as a chromecast, right?
But cant devices like XBMC directly get the streaming URL and stream it? (Confused) :/
Click to expand...
Click to collapse
Apps will only find what they're looking for. If they're looking for a Chromecast or Google Cast device, they will only find Chromecast and Google Cast devices. They will not find DLNA devices.
Likewise, if a app is looking for DLNA devices, it will only find DLNA devices, not Chromecast devices.
So in order for those apps to see other things, there must be some kind of translation or proxy.
This is where the idea of a Chromecast "emulator" or "masquerader" could come in.
The DIAL documentation probably has enough for the discovery aspect.
Once seen, the second half of the equation is whether the receiver is sent something that it knows how to use.
Most DLNA implementations do not restrict formats to only things Chromecast can use. So even if Chromecast is seen, it still may not work.
Thus, as Asphyx said, it's better for the application itself to support Chromecast natively, so it can make sure it only sends things that Chromecast and Google Cast devices can handle - or on the flip side, make sure to only send DLNA-compatible requests to DLNA devices.
The only other option would be to standardize the media router to encompass all target types and be a mediator involved in all links sent...
Not a good way to go really. Limits 3rd Party developers to what they could do and send to devices that are targets.
That said the apps themselves should already being putting this support into their apps because if you feel it is worth supporting a CCast then it's probably just as important to you to be able to cast to other renderers...
Bubble and Allcast do this already as do some others...
I have been waiting for the same thing to happen in Plex's cast menu...
I looked into the Google Play Music APK... and Chormecast API...
Found something which may get us started.... (A big May be.. Also assuming the Stream URL will work with other devices)
Here it is...
According to the Chromecast API
This line should be present in the App for the lifetime of its run
Code:
mMediaRouter = MediaRouter.getInstance(getApplicationContext())
So I searched for it in the APK code...
As it must be some where called when it searches for CCast devices
Found 4 usages.... under....
Code:
com.google.android.music - onCreate
com.google.android.music.cast - getSelectedRouteOnMainThread
com.google.android.music.playback - onCreate
com.google.android.music.ui.mmp - onCreate
4 possible paths.... Took the variable name and ignored...
Going to the next part of CCast API is to build a builder in the mediaRouterSelector.....
API Code...
Code:
mMediaRouteSelector = new MediaRouteSelector.Builder()
.addControlCategory(CastMediaControlIntent.categoryForCast("YOUR_APPLICATION_ID"))
.build();
Searched for it using the found variable name....
Only one usage under
Code:
com.google.android.music.ui.mmp - onCreate
The line.....
Code:
this.mMediaRouteSelector = new MediaRouteSelector.Builder().addControlCategory("android.media.intent.category.LIVE_AUDIO").addControlCategory("android.media.intent.category.REMOTE_PLAYBACK").addControlCategory("com.google.cast.CATEGORY_CAST").addControlCategory("com.google.cast.CATEGORY_CAST_APP_NAME:" + getCastAppName()).addControlCategory(str).build();
So did some queries (May be wrong again) and found that adding control category "com.google.cast.CATEGORY_CAST" filters CCast devices form all devices....
So, I made a Xposed App... to hook to that addControlCategory and read the parameters it receives... And if it has string 'cast' in it... null it...
Xposed Code....
Code:
//Google Play Music
if(lpparam.packageName.equals("com.google.android.music")) {
XposedBridge.log("Connected to Process: " + lpparam.packageName);
final Class<?> hookClass = XposedHelpers.findClass("android.support.v7.media.MediaRouteSelector", lpparam.classLoader);
XposedBridge.log("Injecting code now on" + lpparam.packageName + " : " + hookClass.toString());
XposedBridge.hookAllMethods(hookClass, "addControlCategory", new XC_MethodHook() {
@Override
protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
Log.d("Hook", "Hooked! to addControlCategory");
Log.d("Hook", "Parmas: " + param.args[0].toString());
if(param.args[0].toString().contains("cast")) {
param.args[0] = null;
Log.d("Hook", "Params: Null (changed)!");
}
}
});
}
But I am stuck here.... Xposed seems to be attached to the process and their are no problems in the Xposed logs...
But their is no Debug Log for the hooked method....
No log shows for the received parameters!
Need some help here... Check the code.....
Hope it will be in some use!
Nothing guys? :/
@Asphyx
@bhiga
??
quappic said:
Nothing guys? :/
@Asphyx
@bhiga
??
Click to expand...
Click to collapse
Sorry, I know very little about Xposed Framework. Looks like something that would be a time sink for me, so I'm avoiding.
bhiga said:
Sorry, I know very little about Xposed Framework. Looks like something that would be a time sink for me, so I'm avoiding.
Click to expand...
Click to collapse
Leave Xposed Framework for minute...
But will the theory work? What do you think about it?
Getting the devices listed in the Menu is easy....
The issue is getting every program that it could show up on to send the proper linkage.
You won't be able to use an exposed framework for that.
Your going to have to create code for each and every app or an app like the y2cast app that mimics a CCast and converts links sent to it in DLNA Format.
While you can get the device listed it's almost impossible to get the hooks into each app t make those apps support DLNA if they do not already.
Your best bet is to create that opposite of y2cast and make an emulator that makes DLNA devices into CCasts instead of making CCast a DLNA renderer like y2cast does.
Then you don't need to hook into the menu listing operation the emulator merely gets discovered like any other DIAL device and when links get sent to it it converts those links to a proper DLNA send format.
For all the cord cutters out there, the CCGTV (Sabrina) currently doesn't have the drivers to support the Hauppauge WinTV-dualHD USB TV tuner. I contacted Hauppauge support and they confirmed it.
I have used the USB tuner on my Nvidia Shield with the Live Channels app + DVR just fine, but it sounds like Hauppauge worked directly with Nvidia to get the drivers supported. There's a little green LED on the USB stick that turns on as soon as it's plugged into the Shield. This doesn't happen when it's connected to the Chromecast. The support email mentioned they are unsure if and when this will be supported.
It seems a little strange because I'd read that an older version of this USB tuner (Xbox version, single tuner) worked with the Nexus Player, so I was hoping for native Android TV support out of the box. Looks like we'll have to wait a little longer or find another solution to get live OTA TV channels on this thing.
The Live Channels app is loaded on my Chromecast, but it doesn't see the USB tuner. The only "channel" I'm able to watch right now, ironically, is the Google Play Movies and TV previews channel (still uses the red film icon too) ?*.
Having DVB-C and DVB-T2 support on this CCWGTV would be really nice. However we might have to wait until someone roots it.
And I don't think it will happen soon. Plus the driver needs to be updated and some kernel patches need to be made.
Custom drivers for Android IS possible, but quite a hassle to complete. I wonder why there is no native support for these devices in kernel 4.9.
The Hauppage devices are out there for quite some time already.
It's actually worthwhile setting up a TVHeadend server on an old machine or even on a Raspberry Pi, that way with the tvh-live channels plugin on Android TV you can have access anywhere, even outside the home. For other non android tv devices TVH works extremely well on KODI
---------- Post added at 05:57 PM ---------- Previous post was at 05:55 PM ----------
seapoint said:
It's actually worthwhile setting up a TVHeadend server on an old machine or even on a Raspberry Pi, that way with the tvh-live channels plugin on Android TV you can have access anywhere, even outside the home. For other non android tv devices TVH works extremely well on KODI
Click to expand...
Click to collapse
Plenty of guides available.. here for instance : http://www.davidhunt.ie/new-home-tv-distribution-system-no-more-sky/