FORUMS
Remove All Ads from XDA

Video Player with Chromecast Support

5,008 posts
Thanks Meter: 904
 
By ermacwins, Senior Member on 6th April 2014, 01:01 PM
Post Reply Email Thread
7th April 2014, 05:50 PM |#11  
Member
Flag Italy
Thanks Meter: 5
 
More
Quote:
Originally Posted by Asphyx

...


perfect explanation! Really thank you. I hope that this device will be supported with the right software, meaning apps, in the near future.

Thanks again.
 
 
7th April 2014, 06:07 PM |#12  
Senior Member
Thanks Meter: 374
 
More
Quote:
Originally Posted by davboc

perfect explanation! Really thank you. I hope that this device will be supported with the right software, meaning apps, in the near future.

Thanks again.

The problem right now seems to be that every App creates their own CCast Player App (called the receiver) but the DIAL protocol really doesn't require that to happen.

If the Open Source community would create a FREE TO USE Player App for CCast that any Android (or iOS app for that matter) could have the CCast load You might see a situation where all players could use that app to play to CCast and remove the need to code a Player themselves.

The only reason to code your own player then would be if you wanted to add other features like Media Info Mirroring and if the Player was Open Source it could be used inside their custom versions as well provided there is no issue with GPL license and Commercial Use.

the CCast support has come a long way since December...
I hope by next December we see more after people figure it out better.

The holdup is Google Locking it all up with the Whitelist.

I keep looking here hoping to find a developer that has decided to work on a CCast Player side to bring full client side support that others can use.

So Far Bubble is the only one focused on that side of the coding.

In the end the CCast player should support any container, Most Codecs, Client side selectable Subtitles and Multitrack Audio with Client side selection as well.

If they could add Dolby Support (not likely given the Licensing requirements) it would set the bar for all the others.
7th April 2014, 09:48 PM |#13  
simacca's Avatar
Senior Member
Flag Kent, uk
Thanks Meter: 163
 
More
Localcast works well for me. Even let's me access and stream movies/TV shows straight from my USB stick on my Note 2 using an otg cable.



Sent from my Sinclair ZX81.
8th April 2014, 02:07 PM |#14  
EarlyMon's Avatar
Senior Member
Thanks Meter: 880
 
More
Koush tried software decoding for H.264 video - the processor ran hot enough to destroy his Chromecast, and that was using a known and mature routine.

The MediaTek processor is very good but it has limitations.

Maybe someone will take it further and succeed. I think it's more reasonable to look for more codecs on Chromecast 2, if at all.

Btw, LocalCast now lets you use your phone for headphones for stuff you're casting.
8th April 2014, 05:14 PM |#15  
Senior Member
Thanks Meter: 374
 
More
Not doubting you here...I know the Hardware is close to being an Egg Cooker even under normal usage....

But I'm curious as to why would he software decode H.264? No need to do that as it's already supported.

I'm just wondering if he was trying to do transcode from unsupported codec to H.264 on the device.

That method I would expect to not work at all.

But by adding loadable Software codecs it should not require the same proc cycles and speed as trying to transcode as it's really just a decoding operation which is roughly half the intense of transcoding which both decodes then re-encodes.
The Tricky part would be getting the player to load codecs on an as needed basis which is where I expect it might make the approach impossible.

I'm personally less concerned with codec support as I am with Containers, Subtitles and Audio Track selection being done on the Player side.

All of my Library is already H.264 But I much prefer MKV container for keeping Subs and Multiple Audio (for Commentary) so once a player comes out that supports all of those without transcoding I'll be a very happy puppy.
The Following User Says Thank You to Asphyx For This Useful Post: [ View ] Gift Asphyx Ad-Free
8th April 2014, 07:33 PM |#16  
EarlyMon's Avatar
Senior Member
Thanks Meter: 880
 
More
I don't know but I imagine that he was simply following a standard best practice -

Comparing known quantities to map the solution space before proceeding into the unknown.

The H.264 routine (just a software codec attached to a simple player from what I recall looking at the time) made sense for that, precisely because it was a mature, known quantity that could be compared to the existing feature in hardware.

Apples to apples.
The Following User Says Thank You to EarlyMon For This Useful Post: [ View ] Gift EarlyMon Ad-Free
8th April 2014, 08:12 PM |#17  
Senior Member
Thanks Meter: 374
 
More
perhap he tried that since H.264 is the most hardware intensive compression compared to say On2, Cinepak or the older Indeo...

If it could software decode H.264 then it could pretty much decode everything else just fine with the exception of MPEG2 which requires specific hardware.
8th April 2014, 11:36 PM |#18  
ermacwins's Avatar
OP Senior Member
Thanks Meter: 904
 
Donate to Me
More
Quote:
Originally Posted by Asphyx

What needs to happen is for someone to create an MX Player type CCast Player app that can play many Container and Codec types without the need for Transcoding. Then others could potentially use that Player App (think along the lines of a JW Player type CCast Application) when sending Media to the CCast without the worry of incompatible file and codec format.

Are you saying if a player i.e. MX player had the cast function builtin into it then you can cast any video format that MX player supports?
9th April 2014, 01:39 AM |#19  
EarlyMon's Avatar
Senior Member
Thanks Meter: 880
 
More
Quote:
Originally Posted by ermacwins

Are you saying if a player i.e. MX player had the cast function builtin into it then you can cast any video format that MX player supports?

That's what a lot of people want.
9th April 2014, 03:32 AM |#20  
Senior Member
Thanks Meter: 374
 
More
Quote:
Originally Posted by ermacwins

Are you saying if a player i.e. MX player had the cast function builtin into it then you can cast any video format that MX player supports?

No not at all.....an App's (aka Transmitter) ability to cast to a CCast has little to do with it can support but what the CCast supports....Other than through the player app it tells CCast to load to receive the stream (aka the Receiver app).

Every App tells the CCast to load a player and it is that player that determines what format can be played not what the App that started the cast supports.

So even if MX Player supported CCast now...Doesn't mean at all that streaming from it to a CCast means MKV or MOV files will play on the CCast despite the fact they play in MX Player just fine.

That is unless MX Player wrote a custom player (receiver) for the CCast that supported all the formats MX Player does or MX Player added the ability to transcode any format to work with the receiver they load into the CCast.

As of today just about every app that supports more than just the standard CCast compatible media do so via Transcoding.
And thats not likely to change soon unless someone figures out a way to do it without frying the unit.

I bet it would work a lot better if the player app was run outside of the Google Sandbox the way Netflix is when it does it's own decryption.

The question is will anyone other than one of the Partners who invented the DIAL protocol ever get that type of access to the hardware?
Not without Google being fully on board....
9th April 2014, 04:23 AM |#21  
Senior Member
Thanks Meter: 31
 
More
My favorites are Web Video Caster for casting videos from websites (ie. couchtuner) and BubbleUPnP for everything else.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes