On Thu, Sep 04, 2008 at 12:40:33PM -0600, Rob Savoye wrote: > strk wrote: > >On Thu, Sep 04, 2008 at 12:16:40PM -0400, Jason Woofenden wrote: > > >>This is not the standard type. In fact in all my experience with > >>NetConnection.call connecting to the openstreetmap.org server, the Object > >>type > >>is not used at all. > > openstreetmap.org is a simple user of remoting. Video streaming via > RTMP, as well as things like video conferencing are much more complex. > What we want is a solution that supports all the cases, and not just the > limited usage openstreetmap.org uses. Please think of the bigger > picture, and not just the one use case in front of your face. > > RTMP uses complex AMF Objects heavily, not just simple arrays.
I don't know much about RTMP, but my original question was: can RTMP be seen (like FLV) as an upper layer, transferring (among other things, like video and audio) *also* AMF-encoded data ? > Is this some kind of silly competition ? Evolution itself is a kind of silly competition :) It's not between people, just mind products. > Don't forget LocalConnection, and RTMP. Both also use AMF. If you > seriously intend to completely ignore libamf, then you'd better fix the > RTMP support, all the testcases, and the utilities to use readAMF0. We'll get there if needs be, but I don't feel any rush in doing so. I guess we can keep both Element-based and buffer-based encoder/decoder for AMF and decide on a case-to-case basis which to use when. > Otherwise you'll never know if readAMF0 and SimpleBuffer are sufficient > to handle RTMP. Right. I don't know if it's sufficient atm. > If you don't intend to fix all of this existing > infrastructure, then I suggest not doing anything at all, and waiting > till I get around to doing it the right way. We're getting out with 0.8.3 "fix the damn media design" release shortly, so I needed to get "metadata" FLV support in it, or the new design would look poorer then the old one. In doing so, I found the buffer-based code *more useful* for that task, so I picked that one. I'm sure the Element model fits your RTMP work more, so I'm not suggesting to drop it as a whole (unless proven conceptually bogus). I just tried to seed the discussion a bit with the REFERENCE and GC issues which *may* invalidate the model. It's up to you whether to consider that or ignore it. --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
