to the beginning of the stream by bytes, if all else
fails.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38853 a95241bf-73f2-0310-859d-f6bbb57e9c96
ByteIOContext. libavformat may reallocate it
on demand, we need to use the matching allocation
methods.
* Init the ByteIOContext with the proper "write flag".
This solves a busy loop when writing the trailer of
MKV files, since the first buffer was initially skipped
and the MKV muxer can not seek back in the stream
where it wants.
* Get rid of the fCalculatePTS member, and calculate
PTS of audio packets as well. I don't remember why
I prevented that, however VLC complains about audio
packets having wrong PTS (with or without this change)
Our own MediaPlayer plays videos generated by (a modified)
Clockwerk at least once, but seeking subsequently fails.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38851 a95241bf-73f2-0310-859d-f6bbb57e9c96
and there is also ituh263enc.c, of which I am unsure how it
fits into the picture. However the mpeg4 encoder is using a "RL"
table of the h263 encoder, and it appears it was forgotten to
make sure it's initialized when splitting these files. Should
be upstreamed. Fixes a crash when trying to use the MPEG4 encoder.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38847 a95241bf-73f2-0310-859d-f6bbb57e9c96
to be revealed, as both variables were not supposed to change between calls
to parse_pack_data(). This could cause an invalidation of the CD-text data,
as well as an endless loop.
* Disabled (and improved) some more debug output.
* Added a short description to parse_pack_data().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38844 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Add some more const where appreciated.
- Fix some style issues and a leak in Row and Column.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38842 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Optimize subtitle drawing when subtitles are to be
displayed at screen bottom versus video bottom, and
the subtitle frame does not intersect the video. In
that case we only need to draw it when it changes
(or is to be removed). Fixed the dead-lock problem
in a nicer way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38841 a95241bf-73f2-0310-859d-f6bbb57e9c96
in C, they are 1 byte sized in C++). The empty knlist is what broke the WLAN
stuff in various ways since I renamed ieee80211_haiku.c to cpp.
* This fixes at least bug #6521.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38838 a95241bf-73f2-0310-859d-f6bbb57e9c96
opening parenthesis on a new line & 80 chars/line limit).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38837 a95241bf-73f2-0310-859d-f6bbb57e9c96
in overlay mode. Added TODO, since it should be fixed
eventually. There seems to be a problem with mapping
the BBitmap area into a BBuffer (video stays black).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38834 a95241bf-73f2-0310-859d-f6bbb57e9c96
* In SubtitleBitmap, if we ever take too long to generate a subtitle bitmap
with the drop-shadow, fall back to outline mode. The StackBlurFilter is
extremely fast, though, so there isn't a huge difference. It can fix some
jumps in the video when switching subtitles in fullscreen mode, though.
* Introduce overlay mode to SubpixelBitmap. It uses the black outline then
and disables font anti-aliasing (just for the outline).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38833 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Make sure that turning off anti-aliased font rendering
also works when subpixel-anti-aliasing is used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38831 a95241bf-73f2-0310-859d-f6bbb57e9c96
one cannot open the device anymore if no media is present - this did also let
the disk device manager ignore CD-ROMs in case there was no media present
during boot. This fixes bug #6130.
* Disabled debug output again.
* Fixed missing newline in debug output.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38828 a95241bf-73f2-0310-859d-f6bbb57e9c96
if the SRT file is placed alongside the current playlist
item under the same name (sans extension). The name of the
language is taken from the file which needs to be separated
by a dot (should be improved).
* Instead of the black outline, subtitles have a nice drop
shadow now, which is easier on the eyes somehow.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38827 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Preserve transparency of default color when color
changes via tag.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38826 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Cleanup ParseStates in case the input didn't have
all closing tags.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38824 a95241bf-73f2-0310-859d-f6bbb57e9c96
default drawing mode for text rendering. Don't override it
with B_OP_COPY (still the default). Should not have any
consequences in any existing use-case. The MediaPlayer can
use BTextViews to render semi-transparent subtitles this way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38823 a95241bf-73f2-0310-859d-f6bbb57e9c96
BBitmap from a subtitle line as found in SRT files. It
supports all tags except positioning (should probably be
handled in upper layers anyway). The parsing is simplistic
but should be robust. The layout of text is handled by an
offsreen BTextView. VideoView can be given a subtitle
string.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38822 a95241bf-73f2-0310-859d-f6bbb57e9c96
are stored in signature-based subdirectories. This improves upon r37871 and
should allow BOM to properly harvest catkeys for online translation tools.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38819 a95241bf-73f2-0310-859d-f6bbb57e9c96
not compile on BeOS anymore, I've removed the
BeOS versions from the rest of the source.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38815 a95241bf-73f2-0310-859d-f6bbb57e9c96
don't belong to the audio or video super type. All other files
should now open automatically with MediaPlayer since r38810
even without it claiming direct support for them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38812 a95241bf-73f2-0310-859d-f6bbb57e9c96
the super type is only regarded for "installed" MIME types.
The comment says that uninstalled MIME types are assumed
to be application MIME types, but this is clearly not always
the case. Initializing the secondary signature regardless
fixes the problem that unkown document MIME types open in
a random application, even though their super type has a
preferred handler. If the type is indeed an application
itself, I suppose no harm is done, since the primary
signature takes precedence anyway. Closes ticket #4501.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38810 a95241bf-73f2-0310-859d-f6bbb57e9c96
Some test clips with sub-title tracks would hang MediaPlayer
without this fix here.
* Optimize FindKeyFrame() and Seek(), check the range between
last requested/reported frame and bail out early with the
same result. Seems to fix MediaPlayer starting to drop frames
when it got caught up in a keyframe finding party...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38808 a95241bf-73f2-0310-859d-f6bbb57e9c96
in many situations, FindKeyframe() was unable to reliably
predict what frame Seek() would be able to seek to.
* Refactored a new base class StreamBase from the old
StreamCookie, renamed StreamCookie to just Stream.
* In FindKeyframe(), Stream will create a "ghost" StreamBase
instance. That one will be used to actually seek in the
stream without modifying the AVFormatContext of the real
Stream. From that we can tell what position we can /really/
seek to. For AVIs mostly, it is important to still use
av_index_search_timestamp(), since for many AVIs I tested,
reading the next packet after seeking did not produce a
timestamp, however the index entry contained just the correct
one. If the next packet does contain a PTS, it will still
override the index timestamp, though.
* Contrary to my previous belief, there was still a locking
problem with how MediaPlayer used the BMediaTracks. The video
decoding thread and the playback manager both used
FindKeyframe() without holding the same lock. We support this
now by using one BLocker per Stream. (The source BDataIO is
still protected by another single lock.) With the new ghost
stream stuff, the locking problem became much more of a problem,
previously the FindKeyframe() had a much rarer race condition
which would only trip when the decoding thread would cause new
index entries to be inserted into the index.
* Use the same ByteIOContext buffer size that avformat would be
using if it initialized the ByteIOContext through other API.
* Don't leak the probe buffer in case of error.
* Don't leak the ByteIOContext buffer in the end.
* Do not discard other stream packets anymore, this makes the
ASF demuxer happy and ASF files can now be seeked as well as
with ffplay itself.
With these changes, all my MPEG test streams work. Some could be seeked
before, but would show bad artifacts. Some streams would completely loose
video after seeking once. My MPEG2 test stream works much better now,
although audio is slightly out of sync, unfortunately. All my test AVIs
work as good as before, MP4 and MKV still work perfectly. The single
test ASF I got is now perfectly seekable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38807 a95241bf-73f2-0310-859d-f6bbb57e9c96
the new video decoding function. This just avoids a warning
generated from the libavcodec sources. The function used before
did the exact same thing...
* Maintain fStartTime correctly in _DecodeVideo(). Don't overwrite
it with a calculated starttime in Decode(). This will allow drift
to bubble up to the higher layers.
* Do not use the previously required hack to close and reopen the
AVCodec after seeking. avcodec_flush_buffers() seems to work
fine now, and for certain stream types (MPEG1, MPEG2 video for
example) the keyframe is correctly used after seeking.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38806 a95241bf-73f2-0310-859d-f6bbb57e9c96
asked to seek backwards, cause us to produce silence. This fixes some
occasionally very unpleasant noise after seeking.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38805 a95241bf-73f2-0310-859d-f6bbb57e9c96
