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

Måns Rullgård mru
Tue Dec 12 03:05:47 CET 2006


"Cian Duffy" <myob87 at gmail.com> writes:

> 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 ;)

Fair enough I guess.

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

There's a pageful in lavf, one in lavu, none in lavc, and a couple in
ffmpeg.c.  That's expected, since most weirdness tends to involve
networking or other I/O.

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

Thanks, that would be very welcome.

> 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).

Well, if you choose an OS that costs money, you'd better be prepared
for the consequences...  No money, no new features.

> 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

Well, we're not using that anyway...

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

So Haiku is a code name for the next release?

It seems to me that a sensible plan would be to drop networking
support for R5, and focus on the later releases instead.  We don't
support msdos 3.0 either...

-- 
M?ns Rullg?rd
mru at inprovide.com




More information about the ffmpeg-devel mailing list