ffmpeg: missing const

Change-Id: Id0121958533afde8b226c5e8f6591356d59e3a9e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7250
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

ffmpeg media plugin: merge muxer and demuxer tables

* The media_file_format struct has B_READABLE and B_WRITABLE flags,
allowing us to tell which formats we support decoding and encoding
* This allows application to query for the supported decoding formats.
* Also adjust some of the MIME types to match what's actually used (eg.
in HTML5 audio).

This makes html5test.com detect which formats we declare we can decode.

Enabled any and all decoders and demuxers which are currently compiled into
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

* Changed pretty extractor names to sentence casing.
* 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

Committed more than I intended to in the last commit. Sorry.


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

* Use the same GCC flags for GCC4 that configure in the FFmpeg source
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

Removed the "native" ogg, vorbis, theora and speex plugins in favor
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

Switched support for AVI files from native Reader to
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

Remove the Matroska reader from the image and enable
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

* Enabled the mp2/mp3 decoder in the ffmpeg plug-in (CodecTable.h).
* 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

Added some more defines for demuxers that could in theory be enabled. But we
have native implementations.


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

Updated comment.


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

* synced with ffmpeg-r19678, keeping gcc2 compiler #ifdef we introduced, build only tested on Haiku gcc2
* activated ac3 audio file format support
* uses format metadata to keep the codec context extra data (now needed for flac)


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

* Added support for Flash Video (VP6F video and MP3 audio tested only).
* Seeking does not work, since the duration extraction from libavformat does
not work for this container (maybe there are ways/workarounds but I didn't
look into it).
* Automatic white space cleanup.

TODO: Add MIME type with sniffer rule.


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

added flac to the codec table and the demuxer table.
audio format is now taken into account by the decoder when negociating the media output format.


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

added raw dv format support. tested with PAL DV, I don't know for NTSC though


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

Added "mpegts" to the supported demuxers.


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

Doh, of course we had ASF before! Sorry about that. Must have been blind.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31424 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

ffmpeg media plugin: merge muxer and demuxer tables

* The media_file_format struct has B_READABLE and B_WRITABLE flags,
allowing us to tell which formats we support decoding and encoding
* This allows application to query for the supported decoding formats.
* Also adjust some of the MIME types to match what's actually used (eg.
in HTML5 audio).

This makes html5test.com detect which formats we declare we can decode.

Enabled any and all decoders and demuxers which are currently compiled into
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

* Changed pretty extractor names to sentence casing.
* 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

Committed more than I intended to in the last commit. Sorry.


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

* Use the same GCC flags for GCC4 that configure in the FFmpeg source
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

Removed the "native" ogg, vorbis, theora and speex plugins in favor
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

Switched support for AVI files from native Reader to
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

Remove the Matroska reader from the image and enable
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

* Enabled the mp2/mp3 decoder in the ffmpeg plug-in (CodecTable.h).
* 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

Added some more defines for demuxers that could in theory be enabled. But we
have native implementations.


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

Updated comment.


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

* synced with ffmpeg-r19678, keeping gcc2 compiler #ifdef we introduced, build only tested on Haiku gcc2
* activated ac3 audio file format support
* uses format metadata to keep the codec context extra data (now needed for flac)


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

* Added support for Flash Video (VP6F video and MP3 audio tested only).
* Seeking does not work, since the duration extraction from libavformat does
not work for this container (maybe there are ways/workarounds but I didn't
look into it).
* Automatic white space cleanup.

TODO: Add MIME type with sniffer rule.


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

added flac to the codec table and the demuxer table.
audio format is now taken into account by the decoder when negociating the media output format.


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

added raw dv format support. tested with PAL DV, I don't know for NTSC though


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

Added "mpegts" to the supported demuxers.


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

Doh, of course we had ASF before! Sorry about that. Must have been blind.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31424 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