used About... menu item.
* Setup the About menu item in the file menu such
that it sends its message to the be_app, we no
longer have to forward it then.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38522 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Instead of passing a different message constant for each possible rate of capture, we pass a single message with a int32 'seconds' field.
* switch to templatized layout builders, make use of AddMenuField and AddTextControl methods.
* Changed semantics of VideoWindow::_BuildCaptureControls to only construct views, not add them, the window layout is now built in the VideoWindow constructor.
* EnumeratedStringValueSetting now takes a function pointer to get its strings, instead of a const char**.
* kUploadClients and kCaptureRates arrays are not NULL terminated anymore, there is a size constant associated with each one.
* Style fixes
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38519 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactor code, especially layout-related, there were way too many views being created
* Remove empty hook methods
* Fix a bug which caused the convolution capabilities to be misrepresented as 0x0
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38514 a95241bf-73f2-0310-859d-f6bbb57e9c96
* introduce B_USE_DEFAULT_SPACING, which works somewhat like B_SIZE_UNSET and B_ALIGN_HORIZONTAL_UNSET
* introduce static float BControlLook::ComposeItemSpacing(float spacing), which checks uses be_control_look->DefaultItemSpacing().
* modify layouts to use BControlLook::ComposeItemSpacing() in SetInsets and SetSpacing methods.
* default insets are still 0, 0, 0, 0, but can be set to default spacing by passing B_USE_DEFAULT_SPACING
* I've found two regressions, patches incoming, please report others on #5614.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38512 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Use old ActivateWindow implementation till the Desktop SendBehind question is solved.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38508 a95241bf-73f2-0310-859d-f6bbb57e9c96
added a work-around for the problem that FindKeyFrameForFrame()
may return another frame for a previously found keyframe
(due to rounding issues in the extrator).
At the moment, files which used to play horribly play pretty well
now for me. One remaining problem is that audio may be mute when
seeking far ahead in file, and the audio decoding has to catch
up. It will eventually be all ok. Once a section of the file has
played, it becomes seekable. This seems to be weird behavior of
some FFmpeg demuxers, and only with some files.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38507 a95241bf-73f2-0310-859d-f6bbb57e9c96
the seek frame. It's just not such a good strategy, since
it appears to be faster to just wait until the next keyframe
is reached naturally.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38506 a95241bf-73f2-0310-859d-f6bbb57e9c96
returns a frame, and using that very same frame again
for FindKeyFrame() returns a different frame, because
the rounding effects have converted the time to be smaller
than the timestamp that was found for the first call to
FindKeyFrame(). It still happens sometimes, but a lot less
frequently. Ideas appreciated. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38504 a95241bf-73f2-0310-859d-f6bbb57e9c96
In some error conditions the packet would have been leaked.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38503 a95241bf-73f2-0310-859d-f6bbb57e9c96
to SeekToTime(). The extractor may have
modified the time, don't let the decoder
overwrite the actually seeked time. I am thinking
the API should be called SeekedTo() or Seeked(),
and would be purely informative for decoders,
without even a return value.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38499 a95241bf-73f2-0310-859d-f6bbb57e9c96
much more robust:
* Use a much larger buffer size, since we cache
a lot anyway.
* When reading uncached frames, don't trip over the
situation that the seekable keyframe was very far
away from where we want to read. Don't get caught
up in a loop decoding an entire movie, but return
a time-out error instead. This will get us back
on track eventually.
* Before seeking to a keyframe, check if the current
track position is actually nearer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38498 a95241bf-73f2-0310-859d-f6bbb57e9c96
could be used.
* Finding keyframes is unreliable. Sometimes the index
is built on the fly, without us knowing. The file will
become seekable after we have decoded those parts.
This however means that seeking may not have been successful.
To know the seeked to frame, we extract the next packet
and returned the true current frame in the in/out arguments
to seek.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38497 a95241bf-73f2-0310-859d-f6bbb57e9c96
have adjusted. (The API is somewhat silly, since Decoders
can't really do anything with the seek frame, it can only
be told to them. But current decoders will assign the seeked
frame from the wanted frame, which would override the seeked
frame from the extractor... the API should be fixed.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38496 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
* When the client didn't suggest it, take the sample
size into account.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38494 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Enabled the DTS decoder. The codec tag is fake,
but as long as Readers use this, it will work.
Currently only works with the FFmpeg reader, though,
and I tested only with matroska containers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38493 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the video anymore, but tell the VideoView
the video frame size. So the outside regions of
the video are also painted by the VideoView. Not
tested with overlays, but should work. The side
effect is that the controls appear along the bottom
of the screen in full-screen mode. The controls
may need to be over the video, so they cannot be
attached to the parent of the VideoView (this was
already the case).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38492 a95241bf-73f2-0310-859d-f6bbb57e9c96
restore this file from the backup I've made, so it got
forgotten in the last commit...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38491 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Propagate the current audio channel count to the controls.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38490 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reordered some methods in the source to align with declaration order.
* Applied naming conventions for private methods.
* Switched asterix style in MixerInput.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38488 a95241bf-73f2-0310-859d-f6bbb57e9c96
the ServerPicture calls those itself from SetOwner().
Since there are asserts in ServerPicture about fOwner,
it was easiest to fix the code by using *only* SetOwner()
from within ServerApp to add or remove pictures.
* SetOwner() was broken, since it called a method which
potentially removed the last reference and then still
accessed memory of the now free'd ServerPicture instance.
The easiest fix is to just increase the reference count
temporarily.
* SetOwner() wrongly returned false when the new owner was NULL.
* NestPicture() should simply add it's own reference. There
are two places where it is called, and only one of them
added the extra reference. The other one only acquired the
implicit reference that the ServerApp owns, but pictures
that remove nested children remove a reference from them.
This could leave stale pointers around of course.
* Added more asserts about fOwner.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38484 a95241bf-73f2-0310-859d-f6bbb57e9c96
Initialize the PRNG seed for the sequence number with real_time_clock_usecs()
rather than system_time(). The remaining uses of system_time() for timeout
calculation match UDP.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38482 a95241bf-73f2-0310-859d-f6bbb57e9c96
Partially revert r38465 and move the code from system_time() into a new
real_time_clock_usecs() function. The system_time() implementation was correct
in relying on of_milliseconds(), as pointed out by Axel. Add the correct
function for the desired functionality.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38481 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fix coding style issues and bump copyright (although there's not much anyway).
No functional changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38480 a95241bf-73f2-0310-859d-f6bbb57e9c96
settings. (There is a common "mixing frame rate" to which all inputs
resample, before the MixerCore resamples to the frame rate of the
output.)
* Some more coding style fixes in MixerCore.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38479 a95241bf-73f2-0310-859d-f6bbb57e9c96
to avoid someone drawing into it at the same time. In a debug
build, this avoids hitting an ASSERT.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38478 a95241bf-73f2-0310-859d-f6bbb57e9c96
message loop more clear, both in the code and also via
comments. I get the occasional drop into the debugger
because MultiLocker says the Readlock has been acquired
twice. I don't see how it is possible from the code and
it could be another bug in the MultiLocker debugging
facilities, but the code should be clearer now anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38477 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Use more title space in stacked tabs.
- Fix tab movement in stacked mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38475 a95241bf-73f2-0310-859d-f6bbb57e9c96
