ffmpeg: enable Werror and fix all warnings

Warnings fixed include usage of various deprecated functions, structures
and fields of ffmpeg.

Change-Id: I8d6338ad282f214a805b8d746ce22e2f0895fb25
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5954
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

ffmpeg: delete dead code

ffmpeg: Remove obsolete code

ffmpeg: update build with version 3.0.

* untested.

ffmpeg: check against correct version constants.

54.23.x is ffmpeg 0.11, which still has "CodecID" (and x>0).

ffmpeg: detect the library version the right way.

* Fixes the build by detecting the library version using the provided
constants, instead of guessing from the compiler version.

ffmpeg plugin: remove more deprecated functions.

These were all deprecated between releases 0.6 and 0.10 of ffmpeg,
except for one change (renaming of CodecID to AVCodecID) which we can
work around with a typedef. The deprecated functions were still
available in 0.11, but were removed later on after several years of
deprecation.

This makes it possible to build our plugin with any ffmpeg version
between 0.10 and 2.7, so we can now experiment with updating to 2.7 at
least for the gcc4 builds.

FFMpeg plugin: now build against the optional package for 0.10

* added optional feature package for ffmpeg 0.10 gcc4 and gcc2
* increased probe buffer size to 8K for now.
* built the optional packages the default way, it might need adjustments
like dependencies on speex, ogg, theora, vorbis, which I left out for now.

Add a function to register media codec descriptions for the usual format families using the tag lists from libavformat itself. Untested. the plugin will also have to use av_codec_get_id() to get the codec ID from the tag.


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

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

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

With many AC3 streams in AVIs I have, the FFmpeg AC3 codec
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

* Initialize the channel mask of the media_format.
* 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

* 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

Patch by Adek336: Support one more H264 fourcc in B_QUICKTIME_FORMAT_FAMILY.
Allows playback of H264 content in Flash container (probably among others).
Thanks! Closes #6372.


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

Patch by herdemir: Fix codec table to include correct fourcc for H.264 video
streams in AVI files. Could confirm this with a test video. Thanks and sorry
for the delay!


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

We should only swap the FOURCCs on little endian machines.


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

register another xvid fourcc

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

This restores playback of AVC-HD videos from my video camera. The reported
codec tags in FFmpeg have changed. However, with the FFmpeg AC-3 decoder, I
am no longer getting sound. I suspect it's something to do with the channel
count.

P.S. I should really fix the endianess mess of the codec tags...


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

Do not leak the first StreamCookie that we used in Sniff() and do not free
in FreeCookie().


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

Support MP2 audio also in MPEG containers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31420 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: check against correct version constants.

54.23.x is ffmpeg 0.11, which still has "CodecID" (and x>0).

ffmpeg: detect the library version the right way.

* Fixes the build by detecting the library version using the provided
constants, instead of guessing from the compiler version.

ffmpeg plugin: remove more deprecated functions.

These were all deprecated between releases 0.6 and 0.10 of ffmpeg,
except for one change (renaming of CodecID to AVCodecID) which we can
work around with a typedef. The deprecated functions were still
available in 0.11, but were removed later on after several years of
deprecation.

This makes it possible to build our plugin with any ffmpeg version
between 0.10 and 2.7, so we can now experiment with updating to 2.7 at
least for the gcc4 builds.

FFMpeg plugin: now build against the optional package for 0.10

* added optional feature package for ffmpeg 0.10 gcc4 and gcc2
* increased probe buffer size to 8K for now.
* built the optional packages the default way, it might need adjustments
like dependencies on speex, ogg, theora, vorbis, which I left out for now.

Add a function to register media codec descriptions for the usual format families using the tag lists from libavformat itself. Untested. the plugin will also have to use av_codec_get_id() to get the codec ID from the tag.


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

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

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

With many AC3 streams in AVIs I have, the FFmpeg AC3 codec
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

* Initialize the channel mask of the media_format.
* 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

* 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

Patch by Adek336: Support one more H264 fourcc in B_QUICKTIME_FORMAT_FAMILY.
Allows playback of H264 content in Flash container (probably among others).
Thanks! Closes #6372.


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

Patch by herdemir: Fix codec table to include correct fourcc for H.264 video
streams in AVI files. Could confirm this with a test video. Thanks and sorry
for the delay!


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

We should only swap the FOURCCs on little endian machines.


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

register another xvid fourcc

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

This restores playback of AVC-HD videos from my video camera. The reported
codec tags in FFmpeg have changed. However, with the FFmpeg AC-3 decoder, I
am no longer getting sound. I suspect it's something to do with the channel
count.

P.S. I should really fix the endianess mess of the codec tags...


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

Do not leak the first StreamCookie that we used in Sniff() and do not free
in FreeCookie().


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

Support MP2 audio also in MPEG containers.


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