Print

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

[Matt]

If I had to pick one thing, it'd be robust on-the-fly video transcoding and (real) streaming with automatic bitrate adjustment, so that you could use MC on a laptop, an iPad, or an Nexus 4 to watch video remotely over 3G/LTE and not have to worry about source formats or relatively small pipes.

Have you tried video with Gizmo on an Android?  We've done a lot of work on this for MC18, and I'm really happy with the results.  Bob deserves a lot of the credit.

Client copies of MC are next, probably during the v18 cycle.

[jmone]

I find that Gizmo on Android is great including for Video, but two areas of expansion is:
- Gizmo for other OS (especially for iOS but also for Windows and OSX)
- Gizmo Cache.  As pointed out at you would no longer need to Sync and it these two would solve your iOS compatibility issue.

If I had to pick one thing it would be this one (while Nevcairiel works on the BD Menu stuff of course)!

[Matt]

If I had to pick one thing it would be this one (while Nevcairiel works on the BD Menu stuff of course)!

But I thought intercom support was your one thing

I keep meaning to tell you in Minnesota we don't have houses big enough to have intercoms.  It'd be too expensive to heat them during the eight months of winter.

[rjm]

If I had to pick one thing, it'd be robust on-the-fly video transcoding and (real) streaming with automatic bitrate adjustment, so that you could use MC on a laptop, an iPad, or an Nexus 4 to watch video remotely over 3G/LTE and not have to worry about source formats or relatively small pipes.

Not sure if this is exactly the same thing but what I want is JRemote to play all video types.

[rpalmer68]

But I thought intercom support was your one thing

You should know him by now Matt, he has many "things".  Just at his age he sometimes forgets what they all are

[Matt]

what I want is JRemote to play all video types.

I wonder if an iPad plays MP4 TS?

If so, it might not be too hard for Lespaul to add nice video support.

I should write him.

[jmone]

But I thought intercom support was your one thing

I keep meaning to tell you in Minnesota we don't have houses big enough to have intercoms.  It'd be too expensive to heat them during the eight months of winter.

It is -- but I'm being all "for the good of the collective"!  I don't even have an iOS device (though the other members of my tribe all have iPhones so they just don't use MC!).... and while there is a bit of truth in Richards comment it is more like Fishing at JRiver and these ideas are types of bait, just keep throwing out different stuff till we get a bite on one then hang on for the ride!

[MrC]

I wonder if an iPad plays MP4 TS?

Maybe so: http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/HTTPStreamingArchitecture/HTTPStreamingArchitecture.html

[fitbrit]

I have an Android 2.2 device and am unable to play video on it at all in Gizmo. Does the server have to be configured in a special way?

[rjm]

I wonder if an iPad plays MP4 TS?

If so, it might not be too hard for Lespaul to add nice video support.

I should write him.

Please do contact him. This would be killer and might steal a bunch of Air Video customers.

[jmone]

I have an Android 2.2 device and am unable to play video on it at all in Gizmo. Does the server have to be configured in a special way?

Nope - works out of the box for me but I've flashed both my devices to V4.x

[glynor]

Have you tried video with Gizmo on an Android?  We've done a lot of work on this for MC18, and I'm really happy with the results.  Bob deserves a lot of the credit.

I have not since you added the Video support, though I'm pretty sure it doesn't detect your connection speed and transcode to appropriate settings, at least based on what I see in MC on the "transcoding options end".  That's part of the genius of AirVideo (though I have troubles with it too, and the browsing support is dismal).  Video looks beautiful on my phone on good WiFi, but works perfectly well while I'm driving around, just at lower quality (okay, while someone else is driving).  I don't think it needs to be super-fancy on-the-fly bitrate adjusting or anything, but it would be good to have something like AirVideo where there are discreet profiles for different "connection types".

Unfortunately, all of the Android devices I've gotten to play with more recently have been either friend's, or fairly locked down.  From what I read, though, video playback support is a bit of a mess on Android, due to all the different devices (which support a variety of different flavors of decoders).  What do you do about that?

Client copies of MC are next, probably during the v18 cycle.

This makes me very happy.

[jmone]

Gizmo now has three settings under "Video quality" in Options:
- Low (240p / 0.5Mbps)
- Medium (480p / 1.5Mbps)
- High (720p / 5.0 Mpbs)

These are set in Gizmo.

And I can happily stream all my video content using these over Wifi (with up to High) and using Low when on the Mobile NW.  Sure it is not super smart to work out what the end to end bandwidth is like (I'm sure this could be tested on the fly as a part of the handshake between Gizmo and MC Server) but it does just work.  In fact it works better and easier than any other client method.

There is also similar settings for Audio.

Note, I have to use LOW when on the Mobile network not because the DL on the Mobile Network is slow but the Upload from my house over ADSL2 is under only around 600K sustained.  I'm trying to get onto a cable network that has a higher upload.

[glynor]

Gizmo now has three settings under "Video quality" in Options:
- Low (240p / 0.5Mbps)
- Medium (480p / 1.5Mbps)
- High (720p / 5.0 Mpbs)

And I can happily stream all my video content using these over Wifi (with up to High) and using Low when on the Mobile NW.  Sure it is not super smart to work out what the end to end bandwidth is like (I'm sure this could be tested on the fly as a part of the handshake between Gizmo and MC Server) but it does just work. 

Right, that's exactly the issue.

They work, but you have to pick when you're sitting in front of the Server box.  That defeats the purpose.  I want High when I'm at the office (where we have dual symmetric 20Gbps connections to the Net), Medium when I'm at some crap hotel or on LTE, and something in-between Medium and Low for 3G.

Of course, my crap Maine upstream bandwidth at home can't handle pushing 5mbps, but it can do 2.2 or so just fine.

[jmone]

No - you pick it in Gizmo not at the Server.

[glynor]

No - you pick it in Gizmo not at the Server.

Oh, that's better.  Still not ideal, but usable.

[jmone]

Sure - it is a Manual change to "automagic" but it would not take much for Gizmo to do a quick bandwidth check.  FYI the transcoding starts pretty quickly (eg the wait is under 10 sec but you are going to need MC Library Server running on a PC with some grunt) then you get served TS container with h.264 and AAC for audio so it is nice and std and should play on just about any "modern" device these days (even iStuff).

If you have an Android Device then give it a go.  It works really well on both my 7" Galaxy Tab (the original one but I have flashed Android 4.x onto it) and a Galaxy Note 1

Adding the following would really open MC's Library Server to a much bigger device base with a wider range of useage:
- Additional Platforms (iOS, Win etc)
- Local Caching
- Support for Connected Media (eg you can not currently use Gizmo for streaming the Radio from Library Server) 
- 2 way comms (eg Intercom) 


.... I can just feel Matt tugging on the end of the fishing line, almost but not quite a "hit" yet....

[JimH]

Gizmo now has three settings under "Video quality" in Options:
- Low (240p / 0.5Mbps)
- Medium (480p / 1.5Mbps)
- High (720p / 5.0 Mpbs)

These are set in Gizmo.

Added to the wiki on Gizmo.  Thanks.

[JustinChase]

- Local Caching....

I can just feel Matt tugging on the end of the fishing line, almost but not quite a "hit" yet....

...you know you want to add this...

[glynor]

I wonder if an iPad plays MP4 TS?

If so, it might not be too hard for Lespaul to add nice video support.

I should write him.

I looked into this more.

iOS handles h264 compressed TS files fine, however, they cannot be locally stored.  It only handles them if they are served by a HTTP server via a M3U8 playlist file (designed for live streaming over HTTP).

However, you should have all the pieces for this to work.  You don't segment the TS, but this shouldn't matter much (since it isn't live).  All you'd have to do is have MC's web service serve a simple M3U8 file that shows only one segment per video file (the whole file).  Then the iPhone/iPad should play it fine throu AVFoundation by default.

It'd even work through web gizmo.

[glynor]

If you implement the segmenter, then it'd be even better.  There's BSD licensed (free for all, including commercial software) C code from Apple that does this available.

There are two versions of the segmenter.

One is a Media Stream Segmenter, which takes H.264 compressed TS-wrapped input from STDIN and segments it and builds the M3U8 file for you as it goes (designed for live streaming, but this is also what AirVideo uses, and it just pumps FFMPEG directly into the segmenter).

The alternative approach requires a fully encoded file, and then segments it afterwards.  This is the Media File Segmenter code, which does the same thing, but takes an on-disk H264 TS file as the source (rather than STDIN).

Like I said, both are available with nice licensing implemented in C, but to get the download, you have to be in the iOS Developer program (or find it elsewhere).  I'm happy to send the current package privately if you just want to look at it (I am in the program).

The difference would be that with the non-segmented file, it wouldn't really be a "stream".  Instead, the iOS device would need to download the entire file before it was able to play it, I believe.  Apple's HTTP Segmented system allows you to "stream" video media to a player without having to either: (a) have a real streaming server that serves via RTMP or something similar, or (b) do "progressive-download" style pseudo-streaming.

I think you're doing pseudo streaming on WebGizmo now, and then just wrapping it in a flash player, ala YouTube.  The iPhone doesn't even need the Flash player component, as AVFoundation will play the file by itself, it just needs to be served a M3U8 "playlist" and then it sends it to AVFoundation automatically, even via just Mobile Safari.

I should add, these HTTP-served M3U8-wrapped TS segmented "streams" work fine on Google Chrome on the desktop, so it is entirely plausible that they'd work fine on Android devices as well.   I haven't tested this myself, but it should work in theory.  Basically, Google implemented Apple's suggested HTTP streaming system in Chrome, though, so as long as Android has the same capabilities (I think so, but I don't know for sure).

[Matt]

Robert tried the MP4 TS and said it wasn't working.  He thought the iPad need an MP2 container instead.

I sent him instructions that (hopefully) get Media Center to produce MP2 TS.

Fingers crossed.

[glynor]

I updated my thing above with more detail.

It uses TS (MPEG-2 style Transport Stream), but you can't feed it to AVFoundation directly.  It will only read it from a M3U8 playlist file.  I found lots of examples online of people trying to read local TS files on the phone itself with AVFoundation and it wouldn't work.  One guy, in fact, developed a workaround where his player simply included a tiny little Web Server and just served the TS file via it, and then he had AVFoundation connect to localhost to play the file (which worked), whereas pointing directly at the same TS file on "disk" didn't work.

I'm pretty sure that the segmenting is optional, but I'm not positive (there might be some kind of file-size limit on the individual TS files it will play).

[glynor]

Here's the details on the M3U8 playlist file, from Apple directly...

VOD Example:

Code: [Select]

#EXTM3U

#EXT-X-PLAYLIST-TYPE:VOD

#EXT-X-TARGETDURATION:10

#EXT-X-VERSION:3

#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:10.0,

http://example.com/movie1/fileSequenceA.ts

#EXTINF:10.0,

http://example.com/movie1/fileSequenceB.ts

#EXTINF:10.0,

http://example.com/movie1/fileSequenceC.ts

#EXTINF:9.0,

http://example.com/movie1/fileSequenceD.ts

#EXT-X-ENDLIST

The Extended M3U file format defines two tags: EXTM3U and EXTINF. An Extended M3U file is distinguished from a basic M3U file by its first line, which must be EXTM3U.

EXTINF is a record marker that describes the media file identified by the URL that follows it. Each media file URL must be preceded by an EXTINF tag. The EXTINF tag contains a "duration" attribute that is an integer or floating-point number in decimal positional notation that specifies the duration of the media segment in seconds.

The EXT-X-PLAYLIST-TYPE tag provides mutability information about the playlist file. It applies to the entire playlist file. This tag may contain a value of either EVENT or VOD. If the tag is present and has a value of EVENT, the server must not change or delete any part of the playlist file (although it may append lines to it). If the tag is present and has a value of VOD, the playlist file must not change.

One nice detail is that if you use the Media File Segmenter tool from Apple, it automatically wraps them in the proper MPEG-2 TS File format.  You can just feed it the MP4 directly, if you want.

These TechNotes from Apple have basically all of the details:

https://developer.apple.com/library/ios/#technotes/tn2224/_index.html
https://developer.apple.com/library/ios/#technotes/tn2288/_index.html#//apple_ref/doc/uid/DTS40012238

Take special note of this section:

Byte-Range Support for Segments

As discussed in the Introduction section above, a playlist provides the clients with the URLs of the media segment files. Each media URL refers to a media file which is a segment of a single contiguous stream. This means if you have 700 media segments in your movie, you actually have 700 files on your webserver.

New in iOS 5, you can now specify a media segment as a byte range (subrange) of a larger URL. This allows you to consolidate your media segments into larger files or a single large file. The primary benefit of this is when a client is playing your media, rather than downloading each successive segment file from a different location, it is actually walking through a larger file in sequence.

This also allows proxy caching servers to get a much better idea of what needs to be prefetched in order to ensure that the segment you will need is in the cache at the time you want it. An additional benefit is there are far fewer files to manage. If you have many video variants in a long movie, you can have thousands of individual segment files. With byte range support, you only have a few.

So, if you build your M3U8 file properly, you probably don't even NEED to segment the actual TS file itself to get it to work with iOS 5+.  Honestly, if I were doing it, I'd limit it to iOS 5+ anyway.  The other issue with older versions is that they have less capable video decoders (true on Android as well).  I don't know what settings you're using to convert to those H.264 TS files, but up until the iPhone 3G, they only supported H.264 Baseline profile.  Modern devices support H.264 High Profile (4.0) up to 1080p.  I'd probably target Main profile at 640x360 or something like that, but maybe you're already doing Baseline to support all the wacky Android devices out there (I know the Galaxy S2, for example, only supports Baseline as well).

[jmone]

I can't belive Apple iOS deliberatly prevents a TS file from playing from "disk".  What format (container, video, audio) do they want you to use for Video then?

[glynor]

I can't belive Apple iOS deliberatly prevents a TS file from playing from "disk".  What format (container, video, audio) do they want you to use for Video then?

MP4

I don't know that it is deliberate.  I suspect it is just an unsupported use, so it isn't wired up to expect a file, only a URL.

[glynor]

@glynor - First link is broken - missing the protocol's : separator.  Fix and I'll remove this post.

I'll fix them when I get back to a computer.

[jmone]

MP4

I don't know that it is deliberate.  I suspect it is just an unsupported use, so it isn't wired up to expect a file, only a URL.

Why not just use an MP4 instead of a TS container for Gizmo on iOS then if it was play from file and also stream?

[Matt]

Why not just use an MP4 instead of a TS container for Gizmo

If you only knew how much time we've spent trying to make an MP4 header that works on devices without having the entire file.  It's close enough to impossible, at least if you want the MOOV atom at the front, that we're done trying.

TS is designed exactly for the type of playback we're doing.  It already works great on Android.  We just need to wait for Apple and browsers to catch up, which I think they will do with time.

[glynor]

If you only knew how much time we've spent trying to make an MP4 header that works on devices without having the entire file.  It's close enough to impossible, at least if you want the MOOV atom at the front, that we're done trying.

TS is designed exactly for the type of playback we're doing.  It already works great on Android.  We just need to wait for Apple and browsers to catch up, which I think they will do with time.

That is, I'm sure, exactly why Apple implemented what they did.

Like I said, I suspect you have EXACTLY what you need for it to work on Apple devices, you're just sending the TS File itself, instead of the M3U8 playlist that points to the file.

[glynor]

I'll fix them when I get back to a computer.

Fixed.

[jmone]

If you only knew how much time we've spent trying to make an MP4 header that works on devices without having the entire file.  It's close enough to impossible, at least if you want the MOOV atom at the front, that we're done trying.

TS is designed exactly for the type of playback we're doing.  It already works great on Android.  We just need to wait for Apple and browsers to catch up, which I think they will do with time.

Gotcha.... Apple is so yeasterday   and Andriod so Today!

EDIT - as you point out the TS stuff works perfectly and was designed specifically for streaming. 

[jmone]

I don't know that it is deliberate.  I suspect it is just an unsupported use, so it isn't wired up to expect a file, only a URL.

I bet it is also part of the No "official" BD support - these religious wars are silly.  If they added this I think you would find raw TS/M2TS/M2T container support would work.

[glynor]

MKV would work fine, of course, but no one'd implement that.

So, when you send it to Android, you just progressive download the whole file?  That stinks!  If I skip ahead to 1/2 way through a 2hour video, I have to wait for the whole first half to finish downloading before it plays anything!!  That's not streaming, that's just downloading and playing.

If that's the case, and Android doesn't support HTTP Streaming, then I'd say it is Android, not iOS that is "behind".    

[Matt]

So, when you send it to Android, you just progressive download the whole file?  That stinks!  If I skip ahead to 1/2 way through a 2hour video, I have to wait for the whole first half to finish downloading before it plays anything!!

Each seek is a new request.  It takes a fraction of a second.

[jmone]

So, when you send it to Android, you just progressive download the whole file?

Nope - it is all "good".  When you first play the file it takes about 5-7 sec for playback to start (Gizmo says "Preparing") which must be the start of the session, transcoding, buffering etc.  When you do a seek (to say half way through) you see the Gizmo "Preparing" msg over a paused video for 2-3 seconds then playback starts from the new point.

[glynor]

Of course not.  When you first play the file it takes about 5-7 sec for playback to start (Gizmo says "Preparing") which must be the start of the session, transcoding, buffering etc.  When you do a seek (to say half way through) you see the Gizmo "Preparing" msg over a paused video for 2-3 seconds then playback starts from the new point.

Okay, good.  Then you must not be delivering the raw TS file, though.  If so, it'd have to download the whole thing up until the new "in point" (unless it is segmenting the TS on the fly and only delivering the piece where you start playback, maybe, which would be silly).

How, exactly, does this work?  I looked it up, and Android does support Apple's HTTP Segmented Streaming (as of Android 3.0).  From what I've read, the only other way to do that magic in the past was to use RTMP (flash), RTSP (quicktime), or Silverlight.  And, of course, mobile flash is dead, Quicktime RTSP was never supported on either, and Silverlight is dead.

So... It makes me wonder.  What exactly is being served to Android that allows it to reposition the playback without downloading the entire TS File?  The only thing that makes sense is that it is using HTTP Segmented Streaming.  But, if so, it should work on iOS.  When I try to play a video file on my iPad from Web Gizmo, it looks like it is downloading the entire file...

[jmone]

Hi Glynor - have you access to an Android Device as it is worth a play.  When all this was first introduced I was very excited as it just worked but is limited by OS, not supporting some media (eg connected media) and instantly made me think I could replace the intercom with a bunch of cheap 7" Android Tablets if 2 way comms was enabled!  I like your idea of the auto bandwidth test and thinking on this some more would suggest that in Gizmo --> Options --> Quality add a new (eg don't replace the manual selections) "Automatic" where Gizmo does a bandwith test each session and selects the "best" bitrate for the link.

[glynor]

I bet it is also part of the No "official" BD support - these religious wars are silly.  If they added this I think you would find raw TS/M2TS/M2T container support would work.

I doubt it.

I really think it is just that TS is an old creaky video file format, and there isn't a good reason to support it for on-disk playback (MP4 would be better in basically all cases, they're generally a way better container).  The only time when you need a TS, is when you need a stream, something with no beginning and no end (or, at least, no pre-defined beginning or end).  Apple is certainly not quick to implement things they consider "bad form", and they'd almost certainly consider playing a TS file from disk bad form.  Why not wrap it in a sensible container format first?

Of course, there are business reasons too.  If people can't figure out how to transfer their files onto their iPad, and they just buy them from Apple instead, that's no skin off their backs.

But I'm now really curious about what is actually being sent via MCWS to Android.  On "regular" WebGizmo, it looks like it is being transcoded to FLV, and played by JWPlayer:

Code: [Select]

<script type="text/javascript">
jwplayer('player').setup({
'flashplayer': 'scripts/player.swf',
'file': 'http://home.glynor.com:10630/Gizmo/MCWS/v1/File/GetFile.flv?File=9168774&Conversion=26&Start=&Token=Pva6LD3t',
'autostart': 'true',
'duration': '3233',
'provider': 'scripts/jrmediaprovider.swf',

Can someone give me the GetFile URL to use to get the AndroidVersion of a file so I can try it and see what it actually sends?

[glynor]

Hi Glynor - have you access to an Android Device as it is worth a play.

I don't anymore.

I can easily get one, but I can't install anything on it.  I could probably try with the browser, but I don't know if that works, and even so, I won't be able to try for many weeks (holidays).

Can you give me the GetFile URL for a video as an example?  I really think this is silly, now that I know they're serving TS-wrapped H.264.  I think the only thing they'd need to change would be to detect the browser and then send a M3U8 text file instead to iOS and it would "just work".  I think the problem is that they're specifically detecting Android's browsers (and Gizmo), and then sending something "special" to them that they're not sending to iOS.

To be clear, the M3U8 is nothing fancy.  It is an extended version of the old M3U we all know already.  Basically it just says:  Go here for this segment, and get this file via HTTP.  There is freely-available C code that does the segmenting and M3U8 generation for you, and like I said, with iOS 5+, you don't even need to "physically segment" the TS file, you can just put bytes in the M3U8 to tell it where in the file to start.

That sounds like basically exactly what they're doing on Android.  They might just be using some other playlist format (MPL probably), which means it would only work from Gizmo, not WebGizmo, on Android.  Is that how it works?

[Matt]

So... It makes me wonder.  What exactly is being served to Android that allows it to reposition the playback without downloading the entire TS File?

As I said above, each seek is a new request.  The start time is one of the parameters on the URL.

[glynor]

As I said above, each seek is a new request.  The start time is one of the parameters on the URL.

Right, I got that, but I didn't know what the request delivered (what the start time tells the player to do).

Now I get it.  You're encoding new TS files for each request, starting it at the given start time.  That would work, of course, but it'd make it tough to support a live stream (because you couldn't "rewind" past the point where you originally started without doing acrobatics on the encoding end).  You don't support rebroadcasting a live TV feed, though, right?

Ok, to support iOS, it is actually a bit simpler.  You simply use your existing TS file, but instead of delivering that directly to the client, you deliver a M3U8 playlist file.  The playlist contains the segments, which allows you to FF/RW and seek.  When the client seeks, it just picks a different segment listed in the playlist, and then does a simple HTTP get request for that file (which corresponds to a 10-sec segment of the "full" TS).  This is all handled client side.  It never has to start/stop new encodes when you seek, the client just finds the segment it wants in the playlist, and sends a new HTTP get request.  AirVideo works the same way as your system does when you open a file and IMMEDIATELY seek, it just wraps the new TS in a M3U8.

I think you could support iOS easily then.  You'd just have to generate those M3U8 files, and serve them when you detect a compatible browser agent (which includes Android 3.0+).

As I mentioned, I'd go with the option of not actually segmenting the file on disk, but using the "byte segmenting" (the HTTP get always returns the full file, it just also specifies which byte to start with).

[Matt]

You don't support rebroadcasting a live TV feed, though, right?

Even live TV is backed by disk to support time-shifting.

Ok, to support iOS, it is actually a bit simpler.  You simply use your existing TS file, but instead of delivering that directly to the client, you deliver a M3U8 playlist file.  The playlist contains the segments, which allows you to FF/RW and seek.  When the client seeks, it just picks a different segment listed in the playlist, and then does a simple HTTP get request for that file (which corresponds to a 10-sec segment of the "full" TS).  This is all handled client side.  It never has to start/stop new encodes when you seek, the client just finds the segment it wants in the playlist, and sends a new HTTP get request.  AirVideo works the same way as your system does when you open a file and IMMEDIATELY seek, it just wraps the new TS in a M3U8.

Segments are a problem, because we don't know how to do gapless encoding of little chunks.  It would be better if the device would just play the continuous stream.  And on seek, play a new continuous stream.

[glynor]

Even live TV is backed by disk to support time-shifting.

Right.  I figured that out, which is why I removed that part.  Sorry.

Segments are a problem, because we don't know how to do gapless encoding of little chunks.  It would be better if the device would just play the continuous stream.  And on seek, play a new continuous stream.

You don't start/stop the encode.  You encode a continuous stream, and then you cut (with a different thread) "backwards in time" from the encoding point.  That's how SageTV does gapless TV recordings on the same channel, and how the Segmenter code I mentioned to above works.  TS files can be cut without ill effects if you do it at the right frame in the stream (the I-Frames, I think, but don't quote me on that).

I can see why they did it that way, actually (and why you did it your way).  Yours is, then, really a stream.  Their method is easier on the server-side.  Your method would need to create a new "encode" for each client playing a file simultaneously, right?  At least if their play position doesn't match perfectly... Or do you cache the created files and track them internally somehow and serve the next client to request a segment the "closest match"?  That's actually pretty impressive.  RTMP does something like that in secure mode (though it is really only live encrypting an already encoded file, which it is reading out from disk in a stream), and the newest versions of Wowza (with optional plugins) can live encode multiple bitrates and switch them on the fly, so that would be live-encoding, but they have to be backed by powerful machines.  Of course, so does AirVideo, since that's essentially what it is doing to live encode.

In any case, Apple's system is simpler on the server-side.  It uses one source file, cut up into bits, and then just uses a playlist as a key (a tiny text file, which web servers are good at serving) and the client figures out what pieces it needs and gets them.  The segments are small, so the stop/restart the download process doesn't take much time, and it feels like a stream to the user.  To the server, it is just serving up little TS files and a tiny text file.  The client worries about what order to play them (by reading the text file), and which ones to get.

But that's all irrelevant, as of iOS 5, you don't have to cut the files anymore.  The "segments" can be byte-boundaries simply listed in the playlist as "virtual segments" (within in a full-length file), defined only in the playlist.  I'll requote again (with more this time) from the Apple TechNote:

New in iOS 5, you can now specify a media segment as a byte range (subrange) of a larger URL. This allows you to consolidate your media segments into larger files or a single large file. The primary benefit of this is when a client is playing your media, rather than downloading each successive segment file from a different location, it is actually walking through a larger file in sequence.

This also allows proxy caching servers to get a much better idea of what needs to be prefetched in order to ensure that the segment you will need is in the cache at the time you want it. An additional benefit is there are far fewer files to manage. If you have many video variants in a long movie, you can have thousands of individual segment files. With byte range support, you only have a few.

Important: Making byte range requests against non-static resources is unreliable over the public Internet. Even if your web server can handle it, your intermediary caching servers may not. For that reason, we recommend your media files for live content be static (of course they will always be static for video on demand content). It doesn't matter if they are very small or very large, just as long as you don't append to them after you start playing.

There is a new tag EXT-X-BYTERANGE to specify byte range media segments :

#EXT-X-BYTERANGE: length[@offset]

It specifies the length of the range. It must also specify the offset, unless the byte range also follows immediately from the previous byterange.

Example:

Code: [Select]

#EXTM3U

#EXT-X-TARGETDURATION:11

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-VERSION:4


#EXTINF:10.0,

#EXT-X-BYTERANGE:75232@0

media.ts


#EXTINF:10.0,

#EXT-X-BYTERANGE:82112@752321

media.ts


#EXTINF:10.0,

#EXT-X-BYTERANGE:69864

media.ts
PS.  If you do it, and it is possible, you should also specify I-Frames in the M3U8 to allow scrubbing support (which is covered in the next section down).

[jmone]

FYI - I've not used it since Gizmo came out but Plug Player is providing similar functionality over Android, iOS and OSX.

[glynor]

The main thing that worries me is the bit about the intermediary caching servers.  But that shouldn't apply here, right?  Obviously your web server supports something like that to do its magic (and we're only supporting a handful of clients max, probably).  And we aren't using CDNs to serve this stuff out or anything, so caching servers shouldn't be a problem.

So... If I'm not crazy, it could work something like this:

JRemote (or Mobile Safari or Google Chrome on Android, if that doesn't work now), requests a file.  You create the same TS encode you are now and make it available via the same URL, but instead of sending the TS file as the result of the get request, you send a M3U8 file that you make alongside the TS encode, marking the segments as you go (via the byte boundaries).  JRemote reads this, and should be able to request to go back to a previous segment, or jump ahead to a new one.  Assuming you're encoding at a constant bitrate (which seems likely without look-ahead, multipass support in the encoder), that's just math to translate the byte-boundary request into the timecode based request you're using now.  You stop the encode (same as you'd do for Android) and start a new encode at the proper spot, along with a new M3U8 (changing the URL on disk to a new file).

I think JRemote could even do it on their end, but it'd be harder.  They could take the incoming TS file, and make the M3U8 as it goes (with the segments pointing to your HTTP served TS file).  The problem is that they might need to make an actual webserver in their app and serve the M3U8 file to themselves to get AVFoundation to read it.

I'm not so sure though.  The documentation is vague, and it looked like the people posting I found complained not about the playlist file, but about the TS file itself needing to be served via HTTP, not "filename".  In fact, I'm pretty sure... I'll go look again.

EDIT:  Nope, I remembered wrong.  There's a few guys on StackOverflow who have discussed it.  It seems the M3U8 files have to be served over HTTP (the TS file can maybe be local?), but AVFoundation doesn't read TS files directly, only via the M3U8 which has to be served via HTTP.  At least one guy's solution was to build a little webserver into his app and serve the M3U8 files "to himself" via localhost.

Relevant threads:
http://stackoverflow.com/questions/5642248/can-avfoundation-be-coerced-into-playing-a-local-ts-file
http://stackoverflow.com/questions/13271624/can-ios-devices-stream-m3u8-segmented-video-from-the-local-file-system-using-htm

[jmone]

Glynor, can you tell how Plug Player does it from iOS to MC?

[glynor]

Glynor, can you tell how Plug Player does it from iOS to MC?

Probably like I just mentioned above in my edit.  PlugPlayer uses a built-in WebServer for other stuff, doesn't it?

And, of course, AirVideo just creates and serves the M3U8 files on the server-side, much like MC does for Android, only it serves the client (itself on the device) the M3U8 file it is making.

[Matt]

Assuming you're encoding at a constant bitrate

We're not using CBR, so I don't know how you could make a segment array ahead of time.

Can't an iPhone play a continuous stream?  I mean, if it can play a 10 second segment, why can't it play a 10 hour segment?

[glynor]

We're not using CBR, so I don't know how you could make a segment array ahead of time.

Impressiver and impressiver.

Can't an iPhone play a continuous stream?  I mean, if it can play a 10 second segment, why can't it play a 10 hour segment?

It can.  You can send a M3U8 with one giant segment defining the entire file and it'll play it.  It can read and refresh the M3U8 index file as it goes (I think AVFoundation does this automatically).

I don't know how it works with seeking though.  Even if you recorded the segments as you wrote the file, though, at least it would support seeking backwards (and the I-Frames would support scrubbing).  Of course, JRemote could handle that on its end, by sending the proper MCWS GetFile command.  You wouldn't necessarily have to do any of that (other than serve the MU38 to JRemote) to support only JRemote (or similar clients that know MCWS).

If you did that, it would be to support it on WebGizmo.  In any case, if you serve a M3U8 with one big segment for the TS you have so far, with no end, it will work.  It just needs to be "kicked off" by the playlist, not the TS file.  From this:

The client software begins by fetching the index file, based on a URL identifying the stream. The index file in turn specifies the location of the available media files, decryption keys, and any alternate streams available. For the selected stream, the client downloads each available media file in sequence. Each file contains a consecutive segment of the stream. Once it has a sufficient amount of data downloaded, the client begins presenting the reassembled stream to the user.

The client is responsible for fetching any decryption keys, authenticating or presenting a user interface to allow authentication, and decrypting media files as needed.

This process continues until the client encounters the #EXT-X-ENDLIST tag in the index file. If no #EXT-X-ENDLIST tag is present, the index file is part of an ongoing broadcast. During ongoing broadcasts, the client loads a new version of the index file periodically. The client looks for new media files and encryption keys in the updated index and adds these URLs to its queue.