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
FFmpeg. It's a bit sad, but this obsoletes pretty much all other decoder
and reader plugins. Some of them were built on external libraries as well
(AC3 (not part of default image anyway, since it's GPL), APE, MusePack),
so it's not really a big difference to using FFmpeg as external library.
The format matching is greatly simplified by using B_MISC_FORMAT_FAMILY
for everything but raw audio, and the actual FFmpeg CodecID as codec tag.
The downside of this is that the AVFormatReader can no longer be used with
other decoder plugins, but it would be easy to add special cases for native
decoders we wish to support. Obviously the out of the box support for file
formats and decoders has greatly increased with this change, so there has
to be a pretty good reason now for writing a "native" decoder or reader.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38786 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Enabled SWF demuxer in FFmpeg (though the one test file
I have is compressed, which is not supported by the FFmpeg
SWF demuxer...).
* Removed testing TODOs for demuxers that I tested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38761 a95241bf-73f2-0310-859d-f6bbb57e9c96
itself generates.
* For GCC2, FFmpeg uses -fPIC instead of -DPIC. Also disable SSE for
GCC2, since that fixes a crash in the SSE version of clear_block().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38747 a95241bf-73f2-0310-859d-f6bbb57e9c96
speed up VLC table (whatever it is) initialization. Somehow the code
does not work on GCC2. Use the old code we had previously in SVN
minus a flag (INIT_VLC_USE_STATIC) which is no longer used in FFmpeg.
This fixes the GCC2 build of FFmpeg and closes Ã#6643, #6582 and #656.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38746 a95241bf-73f2-0310-859d-f6bbb57e9c96
different config.h, of which I am adapting the differences in this
commit. Does not change a thing for the broken GCC2 build of FFmpeg.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38745 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added more firmware to be used by the driver and updated the old one.
* avoid the switch to using ICT interrupt mode (dunno what it implies on Haiku)
* commented ieee80211_ratectl_*() calls. They can be uncommented when we support them.
* added ieee80211_ratectl.h with functions commented out
Switch to using ICT interrupt mode
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38734 a95241bf-73f2-0310-859d-f6bbb57e9c96
mpgs, the video does not recover, though.
* Remember the last reported keyframe information, so we
avoid rounding artifacts. Not as effective, since we
cannot use stream time-base for seeking, but have to use
it for finding the keyframes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38706 a95241bf-73f2-0310-859d-f6bbb57e9c96
SeekedTo(), since it's only informative to decoders. They
can't modify the seeked frame/time. This also mirrors what
all existing decoders were doing in Seek(). BMediaTrack
is simplified accordingly (resolved two TODOs).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38705 a95241bf-73f2-0310-859d-f6bbb57e9c96
(This is just until we do proper irq-handling)
On my machines it works either way so I'd like to get feedback on this.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38695 a95241bf-73f2-0310-859d-f6bbb57e9c96
if the input format requires it. Practically,
it does not work.
* Implement the new meta-data API.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38686 a95241bf-73f2-0310-859d-f6bbb57e9c96
the stream is building the index on the fly once.
This allows to seek back to earlier positions, since
then the index will contain entries for later in the
stream and the logic to detect auto-generated indices
was broken.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38678 a95241bf-73f2-0310-859d-f6bbb57e9c96
muxer by the "default" stream. When I previously tried this,
I mistakenly remembered AV_TIME_BASE to be 1000, but it's
1000000, the same as the native bigtime_t time representation.
Luckily, we can still set all other streams (including the
"default" stream) to be discarded when obtaining chunks
packets.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38677 a95241bf-73f2-0310-859d-f6bbb57e9c96
it can be any of these values, hope the priority is right.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38659 a95241bf-73f2-0310-859d-f6bbb57e9c96
frame rate (perhaps it changed in 0.6?). This fixes
playback of several MP4 clips I have for testing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38658 a95241bf-73f2-0310-859d-f6bbb57e9c96
the counters, so it's not the average for the entire
decoding time, but for the last five frames. This gives
a more accurate picture of what's going on.
* Added NOTE about possibly removing the SWS version of the
colorspace conversion code unless it's used for otherwise
unsupported conversions. David's code is about 40% faster
in my tests (nice job!).
* Free the sws context in NegotiateVideoFormat, if necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38651 a95241bf-73f2-0310-859d-f6bbb57e9c96
of support for these codecs and demuxer in the FFmpeg plugin. The
ogg test streams I downloaded play fine now. For example, Big Buck Bunny
would play without video before and ogg files natively encoded with the
FFmpeg plugin wouldn't play at all. Since the removed plugins were not
maintained and were based on external libs themselves, I didn't see the
point in keeping them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38646 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Enabled ogg muxer in MuxerTable.
ogg/vorbis creation successfully tested with MediaConverter.
ogg/theora needs more testing, it seems to work, but I need
to switch from the other vorbis/theora/ogg plugins to the
FFmpeg built-in support, otherwise the current theora stream
is not supported by the old plugin.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38641 a95241bf-73f2-0310-859d-f6bbb57e9c96
in order not to clash with the old libtheora in the theora plugin.
x86 CPU optimizations are only compiled for GCC4.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38640 a95241bf-73f2-0310-859d-f6bbb57e9c96
in order not to clash with the old libvorbis in the vorbis plugin. I plan to remove
that one after I've done more testing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38639 a95241bf-73f2-0310-859d-f6bbb57e9c96
float_to_int16_interleave_sse, since it crashes for reasons
I would have no clue about. Fixes a few duplicated tickets,
which I'll have to sort out later.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38636 a95241bf-73f2-0310-859d-f6bbb57e9c96
The changes looks reasonable, although I don't have VMWare to test with.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38602 a95241bf-73f2-0310-859d-f6bbb57e9c96
This might help with ACPI shutdown issues, if not this change can be reverted. Not verified as it works on all my machines even without this.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38585 a95241bf-73f2-0310-859d-f6bbb57e9c96
source are instead conditionally included by other source code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38582 a95241bf-73f2-0310-859d-f6bbb57e9c96
Add the new vp3dsp_altivec.c, though.
Should fix the ppc build.
*Untested*
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38581 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Tested and checked most features and fs operations, while passing successfully the Linux fsck. Though the implementation still needs more testing and is to be used with
caution, it's better in my mind to have the code committed now given the size of the patch.
* Code style isn't extensively checked but is mostly OK. Code review is welcome.
Some notes from Janito:
* Sparse files aren't supported and hard links aren't supported. Write attributes methods aren't activated nor tested.
* Journaling needs more testing to make sure it behaves in a compatible way to Ext3, and support for the different modes hasn't been implemented (due to the block
and file cache incompatibility). Correct revoke management is also lacking, as is proper management of the superblock state and copies and block group copies.
* The code is partly based and inspired by the BFS implementation. Author information might need to be fixed.
I'd like to congratulate and thank Janito for his hard work to bring the implementation to the current state. I hope he'll keep on maintaining it and become a regular
contributor/committer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38573 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
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
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
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
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
- 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
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
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
* 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
* 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
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
- 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
accepted. This should have been the reason for Duggan's problem with DHCP
as part of bug #6454.
* Stippi's router seems to answer DHCP requests with broadcasts to the future
broadcast IP address. Luckily, it's also a link layer broadcast, so we let
the upper protocols decide what to do with it, depending on that; this could
also be done depending on the existence of any unconfigured networks.
* This should fix Stippi's DHCP problems, and therefore bug #6454 - in any
case, this will be the last try before my vacation :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38450 a95241bf-73f2-0310-859d-f6bbb57e9c96
