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.

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.

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