files during starting the app_server. Should in theory
reduce disk seeks when booting from CD.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31788 a95241bf-73f2-0310-859d-f6bbb57e9c96
inside the window. These are Command + Alt. In X11, it's just Alt, but that
is already used in various Haiku/BeOS apps.
* Introduced new window flag B_NO_SERVER_SIDE_WINDOW_MODIFIERS to disable the
above.
* Made click to front in FFM mode less strict, you can slightly move the mouse
now and still click windows to front.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31785 a95241bf-73f2-0310-859d-f6bbb57e9c96
Reworked the glyph caching:
* It is now glyph index based (a font file has an internal glyph code to
index mapping, so that for example the same fallback glyph is used for
all unsupported codes).
* We do not truncate to uint16 anymore at various places, but support
the full 32 bit char codes.
* This made it necessary to switch to an OpenHashTable based cache lookup.
* In CharacterMap, you can now see that the second Unicode plane does not
wrap around anymore.
TODO: Remove old entries from the hash table after a while to free up memory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31780 a95241bf-73f2-0310-859d-f6bbb57e9c96
the remaining part with the solid color of the last stop was
filled with red and blue swapped. In the current GUI, it would
only be visible with BTabViews. I am pretty sure there was a
bug report about it (by julun if memory serves), but I cannot
find it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31772 a95241bf-73f2-0310-859d-f6bbb57e9c96
already...
* Moved Michele Frau to correctly sorted spot.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31752 a95241bf-73f2-0310-859d-f6bbb57e9c96
was already sent by this or another view. This was already the case for the
BRect version of Invalidate(), but was forgotten in the BRegion version. I
just had an idea what the problem could be, but I think it's bogus. Needs some
investigation. Should fix ticket #4119 for the time being.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31734 a95241bf-73f2-0310-859d-f6bbb57e9c96
MainWin::_GetUnscaledVideoSize() would result in 0 width/height. Fixes ticket
#4114.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31729 a95241bf-73f2-0310-859d-f6bbb57e9c96
Implemented the statfs operation which helps to get
information like used and free blocks on the volume.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31716 a95241bf-73f2-0310-859d-f6bbb57e9c96
It completes the previous patch to the Installer, this time in the Installer
FinishScript, to support making volumes with spaces in their names bootable.
Thanks a bunch!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31620 a95241bf-73f2-0310-859d-f6bbb57e9c96
AVStream does not provide it. For my test Flash Videos, I can at least get
a duration now, although seeking is pretty broken.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31616 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Small hack to display at least some frames (one every 15 frames) when the
CPU is utterly incapable of decoding video fast enough.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31610 a95241bf-73f2-0310-859d-f6bbb57e9c96
Escape the mount point, so volumes with spaces in their name can be made
bootable after installing. Thanks a lot! Fixes#4063.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31607 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Seeking does not work, since the duration extraction from libavformat does
not work for this container (maybe there are ways/workarounds but I didn't
look into it).
* Automatic white space cleanup.
TODO: Add MIME type with sniffer rule.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31605 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Icon for Beacon by zuMi (I think Ryan had the idea), with many tweaks by
myself (new and simplified shaft with outline, beams are not cropped, better
shadow).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31593 a95241bf-73f2-0310-859d-f6bbb57e9c96
* In full screen mode, make sure to relayout the video view if size and/or
aspect change. Also adjust the window size limits (for later).
* Add optional code to _ResizeWindow() to make sure the window is fully on
screen. When it is out on one side, move it back in, when it is too large,
scale and center it so all the border is visible. This code is used when
switching clips if not in full screen mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31559 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Updated BeHappy icon
* Updated PoorMan icon
* Beacon draft (I don't think it fits so well with the rest of the icons)
* New CF LightBulb
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31554 a95241bf-73f2-0310-859d-f6bbb57e9c96
is now superfluous.
* When switching aspect ratio and the current video size is 100%, always
resize such that one side stays at 100% (which would be the height mostly)
and the other is scaled up (mostly the width).
* In _SetupWindow(), which is triggered by a new stream for example, also
check if the aspect ratio changed and resize accordingly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31541 a95241bf-73f2-0310-859d-f6bbb57e9c96
which doesn't seem to be correct from how I read the BeBook. Ignore it for
now which is pretty unlikely to be a problem.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31511 a95241bf-73f2-0310-859d-f6bbb57e9c96
the HAIKU_FFMPEG_DEFINES and friends to the toplevel ffmpeg Jamfile.
* Define the X86 CPU acceleration features in global Jamfile variables,
so that we can build specific source files depending on those defines
later (used for libavcodec_x86.a).
* In config.h, a whole bunch of parsers were defined off, which was the
actual reason why plain old .MPG files and also my .MTS streams with
H.264 video gave only scrambled video.
* Removed some files from the build by comparing which files are build
by a pristine FFmpeg libavcodec Makefile.
Attention: The following changes may break the GCC2 build:
* Remove Haiku specific changes from
- libavcodec/x86/cavsdsp_mmx.c
- libavcodec/x86/dsputil_mmx.c
- libavcodec/x86/h264dsp_mmx.c
I will test this next after switching my GCC. If you are impatiant, the
following changes were previously done to the pristine FFmpeg 0.5 files:
libavcodec/x86/cavsdsp_mmx.c:
* commented out line 426 to 429
libavcodec/x86/h264dsp_mmx.c
* h264_loop_filter_strength_mmx2() was commented out.
libavcodec/x86/dsputil_mmx.c
* gmc_mmx() was commented out.
* commented out line 2665 (assigning c->gmc)
* commented out line 2786 (assigning c->h264_loop_filter_strength)
However, I would now make similar changes by checking the GCC version. Also,
the libavcodec/x86/dsputil_mmx.c:2786 was still assigning the dummy
h264_loop_filter_strength_mmx2() version.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31506 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Improved Seek(). If wence is not SEEK_SET, make sure to check the current
source position and adjust it to what the stream points to. Also, return
just -1 on error since this is used for libavformat code. And don't set
the stream position to the error return value.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31504 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added debugging facility to dump the first 100 packets of a video stream
to a debug file on the Desktop.
* When needing to flush packets, avcodec_flush_buffers() is unfortunately
not reliable. For audio codecs, the work around was to close and reopen
the codec in Seek(). Do this also for video codecs. Makes H.264 more
reliable here.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31503 a95241bf-73f2-0310-859d-f6bbb57e9c96
* We can actually tell libavformat to discard packets for streams that
we are not interested in. Found this in the ffplay code. This should hopefully
avoid the efficiency impact of using one AVFormatContext per stream.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31458 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactored NegotiateOutputFormat() and Decode() into two separate private
methods each, one for video and one for audio.
* Keep reading chunks when video decoding, until we have got a picture. This
gets us scrambled video instead of a black picture for h264 in mpegts.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31457 a95241bf-73f2-0310-859d-f6bbb57e9c96
context has AVPrograms. I gather this feature is for container streams
that contain multiple "groups of streams" like how it would work for
satilite mpeg-ts streams with multiple TV channels in one stream. For this
to be properly supported, we should extend the BMediaFile/Track API. For
now, the AVFormatReader uses the first program, if one is there. This
was also needed to get make mpegts demuxer work, but it is not yet enabled
for other reasons.
* Read more probe data. 1024 bytes were not enough to detect "mpegts" properly
for example.
* For now, I disabled the locking in the AVFormatReader hooks themselves,
this should not be necessary, though I hope libavformat is reentrant as
long as you have your own AVFormatContext for each thread. So far everything
hints that it is the case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31454 a95241bf-73f2-0310-859d-f6bbb57e9c96
just architecture specific flags, call them just HAIKU_FFMPEG_DEFINES.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31432 a95241bf-73f2-0310-859d-f6bbb57e9c96
how everything currently worked. (Packet peaking was only done once in Init().)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31423 a95241bf-73f2-0310-859d-f6bbb57e9c96
container formats we support. I hope I have turned on only those that don't
have an implementation already (did we support ASF already?). I mostly tested
with AVI and that works reasonably well, but I only tested raw audio so far.
However, the backend for Marcus' avi_reader is much nicer than FFmpeg, so I
think it should stay and have disabled the support for AVI in AVFormatReader.
A big disappointment is that MPG containers only give scrambled video. It may
be a problem of the AVCodecDecoder, but I am not so sure. After all, it works
fine for other container formats. If I am not mistaken, VLC also does not use
the mpeg demuxer from FFmpeg. :-\ On top of that, libavformat detects the
time_base and stream duration wrongly for one of my test MPGs.
As for the implementation: Although seeking in libavformat happens for an
individual stream, in reality, the packets for all other streams need to be
flushed (that's also what happens in the libavformat tutorials I've seen).
Since our MediaKit API allows to seek tracks indivually, this is of course
a no-go, since then all other tracks would be out of sync. My solution is to
simply open the demuxer once for each stream and then completely ignore the
packets of the respective other streams. This also works around the problem
that libavformat is unable to provide packets by stream, requiring the
API user to queue the packets that he needs not now, but later for other
streams. It also means we have to no memory copies, since we can directly
use the packet buffer until the next call to GetNextChunk().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31421 a95241bf-73f2-0310-859d-f6bbb57e9c96
Re-use the kernel emulation of the FS shell to implement a FUSE module
for BFS. In theory, it could use any Haiku file system implementation
just like the FS shell itself, but currently only the BFS code supports
being compiled as an FS shell module. The build target is <build>bfs_fuse
On Ubuntu, you would do this:
sudo apt-get install libfuse-dev
jam \<build\>bfs_fuse
mkdir path/to/moundPoint
path/to/bfs_fuse /dev/sdaX path/to/mountPoint
And that will mount your BFS volume at /dev/sdaX
read/write. As this is new code, you should be careful with your
data and expect potential data loss. Not that I don't trust Raghu's
code, but a warning is always better with such things. So far, my
tests have been successful and it is great to finally have write
support for BFS in Linux! Thanks a lot, Raghu, for your great work!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31409 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved stuff from testing in Sniff() into class members.
* Added function to gfx_utils() that converts an FFmpeg pix_fmt to color_space.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31402 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The URLProtocol idea seems not to work out, so I removed that code, but
the other idea of setting up a ByteIOContext actually works, once I seek
back to the beginning of the stream after reading the initial probe buffer,
we may also offset the buffer pointer in the ByteIOContext to where we
have already read, but I am not sure of possible side effects of that.
We can now probe for the correct demuxer and detect streams.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31379 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Turn off tracing in the AVCodecDecoder which I accidentally turned on in
a previous commit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31366 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed inclusion of internal.h from libavcodec.h, it's not there in the
plain FFmpeg 0.5 version of the file.
The last item fixes the GCC2 build, at least AFAICT.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31364 a95241bf-73f2-0310-859d-f6bbb57e9c96
unified the Reader and Decoder plugins and renamed the add-on to "ffmpeg".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31358 a95241bf-73f2-0310-859d-f6bbb57e9c96
"ffmpeg" and export multiple plugin types from the same plugin (Decoder and
Reader).
* Work in progress on an libavformat based Reader plugin, does nothing yet.
* Moved config.h from libavcodec subfolder up one level, so that it's used
by libavformat as well. Adjusted libavutil/common.h accordingly.
* Turned off GPL code in config.h
* Turned off BeOS muxers in config.h
* Turned on HAVE_THREADS and HAVE_PTHREADS, although that is nowhere used
in the ffmpeg code (it appears).
* Indentation cleanup in avcodecplugin.h
I have built this with GCC4, but last night I built libavformat.a with GCC2
so I am hoping this doesn't break the GCC2 built.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31355 a95241bf-73f2-0310-859d-f6bbb57e9c96
setting and made them available in the context menu again. During my testing,
I couldn't find any weird behavior, only the window dragging should still be
a problem on slower computers when multiple mouse messages piled up.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31324 a95241bf-73f2-0310-859d-f6bbb57e9c96
write 0 bytes after doing a successful copy of an attribute. Since
fs_write_attr() was actually ignoring the position argument, this would just
clobber attributes and truncate them back to 0 bytes. This was fixed in the
previous commit, however, it should be noted that if the buffer which
copy_attributes() uses were too small, writing attributes which live in the
"small data section" iteratively would not work because of a current BFS
limitation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31310 a95241bf-73f2-0310-859d-f6bbb57e9c96
* As even the author of fs_attr.c was trying to use fs_write_attr() in an
unsupported way in the cp copy_attributes() implementation, try to be
more forgiving and support writing attributes at an offset. The method is
required to behave inconsistent in that replacing bytes at offset 0 is
not supported as replacing bytes at any other offset. Writing at offset 0
will clobber the existing attribute to stay compatible with BeOS.
NOTE: BFS itself still does not support writing attributes at an offset which
are withing the "small data section". To work around this problem, programs
which copy attributes in a loop must make sure that their buffer is large
enough that such "small data section" attributes require only one loop
iteration.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31309 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added "Force Aspect Ratio" to Video menu and context menu.
* Removed some code duplication in handling the video size messages.
* Added track selection sub-menus to the context menu, replacing the IMHO
not so important interface settings items.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31302 a95241bf-73f2-0310-859d-f6bbb57e9c96
Totally "gapless", unlike any other media player I've ever used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31301 a95241bf-73f2-0310-859d-f6bbb57e9c96
asking what to do with the debugged team. Killing it is not yet implemented.
Then it notifies the application about the quit request. That in turn tears
down the TeamDebugger and if no other ones are left, it quits itself.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31201 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use insets around everything. The visual change are insets also around the
source code view. Another option would be to put the source code view on the
right/bottom, attaching the window border and using a B_DOCUMENT_WINDOW
resize knob on the window border. The register view could also use the
additional height of the buttons. However, I agree it's somehow more logical
to have the register view on the right side. Maybe only because of
convention... so it's possibly still up for debate.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31198 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Give access to BSplitLayout::SetInsets() and GetInsets() from BSplitView.
* Give access to BSplitView::SetInsets() from BSplitLayoutBuilder and
LayoutBuilder.
* Some automatic white-space cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31197 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented a CPU feature detection function in AppServer.cpp.
The results are put into the global variable gAppServerSIMDFlags.
* Implemented an SIMD accelerated version of the bilinear bitmap
scaling code that is the backend of BView::DrawBitmap(...,
uint32 options) used by the MediaPlayer to smoothly upscale
movies when no video overlay is available. The speed up is very
noticable and a Core 2 Duo @ 1.8 GHz can play at 1920x1200 now
without breaking a sweat. There is currently one SIMD version
implemented which uses MMX and plain SSE.
Very cool! Thanks a lot!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31165 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added _MinTabeSize() to BTabView. It makes sure that the BTabView displays
at least two tabs. In the future it should also add the room to display some
buttons for cycling the currently displayed tabs left/right if there is more
than can fit.
* In BTabView::Min/Max/PreferredSize(), use _MinTabSize() to compute the
respective size.
* Improve Tab rendering code so there are no ugly overlaps at the right edge
if the tabs falls directly on the view edge.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31157 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add some spacing around most views in the top level layout.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31152 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan Aßmus