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
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
