To make it better, there should be a looping mode per
window, and the settings should serve only as defaults.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38570 a95241bf-73f2-0310-859d-f6bbb57e9c96
in a CONFIG_GPL #ifdef (should be upstreamed, actually). This fixes
the GCC2 build (and probably GCC4) if the Haiku build is not configured
to include GPL add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38563 a95241bf-73f2-0310-859d-f6bbb57e9c96
GPL code is enabled or not. We need to build it in either case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38561 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
using vendor branches properly... I remember having to make this change
before... GCC2 build goes much further now, investigating next problem.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38554 a95241bf-73f2-0310-859d-f6bbb57e9c96
what it's internally using. Adapt NotifyCurrentFrameChanged()
implementors.
* Controller::SetTo() does not need to set the current frame,
since either Init() or FormatChanged() will have taken care
of it now.
* Reset the seeking request info in Controller::SetTo().
* Changed the parameter passed to VideoSupplier::FillBuffer()
from media_format to media_raw_video_format, so the
VideoProducer doesn't have to generate a media_format for
each frame...
* ProxyVideoSupplier caches the last produced frame, which
avoids a situation that the VideoProducer asks to generate
the same frame twice sometimes.
* In PlaybackManager::_PushState(), make sure we really
schedule the next current_frame if asked. This avoids
one situation in which the VideoSupplier was asked to generate
the same frame again and fixes playback after pausing (was
showing black video until the next keyframe before.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38553 a95241bf-73f2-0310-859d-f6bbb57e9c96
sure we don't deal with stale PlayingState and other outdated data
when the Controller initializes to a new file, but does not need
to teardown the old and setup new media nodes. Fixes ticket #3855.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38551 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
