[Ffmpeg-devel] BeOS support to be discontinued Feb 1 2007

[Cian Duffy]

On 12/12/06, M?ns Rullg?rd <mru at inprovide.com> wrote:
>
> "Cian Duffy" <myob87 at gmail.com> writes:
>
> > Erm... I seem to remember I'm the only person who's pushed for BeOS
> > support recently, I don't remember being asked? If you could provide
> > a clearer description of what the "mess" is, I'd be more than
> > willing to take a look in to it, but not having heard anything on
> > here or when I've been on IRC, I haven't got a clue.
>
> Hehe... I and Diego figured something like this would get your
> attention.  We've discussed this very course of action on IRC, but
> maybe you weren't around just then.


I'm usually only around when someone breaks the BeOS build, and you've all
been good the past while ;)

>> In light of the above, we regrettably have only one remaining option:
> >> dropping BeOS support.
> >>
> >> If the BeOS users wish to see continued support for their OS of
> >> choice, they have until February 1 2007 to come up with a clean
> >> solution for whatever the issues may be.  If by that time we have seen
> >> some serious efforts to set things straight, we will of course extend
> >> the deadline within reasonable bounds.
> >
> > Again, if the "issues" were made clear...
>
> Do a grep for BEOS in the FFmpeg source.  There's a lot of
> BeOS-related #ifdeffery in libavformat.


Just lavf? Theres a bit in lavu and lavc I think. I seem to remember a lot
of them just relate to the often weird and wonderful places Be moved stuff
to in the headers.

>
> > Full functionality on BeOS R5 isn't possible without "ugly hacks",
> > however with networking disabled, it should be.
>
> Would it be possible to contain those hacks in single C source or
> header file?


Probably. Would have to see what I can do...

Also, could you please outline the major variants of BeOS around, what
> problems they might have with FFmpeg code, and if there's any good
> reason for people to still be using old troublesome versions?


Major families:

R5 - shit networking. No sockets-as-files, barely working select(), etc.
BONE-based - relatively decent networking. Appears to have partially ported
from NetBSD 1.x.

Some people use R5 because they don't want to use the leaked-out early BONE
releases or pay for the current one (magnussoft ZETA). I used to use it
myself until my (very) new hardware was no longer supported - it doesn't
have SATA. R5, perversely, has a few BSD/POSIX compatibility hacks that
don't work on BONE-based systems, including support for flock(), meaning
newer versions don't have current autotools but old ones do... The poor
networking also impacts on other stuff. However, as ffmpeg is mostly vital
for VLC on BeOS, and it looks like VLC 0.90 won't be made available (by me)
for R5, the issue could now be nullified. Haiku should have RCs within 6
months, these will be effectively equal to the BONE compatible systems.

The biggest problem by now is that neither of them has a C++ compiler newer
than GCC 2.95.3. However, as ffmpeg is C - thats not an issue here. Theres
GCC 3.4.3, and theres also 4.x knocking around.

I'm currently in Windows (work reasons, BT seeemed to think writing "web"
apps in ActiveX was a good idea), so I don't have a copy of the source
handy, but I'll take a look tomorrow night to see what can be done, and also
see if killing R5 support would clean it up much.

Cian

-- 
-------------------------
"We're busyh running out of time"