Added BurnItNow, both a gcc2 and gcc4 build.
Added Bazaar, both a gcc2 and gcc4 build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38665 a95241bf-73f2-0310-859d-f6bbb57e9c96
of support for these codecs and demuxer in the FFmpeg plugin. The
ogg test streams I downloaded play fine now. For example, Big Buck Bunny
would play without video before and ogg files natively encoded with the
FFmpeg plugin wouldn't play at all. Since the removed plugins were not
maintained and were based on external libs themselves, I didn't see the
point in keeping them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38646 a95241bf-73f2-0310-859d-f6bbb57e9c96
on PPC and it was pointless to give the PPC developers trouble while
there isn't even a desktop on PPC yet. Sorry about that!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38611 a95241bf-73f2-0310-859d-f6bbb57e9c96
the build depending on the target architecture.
* Add the folder for media plugins to home/config/add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38559 a95241bf-73f2-0310-859d-f6bbb57e9c96
FFmpeg plugin, which now works for much more files
in my testings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38556 a95241bf-73f2-0310-859d-f6bbb57e9c96
Matroska support in the FFmpeg plugin. I have a few streams
to test with, most didn't play right with the Matroska reader,
many simply crash. With the FFmpeg matroska support, most files
do play fine. Seeking the audio stream is a problem, in that
the FFmpeg code does not build the index for the audio stream,
and so seeking always falls back to regions of the file that
have already played. The audio will catch up eventually and
playback will be fine again. A minority of files I could test
with don't work right, those seem all to be older files.
Overall, the support for Matroska files has much improved
with this commit. I am still investigating why FFplay has
no trouble seeking in mkv files, while the FFmpeg plugin only
seeks perfectly in video streams. It may be a problem that
the FFmpeg plugin uses completely separate AVFormatContexts
for each stream, which on the other hand allows to seek BMediaTracks
independently from each other and resolves concurrency issues.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38541 a95241bf-73f2-0310-859d-f6bbb57e9c96
man files from /boot/common/man to B_COMMON_DOCUMENTATION_DIRECTORY/man.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38495 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed the mp3_reader and mp3_decoder from the image and from
the source tree even. The mpeg123lib based decoder was crashy,
since the lib didn't cope with bad input data too well, whatever
the reason, but bad input can also be a specially crafted file.
I didn't see the value in keeping two decoders around that use
a third party library as backend. While reading in the mp3_decoder
code, I even saw that it used global variables in the mpeg123 lib
to figure out framerate and channel count, after decoding a bit of
input. Obviously this has concurrency issues.
* Removed the mp4_reader from the image. It is native code, and should
perhaps be preferred over imported code, but I don't have the
resources to look into it, and David doesn't seem to have the time
either. There are basically three types of problems with the
native mp4 reader: 1) It is way too CPU intensive. I have many HD
files that don't play at all, since there is not enough time left
for actual decoding. 2) Seeking leaves a lot of visual artifacts
(with the very same decoder plug-in), since there seems something
wrong either with finding true keyframes, or with flushing buffers
correctly. And 3) very often audio stops working at all after
seeking. Sometimes a keyframe is returned for audio which is very
far away from the wanted frame, which currently triggers bad
behavior in the audio producer node in MediaPlayer and can even
crash the media_addon_server. With the ffmpeg based mp4 reader,
none of these problems exist: Seeking is perfect, no artifacts,
CPU load is low enough for pretty much all HD clips I tested with,
and audio always works and is always in perfect sync with the video
after seeking.
If there are regressions after this commit at all (I tested a lot of
files), then I anticipate only that the ffmpeg plugin does not advertise
support for files it could actually handle (i.e. easily fixable). In
those cases hopefully a test stream can be made available. If the
native mp4 reader is improved to the point that it works as well as
the ffmpeg mp4 demuxer, we can easily switch it back, but for now, users
will prefer reliable playback.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38403 a95241bf-73f2-0310-859d-f6bbb57e9c96
trying to build the compiler when it's not going to work
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38384 a95241bf-73f2-0310-859d-f6bbb57e9c96
* make BDADDR_* macros refer to value types instead of addresses
* adjust all interfaces using bdaddr_t* to use (mostly const) refs instead,
which IMHO makes the interface & code clearer
* that got rid of a couple of const incorrectness casts
* some cleanup along the way
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38265 a95241bf-73f2-0310-859d-f6bbb57e9c96
As an interim solution for fixing the build,
download an ICU package from Haiku Ports.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38254 a95241bf-73f2-0310-859d-f6bbb57e9c96
constants, which had to be defined in several places in order to be available
in the kernel addons, network protocols and the server/kit.
* enable -Werror for all servers
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38213 a95241bf-73f2-0310-859d-f6bbb57e9c96
to SetBaseFont() (and fFont to fBaseFont)
* enabled -Werror for all preflets
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38203 a95241bf-73f2-0310-859d-f6bbb57e9c96
Add Jam rule SuppressOptionalHaikuImagePackages as a mechanism to keep
packages from being installed.
Extend the UserBuildConfig.ReadMe document to cover the new command.
Closes ticket #6260.
Changes from v1:
* Simplified IsOptionalHaikuImagePackageAdded as suggested by Ingo.
* Added example as documentation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38100 a95241bf-73f2-0310-859d-f6bbb57e9c96
* I didn't manage to make it work for the translations, however. If someone with better jam knowledge could look at it...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37871 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Since they all work reasonalbly well, add them to the default image. (beOs had them after all)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37864 a95241bf-73f2-0310-859d-f6bbb57e9c96
