Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[Q]Possibility of Playing Other Media Types

OP tomg09

4th March 2014, 02:31 AM   |  #1  
OP Member
Thanks Meter: 6
 
33 posts
Join Date:Joined: Jul 2012
So, got a question...

How hard would it be/would it be possible to cross-compile a media player for the cc (something that can be run from CLI like vlc), put it on an external storage device (if cc recognizes a connected USB device while the rom is running - maybe eureka rom, bhiga?), mount a samba share, and play a wider variety of movie formats.

So the solution would look something like this...
1. Put vlc binary on flash drive connected to cc via powered OTG cable
2. Ssh in to cc
3. Mount network samba share containing videos
4. Play whatever videos from vlc operated by cli over samba, replacing dial

Not really a programmer, and have absolutely no idea how a cc works... But it seems to me that a solution like this, while unwieldy, would allow one to bypass the limitations of cc's implementation of dial.

What do y'all think?

Sent from my SCH-I535 using XDA Premium 4 mobile app
4th March 2014, 02:45 AM   |  #2  
OP Member
Thanks Meter: 6
 
33 posts
Join Date:Joined: Jul 2012
And what about other binaries? Something like apache, php... Maybe turn the cc into a cheap webserver?

Sent from my SCH-I535 using XDA Premium 4 mobile app
4th March 2014, 08:54 AM   |  #3  
bhiga's Avatar
Recognized Contributor
Thanks Meter: 882
 
2,248 posts
Join Date:Joined: Oct 2010
Donate to Me
More
I think one of the Team Eureka folks said the USB storage isn't available at normal runtime, but I could be mistaken.

Webserver is definitely possible, as that's what the Eureka Web Panel is, but general-purpose webserver use would be limited by both wireless bandwidth and moreso by the lack of storage (unless USB actually does work),

An important thing to keep in mind here... Unlike Android phones, tablets and TV sticks, Chromecast is much more scaled down and limited in design. I consider phones, tablets and TV sticks as Android-powered devices with the qualification that they are meant to be interacted with, apps installed, expanded, etc.

Think of Chromecast it more of an "accessory," black box or dumb terminal. Chromecast is more of an "extension" to those user-configurable devices.

Remember the ViewSonic AirPanel? Technically it is a computer, but a very limited (embedded) one. While it mirrored the primary screen of the computer, rather than being a second screen, it's a similar model. The AirPanel has some intelligence to accelerate the user experience but the core processing is done on the computer it's attached to.

Neither AirPanel nor Chromecast are meant to be interacted with directly at the device level, or loaded down with a lot of background processes. Chromecast doesn't have an interactive UI of its own, nor does it have external input (keyboard, mouse, touchscreen, etc) like your typical Android device does.

I wouldn't surprised if a number of "standard" libraries that your typical Android platform has simply aren't there.

I'm not saying getting VLC on it is impossible - I really don't know, but I do think it's improbable and would require a great deal of effort.
Without hardware acceleration or SDK/API support, you're relying purely on the software processing, and I haven't found much in the way of detailed specs on the platform itself. I have seen mention of the platform supporting other compression formats that Google isn't supporting yet, like MPEG-2, so it remains to be seen what Google's long-term plans are.

Not trying to be a downer here, just trying to keep things in perspective. After all, Google didn't sell us a $35 PS4 equivalent.
The Following User Says Thank You to bhiga For This Useful Post: [ View ]
5th March 2014, 09:39 PM   |  #4  
OP Member
Thanks Meter: 6
 
33 posts
Join Date:Joined: Jul 2012
Quote:
Originally Posted by bhiga

I think one of the Team Eureka folks said the USB storage isn't available at normal runtime, but I could be mistaken.

So, if I'm understanding correctly, this sounds like a software limitation...Clearly the hardware is compatible - Flashcast relies on it. I don't know much about the intricacies of programming for mobile devices, but conceptually it would seem possible to make usb accessible during normal operation if it's accessible to something like Flashcast. I would love to read up on Flashcast more...it's just that normally things like flashcast which are very specific to certain hardware and require exploitation of particular holes/flaws in the software residing on that device are not normally very well documented.

How is it that Flashcast "unlocks" the functionality of USB OTG, and what limits its use when the device is booted normally? Is it something in the bootloader? Does Flashcast "hijack" the bootloader and use a different one?

EDIT: Or even how about something like this: Create an image like the recovery image that's flashed to a USB Drive, except make the "recovery image" a full ROM. That way, ROM gets access to USB device, we have much more room to put other features/binaries, etc, and then there's built in storage...Would something like that work?
Last edited by tomg09; 5th March 2014 at 09:53 PM.
6th March 2014, 12:13 AM   |  #5  
bhiga's Avatar
Recognized Contributor
Thanks Meter: 882
 
2,248 posts
Join Date:Joined: Oct 2010
Donate to Me
More
Quote:
Originally Posted by tomg09

How is it that Flashcast "unlocks" the functionality of USB OTG, and what limits its use when the device is booted normally? Is it something in the bootloader? Does Flashcast "hijack" the bootloader and use a different one?

EDIT: Or even how about something like this: Create an image like the recovery image that's flashed to a USB Drive, except make the "recovery image" a full ROM. That way, ROM gets access to USB device, we have much more room to put other features/binaries, etc, and then there's built in storage...Would something like that work?

As I understand things, FlashCast runs in recovery mode, which uses its own bootloader - which is what allows access to OTG.

If that code isn't in the normal mode bootloader, then OTG won't be accessible. It might be loadable via a kernel module, but it seems the current Android direction is to disallow loading of kernel modules (probably because it's a potential security hole).

There's more information about how and why FlashCast works in the FlashCast thread.
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes