* Reverted part of r38901 to create the symlink
develop/abi/x86/gcc4/headers/cpp -> ../tools/current/include/g++
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38905 a95241bf-73f2-0310-859d-f6bbb57e9c96
* libstdc++.so, libsupc++.so were being created in gcc-4.3.3-haiku-100425/lib
* updated the target directory for the headers (from g++/ to c++/)
May help with #6701 -- at least #6701#comment:2
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38901 a95241bf-73f2-0310-859d-f6bbb57e9c96
generation/collection. Thanks RISC for pointing this out!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38894 a95241bf-73f2-0310-859d-f6bbb57e9c96
on it.
* This also fixes a broken build, as libalm currently does not compile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38882 a95241bf-73f2-0310-859d-f6bbb57e9c96
a directory structure that reflects the catalogs in the repository. DoCatalogs
accepts an optional folder parameter, which allows one to specify an additional
subfolder to glob *.catkeys from. For example dstcheck in src/bin.
Improves upon r38819 and should address the concerns in
http://www.freelists.org/post/haiku/BOM-providing-catkeyszip-and-catkeyszipmd5-again,1
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38873 a95241bf-73f2-0310-859d-f6bbb57e9c96
are stored in signature-based subdirectories. This improves upon r37871 and
should allow BOM to properly harvest catkeys for online translation tools.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38819 a95241bf-73f2-0310-859d-f6bbb57e9c96
FFmpeg. It's a bit sad, but this obsoletes pretty much all other decoder
and reader plugins. Some of them were built on external libraries as well
(AC3 (not part of default image anyway, since it's GPL), APE, MusePack),
so it's not really a big difference to using FFmpeg as external library.
The format matching is greatly simplified by using B_MISC_FORMAT_FAMILY
for everything but raw audio, and the actual FFmpeg CodecID as codec tag.
The downside of this is that the AVFormatReader can no longer be used with
other decoder plugins, but it would be easy to add special cases for native
decoders we wish to support. Obviously the out of the box support for file
formats and decoders has greatly increased with this change, so there has
to be a pretty good reason now for writing a "native" decoder or reader.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38786 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
