Revert the Codec Kit.

All of Barrett's individual reverts have been squashed into this
one commit, save a few actual bugfixes.

Change-Id: Ib0a7d0a841d3ac40b1fca7372c58b7f9229bd1f0

Codec Kit: Introduce BCodecKit namespace

ffmpeg: Update class names

Codec Kit: Rename files

ffmpeg: Use new BMetaData API

FFMPEG Copyright(): Fix memory leak

Fix a memory leak I introduced. Followed Stippi's suggestion. Thanks!

Rewrote finding keyframes and seeking. The problem was that
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

* Theoretically implemented seeking by bytes,
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

White space cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36845 a95241bf-73f2-0310-859d-f6bbb57e9c96

Get the AVFormatReader into a usable state. DemuxerTable.cpp controls which
container formats we support. I hope I have turned on only those that don't
have an implementation already (did we support ASF already?). I mostly tested
with AVI and that works reasonably well, but I only tested raw audio so far.
However, the backend for Marcus' avi_reader is much nicer than FFmpeg, so I
think it should stay and have disabled the support for AVI in AVFormatReader.
A big disappointment is that MPG containers only give scrambled video. It may
be a problem of the AVCodecDecoder, but I am not so sure. After all, it works
fine for other container formats. If I am not mistaken, VLC also does not use
the mpeg demuxer from FFmpeg. :-\ On top of that, libavformat detects the
time_base and stream duration wrongly for one of my test MPGs.
As for the implementation: Although seeking in libavformat happens for an
individual stream, in reality, the packets for all other streams need to be
flushed (that's also what happens in the libavformat tutorials I've seen).
Since our MediaKit API allows to seek tracks indivually, this is of course
a no-go, since then all other tracks would be out of sync. My solution is to
simply open the demuxer once for each stream and then completely ignore the
packets of the respective other streams. This also works around the problem
that libavformat is unable to provide packets by stream, requiring the
API user to queue the packets that he needs not now, but later for other
streams. It also means we have to no memory copies, since we can directly
use the packet buffer until the next call to GetNextChunk().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31421 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Fleshed out some more of the format detection.
* Moved stuff from testing in Sniff() into class members.
* Added function to gfx_utils() that converts an FFmpeg pix_fmt to color_space.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31402 a95241bf-73f2-0310-859d-f6bbb57e9c96

* It actually helps a lot to turn on all the demuxers if you want to use any.
* The URLProtocol idea seems not to work out, so I removed that code, but
the other idea of setting up a ByteIOContext actually works, once I seek
back to the beginning of the stream after reading the initial probe buffer,
we may also offset the buffer pointer in the ByteIOContext to where we
have already read, but I am not sure of possible side effects of that.

We can now probe for the correct demuxer and detect streams.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31379 a95241bf-73f2-0310-859d-f6bbb57e9c96

Work in Progress of trying to get libavformat to detect anything...
unsuccessful so far.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31369 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed avcodec folder to ffmpeg.
* Cleaned up plugins Jamfile.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31359 a95241bf-73f2-0310-859d-f6bbb57e9c96

FFMPEG Copyright(): Fix memory leak

Fix a memory leak I introduced. Followed Stippi's suggestion. Thanks!

Rewrote finding keyframes and seeking. The problem was that
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

* Theoretically implemented seeking by bytes,
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

White space cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36845 a95241bf-73f2-0310-859d-f6bbb57e9c96

Get the AVFormatReader into a usable state. DemuxerTable.cpp controls which
container formats we support. I hope I have turned on only those that don't
have an implementation already (did we support ASF already?). I mostly tested
with AVI and that works reasonably well, but I only tested raw audio so far.
However, the backend for Marcus' avi_reader is much nicer than FFmpeg, so I
think it should stay and have disabled the support for AVI in AVFormatReader.
A big disappointment is that MPG containers only give scrambled video. It may
be a problem of the AVCodecDecoder, but I am not so sure. After all, it works
fine for other container formats. If I am not mistaken, VLC also does not use
the mpeg demuxer from FFmpeg. :-\ On top of that, libavformat detects the
time_base and stream duration wrongly for one of my test MPGs.
As for the implementation: Although seeking in libavformat happens for an
individual stream, in reality, the packets for all other streams need to be
flushed (that's also what happens in the libavformat tutorials I've seen).
Since our MediaKit API allows to seek tracks indivually, this is of course
a no-go, since then all other tracks would be out of sync. My solution is to
simply open the demuxer once for each stream and then completely ignore the
packets of the respective other streams. This also works around the problem
that libavformat is unable to provide packets by stream, requiring the
API user to queue the packets that he needs not now, but later for other
streams. It also means we have to no memory copies, since we can directly
use the packet buffer until the next call to GetNextChunk().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31421 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Fleshed out some more of the format detection.
* Moved stuff from testing in Sniff() into class members.
* Added function to gfx_utils() that converts an FFmpeg pix_fmt to color_space.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31402 a95241bf-73f2-0310-859d-f6bbb57e9c96

* It actually helps a lot to turn on all the demuxers if you want to use any.
* The URLProtocol idea seems not to work out, so I removed that code, but
the other idea of setting up a ByteIOContext actually works, once I seek
back to the beginning of the stream after reading the initial probe buffer,
we may also offset the buffer pointer in the ByteIOContext to where we
have already read, but I am not sure of possible side effects of that.

We can now probe for the correct demuxer and detect streams.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31379 a95241bf-73f2-0310-859d-f6bbb57e9c96

Work in Progress of trying to get libavformat to detect anything...
unsuccessful so far.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31369 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed avcodec folder to ffmpeg.
* Cleaned up plugins Jamfile.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31359 a95241bf-73f2-0310-859d-f6bbb57e9c96