[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Re: About AMF (Techical)

From: Rob Savoye
Subject: Re: [Gnash-dev] Re: About AMF (Techical)
Date: Thu, 04 Sep 2008 14:43:35 -0600
User-agent: Thunderbird (X11/20080723)

strk wrote:

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 ?

  Yes, RTMP transfers AMF encoded data, as well as audio and video. RTMP
also has a bunch of custom objects that are directly used for system level commands.

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.

This is so inefficient... We should be working towards one model for handling AMF objects that works for all cases. For the time being we're stuck with the two approaches, which sucks. Either evolve the readAMF0 and SimpleBuffer to support RTMP, (which means adding better encoding support), or evolve libamf/libnet, cause we need to support RTMP.

Right. I don't know if it's sufficient atm.

I don't believe they are sufficient. The entire readAMF0 and SimpleBuffer code is overly focused on a narrow usage case of and FLV Meta data, which are just glorified arrays.

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.

Ok, I added support to as_value for you to convert Elements, and you still won't use it ? I had a working FLV meta data decoder working already, so I can't see why it was hard to use. I'm not too hung up on Element vs as_value, but I don't want libamf to have dependencies on libcore. I'm not totally hung up on the design of libamf and libnet either, which is why we should be evolving that code, and not creating an entirely new implementation.

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.

I'm not ignoring references, I'm just not adding support for that *right now*. My current priority is to finish rtmpget, before launching off on other things like supporting references. Just saying you can invalidate why I use Element doesn't mean I should drop everything I'm working on as a top priority. I have ideas on how to support reference types, but I'll be happier when I can download videos from the BBC using RTMP. :-)

While you say I'm ignoring your technical issue, I see you totally ignoring the bigger picture of what RTMP needs to work, and not being very open minded about those issues. Somewhere in the middle is probably a perfect solution. :-)

        - rob -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]