Ffmpeg is a "Multimedia Encoder and Streaming Server", as described on the project page. It is composed of a file handling library, a codec library, the file converter and grabber binary, and the server part.

Ffmpeg is currently used in several other projects, such as MPlayer, a full-featured media player for Linux, which uses the codec library from ffmpeg. This has brought some more developers to the ffmpeg project, but the primary focus is currently on the codec library, and so the server part is currently broken.

The multiple codecs supported by ffmpeg include:

• AC3 (Dolby)
• mpeg audio layer 1, 2, 3 (only layer 2 for encoding)
• mpeg 1 and mpeg 2 video
• RealVideo 1
• mpeg 4 (OpenDiVX)
• msmpeg4 (a.k.a. DiVX ;-)

Compilation on The BeOS

A first try had been published on BeBits, but now the compilation of the CVS version (located at Sourceforge) should be easy, as the patch recently merged and adds the default settings to the configure script. Compilation without BONE hasn't been tested and may require some additional patching. Currently, there still are some limitations, which are:

• compiling with mmx support needs the updated gcc from BeBits,
• grabbing is not enabled, since BeOS doesn't feature Video4Linux, but has its own API for that matter. (any help in writing a beosgrab.c would be welcome :-) ),
• the networking code (http access, such as recording streamed mp3) does work, but requires BONE.
• PPC support hasn't been tested, though, except all asm optimisations (which include ARM, x86...), the rest of the code is plain ANSI C. Any takers?
• ffserver doesn't compile due to a lack of support for poll() (a select() variant) in BeOS (and networking would work only on BONE out of the box).
• ffmpeg still crashes sometimes due to the code returning negated error codes, which are already below 0 in BeOS, resulting in a lot of warnings and errors not detected as such.

At any rate, ffmpeg is still useful in BeOS, and we can hope all the problems described above can be fixed quickly.

The code

Ffmpeg is coded in C, but the code has some object-oriented aspects within that makes it a pleasure, to an extent. The project is devided into several parts, as shown here:

specific handlers (contained in libs)

audio grab

video grab

protocol handler

mux / demux

...

mpeg1 codec

mpeg4 codec

AC3 codec

...

libraries

libav

libavcodec

binaries

ffmpeg

ffserver

Each library defines a set of C structures that a handler may fill with names, mime types it supports, and functions it provides to open, close... read, write, or decode and encode. As an example, here is is the definition of the AVCodec struct:

typedef struct AVCodec {
    char *name;
    int type;
    int id;
    int priv_data_size;
    int (*init)(AVCodecContext *);
    int (*encode)(AVCodecContext *, UINT8 *buf, int buf_size, void *data);
    int (*close)(AVCodecContext *);
    int (*decode)(AVCodecContext *, void *outdata, int *outdata_size,
                  UINT8 *buf, int buf_size);
    int capabilities;
    struct AVCodec *next;
} AVCodec;

Upon initialisation, the libavcodec library that is to be called is its avcodec_register_all() function, which builds a linked list of codec descriptors (using the next field in the structure). The libav library does the same.

When reading a file, ffmpeg asks libav to "instantiate" a protocol handler (either file, http, ...), then the library guesses the format of the stream, either using the mimetype, the file extension, or by sniffing. Then it instantiates a demuxer (.avi, .mpg, .rm ...), which builds a list of the tracks present in the stream. ffmpeg then instantiates a codec from libavcodec for each stream it can handle.

The use of function pointers in the C structs remind me of a sort of object-oriented approach, one that proves to be very easy to extend, as adding a new protocol handler is just adding a struct and functions for reading bytes off the streams, and the demuxers don't care if the functions they call read from files or from http.

Conclusion

GUI, the insightful and probably uncopyrightable name for this little tool, could create windows, when last we left. Nothing more or less. I decided that today I was in the mood to go deep (more window features) instead of wide (adding widgets). For this installment, I have added a number of additional commands to the language:

option: EOS | LABEL NAME {myGui.SetTitle(yytext);} EOS  |
        LOOK NAME {myGui.SetLook(yytext);} EOS |
        FEEL NAME {myGui.SetFeel(yytext);} EOS |
        PULSERATE NAME {myGui.SetPulse(yytext);} EOS |
        SIZELIMITS NAME {myGui.SetSizeLimits(yytext);} EOS |
        ZOOMLIMITS NAME {myGui.SetZoomLimits(yytext);} EOS |
        TYPE NAME {myGui.SetType(yytext);} EOS |
        FLAGS NAME {myGui.SetFlags(yytext);} EOS |
        POSITION NAME {myGui.SetPosition(yytext);} EOS |
        SIZE NAME {myGui.SetSize(yytext);} EOS |
        WORKSPACE NAME {myGui.SetWorkspace(yytext);} EOS  

You will notice, right off, that I did some refactoring. All of the options that were inline before no longer are. The lexer code is much more "pure". This is a standard part of extreme programming - code the simplest thing possible, then rework the code when changes are made. As a wise programmer from LucasArts once said, "Fail fast and hard, if ever". Instead of spending hours crafting beautiful classes, only to find that the idea doesn't work, I built something that was not scalable, then used standardized techniques to make it better.

I decided to handle more than one might expect in the individual functions. For example, bison is not handling the number parsing in this version. Nor the flag separation. The very simple reason for that is the error handling. Bison normally will say things like "parse error" if you make a grammer mistake. Not very helpful. By parsing the parameters for each option in the option's method, I can look for errors and give a better error message. There are several places in the code where I left markers to do so, but have not done so. I debated between BAlerts, exceptions, classic printf's and decided to delay the decision.

The next things on the feature list to do include:

• Allow references to other objects - this will require some level of symbol table
• Add some relative positioning operators so that not every position parameter has to be absolute
• Add (at least) one widget that can be added to the window

A fair amount of code was added for this release. Mostly very simple to write, but a lot to do. More unit tests were added (after coding, much to my shame). In fact, not every feature has been extensively tested. Caveat emptor.

I bring this up because I believe that the Be community has a need for such a thing. There are many people who have mirrored www.be.com. And that is a Good Thing. There are, however, other resources that need to be collected. One good example is www.b500.com. This is a site run by, IIRC, Jon Watte, formerly of Metrowerks and Be. If he decided not to pay for hosting for that site anymore, much BeOS goodness would go away.

All of the hobbyist sites that are of value could go away at any time. Running a website costs money. Real money. And many Be users don't have piles lying around. Not to mention the pain of the death of a dream. When resubscription time comes around for a remnent of that dream, maybe people will choose not to remember. I understand that. I might have made the same choice, in their place.

I don't want to speak in FUD, and I don't want to depress you. I believe more in OBOS now than I ever did. Good stuff has happened and is happening (and will happen). But I don't want to lose all of the goodness that has ever been, either. Not everyone shares our optimism.

So, here is what I think we should do. Some group with reasonable hosting and space should approach each of those sites. Offer to (minimally) mirror their content. Offer to host for a small fee. Offer to have their URL redirected (i.e. www.myBeSite.com would point to mybesite..com). Have a portal page that points to each site, catagorized their way. Searchable by content. One portal, so I can go to www.someplace.com and find all things Be related.

This will take some humility on the part of the web site owners. And I don't expect everyone to go for it. But I, for one, am sick of Google searches to broken links. I am sick of scrounging for files and info that should be easily accessible.

One central repository for Be mirrors, web pages and community would be a huge asset to the community. A place to show that the Be community is united. Someplace that doesn't prefer one site to another (and maybe doesn't even have its own content). Someplace where you can go and say "I want to build a site dedicated to Flight, the demo that came with BeOS" and get some space. Maybe it would host email accounts for people in the Be community. And a BeShare area. Who knows - someday, it could include some web services, too. I think that Apple's model in this is *BRILLIANT*. When Steve introduced mac.com, I wanted to buy in, and I *hate* MacOS.

It will also be a full time job for someone. Or several such someones. And a fair amount of money for hosting. This can't be something you run on your dial up. Dedicated T1, I would think, would be the minimum. Professionally hosted, running a BSD or something (yeah, I know, but BeOS was never meant to be a server OS). A machine with a hot swappable spare, RAID 10 drives, etc. Not a hobbiest throw together, but a professional level setup. Then people to go and look for sites and contact people. Copying and mirroring. Scripting mirroring so that it is done nightly. This is a "real job" for no money.