How can you use one NetStream to publish video and audio from another NetStream in AS3?

[Howitzer21]

Let's say one of your client programs in AS3 is able to receive live video and audio from a NetStream and play it on the screen.  How could you make it also take that video/audio stream that it's receiving, copy it over into another NetStream, and publish it elsewhere?  I need to know how to do with this regardless of whether RTMP, RTMFP, or some mixture is involved.  The reason why the stream needs to be relayed this way is a real long story, but it's necessary in this particular case. Thanks!

[kglad]

if you can load the video file you can use the appendBytes method of the netstream class.

[Howitzer21]

Can this be used to facilitate a live, three-way video chat?

[sinious]

That's a very broad topic.

Just to touch on it you're going to want to open the stream in a asynchronous way, meaning start accepting a stream of data and work with it as it continues to come in over time. One AS3 class that can do this is URLStream:

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/URLStream.html

When you create your NetStream object you set the constructor to null (ns = new NetStream(null)) so you can use appendBytes(). As UrlStream loads data from the URL you give it you can apply it to that NetStream object via appendBytes().

[Howitzer21]

Basically assume three clients: A, B, and C.  B can communicate with A and C, but A can only communicate with B, and C can only communicate with B.  B and C will always use RTMFP, but A and B will sometimes use RTMP, sometimes use RTMFP.  My understanding is that Adobe's RTMFP setup allows for multi-hop jumps, but their RTMP setup doesn't.  But regardless of which protocol A and B are using, I still need all three clients to be able to talk to either other over video chat, A and C hopping to each other through B, without serious issues with latency (even when A is actually n number of clients spread out across the Internet, though B and C are each always just one and are on the same intranet).

That being said, would URLStream pretty much be the way to go?

[sinious]

RTMP is TCP, which has higher overhead and latency because it guarantees packets are delivered (handshaking, causing latency and overhead). It also doesn't allow you to share connections directly between clients forcing the server to do all the work.

RTMFP uses UDP, which is a choice protocol for streaming video because it's the opposite. It's lossy which decreases latency and overhead from no retransmissions and most importantly (in some applications) allows you to connect directly from one Flash Player to another Flash Player (p2p) so the server overhead is dramatically reduced. The server is only required to negotiate the initial connection and then it's up to the clients to continue to facilitate that.

How you code your one to many or many to many relationship broadcast network will be based entirely on which of those you choose.

URLStream is very common to use in p2p. Here's an older Adobe article on p2p and an alternate quick old video tutorial (FP10) as a quick simple example of p2p over RTMFP you can view the source of.

[Howitzer21]

Is there a way to take what it's loaded through appendBytes() and publish it on a separate NetConnection?  So far I haven't been able to find that.

[kglad]

:

http://blog.magicalhobo.com/2010/06/23/netstream-appendbytes/

[sinious]

That's URLLoader code kglad, which will download the whole FLV before starting playback. The NetStream isn't too different.

Howitzer~ You want to attach to the UrlStream objects data coming in. As far as I know there is no exposure of a NetStreams data that you can attach to.

[kglad]

that's a limitation of appendbytes (i believe): you have to load that entire stream before you can append it to a netstream instance.  i don't see that as being an issue for the op's app.

but i don't see an easy way to create a real time video chat with flash.   using rtmfp that you already cited along with the appendbytes method should work but you need to create those bytes and then reconstruct the video from a message object.

i don't see anything easy about that.

[sinious]

It sure is a FIFO and it won't send to output until you send a FLV complete tag or flush. Inserting those tags will cause the player to show the appended data and continue to do so as long as you reset, show, flush, rinse repeat. How the video will perform is in question.

[kglad]

i think (but haven't tried) each client can use the same generic header for each message.  but, if the op intends to send continuous video, i think you're correct, performance will be problematic.

i was thinking about sending a video snippet only when one of the peers had something to say.  even with that limitation, if there are more than 2 people connected, this will be a mess with each client (trying to) display feeds from every peer.

[sinious]

You can reuse the same meta for each connect as long as you send the end to flush the FIFO so it presents and restarts.

The CPU threads everything it's doing so fast it gives the illusion that iTunes is somehow dedicatedly playing your music while also dedicatedly playing your video game, with no studders, on a single CPU system (pre-multi-core). It's an illusion. The CPU was always chopping each task into tiny bits, processing them so fast the audio never studdered and the game FPS stayed smooth.

This is the same basic illusion only the wildcard here is the network. With RTMFP offering direct connections (after negotiation), the video quality will rely on the users system to relay the feed. Not ideal but possible. If all conditions are ideal (fast computers, fast broadband), it's feasible the same illusion could happen, especially LAN.

Mixing RTMP (tcp) and RTMFP (udp) together (as I saw in your other post), well, now you're getting into some really exotic requirements that an internet service should be handling for you.