with regards to using the wrong #include scope in one file and disabling two
apparently unmaintained asserts when compiling in DEBUG mode). I didn't yet test
the GCC 2 build, but I need to get this into SVN since I am having some annoying
file corruption troubles. In fact I am hoping I am not commiting broken files,
but a few seconds ago everything was still building cleanly. One thing that definitely
improved is the (disabled at the moment) AVI support. Every clip I tested so far
plays, which can't be said about our native AVI reader. With the previous FFmpeg
version (a random SVN revision is my guess), many old AVIs played completely broken.
So far, I have not spotted any regressions
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38548 a95241bf-73f2-0310-859d-f6bbb57e9c96
object. Demuxers may actually resize the I/O context buffer,
which would corrupt memory. This is certainly the case in FFmpeg
0.6, don't know if it was a problem before.
* Do not set the time to the packet PTS in Seek(), if it's the magic
value for "no PTS".
* Don't regard the AVInputFormat flags (generic index), we can detect
this more reliably by the observed behavior: Don't trust the found
keyframe if we are obvioulsy building the keyframe index on the fly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38545 a95241bf-73f2-0310-859d-f6bbb57e9c96
the beginning of the next buffer. GetNextChunk()
still has the same problem.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38544 a95241bf-73f2-0310-859d-f6bbb57e9c96
from "frames". LateNoticeReceived() would have skipped
two many buffers depending on the channel count.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38542 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
in the Playlist code, but we don't want to get to this
index from the GUI. Handle truncation of the index in
the ControllerView. This solves invalid button state
when using the keyboard to skip to the previous item
when the current item was already the first item.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38540 a95241bf-73f2-0310-859d-f6bbb57e9c96
If no Haiku remote disk server is found, try an iSCSI discovery session on
the TFTP server, using the IP address from the boot command or OF options.
All available IPv4 targets are considered, Target Portal Groups are ignored.
RFC 4173 suggests a mechanism that avoids a discovery session by using DHCP;
that requires a compatibly configured DHCP server though and we wouldn't have
access to such data currently anyway. iSCSI is currently used as fallback,
and when it doesn't succeed it falls back to the menu as before.
Resolves ticket #5319.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38537 a95241bf-73f2-0310-859d-f6bbb57e9c96
Add support for both discovery and regular iSCSI sessions. Command and status
sequence numbers do differentiate between session and connection but only
one connection per session is currently supported.
Code is Big Endian for now, so compile it for ppc only.
Based on RFC 3720 ff. Tested against OpenSolaris 2009.06.
Resolves most of ticket #5319.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38536 a95241bf-73f2-0310-859d-f6bbb57e9c96
Don't enqueue a packet whose sequence number matches the first one in queue
or is between the next and the acknowledged on. This would lead to packet
duplication in the queue and leftovers after dequeuing.
Optimize calculation of acknowledgement number for out-of-order reception.
If a single missing packet arrived, this could have resulted in a timeout
depending on the window size.
In case the connection is closed, do dequeue remaining packets. This would
have caused a read error after a unidirectional FIN.
Prepare a dynamic window size calculation.
Do checksum calculation before attempting to trace packet contents. I have
seen a few and couldn't spot an error in the checksum calculation.
More fine-grained control over trace output.
Trace the Maximum Segment Size option if present; break after End of Options.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38535 a95241bf-73f2-0310-859d-f6bbb57e9c96
Pass the desired window size from the socket to the service.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38530 a95241bf-73f2-0310-859d-f6bbb57e9c96
Define structs for iSCSI messages, to be used by boot loader and kernel add-on.
For now it will refuse to compile for Little Endian systems (e.g., x86).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38528 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the thread related methods.
* Explicitely reset the fThread member in
_StopOutputThread().
* Added TODO about the somewhat seemingly fragile method
to ensure the previous buffer for a channel has
been processed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38527 a95241bf-73f2-0310-859d-f6bbb57e9c96
crashes. In some MKVs I have, the FFmpeg implementation
behaves badly when the stream switches from stereo to 6-channel
(weird, but can apparently happen). So simply don't claim
support for AC3, since we have a "native" AC3 decoder which
works much better.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38524 a95241bf-73f2-0310-859d-f6bbb57e9c96
some time ago on the mailing list. This change will not exactly
break existing audio tools, but once those tools write the old
attributes, the user will not see the expected changes when he
is displaying the new attributes in Tracker, and the old
attributes will of coerse appear alongside the new ones in
the Attribute menu. In the long run, it makes things cleaner,
though.
* Make MediaPlayer write the new duration attribute, and also for
video clips.
* Register opened playlist items when they are files with the
system, so not only files opened via drag and drop or Tracker
will appear in MediaPlayers "Open File" menu.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38523 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
