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
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
* Removed the mp3_reader and mp3_decoder from the image and from
the source tree even. The mpeg123lib based decoder was crashy,
since the lib didn't cope with bad input data too well, whatever
the reason, but bad input can also be a specially crafted file.
I didn't see the value in keeping two decoders around that use
a third party library as backend. While reading in the mp3_decoder
code, I even saw that it used global variables in the mpeg123 lib
to figure out framerate and channel count, after decoding a bit of
input. Obviously this has concurrency issues.
* Removed the mp4_reader from the image. It is native code, and should
perhaps be preferred over imported code, but I don't have the
resources to look into it, and David doesn't seem to have the time
either. There are basically three types of problems with the
native mp4 reader: 1) It is way too CPU intensive. I have many HD
files that don't play at all, since there is not enough time left
for actual decoding. 2) Seeking leaves a lot of visual artifacts
(with the very same decoder plug-in), since there seems something
wrong either with finding true keyframes, or with flushing buffers
correctly. And 3) very often audio stops working at all after
seeking. Sometimes a keyframe is returned for audio which is very
far away from the wanted frame, which currently triggers bad
behavior in the audio producer node in MediaPlayer and can even
crash the media_addon_server. With the ffmpeg based mp4 reader,
none of these problems exist: Seeking is perfect, no artifacts,
CPU load is low enough for pretty much all HD clips I tested with,
and audio always works and is always in perfect sync with the video
after seeking.
If there are regressions after this commit at all (I tested a lot of
files), then I anticipate only that the ffmpeg plugin does not advertise
support for files it could actually handle (i.e. easily fixable). In
those cases hopefully a test stream can be made available. If the
native mp4 reader is improved to the point that it works as well as
the ffmpeg mp4 demuxer, we can easily switch it back, but for now, users
will prefer reliable playback.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38403 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Output more information in AVFormatReader::StreamCookie::Open(),
AVInputFormat flags for example.
* Added CODEC_ID_AAC handling when codecTag is 0. Adds support
for AAC in Matroska containers when the ffmpeg plugin is enabled
to handle those.
* Added some rounding to frame<->time conversions.
* AVFormatReader::StreamCookie::Seek() forgot to pass the seek
flags to av_seek_frame().
* The most important fix is this, though: There are formats which
build the keyframe index on the fly, while parsing the stream!!
These means we can only seek to real keyframes for parts of the
stream that has already been decoded. Handle this situation by
assuming we can seek to the requested frame/time. This change
fixes the use of the AVFormatReader as MP3 reader.
* Anothe important fix is to ignore the nb_frames member of the
stream for the total frame count. This makes MP4 movies
also work perfectly now when the AVFormatReader is used for them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38401 a95241bf-73f2-0310-859d-f6bbb57e9c96
gives the deprecated warning... We need to cache an AVPacket for this.
* Check the allocation of fOutputBuffer.
* When seeking, we need to flush the already decoded stuff
in fOutputBuffer, and throw away the last chunk buffer as well.
* Handle an incomplete input format at least to the point of not
crashing with a divide error (mp3_reader would give us such an
incomplete format for example).
* _DecodeAudio():
- Fixed some edge cases in the audio decoding loop: avcodec_decode_audio3()
can return a 0 length, which means no error, but no decoded frames
either. ffplay throws away the chunk in this case, do the same.
- Convert some invalid situations that were printf()s into debugger()s.
- Add much more comments to explain how everything works.
* Fixed the occasional coding style issue.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38400 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When writing encoded audio, we were leaking one
temporary buffer per chunk.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38388 a95241bf-73f2-0310-859d-f6bbb57e9c96
First B_MEDIA_SEEK_TO_FRAME was handled to compute a time, then
it was ignored and frame was used as time stamp. Also the
conversion from frame to time had the num and den members of
the time base swapped in the computation, so it computed
bogus time stamps. Refactored the conversion methods, always
seek based on the time. Needs more testing (perhaps there are rounding
issues), but overriding a lot of native reader implementations with
AVFormatReader holds up very well now with a lot of files I tested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38332 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Not plugged anywhere yet.
* I'm not sure the downsampling is done properly, either.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38037 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Set the AVContext->frame_size, though I don't think it has any effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37707 a95241bf-73f2-0310-859d-f6bbb57e9c96
