The Glade 4.0

Why can't this thing be simple to use? And if it's not going to be simple, why is Linux and its damnable Apache stuff REQUIRED for what I need?

RAGEFUME.

Gremlin Rage, Phe, go find a safe house before he gets home. (you fed him after midnight didn't you?)

_________________
The U. S. Constitution doesn't guarantee happiness, only the pursuit of it. You have to catch up with it yourself. B. Franklin

"A mind needs books like a sword needs a whetstone." -- Tyrion Lannister, A Game of Thrones

What exactly are you doing? Apache is easy to get running on a mac...

We're having to run a virtual instance of Linux on a Windows web server in order to set up Apache, in order to do an HTTP stream test, in order to stream our live video signal to iOS devices. Tech guy at transcoder provider says " tried setting up a test stream to this system and it fails to connect. Webdav authorization must be turned off.. can you verify that?"

*sigh*

Because it's made to make the complexity accessible to the user, as opposed to try to abstract it away so that it does odd, unrectifiable things at inopportune times.

_________________

screw iOS devices.

_________________

Holy shitsnacks!

Farsky,

 > System Preferences > Sharing > Web Sharing

Apache is now on.

Not sure it helps, but if your Mac can't help by having Apache on, at least you see how it can work in a more user-friendly setup.

_________________
Once, I was a ranger
Then, I was a warlock
And a mage
And a paladin
Now, I seek to be myself

Have you tried Xampp for windows? I have Apache and my SQL on my desktop box right now. I just use them as a local loop to test word press templates without uploading them to the host. I have no idea if it will meet your needs.

_________________
I prefer to think of them as "Fighting evil in another dimension"

I'm reading "Linux" in the title, where are you getting the Mac from?

_________________
In time, this too shall pass.

Lenas knows that FarSky is predominately a Mac-user. Thus he was wondering why FarSky was messing with Linux (which he apparently hates) if all he needs is Apache.

That said, I'm still confused about the underlying issue. That's probably because I don't understand how a 3rd-party live transcoding service works. Correct me if/where I'm wrong:

1. You have a Windows web server, running (I presume) IIS.
2. Your live video stream is served up by the IIS server in a non-iOS friendly format (Flash-wrapped H.264?)
3. Clients who want to view your live stream connect not to your IIS server, but rather to the transcoding provider's server.
4. The transcoder provider's server then fetches the source stream from your IIS server.
5. They then transcode the source stream on-the-fly to an appropriate format (per the client's user agent string, I guess) and serve up the transcoded stream to the client.

Is that process correct? My understanding is that something is going wrong at #4, and the transcoding service is unable to fetch the original source stream from your IIS web server.

If that's the case, the fundamental problem is that your IIS server isn't configured right for this application. As much as I've grown to hate IIS and love Apache, the appropriate solution to this problem is to fix the IIS config, not to completely change web server architectures.

Do you have someone in-house that knows how to operate and configure an IIS web server? If so, they need to read through the IIS logs and figure out why the transcoder service is unable to connect to the stream. I.e., are they getting 403'd? Is the server responding at all? etc. If you don't have someone in-house who knows how to work with IIS, then honestly that's kind of the root problem. You're trying to run an IIS server in-house without in-house knowledge of how to run an IIS server (and you're trying to do something more complicated than just a simple static web site).

_________________
Sail forth! steer for the deep waters only!
Reckless, O soul, exploring, I with thee, and thou with me;
For we are bound where mariner has not yet dared to go,
And we will risk the ship, ourselves and all.

It's...twofold. One, we don't have a network admin, which we desperately need, and will be getting in the very near future. But in the meantime, as it's always been since I've been here, it's run, gun, and learn what you can on the fly. So there's that.

Let me clarify the other part, the workflow.

We have a video server. It's set up with the local assets (videos), playlist, etc. It runs not via IIS, but rather directly into the transcoder (from a company called Kulabyte) via SDI video with embedded audio.

That Kulabyte server then takes the video feed and transcodes it to an HTTP stream. This is necessitated by iOS's lack of RTMP support. Blargh.

Then (and this is where the network-y stuff comes in and I lose grasp of the intricacies) that HTTP stream would normally be served to our CDN, Akami, who would then take it, "chunk" it, and play it out. Then then that chunked stream is taken into our online video platform (Brightcove) to have a nice, branded GUI player wrapped around it and delivered out to happy little iOS devices everywhere. A rich, full day.

HOWEVER.

Akami just started with this whole HTTP streaming thing, and the demand for it was so great that they quickly got in over their heads. So, for new customers (i.e., us), they require us to do the heavy lifting (the chunking) with our own web server. This wasn't mentioned when we began the relationship, but whatever. Gotta get it working.

So, as it was a last-minute thing, and we have a web server already sitting there and doing little but running QuickBooks, we floated the idea of using it to do the chunking. Ak/ul/ightcove agreed that should work...they just need a Linux server running Apache to do their voodoo. I don't know if there were other options (that part isn't really my bailiwick). So, we Elanced a guy out of CA to get that set up, but it wasn't working correctly. So finally we said "**** this," and offered to pay Kulabyte's tech to get the **** going. Yay!

But that's not the last piece of the puzzle. Now the Kulabyte server is configured, but I'm currently waiting on Brightcove to get their **** together to provide me what I need to take the Kulabyte feed and have Akami pull it to push to Brightcove.

O brave new world that has such incredible-but-headache-inducing tech in it.

Wait... if you are a Mac user then why don't you know how to use Linux? I thought they both used Unix commands?

Why don't you install Xampp which puts on everything Apache related super easily?

Lex if you're going to say anything you should probably read the thread first.

Appropriateness to the thread aside, I'd love to see stats on the ratio of Mac users who know they can use *nix commands on their Mac, and the ratio of Mac users who *can* use *nix commands on their Mac. I imagine both would be pretty damn low. When the brand sells on the "it just works" campaign, that doesn't say to me "command line skills are common knowledge among the userbase."

_________________
"Aaaah! Emotions are weird!" - Amdee
"... Mirrorshades prevent the forces of normalcy from realizing that one is crazed and possibly dangerous. They are the symbol of the sun-staring visionary, the biker, the rocker, the policeman, and similar outlaws." - Bruce Sterling, preface to Mirrorshades

After much reading and googling, I think I more or less get the workflow/topology.

Akamai doesn't accept this (anymore) because converting an RTMPT stream to an HLS or MSS stream is non-trivial, even though all of the above protocol suites are variations on H.264 within <container format> transfered via "chunked" (Tranfer-Encoding) HTTP. Beyond that, HLS and MSS are both pretty similar to one another (from what I understand) and support changing bitrate in mid-stream (on a per-chunk basis). Akamai makes use of this to deal with client connection-specific conditions like temporary network congestion, etc. RTMP is chunked like any of the other HTTP streaming methods, but unless I'm mistaken, it doesn't support this sort of adaptive bitrate methods.

The core issue is that your XStream Live encoder only knows how to produce RTMP streams. If you need HLS/MSS/etc. your only recourse is to take the encoded output and hand it off to a middle man that can produce an HLS stream. It has two ways of doing this:

1) Hand it off to a Wowza or Flash Media Server using RTMP, and then Wowza/FMS will re-format it to HLS.
2) Hand it off as an .m3u8 file via WebDAV to any WebDAV-capable web server that is also capable of content-encoding .m3u8 with the appropriate chunking method.

In a nutshell, this:

http://support.kulabyte.com/entries/252885-how-to-stream-to-iphone-and-ipad-live-using-native-http-streaming

Hence their recommendation of Apache. It should be possible to use a web server other than Apache, including IIS, but as they say, that's an exercise left to the reader.

Edit:

Long story short, your options are either to get a different encoder that can handle the newer transfer protocols required by Akamai, or figure out how to set up an intermediate web server that can do the translation. Honestly, the latter goes beyond web-server-administration 101, and it's going to be frustrating and complicated with any web server unless you really "get" WebDAV, HLS, etc., etc. on top of knowing how to configure and administer the particular flavor of web server in question in the first place.

_________________
Sail forth! steer for the deep waters only!
Reckless, O soul, exploring, I with thee, and thou with me;
For we are bound where mariner has not yet dared to go,
And we will risk the ship, ourselves and all.