|
|
|
|
|
|
by toptalgergely
4791 days ago
|
|
|
Author of the original post here. >It's not clear what the article means by "repackaging" a
stream or "pointers" to tags (especially in the diagram
that shows tag pointers being transported between users). By repackaging I meant extracting the FLV tags which pretty much travel in the same format as in an FLV stream (.flv file) if memory serves well. Pointers to tags refer to the internal implementation. I took the FLV tags out of the RTMP stream, which resulted in an almost complete FLV stream. With the proper header prepended to it you could save it as a file and play it or stream it and play it. That's just what I did, created a header for every new user, and after that was sent I could just stream the FLV tags from a common buffer. The users had pointers that pointed in this buffer so after the header is sent it was true multicasting. > So I'm not really following this. Is this cutting out the
RTMP entirely for receiving clients, and instead sending
the FLV down via another transport, like HTTP or whatever?
Or is it more of, "I wrote my own RTMP streaming server in
C and Python", along with some implementation details
which I'm not understanding? (Not that there's anything
wrong with doing so. Options are limited in the streaming-
server space.) Yes. From the source RTMP stream I extract the FLV tags, which I could use to multicast. Sending the same RTMP stuff to every user would not work, but I can easily send the FLV tag stream over HTTP if I send the crafted header first. I hope that helped |
|
|
I assume you don't really mean IP multicast (which would, incidentally, be one approach to edge-origin mirroring for the popular marketing campaigns you mentioned, at least within a data center).
Anyway that makes sense, simply sending the FLV is clever. What's the method of delivery -- chunked HTTP? Does it play well with proxies?