Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rjm]

I'm slowly becoming aware of what's possible and wondering where JRiver fits in the puzzle...

I was given an iPad a month ago and an Apple TV yesterday. I installed a free iPad app named "Air Playit" and it's free server on my PC.

Now using my iPad I can navigate to and play any video in any format from my PC on my TV via the Apple TV over a mediocre wireless network.

I'm very impressed because I previously thought only Apple friendly mp4s would play in this world. Everything including mkv, avi, and flv is working.

The only thing missing in my media world is how to take advantage JRiver's excellent library organization and navigation abilities to play video from JRiver to my Apple TV.

I saw the new WebGizmo feature. Is this going to be the answer? Or do we need something else?

[glynor]

Airvideo does the same thing.

The server app is transcoding the videos on the fly to a compliant H264 MP4 and streaming it to your device (which can then AirPlay it to the TV).  I'd really love to see this on-the-fly transcoding built into MC in the future so that I don't have to run a separate server application and so that I can browse my videos using my MC metadata.

[rjm]

Thanks Glynor. Was curious how it worked.

AirPlay would be a killer feature for JRiver.
We know it's feasible because lots a small developers are supporting it.
Any comment on direction Jim or Matt?

[gvanbrunt]

I'd really love to see this on-the-fly transcoding built into MC in the future

I thought it did this to Gimzo already. Is that not correct?

[glynor]

I thought it did this to Gimzo already. Is that not correct?

It sure doesn't work like AirVideo.

With AirVideo, I can play any of my video files on my iPhone and they start playback immediately (after maybe a 1-3 second long prebuffering period, even remotely over 3G).  The server is actually converting the file "on the fly" as it streams the file over to my phone or iPad.  I can watch videos as though they are local, as long as I have a fairly strong network connection.  I can fast forward and rewind easily (scrubbing or via 30 sec skip ahead/back buttons) and it essentially works beautifully.

In the new WebGizmo, I can tap on one of my videos (I am annoyed that I might have to set up my views for this yet again) and the web browser essentially hangs forever while it tries to convert and then load one big monolithic video file.  The resulting file then, if you wait 10-15 minutes for it to finish converting on my 4GHz Core i5 750 server, usually exceeds the maximum size in Mobile Safari too (so it typically fails to ever eventually play).

Then there are all the separate problems with it being a web app, not a native app, but that's another story for another time.

[Hendrik]

With AirVideo, I can play any of my video files on my iPhone and they start playback immediately (after maybe a 1-3 second long prebuffering period, even remotely over 3G).  The server is actually converting the file "on the fly" as it streams the file over to my phone or iPad.  I can watch videos as though they are local, as long as I have a fairly strong network connection.  I can fast forward and rewind easily (scrubbing or via 30 sec skip ahead/back buttons) and it essentially works beautifully.

Thats exactly how Gizmo works.

I have not tried WebGizmo yet, only speaking of the Android version.
AFAIK, WebGizmo requires flash (at least for the time being), so don't try it on a iOS system for a objective trial.

Apple is not compatible with the rest of the world, just face it.

[glynor]

Thats exactly how Gizmo works.

I don't personally own any Android devices (for reasons I've explained ad nauseum before), so I can't test it myself.

Does video support work well and reliably over 3G, even when converting on-the-fly from 720/1080 TS sources (such as those from a HD-PVR)?  Does it smartly adjust quality for local Wifi versus remote Wifi versus remote cellular speeds?

AirVideo does all of that.  When I play a 720p TS file on my local WiFi network at home on my iPad, it looks absolutely stunning, even when AirPlayed up to a HDTV.  Yet, when I play video on my iPad in the car somewhere on the freeway (someone else driving, of course) as I did a LOT this past week while traveling, it automatically uses lower-bandwidth settings so that it plays perfectly without needing to buffer or pause all the time.

I can customize each of these settings to my liking (for example, the default "remote WiFi" setting is identical to the "remote 3G" setting, but since most of my commonly used remote Wifi networks can handle a little more bandwidth, I was able to bump this up a bit).

Apple is not compatible with the rest of the world, just face it.

Flash is a piece of crap that is not compatible with the rest of the world.  

Oh, and it runs like crap on all of the mobile devices that I've tried it with too, and is discontinued to boot.

If Google would fix the problems with Android, I'd happily buy a device (probably not a phone with a service contract though, at least not at first).  Unfortunately, Google doesn't seem to have any real interest in fixing the problems I consider most serious.

[Hendrik]

Does video support work well and reliably over 3G, even when converting on-the-fly from 720/1080 TS sources (such as those from a HD-PVR)?  Does it smartly adjust quality for local Wifi versus remote Wifi versus remote cellular speeds?

AirVideo does all of that.  When I play a 720p TS file on my local WiFi network at home on my iPad, it looks absolutely stunning, even when AirPlayed up to a HDTV.  Yet, when I play video on my iPad in the car somewhere on the freeway (someone else driving, of course) as I did a LOT this past week while traveling, it automatically uses lower-bandwidth settings so that it plays perfectly without needing to buffer or pause all the time.

I can customize each of these settings to my liking (for example, the default "remote WiFi" setting is identical to the "remote 3G" setting, but since most of my commonly used remote Wifi networks can handle a little more bandwidth, I was able to bump this up a bit).

Gizmo does not currently support dynamic bandwidth adjustments (or even a configuration for that), but as long as you have around 1.5mbit bandwidth is plays perfectly fine. Quality is good on a 10" tablet. Its not meant to play on any bigger devices (If you have a TV, why the hell use something like that and not use MC17 directly, much nicer!)
Matt has indicated in the past that configurable bandwidth and possibly even automatic bandwidth is a feature for the future.

PS:
Funny how you now come up with features that you didn't mention at first, seems like you want to show-off AirVideo, if thats the case, go nuts, use commercial apple software.
Fact is, Apple doesn't make it easy for third-party tools to integrate with their systems, infact they even make it especially hard.

Unfortunately, Google doesn't seem to have any real interest in fixing the problems I consider most serious.

Its all subjective i suppose. I would never consider buying a Apple Phone, Tablet or TV device, because their philosophy seriously conflicts with everything i try to stand for and i consider their designs therefor flawed.

[Matt]

Maybe you could ask Apple about supporting JRiver's web service with their devices?  Our web service is open, documented, and we'd be happy to work with them if they need features added.

[Matt]

Fact is, Apple doesn't make it easy for third-party tools to integrate with their systems, infact they even make it especially hard.

Its all subjective i suppose. I would never consider buying a Apple Phone, Tablet or TV device, because their philosophy seriously conflicts with everything i try to stand for and i consider their designs therefor flawed.

Apple has not been nice to JRiver.

They added unneeded cryptographic locks to their iPod database.  This invalidated several man-years of our work.  A lot of that work was mine.

This only affected a handful of small companies with JRiver near the top of the list. 

I still don't understand their reasoning, but once bitten, twice shy.

[glynor]

Funny how you now come up with features that you didn't mention at first, seems like you want to show-off AirVideo, if thats the case, go nuts, use commercial apple software.
Fact is, Apple doesn't make it easy for third-party tools to integrate with their systems, infact they even make it especially hard.

I don't think I "came up with features I didn't mention at first".

I said:

Airvideo does the same thing.

The server app is transcoding the videos on the fly to a compliant H264 MP4 and streaming it to your device (which can then AirPlay it to the TV).  I'd really love to see this on-the-fly transcoding built into MC in the future so that I don't have to run a separate server application and so that I can browse my videos using my MC metadata.

With AirVideo, I can play any of my video files on my iPhone and they start playback immediately (after maybe a 1-3 second long prebuffering period, even remotely over 3G).  The server is actually converting the file "on the fly" as it streams the file over to my phone or iPad.  I can watch videos as though they are local, as long as I have a fairly strong network connection.  I can fast forward and rewind easily (scrubbing or via 30 sec skip ahead/back buttons) and it essentially works beautifully.

Now, I didn't specifically mention that it does automatic bandwidth adjustment depending on your connection type, but I shouldn't have to mention that.  I said it works, even on remote 3G connections, and it does.  Forcing it to be crappy low-res streaming quality when I'm on a 802.11n wifi connection on the same network as the file server would qualify as "not working" as far as I'm concerned.  I'd certainly be interested to see what video on Gizmo looks like on a relatively decent tablet screen.  But, if it is clearly compressed for a low-resolution phone screen, then I'd really not be interested.  AirVideo does a passable job converting videos on the fly for me when I'm on 3G.  They look beautiful on the phone.  They look passable on the iPad, though I wouldn't call it "beautiful".  On local Wifi, they look pristine though.

Maybe MC's conversion engine is either a lot more capable, or a lot more aggressive about using upstream bandwidth on your home connection.  But, color me skeptical.

Fact is, Apple doesn't make it easy for third-party tools to integrate with their systems, infact they even make it especially hard.

That, too, is a matter of perspective.  There is absolutely nothing stopping anyone, JRiver or one of us schlubs, from creating Gizmo for iOS other than learning Objective C and paying $100 to join the developer's program.  I'm not sure how that qualifies as "especially hard".

What the App Store model does achieve, though, is that they protect me from the pre-installed crap, skins, and spyware that proliferates on other platforms.  Now, all is not wonderful and perfect, I agree.  The App Store model also means I can't easily get a good NES Emulator for my iPad, and means they just pulled down the awesome iMame app.  But, I get good battery life, I don't have to worry about malware, and I get updates right when they come out directly from Apple.

Everything is a balance.

[Hendrik]

That, too, is a matter of perspective.  There is absolutely nothing stopping anyone, JRiver or one of us schlubs, from creating Gizmo for iOS other than learning Objective C and paying $100 to join the developer's program.  I'm not sure how that qualifies as "especially hard".

I was more thinking about interfacing with their device directly, ie. building apps that sync with the phone instead of iTunes, or building a tool that sends stuff to AirVideo receivers.

For the record, since Gizmo uses FLV for streaming, it might end up harder then you think because there is no Flash.

I'd certainly be interested to see what video on Gizmo looks like on a relatively decent tablet screen.

It looks great on my Galaxy Tab 10.1" screen. It could probably be a bit sharper if we used more bandwidth, but its a very good compromise between bandwidth and quality, considering there is only one setting.

Anyhow, this discussion went a bit OT.
If they can pull off H264 MP4 on-the-fly re-encoding, this could also be used in Gizmo itself and replace the Flash dependency (Android natively supports MP4 in H264).
Last time i asked however, Matt explained that there were some technical difficulties that made using FLV for streaming much easier.

[glynor]

Anyhow, this discussion went a bit OT.
If they can pull off H264 MP4 on-the-fly re-encoding, this could also be used in Gizmo itself and replace the Flash dependency (Android natively supports MP4 in H264).
Last time i asked however, Matt explained that there were some technical difficulties that made using FLV for streaming much easier.

I'm sure it IS doing H264 MP4 on-the-fly encoding.  That's what Flash uses too.

And, assuming that the main point of this is to support mobile devices, they really need to abandon flash no matter what the difficulties.  Not only does it immediately kill reaching a huge portion of the existing mobile device installed base (iOS), Mobile Flash was killed by Adobe, so there'll be no more Android support for it going forward.

[glynor]

It looks great on my Galaxy Tab 10.1" screen. It could probably be a bit sharper if we used more bandwidth, but its a very good compromise between bandwidth and quality, considering there is only one setting.

That's good to hear.  I'll check it out next time I have some time with an Android tablet.

[Hendrik]

I'm sure it IS doing H264 MP4 on-the-fly encoding.  That's what Flash uses too.

Gizmo?
No it isn't. It uses FLV with i guess FLV1 video (H263 derivate). Not 100% sure about the codec in use, but its most certainly not H264.

I suggested moving over to H264 quite a while ago in relation to Gizmo, and Matt explained back then why FLV was chosen over MP4.

[glynor]

Gizmo?
No it isn't. It uses FLV with i guess FLV1 video (H263 derivate). Not 100% sure about the codec in use, but its most certainly not H264.

I suggested moving over to H264 quite a while ago in relation to Gizmo, and Matt explained back then why FLV was chosen over MP4.

That's silly.  Adobe's Flash Media Server doesn't even use FLVs anymore, and none of the common Flash web players out there require them anymore.  FLV1 is awful quality for equivalent bandwidth.  Is this true even on devices?

If so, that would go a long way towards answering my previous questions about quality.

If I could get WebGizmo to work at all, I'd be able to tell you exactly what format it is using.  I can't get it to load a video in a browser at all though.  

[Hendrik]

If I could get WebGizmo to work at all, I'd be able to tell you exactly what format it is using.  I can't get it to load a video in a browser at all though.  

I just checked, and i can confirm that its FLV with FLV1 video and AAC 44100Hz Stereo audio.
Granted, on my 30" PC screen it looks rather crappy (a bit like a bad DVD rip, resolution is around DVD). I was wrong about the bitrate, its closer to 2.5mbit.

Anyhow, like i said, the topic came up before, and i suggested moving to a "native" Gizmo player (native as in no flash component) with MP4/H264 at the time, and Matt said they would like to, but when they first built Gizmo they hit some issues with live-encoding the MP4, and for FLV it apparently worked right away (and it stuck).
I'm sure they are willing to re-evaluate the whole deal in the future, but they are limited on manpower as well.

I would love to be able to help somehow, but guess i have to be patient as well.

[glynor]

I'm sure they are willing to re-evaluate the whole deal in the future, but they are limited on manpower as well.

I would love to be able to help somehow, but guess i have to be patient as well.

Of course.  Thanks for checking. 

[gvanbrunt]

Ya Gizmo works great on handheld devices. Pretty much as Glynor described with the Apple version in my experience.

I too would like to see some native h264 conversion with dynamic adjustment for bandwidth. However I'm not sure that is what AirStream is doing. To encode something in h264 at 1080p takes forever on a beefy computer so it wouldn't work on the fly.

Glynor: any chance you can capture a stream and see what it is using? Or is the info available on the net somewhere? That kind of info may help Matt et al figure out what they need to do to achieve the performance you are looking for.

Given the appearance of WebGizmo, I think they may be doing exactly what you are hoping.

[glynor]

Glynor: any chance you can capture a stream and see what it is using? Or is the info available on the net somewhere? That kind of info may help Matt et al figure out what they need to do to achieve the performance you are looking for.

AirVideo uses ffmpeg to do it's magic and it can render it on the fly (even from a 1080p source) on my machine.  It doesn't, I'm sure, use the highest-quality possible settings.  But modern CPUs are powerful, and can do real-time H264 transcoding if you're careful with the settings.

Here is the command line AirVideo uses for ffmpeg for Live Converting a MKV file (H264 720p24 @ 4.2mbps, with AC3 audio):

Code: [Select]

"C:\Program Files (x86)\AirVideoServer\ffmpeg.exe" --segment-length 4 --segment-offset 0 --conversion-id e7a3a9bb-d1f4-43f5-a5f7-ef973fc653209f3d7d3f-8b83-45eb-acc6-c9804632494d --port-number 46631 -threads 4 -map 0.0:0.0 -map 0.1:0.1 -ss 0.0 -i "M:\Video\TV Show\Star Trek ENT\01\s01e18 - Rogue Planet.mkv" -vf "crop=1280:720:0:0, scale=480:272" -aspect 480:272 -y -f mpegts -vcodec libx264 -flags2 +fast -flags +loop -g 30 -keyint_min 1 -bf 0 -b_strategy 0 -flags2 -wpred-dct8x8 -cmp +chroma -deblockalpha 0 -deblockbeta 0 -refs 1 -coder 0 -me_range 16 -subq 5 -partitions +parti4x4+parti8x8+partp8x8 -trellis 0 -sc_threshold 40 -i_qfactor 0.71 -qcomp 0.6 -bufsize 1024k -b 1200k -bt 1300k -qmax 48 -qmin 2 -r 23.976 -acodec libvo_aacenc -ab 192k -ar 48000 -ac 2 -
Here's what it uses when Live Converting a TS file from my HD-PVR:

Code: [Select]

"C:\Program Files (x86)\AirVideoServer\ffmpeg.exe" --segment-length 4 --segment-offset 0 --conversion-id 45e2de01-6a26-4c97-b4d1-d6953bc7faf07b33d88e-827b-4306-aab9-e1b0aedef849 --port-number 46631 -threads 4 -map 0.0:0.0 -map 0.1:0.1 -ss 0.0 -i "M:\Video\TV Show\Fringe\04\s04e02 - One Night in October.ts" -vf "crop=1280:720:0:0, scale=480:272" -aspect 480:272 -y -f mpegts -vcodec libx264 -flags2 +fast -flags +loop -g 30 -keyint_min 1 -bf 0 -b_strategy 0 -flags2 -wpred-dct8x8 -cmp +chroma -deblockalpha 0 -deblockbeta 0 -refs 1 -coder 0 -me_range 16 -subq 5 -partitions +parti4x4+parti8x8+partp8x8 -trellis 0 -sc_threshold 40 -i_qfactor 0.71 -qcomp 0.6 -bufsize 1024k -b 1200k -bt 1300k -qmax 48 -qmin 2 -r 29.97 -acodec libvo_aacenc -ab 192k -ar 48000 -ac 2 -
And, lastly, this is what it uses when I play back a MKV BluRay rip I made (1920x800 H264 @ 12.8Mbps, TrueHD audio, in a MKV):

Code: [Select]

"C:\Program Files (x86)\AirVideoServer\ffmpeg.exe" --segment-length 4 --segment-offset 0 --conversion-id cffeff92-3b6d-4528-bde7-74fb31e68bf5ac803694-67d8-4b14-b8d2-a74c9dc05488 --port-number 46631 -threads 4 -map 0.0:0.0 -map 0.1:0.1 -ss 0.0 -i "M:\Video\Movie\Harry Potter and the Half-Blood Prince.mkv" -vf "crop=1920:800:0:0, scale=480:200" -aspect 480:200 -y -f mpegts -vcodec libx264 -flags2 +fast -flags +loop -g 30 -keyint_min 1 -bf 0 -b_strategy 0 -flags2 -wpred-dct8x8 -cmp +chroma -deblockalpha 0 -deblockbeta 0 -refs 1 -coder 0 -me_range 16 -subq 5 -partitions +parti4x4+parti8x8+partp8x8 -trellis 0 -sc_threshold 40 -i_qfactor 0.71 -qcomp 0.6 -bufsize 1024k -b 1200k -bt 1300k -qmax 48 -qmin 2 -r 23.976 -acodec libvo_aacenc -ab 192k -ar 48000 -ac 2 -
They all look mostly the same to me, except for the framerate crop and scale and other source-file specific items.

NOTE:  I grabbed those command lines using Process Explorer.  I'm not 100% sure that they aren't cut off at the very end, but I don't think so (why wouldn't PE show the whole command line for a process?).

[glynor]

I should note... The company that makes AirVideo is a small little software company (it might even be a one-man shop).  They run a forum over here.  I'm pretty sure there are other apps that "integrate" with AirVideo and use it to power their own video.  I suspect the developers might be open to collaboration if someone from JRiver contacted them.

If MC could "act" as an AirVideo server, but serve it a tag-based media hierarchy (the one used for Gizmo and WebRemote), that would be sweet.  Or, perhaps they could work out a way to "launch" AirVideo from WebRemote/WebGizmo itself, so that if you "Play" a video file from inside WebGizmo, it launches AirVideo on the device and loads that particular video.

That would also get you a lot closer to where you want to go quicker, while supporting a nice iOS app, and not having to build (as much) of it yourselves.

[rjm]

Just switched from Air Playit to Air Video. Pegs my old XP system to 98% but works great. Thanks for the tip.

Now If I could browse my MC library I would have everything I want.

[Castius]

For another point of reference.

On my phone (Android 2.2 Samsung Galaxy S)
1080 MKV files (Codec: VP8, vorbis 5.1 and mp3 stereo)
Convertion: MP4 (Best for Phones)
Over 3g
1-20 seconds start up
and chopping playback

Over wifi
My Videos take about 1-4 second startup
and smooth playback.

JMC is awesome for local media.
But it can't replace my http://www.subsonic.org server yet.
I use this to play my music at work and my phone.

I can setup whatever transcoding i want for any file type.
And use any Encoder as long as it supports stdin and stdout.

This is my ffmpeg transcode cmd line. It's very basic.
Subsonic adjusts the width and height based on the bitrate you want to play the video at.
ffmpeg -ss "TIME" -i "FILE" -async 1 -b "BITRATE"k -s "WIDTH"x"HIGHT" -ar 44100 -ac 2 -map 0:0 -map 0:2 -v 0 -f flv -

I just tell ffmpeg to use the second stereo audio channel i have encoded into my MKV files.
JWplayer(IE: flash) does support 5.1 48K audio.
And i have not found a way to transcode 5.1, 48K to 2, 44k audio

Msg me if you want to give my server a spin.

I'd love to see JRiver replace my whole setup so i can get back to one media source.

[)p(]

If MC could "act" as an AirVideo server, but serve it a tag-based media hierarchy (the one used for Gizmo and WebRemote), that would be sweet.  Or, perhaps they could work out a way to "launch" AirVideo from WebRemote/WebGizmo itself, so that if you "Play" a video file from inside WebGizmo, it launches AirVideo on the device and loads that particular video.

Doesnt mc also use fffmpeg for reencoding? The ideal would be that jrmc itself could do the on the fly encoding like airvideo does. Webgizmo and third party apps could then take advantage about that to provide a nicely tagged library. I love airvideo on our idevices. It plays anything I throw at it really well but I really miss a good gui.

[gvanbrunt]

Glynor, that is going above and beyond for sure. I ask for the format spit out and give command lines... I didn't even think to grab such a thing with Process Explorer, but since it shows start up arguments... Good thinking.

AirVideo uses ffmpeg to do it's magic and it can render it on the fly (even from a 1080p source) on my machine.

I was referring to rendering at 1080p during a conversion, not from it. For example when a source is in a format other than h264.

Still this is good. With those settings it provides JRiver with something you feel has decent quality. And better still it is using a program that is open source and free to use.

[struct]

I was curious about an earlier mention of mc sending 2.5mbit/s stream as the output for video via gizmo. Is this correct and is this a value that can be modified?

I have no problem getting this download rate on my phone when the co erage is good but unfortunately Adsl2 which is very common here in Australia has a maximum upload rate of near 100kbytes/s so I need to respect this restriction or gizmo is useless for serving video to my phone (which is my current experience with gizmo).

Thanks
Craig

[gvanbrunt]

I was curious about an earlier mention of mc sending 2.5mbit/s stream as the output for video via gizmo. Is this correct and is this a value that can be modified?

That is the bitrate of the video nev was referring to not the speed of the connection. They are not the same. And no it cannot be changed... yet (we hope).

[glynor]

I was referring to rendering at 1080p during a conversion, not from it. For example when a source is in a format other than h264.

I plan to test another file that isn't in H264 already when I have a chance, though I suspect it won't be any different.  It is re-encoding it to h264 anyway (to get a different output bitrate and compression profile) so it doesn't much matter what the input format is, I suspect.

I'd have no reason to actually stream to 1080p on an iDevice, since they can't display it anyway.
Streaming to 720p would be nice for when you hook up to an external display, but not at the expense of reliability.  It looks like AirVideo is converting 720p sources to something like 800x448.

[gvanbrunt]

I'd have no reason to actually stream to 1080p

That's what I was referring to but didn't really make it clear. If the source was already h264 1080p MC wouldn't have to convert. So I was suggesting something at 1080p that wasn't h264 converting to 1080p h264 which would be the most extreme case CPU wise.

I agree that 1080p would not normally be needed when streaming to a device, however when streaming to something with a large display hooked up to it, it might be nice to have.

[JohnT]

There's a lot of good information here to digest, thanks guys.  Looks like AirVideo is using ffmpeg to create segmented MP4/H264 files which are playable on the iPhone using that platform's "HTTP Live Streaming" support.  The reason we haven't supported "live" transcoding of MP4/H264 to our Gizmo app is because that format requires a "MOV" header at the beginning with knowledge about the entire encoded file, which you don't have in a live transcoding scenario.  And Android did not support any segmented MP4 format like Apple's "HTTP Live Streaming" or Microsoft's "Smooth Streaming".  We need to re-visit this and check if the latest Android releases have added support for something like this, and in any case we could look into supporting it for browser based playback on iOS.  Segmented MP4 files are basically playlists of lots of small MP4 files with the proper MOV header at the front of each segment.

[gvanbrunt]

From the Android 4.0 SDK page:

New media codecs and containers

Android 4.0 adds support for additional media types and containers to give developers access to the formats they need. For high-quality compressed images, the media framework adds support for WebP content. For video, the framework now supports streaming VP8 content. For streaming multimedia, the framework supports HTTP Live streaming protocol version 3 and encoding of ADTS-contained AAC content. Additionally, developers can now use Matroska containers for Vorbis and VP8 content.

So hopefully something can be developed for iOS and Android that is HTTP 5 and uses live streaming. That would be amazing and something no one else has in their application.

[gvanbrunt]

Did some looking around and apparently there isn't a whole lot of information about how this is supported in the browser. I'm just guessing here, but I would say that it is. They dev's would have to be complete morons to add that to the platform and not make it available via the browser since that is it's main use and the center of all the streaming attention lately.

However I did not find any docs (even third party) in the 1/2 hour I searched. It may be quicker to just test via a whipped out HTML 5 page. Also you can get ICS on Nexus S right now if you don't have a Galaxy Nexus. I've been using it for a while and it is quite good. If you need any guinea pigs, let me know...

[JohnT]

Thanks for doing more research on this.  Even if the browser doesn't have real great support for the HTTP Live Streaming protocol, the component we use for flash playback (JWPlayer) may do a reasonable job.

[rjm]

The server app is transcoding the videos on the fly to a compliant H264 MP4 and streaming it to your device (which can then AirPlay it to the TV).

Just bought a fancy new wireless router that lets me set up independent 2.5 and 5 GHz networks. Wondering what optimal config is for AirPlay. Are you saying my server sends mp4 stream to iPad which then resends to Apple TV? I would have thought server sends directly to TV.