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

[Rob Savoye]

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 
openstreetmap.org 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 -