[Top][All Lists]

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

Re: [Gnash-dev] About AMF

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

strk wrote:
I've been thinking about AMF and wanted to share some of that.

It's about time somebody else was thinking about AMF...Just as a note, there is a bunch of information about AMF up on our wiki.

the version you find in FLV is a function call, what you use for remoting
is a function call.
A function call is a name, a set of args and a return. Mostly just
a string plus as_value types.

It's often used for much more than that, but basically yes, AMF is for serializing ActionScript objects. So it's not always a function call, but an object. The strings you see are property names, followed by it's associated data. In the FLV files you're looking at, AMF is used in a simpler fashion than for anything else.

Now, the question is: why would we want another pointer-based
(heap-allocated) intermediate class between as_value and AMF itself ?
This intermediate class is amf::Element.

If you change this, you'll have to change about 15,000 lines of RTMP code to work differently. The idea is that Elements are best suited for holding low level AMF data, and usually get deleted when converted to a higher level form, like as_value. As_values are designed for how a swf interpreter needs them to work internally, while Element is designed to handle the decoding & encoding of AMF data, and how it needs to be handled by the various other file formats, or RTMP.

But again, if we do raise Element at the level of as_value, isn't it
a code duplication ?

Yes, but we've gotten into code duplication anyway. :-( I think Element and as_value while having similar roles, have very different focuses. Please don't even consider changing this without serious study of how *everything than handles AMF* needs to work, and not just the limited example of an FLV file.

One of the reasons for Element to exist (if I got it correctly)
is that it supports more types then as_value.

  It's because it supports *different* types, not an enlarged set.

In particular Video/Audio types.
Do we need to consider them part of the AMF format at all ?
Can it be instead that Video/Audio are RTMP packet types instead
and AMF is another packet type ?

  Audio and Video are only RTMP and FLV packet types, not AMF ones.

The analogy with FLV looks interesting. FLV is a stream of tags
(or packets if you want). Each packet has a timestamp. Content
of the packet may be: Video, Audio, Meta; Meta is AMF-encoded.

Just looking at FLV files is too limited a use of AMF to make any big changes to how AMF works. Please don't reinvent the wheel here.

So, my feeling is that:

        - AMF is *only* for serializing ActionScript values
        - RTMP can contain ActionScript calls encoded in AMF
        - FLV can contain ActionScript calls encoded in AMF (an RTMP session 

Also SharedObject .sol files and LocalConnection memory segments also use AMF. SOL, LC, FLV, and RTMP all have different headers.

        - rob -

reply via email to

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