2010-01-30 17:57:40 +01:00
|
|
|
/*
|
2015-04-13 09:36:54 +02:00
|
|
|
* This file is part of mpv.
|
2010-01-30 17:57:40 +01:00
|
|
|
*
|
vd, vd_lavc: change license to LGPL (almost)
iive agreed only to LGPL 3.0+ only. All of his relevant changes are for
XvMC, for which mpv completely dropped support back in mplayer2 times.
But you could claim that the get_format code represents some residual
copyright (everything else added by iive was removed, only get_format
still is around in some form). While I doubt that this is relly
copyright-relevant, consider it is for now.
michael is the original author of vd_lavc.c, so this file can become
LGPL only after the core becomes LGPL.
cehoyos did not agree with the LGPL relicensing, but all of his code is
gone.
Some others could not be reached, but their code is gone as well. In
particular, vdpau support, which was originally done by Nvidia, had
larger impact on vd_lavc.c, but vdpau support was first refactored a few
times (for the purpose of modularization) and moved to different files,
and then decoding was completely moved to libavcodec.
Lastly, assigning the "opaque" field was moved by Gwenole Beauchesne in
commit 8e5edec13eab. Agreement is pending (due to copyright apparently
owned by the author's employer). So just undo the change, so we don't
have to think about whether the change is copyrightable.
2017-06-15 15:52:18 +02:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2010-01-30 17:57:40 +01:00
|
|
|
*
|
2015-04-13 09:36:54 +02:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2010-01-30 17:57:40 +01:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
vd, vd_lavc: change license to LGPL (almost)
iive agreed only to LGPL 3.0+ only. All of his relevant changes are for
XvMC, for which mpv completely dropped support back in mplayer2 times.
But you could claim that the get_format code represents some residual
copyright (everything else added by iive was removed, only get_format
still is around in some form). While I doubt that this is relly
copyright-relevant, consider it is for now.
michael is the original author of vd_lavc.c, so this file can become
LGPL only after the core becomes LGPL.
cehoyos did not agree with the LGPL relicensing, but all of his code is
gone.
Some others could not be reached, but their code is gone as well. In
particular, vdpau support, which was originally done by Nvidia, had
larger impact on vd_lavc.c, but vdpau support was first refactored a few
times (for the purpose of modularization) and moved to different files,
and then decoding was completely moved to libavcodec.
Lastly, assigning the "opaque" field was moved by Gwenole Beauchesne in
commit 8e5edec13eab. Agreement is pending (due to copyright apparently
owned by the author's employer). So just undo the change, so we don't
have to think about whether the change is copyrightable.
2017-06-15 15:52:18 +02:00
|
|
|
* GNU Lesser General Public License for more details.
|
2010-01-30 17:57:40 +01:00
|
|
|
*
|
vd, vd_lavc: change license to LGPL (almost)
iive agreed only to LGPL 3.0+ only. All of his relevant changes are for
XvMC, for which mpv completely dropped support back in mplayer2 times.
But you could claim that the get_format code represents some residual
copyright (everything else added by iive was removed, only get_format
still is around in some form). While I doubt that this is relly
copyright-relevant, consider it is for now.
michael is the original author of vd_lavc.c, so this file can become
LGPL only after the core becomes LGPL.
cehoyos did not agree with the LGPL relicensing, but all of his code is
gone.
Some others could not be reached, but their code is gone as well. In
particular, vdpau support, which was originally done by Nvidia, had
larger impact on vd_lavc.c, but vdpau support was first refactored a few
times (for the purpose of modularization) and moved to different files,
and then decoding was completely moved to libavcodec.
Lastly, assigning the "opaque" field was moved by Gwenole Beauchesne in
commit 8e5edec13eab. Agreement is pending (due to copyright apparently
owned by the author's employer). So just undo the change, so we don't
have to think about whether the change is copyrightable.
2017-06-15 15:52:18 +02:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2010-01-30 17:57:40 +01:00
|
|
|
*/
|
|
|
|
|
2008-02-22 10:09:46 +01:00
|
|
|
#ifndef MPLAYER_VD_H
|
|
|
|
#define MPLAYER_VD_H
|
2002-03-25 03:39:36 +01:00
|
|
|
|
2012-11-09 01:06:43 +01:00
|
|
|
#include "video/mp_image.h"
|
|
|
|
#include "demux/stheader.h"
|
2013-11-23 21:36:20 +01:00
|
|
|
#include "dec_video.h"
|
2008-03-06 09:34:50 +01:00
|
|
|
|
2011-08-20 19:25:43 +02:00
|
|
|
struct demux_packet;
|
core: redo how codecs are mapped, remove codecs.conf
Use codec names instead of FourCCs to identify codecs. Rewrite how
codecs are selected and initialized. Now each decoder exports a list
of decoders (and the codec it supports) via add_decoders(). The order
matters, and the first decoder for a given decoder is preferred over
the other decoders. E.g. all ad_mpg123 decoders are preferred over
ad_lavc, because it comes first in the mpcodecs_ad_drivers array.
Likewise, decoders within ad_lavc that are enumerated first by
libavcodec (using av_codec_next()) are preferred. (This is actually
critical to select h264 software decoding by default instead of vdpau.
libavcodec and ffmpeg/avconv use the same method to select decoders by
default, so we hope this is sane.)
The codec names follow libavcodec's codec names as defined by
AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders
have names different from the canonical codec name. The AVCodecDescriptor
API is relatively new, so we need a compatibility layer for older
libavcodec versions for codec names that are referenced internally,
and which are different from the decoder name. (Add a configure check
for that, because checking versions is getting way too messy.)
demux/codec_tags.c is generated from the former codecs.conf (minus
"special" decoders like vdpau, and excluding the mappings that are the
same as the mappings libavformat's exported RIFF tables). It contains
all the mappings from FourCCs to codec name. This is needed for
demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the
codec as determined by libavformat, while the other demuxers have to do
this on their own, using the mp_set_audio/video_codec_from_tag()
functions. Note that the sh_audio/video->format members don't uniquely
identify the codec anymore, and sh->codec takes over this role.
Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which
provide cover the functionality of the removed switched.
Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure
container/video combinations (e.g. the sample Film_200_zygo_pro.mov)
are played flipped. ffplay/avplay doesn't handle this properly either,
so we don't care and blame ffmeg/libav instead.
2013-02-09 15:15:19 +01:00
|
|
|
struct mp_decoder_list;
|
2011-08-20 19:25:43 +02:00
|
|
|
|
2002-03-07 22:12:27 +01:00
|
|
|
/* interface of video decoder drivers */
|
2008-04-24 04:49:44 +02:00
|
|
|
typedef struct vd_functions
|
2002-02-28 01:57:30 +01:00
|
|
|
{
|
core: redo how codecs are mapped, remove codecs.conf
Use codec names instead of FourCCs to identify codecs. Rewrite how
codecs are selected and initialized. Now each decoder exports a list
of decoders (and the codec it supports) via add_decoders(). The order
matters, and the first decoder for a given decoder is preferred over
the other decoders. E.g. all ad_mpg123 decoders are preferred over
ad_lavc, because it comes first in the mpcodecs_ad_drivers array.
Likewise, decoders within ad_lavc that are enumerated first by
libavcodec (using av_codec_next()) are preferred. (This is actually
critical to select h264 software decoding by default instead of vdpau.
libavcodec and ffmpeg/avconv use the same method to select decoders by
default, so we hope this is sane.)
The codec names follow libavcodec's codec names as defined by
AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders
have names different from the canonical codec name. The AVCodecDescriptor
API is relatively new, so we need a compatibility layer for older
libavcodec versions for codec names that are referenced internally,
and which are different from the decoder name. (Add a configure check
for that, because checking versions is getting way too messy.)
demux/codec_tags.c is generated from the former codecs.conf (minus
"special" decoders like vdpau, and excluding the mappings that are the
same as the mappings libavformat's exported RIFF tables). It contains
all the mappings from FourCCs to codec name. This is needed for
demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the
codec as determined by libavformat, while the other demuxers have to do
this on their own, using the mp_set_audio/video_codec_from_tag()
functions. Note that the sh_audio/video->format members don't uniquely
identify the codec anymore, and sh->codec takes over this role.
Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which
provide cover the functionality of the removed switched.
Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure
container/video combinations (e.g. the sample Film_200_zygo_pro.mov)
are played flipped. ffplay/avplay doesn't handle this properly either,
so we don't care and blame ffmeg/libav instead.
2013-02-09 15:15:19 +01:00
|
|
|
const char *name;
|
|
|
|
void (*add_decoders)(struct mp_decoder_list *list);
|
2013-11-23 21:36:20 +01:00
|
|
|
int (*init)(struct dec_video *vd, const char *decoder);
|
|
|
|
void (*uninit)(struct dec_video *vd);
|
|
|
|
int (*control)(struct dec_video *vd, int cmd, void *arg);
|
2017-01-10 16:19:57 +01:00
|
|
|
// Return whether or not the packet has been consumed.
|
|
|
|
bool (*send_packet)(struct dec_video *vd, struct demux_packet *pkt);
|
2017-01-11 10:56:25 +01:00
|
|
|
// Return whether decoding is still going on (false if EOF was reached).
|
|
|
|
// Never returns false & *out_image set, but can return true with no image.
|
|
|
|
bool (*receive_frame)(struct dec_video *vd, struct mp_image **out_image);
|
2002-02-28 01:57:30 +01:00
|
|
|
} vd_functions_t;
|
|
|
|
|
|
|
|
// NULL terminated array of all drivers
|
2011-11-03 14:21:53 +01:00
|
|
|
extern const vd_functions_t *const mpcodecs_vd_drivers[];
|
2002-02-28 01:57:30 +01:00
|
|
|
|
2013-10-02 21:19:16 +02:00
|
|
|
enum vd_ctrl {
|
2013-12-10 19:07:29 +01:00
|
|
|
VDCTRL_RESET = 1, // reset decode state after seeking
|
|
|
|
VDCTRL_FORCE_HWDEC_FALLBACK, // force software decoding fallback
|
2014-04-23 01:17:28 +02:00
|
|
|
VDCTRL_GET_HWDEC,
|
2016-01-29 22:47:27 +01:00
|
|
|
VDCTRL_REINIT,
|
video: approximate AVI timestamps via DTS handling
Until now (and in mplayer traditionally), avi timestamps were handled
with a timestamp FIFO. AVI timestamps are essentially just strictly
increasing frame numbers and are not reordered like normal timestamps.
Limiting the FIFO is required because frames can be dropped. To make
it worse, frame dropping can't be distinguished from the decoder not
returning output due to increasing the buffering required for B-frames.
("Measuring" the buffering at playback start seems like an interesting
idea, but won't work as the buffering could be increased mid-playback.)
Another problem are skipped frames (packets with data, but which do
not contain a video frame).
Besides dropped and skipped frames, there is the problem that we can't
always know the delay. External decoders like MMAL are not going to
tell us. (And later perhaps others, like direct VideoToolbox usage.)
In general, this works not-well enough that I prefer the solution of
passing through AVI timestamps as DTS. This is slightly incorrect,
because most decoders treat DTS as mpeg-style timestamps, which
already include a b-frame delay, and thus will be shifted by a few
frames. This means there will be a problem with A/V sync in some
situations.
Note that the FFmpeg AVI demuxer shifts timestamps by an additional
amount (which increases after the first seek!?!?), which makes the
situation worse. It works well with VfW-muxed Matroska files, though.
On RPI, the first X timestamps are broken until the MMAL decoder "locks
on".
2016-02-11 16:01:11 +01:00
|
|
|
VDCTRL_GET_BFRAMES,
|
2017-01-10 16:19:57 +01:00
|
|
|
// framedrop mode: 0=none, 1=standard, 2=hrseek
|
|
|
|
VDCTRL_SET_FRAMEDROP,
|
2013-10-02 21:19:16 +02:00
|
|
|
};
|
2002-02-28 01:57:30 +01:00
|
|
|
|
2008-02-22 10:09:46 +01:00
|
|
|
#endif /* MPLAYER_VD_H */
|