2010-01-30 16:57:40 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2010-01-30 16:57:40 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or modify
|
2010-01-30 16:57:40 +00:00
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2010-01-30 16:57:40 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2015-04-13 07:36:54 +00:00
|
|
|
* with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2010-01-30 16:57:40 +00:00
|
|
|
*/
|
2002-03-01 00:25:43 +00:00
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
2008-12-01 17:53:57 +00:00
|
|
|
#include <stdbool.h>
|
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 14:15:19 +00:00
|
|
|
#include <assert.h>
|
|
|
|
|
2015-12-19 19:04:31 +00:00
|
|
|
#include <libavutil/rational.h>
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
#include "options/options.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/msg.h"
|
2002-03-01 00:25:43 +00:00
|
|
|
|
2003-02-09 20:18:23 +00:00
|
|
|
#include "osdep/timer.h"
|
2002-03-01 00:25:43 +00:00
|
|
|
|
2007-03-15 17:10:36 +00:00
|
|
|
#include "stream/stream.h"
|
2016-01-16 20:19:52 +00:00
|
|
|
#include "demux/demux.h"
|
2013-11-18 17:46:44 +00:00
|
|
|
#include "demux/packet.h"
|
2002-03-01 00:25:43 +00:00
|
|
|
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/codecs.h"
|
2002-03-01 00:25:43 +00:00
|
|
|
|
2012-11-09 00:06:43 +00:00
|
|
|
#include "video/out/vo.h"
|
|
|
|
#include "video/csputils.h"
|
2002-03-01 00:25:43 +00:00
|
|
|
|
2012-11-09 00:06:43 +00:00
|
|
|
#include "demux/stheader.h"
|
|
|
|
#include "video/decode/vd.h"
|
2002-03-01 00:25:43 +00:00
|
|
|
|
2012-11-09 00:06:43 +00:00
|
|
|
#include "video/decode/dec_video.h"
|
2002-03-01 00:25:43 +00:00
|
|
|
|
2013-11-23 20:28:28 +00:00
|
|
|
extern const vd_functions_t mpcodecs_vd_ffmpeg;
|
|
|
|
|
|
|
|
/* Please do not add any new decoders here. If you want to implement a new
|
|
|
|
* decoder, add it to libavcodec, except for wrappers around external
|
|
|
|
* libraries and decoders requiring binary support. */
|
|
|
|
|
|
|
|
const vd_functions_t * const mpcodecs_vd_drivers[] = {
|
|
|
|
&mpcodecs_vd_ffmpeg,
|
|
|
|
/* Please do not add any new decoders here. If you want to implement a new
|
|
|
|
* decoder, add it to libavcodec, except for wrappers around external
|
|
|
|
* libraries and decoders requiring binary support. */
|
|
|
|
NULL
|
|
|
|
};
|
2002-03-01 00:25:43 +00:00
|
|
|
|
2016-01-16 20:19:52 +00:00
|
|
|
void video_reset(struct dec_video *d_video)
|
2013-11-27 19:54:07 +00:00
|
|
|
{
|
|
|
|
video_vd_control(d_video, VDCTRL_RESET, NULL);
|
2015-10-06 16:13:23 +00:00
|
|
|
d_video->first_packet_pdts = MP_NOPTS_VALUE;
|
2016-01-16 20:19:52 +00:00
|
|
|
d_video->start_pts = MP_NOPTS_VALUE;
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
d_video->decoded_pts = MP_NOPTS_VALUE;
|
|
|
|
d_video->codec_pts = MP_NOPTS_VALUE;
|
|
|
|
d_video->codec_dts = MP_NOPTS_VALUE;
|
2016-11-09 16:51:19 +00:00
|
|
|
d_video->has_broken_decoded_pts = 0;
|
2016-01-13 23:18:31 +00:00
|
|
|
d_video->last_format = d_video->fixed_format = (struct mp_image_params){0};
|
2016-01-16 20:19:52 +00:00
|
|
|
d_video->dropped_frames = 0;
|
2016-02-01 20:32:01 +00:00
|
|
|
d_video->current_state = DATA_AGAIN;
|
2016-01-16 20:19:52 +00:00
|
|
|
mp_image_unrefp(&d_video->current_mpi);
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
talloc_free(d_video->packet);
|
|
|
|
d_video->packet = NULL;
|
|
|
|
talloc_free(d_video->new_segment);
|
|
|
|
d_video->new_segment = NULL;
|
|
|
|
d_video->start = d_video->end = MP_NOPTS_VALUE;
|
2013-11-27 19:54:07 +00:00
|
|
|
}
|
|
|
|
|
2013-11-23 20:36:20 +00:00
|
|
|
int video_vd_control(struct dec_video *d_video, int cmd, void *arg)
|
2013-07-14 22:52:17 +00:00
|
|
|
{
|
2013-11-23 20:36:20 +00:00
|
|
|
const struct vd_functions *vd = d_video->vd_driver;
|
2013-07-14 22:52:17 +00:00
|
|
|
if (vd)
|
2013-11-23 20:36:20 +00:00
|
|
|
return vd->control(d_video, cmd, arg);
|
2013-07-14 22:52:17 +00:00
|
|
|
return CONTROL_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
2013-11-23 20:36:20 +00:00
|
|
|
void video_uninit(struct dec_video *d_video)
|
2006-07-06 06:58:17 +00:00
|
|
|
{
|
2016-02-09 23:07:01 +00:00
|
|
|
if (!d_video)
|
|
|
|
return;
|
2016-01-16 20:19:52 +00:00
|
|
|
mp_image_unrefp(&d_video->current_mpi);
|
2013-11-23 20:38:39 +00:00
|
|
|
if (d_video->vd_driver) {
|
2013-12-21 16:47:38 +00:00
|
|
|
MP_VERBOSE(d_video, "Uninit video.\n");
|
2013-11-23 20:36:20 +00:00
|
|
|
d_video->vd_driver->uninit(d_video);
|
|
|
|
}
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
talloc_free(d_video->packet);
|
|
|
|
talloc_free(d_video->new_segment);
|
2013-11-23 20:36:20 +00:00
|
|
|
talloc_free(d_video);
|
2002-03-01 00:25:43 +00:00
|
|
|
}
|
|
|
|
|
2013-11-23 20:36:20 +00:00
|
|
|
static int init_video_codec(struct dec_video *d_video, const char *decoder)
|
2008-04-24 02:23:45 +00:00
|
|
|
{
|
2013-11-23 20:36:20 +00:00
|
|
|
if (!d_video->vd_driver->init(d_video, decoder)) {
|
2013-12-21 16:47:38 +00:00
|
|
|
MP_VERBOSE(d_video, "Video decoder init failed.\n");
|
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 14:15:19 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
2002-08-31 13:09:23 +00:00
|
|
|
}
|
|
|
|
|
2013-11-23 20:36:20 +00:00
|
|
|
struct mp_decoder_list *video_decoder_list(void)
|
2008-04-24 02:23:45 +00: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 14:15:19 +00:00
|
|
|
struct mp_decoder_list *list = talloc_zero(NULL, struct mp_decoder_list);
|
|
|
|
for (int i = 0; mpcodecs_vd_drivers[i] != NULL; i++)
|
|
|
|
mpcodecs_vd_drivers[i]->add_decoders(list);
|
|
|
|
return list;
|
|
|
|
}
|
2002-05-29 22:39:25 +00:00
|
|
|
|
2016-12-23 17:12:29 +00:00
|
|
|
static struct mp_decoder_list *mp_select_video_decoders(struct mp_log *log,
|
|
|
|
const char *codec,
|
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 14:15:19 +00:00
|
|
|
char *selection)
|
|
|
|
{
|
2013-11-23 20:36:20 +00:00
|
|
|
struct mp_decoder_list *list = video_decoder_list();
|
2016-12-23 17:12:29 +00:00
|
|
|
struct mp_decoder_list *new = mp_select_decoders(log, list, codec, selection);
|
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 14:15:19 +00:00
|
|
|
talloc_free(list);
|
|
|
|
return new;
|
|
|
|
}
|
2008-04-24 03:41:12 +00: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 14:15:19 +00:00
|
|
|
static const struct vd_functions *find_driver(const char *name)
|
|
|
|
{
|
|
|
|
for (int i = 0; mpcodecs_vd_drivers[i] != NULL; i++) {
|
|
|
|
if (strcmp(mpcodecs_vd_drivers[i]->name, name) == 0)
|
|
|
|
return mpcodecs_vd_drivers[i];
|
2002-03-01 00:26:10 +00: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 14:15:19 +00:00
|
|
|
return NULL;
|
2002-03-01 00:25:43 +00:00
|
|
|
}
|
|
|
|
|
2016-02-15 19:28:36 +00:00
|
|
|
bool video_init_best_codec(struct dec_video *d_video)
|
2008-04-24 02:23:45 +00:00
|
|
|
{
|
2016-02-15 19:28:36 +00:00
|
|
|
struct MPOpts *opts = d_video->opts;
|
|
|
|
|
2013-11-23 20:38:39 +00:00
|
|
|
assert(!d_video->vd_driver);
|
2016-01-16 20:19:52 +00:00
|
|
|
video_reset(d_video);
|
2013-11-28 12:34:56 +00:00
|
|
|
d_video->has_broken_packet_pts = -10; // needs 10 packets to reach decision
|
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 14:15:19 +00:00
|
|
|
|
|
|
|
struct mp_decoder_entry *decoder = NULL;
|
2016-12-23 17:12:29 +00:00
|
|
|
struct mp_decoder_list *list = mp_select_video_decoders(d_video->log,
|
|
|
|
d_video->codec->codec,
|
|
|
|
opts->video_decoders);
|
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 14:15:19 +00:00
|
|
|
|
2013-12-21 17:46:24 +00:00
|
|
|
mp_print_decoders(d_video->log, MSGL_V, "Codec list:", list);
|
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 14:15:19 +00:00
|
|
|
|
|
|
|
for (int n = 0; n < list->num_entries; n++) {
|
|
|
|
struct mp_decoder_entry *sel = &list->entries[n];
|
|
|
|
const struct vd_functions *driver = find_driver(sel->family);
|
|
|
|
if (!driver)
|
|
|
|
continue;
|
2016-12-23 17:12:29 +00:00
|
|
|
MP_VERBOSE(d_video, "Opening video decoder %s\n", sel->decoder);
|
2013-11-23 20:36:20 +00:00
|
|
|
d_video->vd_driver = driver;
|
|
|
|
if (init_video_codec(d_video, sel->decoder)) {
|
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 14:15:19 +00:00
|
|
|
decoder = sel;
|
|
|
|
break;
|
2008-04-24 02:23:45 +00:00
|
|
|
}
|
2013-11-23 20:36:20 +00:00
|
|
|
d_video->vd_driver = NULL;
|
2016-12-23 17:12:29 +00:00
|
|
|
MP_WARN(d_video, "Video decoder init failed for %s\n", sel->decoder);
|
2002-09-25 23:45:34 +00:00
|
|
|
}
|
|
|
|
|
2013-11-23 20:38:39 +00:00
|
|
|
if (d_video->vd_driver) {
|
2013-11-23 20:36:20 +00:00
|
|
|
d_video->decoder_desc =
|
2016-12-23 17:12:29 +00:00
|
|
|
talloc_asprintf(d_video, "%s (%s)", decoder->decoder, decoder->desc);
|
2014-05-31 20:07:36 +00:00
|
|
|
MP_VERBOSE(d_video, "Selected video codec: %s\n", d_video->decoder_desc);
|
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 14:15:19 +00:00
|
|
|
} else {
|
2013-12-21 16:47:38 +00:00
|
|
|
MP_ERR(d_video, "Failed to initialize a video decoder for codec '%s'.\n",
|
2016-02-15 19:34:45 +00:00
|
|
|
d_video->codec->codec);
|
2008-04-24 02:23:45 +00:00
|
|
|
}
|
2002-09-25 23:45:34 +00:00
|
|
|
|
2015-03-20 21:07:26 +00:00
|
|
|
if (d_video->header->missing_timestamps) {
|
|
|
|
MP_WARN(d_video, "This stream has no timestamps!\n");
|
|
|
|
MP_WARN(d_video, "Making up playback time using %f FPS.\n", d_video->fps);
|
|
|
|
MP_WARN(d_video, "Seeking will probably fail badly.\n");
|
|
|
|
}
|
|
|
|
|
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 14:15:19 +00:00
|
|
|
talloc_free(list);
|
2013-11-23 20:38:39 +00:00
|
|
|
return !!d_video->vd_driver;
|
2002-09-25 23:45:34 +00:00
|
|
|
}
|
|
|
|
|
2016-01-13 23:18:31 +00:00
|
|
|
static void fix_image_params(struct dec_video *d_video,
|
|
|
|
struct mp_image_params *params)
|
|
|
|
{
|
|
|
|
struct MPOpts *opts = d_video->opts;
|
|
|
|
struct mp_image_params p = *params;
|
2016-02-15 19:34:45 +00:00
|
|
|
struct mp_codec_params *c = d_video->codec;
|
2016-01-13 23:18:31 +00:00
|
|
|
|
|
|
|
MP_VERBOSE(d_video, "Decoder format: %s\n", mp_image_params_to_str(params));
|
2016-09-20 13:40:44 +00:00
|
|
|
d_video->dec_format = *params;
|
2016-01-13 23:18:31 +00:00
|
|
|
|
|
|
|
// While mp_image_params normally always have to have d_w/d_h set, the
|
|
|
|
// decoder signals unknown bitstream aspect ratio with both set to 0.
|
|
|
|
float dec_aspect = p.p_w > 0 && p.p_h > 0 ? p.p_w / (float)p.p_h : 0;
|
|
|
|
if (d_video->initial_decoder_aspect == 0)
|
|
|
|
d_video->initial_decoder_aspect = dec_aspect;
|
|
|
|
|
|
|
|
bool use_container = true;
|
|
|
|
switch (opts->aspect_method) {
|
|
|
|
case 0:
|
|
|
|
// We normally prefer the container aspect, unless the decoder aspect
|
|
|
|
// changes at least once.
|
|
|
|
if (dec_aspect > 0 && d_video->initial_decoder_aspect != dec_aspect) {
|
|
|
|
MP_VERBOSE(d_video, "Using bitstream aspect ratio.\n");
|
|
|
|
// Even if the aspect switches back, don't use container aspect again.
|
|
|
|
d_video->initial_decoder_aspect = -1;
|
|
|
|
use_container = false;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
use_container = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (use_container && c->par_w > 0 && c->par_h) {
|
|
|
|
MP_VERBOSE(d_video, "Using container aspect ratio.\n");
|
|
|
|
p.p_w = c->par_w;
|
|
|
|
p.p_h = c->par_h;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (opts->movie_aspect >= 0) {
|
|
|
|
MP_VERBOSE(d_video, "Forcing user-set aspect ratio.\n");
|
|
|
|
if (opts->movie_aspect == 0) {
|
|
|
|
p.p_w = p.p_h = 1;
|
|
|
|
} else {
|
|
|
|
AVRational a = av_d2q(opts->movie_aspect, INT_MAX);
|
|
|
|
mp_image_params_set_dsize(&p, a.num, a.den);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Assume square pixels if no aspect ratio is set at all.
|
|
|
|
if (p.p_w <= 0 || p.p_h <= 0)
|
|
|
|
p.p_w = p.p_h = 1;
|
|
|
|
|
2016-09-20 13:38:19 +00:00
|
|
|
if (opts->video_rotate < 0) {
|
|
|
|
p.rotate = 0;
|
|
|
|
} else {
|
|
|
|
p.rotate = (p.rotate + opts->video_rotate) % 360;
|
|
|
|
}
|
|
|
|
p.stereo_out = opts->video_stereo_mode;
|
|
|
|
|
2016-01-13 23:18:31 +00:00
|
|
|
// Detect colorspace from resolution.
|
2016-11-08 16:53:55 +00:00
|
|
|
mp_colorspace_merge(&p.color, &c->color);
|
2016-01-13 23:18:31 +00:00
|
|
|
mp_image_params_guess_csp(&p);
|
|
|
|
|
|
|
|
d_video->last_format = *params;
|
|
|
|
d_video->fixed_format = p;
|
|
|
|
}
|
|
|
|
|
2016-01-16 20:19:52 +00:00
|
|
|
static struct mp_image *decode_packet(struct dec_video *d_video,
|
|
|
|
struct demux_packet *packet,
|
|
|
|
int drop_frame)
|
2007-03-11 17:30:43 +00:00
|
|
|
{
|
2013-11-23 20:36:20 +00:00
|
|
|
struct MPOpts *opts = d_video->opts;
|
video: better handling for (very) broken timestamps
Sometimes, Matroska files store monotonic PTS for h264 tracks with
b-frames, which means the decoder actually returns non-monotonic PTS.
Handle this with an evil trick: if DTS is missing, set it to the PTS.
Then the existing logic, which deals with falling back to DTS if PTS is
broken. Actually, this trick is not so evil at all, because usually, PTS
has no errors, and DTS is either always set, or always unset. So this
_should_ provoke no regressions (famous last words).
libavformat actually does something similar: it derives DTS from PTS in
ways unknown to me. The result is very broken, but it causes the DTS
fallback to become active, and thus happens to work.
Also, prevent the heuristic from being active if PTS is merely monotonic
instead of strictly-monotonic. Non-unique PTS is broken, but we can't
fallback to DTS anyway in these cases.
The specific mkv file that is fixed with this commit had the following
fields set:
Muxing application: libebml v1.3.0 + libmatroska v1.4.1
Writing application: mkvmerge v6.7.0 ('Back to the Ground') [...]
But I know that this should also fix playback of mencoder produced mkv
files.
2014-05-27 19:56:46 +00:00
|
|
|
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
if (!d_video->vd_driver)
|
|
|
|
return NULL;
|
|
|
|
|
2013-11-27 19:52:28 +00:00
|
|
|
double pkt_pts = packet ? packet->pts : MP_NOPTS_VALUE;
|
|
|
|
double pkt_dts = packet ? packet->dts : MP_NOPTS_VALUE;
|
2007-03-11 17:30:43 +00:00
|
|
|
|
2016-02-19 17:16:21 +00:00
|
|
|
if (pkt_pts == MP_NOPTS_VALUE)
|
|
|
|
d_video->has_broken_packet_pts = 1;
|
|
|
|
|
2013-11-27 19:52:28 +00:00
|
|
|
double pkt_pdts = pkt_pts == MP_NOPTS_VALUE ? pkt_dts : pkt_pts;
|
2015-10-06 16:13:23 +00:00
|
|
|
if (pkt_pdts != MP_NOPTS_VALUE && d_video->first_packet_pdts == MP_NOPTS_VALUE)
|
|
|
|
d_video->first_packet_pdts = pkt_pdts;
|
2013-11-25 22:12:18 +00:00
|
|
|
|
2014-04-17 19:47:00 +00:00
|
|
|
MP_STATS(d_video, "start decode video");
|
|
|
|
|
2013-11-27 19:52:28 +00:00
|
|
|
struct mp_image *mpi = d_video->vd_driver->decode(d_video, packet, drop_frame);
|
2007-03-11 17:30:43 +00:00
|
|
|
|
2014-04-17 19:47:00 +00:00
|
|
|
MP_STATS(d_video, "end decode video");
|
2002-03-01 00:25:43 +00:00
|
|
|
|
2016-02-04 14:28:25 +00:00
|
|
|
// Error, discarded frame, dropped frame, or initial codec delay.
|
video/filter: change filter API, use refcounting, remove filter DR
Change the entire filter API to use reference counted images instead
of vf_get_image().
Remove filter "direct rendering". This was useful for vf_expand and (in
rare cases) vf_sub: DR allowed these filters to pass a cropped image to
the filters before them. Then, on filtering, the image was "uncropped",
so that black bars could be added around the image without copying. This
means that in some cases, vf_expand will be slower (-vf gradfun,expand
for example).
Note that another form of DR used for in-place filters has been replaced
by simpler logic. Instead of trying to do DR, filters can check if the
image is writeable (with mp_image_is_writeable()), and do true in-place
if that's the case. This affects filters like vf_gradfun and vf_sub.
Everything has to support strides now. If something doesn't, making a
copy of the image data is required.
2012-11-05 13:25:04 +00:00
|
|
|
if (!mpi || drop_frame) {
|
|
|
|
talloc_free(mpi);
|
2016-02-04 14:28:25 +00:00
|
|
|
return NULL;
|
video/filter: change filter API, use refcounting, remove filter DR
Change the entire filter API to use reference counted images instead
of vf_get_image().
Remove filter "direct rendering". This was useful for vf_expand and (in
rare cases) vf_sub: DR allowed these filters to pass a cropped image to
the filters before them. Then, on filtering, the image was "uncropped",
so that black bars could be added around the image without copying. This
means that in some cases, vf_expand will be slower (-vf gradfun,expand
for example).
Note that another form of DR used for in-place filters has been replaced
by simpler logic. Instead of trying to do DR, filters can check if the
image is writeable (with mp_image_is_writeable()), and do true in-place
if that's the case. This affects filters like vf_gradfun and vf_sub.
Everything has to support strides now. If something doesn't, making a
copy of the image data is required.
2012-11-05 13:25:04 +00:00
|
|
|
}
|
2002-03-11 01:13:13 +00:00
|
|
|
|
2015-09-10 03:28:22 +00:00
|
|
|
if (opts->field_dominance == 0) {
|
|
|
|
mpi->fields |= MP_IMGFIELD_TOP_FIRST | MP_IMGFIELD_INTERLACED;
|
|
|
|
} else if (opts->field_dominance == 1) {
|
2008-04-24 02:23:45 +00:00
|
|
|
mpi->fields &= ~MP_IMGFIELD_TOP_FIRST;
|
2015-09-10 03:28:22 +00:00
|
|
|
mpi->fields |= MP_IMGFIELD_INTERLACED;
|
|
|
|
}
|
2015-10-03 19:21:27 +00:00
|
|
|
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
// Note: the PTS is reordered, but the DTS is not. Both should be monotonic.
|
2016-01-25 19:47:13 +00:00
|
|
|
double pts = mpi->pts;
|
|
|
|
double dts = mpi->dts;
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
|
2016-01-29 21:43:18 +00:00
|
|
|
if (pts != MP_NOPTS_VALUE) {
|
|
|
|
if (pts < d_video->codec_pts)
|
|
|
|
d_video->num_codec_pts_problems++;
|
2016-01-25 19:47:13 +00:00
|
|
|
d_video->codec_pts = mpi->pts;
|
2007-03-11 17:30:43 +00:00
|
|
|
}
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
|
2016-01-29 21:43:18 +00:00
|
|
|
if (dts != MP_NOPTS_VALUE) {
|
|
|
|
if (dts <= d_video->codec_dts)
|
|
|
|
d_video->num_codec_dts_problems++;
|
2016-01-25 19:47:13 +00:00
|
|
|
d_video->codec_dts = mpi->dts;
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
}
|
|
|
|
|
2016-02-19 17:16:21 +00:00
|
|
|
if (d_video->has_broken_packet_pts < 0)
|
|
|
|
d_video->has_broken_packet_pts++;
|
|
|
|
if (d_video->num_codec_pts_problems)
|
|
|
|
d_video->has_broken_packet_pts = 1;
|
|
|
|
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
// If PTS is unset, or non-monotonic, fall back to DTS.
|
|
|
|
if ((d_video->num_codec_pts_problems > d_video->num_codec_dts_problems ||
|
|
|
|
pts == MP_NOPTS_VALUE) && dts != MP_NOPTS_VALUE)
|
|
|
|
pts = dts;
|
|
|
|
|
2013-11-27 19:56:38 +00:00
|
|
|
if (!opts->correct_pts || pts == MP_NOPTS_VALUE) {
|
2016-11-09 16:51:19 +00:00
|
|
|
if (opts->correct_pts && !d_video->header->missing_timestamps) {
|
|
|
|
if (d_video->has_broken_decoded_pts <= 1) {
|
|
|
|
MP_WARN(d_video, "No video PTS! Making something up.\n");
|
|
|
|
if (d_video->has_broken_decoded_pts == 1)
|
|
|
|
MP_WARN(d_video, "Ignoring further missing PTS warnings.\n");
|
|
|
|
d_video->has_broken_decoded_pts++;
|
|
|
|
}
|
|
|
|
}
|
2013-11-27 19:56:38 +00:00
|
|
|
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
double frame_time = 1.0f / (d_video->fps > 0 ? d_video->fps : 25);
|
2015-10-06 16:13:23 +00:00
|
|
|
double base = d_video->first_packet_pdts;
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
pts = d_video->decoded_pts;
|
2015-10-06 16:13:23 +00:00
|
|
|
if (pts == MP_NOPTS_VALUE) {
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
pts = base == MP_NOPTS_VALUE ? 0 : base;
|
2015-10-06 16:13:23 +00:00
|
|
|
} else {
|
|
|
|
pts += frame_time;
|
|
|
|
}
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
}
|
|
|
|
|
2016-01-13 23:18:31 +00:00
|
|
|
if (!mp_image_params_equal(&d_video->last_format, &mpi->params))
|
|
|
|
fix_image_params(d_video, &mpi->params);
|
|
|
|
|
|
|
|
mpi->params = d_video->fixed_format;
|
|
|
|
|
video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 19:54:56 +00:00
|
|
|
mpi->pts = pts;
|
|
|
|
d_video->decoded_pts = pts;
|
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 15:01:11 +00:00
|
|
|
|
|
|
|
// Compensate for incorrectly using mpeg-style DTS for avi timestamps.
|
2016-02-19 17:28:46 +00:00
|
|
|
if (d_video->codec->avi_dts && opts->correct_pts &&
|
|
|
|
mpi->pts != MP_NOPTS_VALUE && d_video->fps > 0)
|
|
|
|
{
|
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 15:01:11 +00:00
|
|
|
int delay = -1;
|
|
|
|
video_vd_control(d_video, VDCTRL_GET_BFRAMES, &delay);
|
|
|
|
mpi->pts -= MPMAX(delay, 0) / d_video->fps;
|
|
|
|
}
|
|
|
|
|
2007-03-11 17:30:43 +00:00
|
|
|
return mpi;
|
2006-11-14 12:29:20 +00:00
|
|
|
}
|
2016-01-14 08:46:03 +00:00
|
|
|
|
2016-09-20 13:34:31 +00:00
|
|
|
void video_reset_params(struct dec_video *d_video)
|
2016-01-14 08:46:03 +00:00
|
|
|
{
|
|
|
|
d_video->last_format = (struct mp_image_params){0};
|
|
|
|
}
|
2016-01-16 20:19:52 +00:00
|
|
|
|
2016-09-20 13:40:44 +00:00
|
|
|
void video_get_dec_params(struct dec_video *d_video, struct mp_image_params *p)
|
|
|
|
{
|
|
|
|
*p = d_video->dec_format;
|
|
|
|
}
|
|
|
|
|
2016-01-16 20:19:52 +00:00
|
|
|
void video_set_framedrop(struct dec_video *d_video, bool enabled)
|
|
|
|
{
|
|
|
|
d_video->framedrop_enabled = enabled;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Frames before the start timestamp can be dropped. (Used for hr-seek.)
|
|
|
|
void video_set_start(struct dec_video *d_video, double start_pts)
|
|
|
|
{
|
|
|
|
d_video->start_pts = start_pts;
|
|
|
|
}
|
|
|
|
|
|
|
|
void video_work(struct dec_video *d_video)
|
|
|
|
{
|
|
|
|
if (d_video->current_mpi)
|
|
|
|
return;
|
|
|
|
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
if (!d_video->packet && !d_video->new_segment &&
|
|
|
|
demux_read_packet_async(d_video->header, &d_video->packet) == 0)
|
|
|
|
{
|
2016-02-01 20:32:01 +00:00
|
|
|
d_video->current_state = DATA_WAIT;
|
2016-01-16 20:19:52 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-02-19 17:28:46 +00:00
|
|
|
if (d_video->packet) {
|
|
|
|
if (d_video->packet->dts == MP_NOPTS_VALUE && !d_video->codec->avi_dts)
|
|
|
|
d_video->packet->dts = d_video->packet->pts;
|
|
|
|
}
|
|
|
|
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
if (d_video->packet && d_video->packet->new_segment) {
|
|
|
|
assert(!d_video->new_segment);
|
|
|
|
d_video->new_segment = d_video->packet;
|
|
|
|
d_video->packet = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool had_input_packet = !!d_video->packet;
|
|
|
|
bool had_packet = had_input_packet || d_video->new_segment;
|
|
|
|
|
|
|
|
double start_pts = d_video->start_pts;
|
|
|
|
if (d_video->start != MP_NOPTS_VALUE && (start_pts == MP_NOPTS_VALUE ||
|
|
|
|
d_video->start > start_pts))
|
|
|
|
start_pts = d_video->start;
|
|
|
|
|
2016-01-16 20:19:52 +00:00
|
|
|
int framedrop_type = d_video->framedrop_enabled ? 1 : 0;
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
if (start_pts != MP_NOPTS_VALUE && d_video->packet &&
|
|
|
|
d_video->packet->pts < start_pts - .005 &&
|
2016-01-16 20:19:52 +00:00
|
|
|
!d_video->has_broken_packet_pts)
|
|
|
|
{
|
|
|
|
framedrop_type = 2;
|
|
|
|
}
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
d_video->current_mpi = decode_packet(d_video, d_video->packet, framedrop_type);
|
2016-02-19 17:35:11 +00:00
|
|
|
if (d_video->packet && d_video->packet->len == 0) {
|
|
|
|
talloc_free(d_video->packet);
|
|
|
|
d_video->packet = NULL;
|
|
|
|
}
|
2016-01-16 20:19:52 +00:00
|
|
|
|
2016-02-01 20:32:01 +00:00
|
|
|
d_video->current_state = DATA_OK;
|
2016-01-16 20:19:52 +00:00
|
|
|
if (!d_video->current_mpi) {
|
2016-02-01 20:32:01 +00:00
|
|
|
d_video->current_state = DATA_EOF;
|
2016-01-16 20:19:52 +00:00
|
|
|
if (had_packet) {
|
|
|
|
if (framedrop_type == 1)
|
|
|
|
d_video->dropped_frames += 1;
|
2016-02-01 20:32:01 +00:00
|
|
|
d_video->current_state = DATA_AGAIN;
|
2016-01-16 20:19:52 +00:00
|
|
|
}
|
|
|
|
}
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
|
|
|
|
bool segment_ended = !d_video->current_mpi && !had_input_packet;
|
|
|
|
|
|
|
|
if (d_video->current_mpi && d_video->current_mpi->pts != MP_NOPTS_VALUE) {
|
|
|
|
double vpts = d_video->current_mpi->pts;
|
|
|
|
segment_ended = d_video->end != MP_NOPTS_VALUE && vpts >= d_video->end;
|
2016-02-28 19:29:51 +00:00
|
|
|
if ((d_video->start != MP_NOPTS_VALUE && vpts < d_video->start)
|
|
|
|
|| segment_ended)
|
|
|
|
{
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
talloc_free(d_video->current_mpi);
|
|
|
|
d_video->current_mpi = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If there's a new segment, start it as soon as we're drained/finished.
|
|
|
|
if (segment_ended && d_video->new_segment) {
|
|
|
|
struct demux_packet *new_segment = d_video->new_segment;
|
|
|
|
d_video->new_segment = NULL;
|
|
|
|
|
2016-11-09 15:35:44 +00:00
|
|
|
if (d_video->codec == new_segment->codec) {
|
|
|
|
video_reset(d_video);
|
|
|
|
} else {
|
|
|
|
d_video->codec = new_segment->codec;
|
|
|
|
if (d_video->vd_driver)
|
|
|
|
d_video->vd_driver->uninit(d_video);
|
|
|
|
d_video->vd_driver = NULL;
|
|
|
|
video_init_best_codec(d_video);
|
|
|
|
}
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
|
|
|
|
d_video->start = new_segment->start;
|
|
|
|
d_video->end = new_segment->end;
|
|
|
|
|
|
|
|
new_segment->new_segment = false;
|
|
|
|
|
|
|
|
d_video->packet = new_segment;
|
|
|
|
d_video->current_state = DATA_AGAIN;
|
|
|
|
}
|
2016-01-16 20:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Fetch an image decoded with video_work(). Returns one of:
|
2016-02-01 20:32:01 +00:00
|
|
|
// DATA_OK: *out_mpi is set to a new image
|
|
|
|
// DATA_WAIT: waiting for demuxer; will receive a wakeup signal
|
|
|
|
// DATA_EOF: end of file, no more frames to be expected
|
|
|
|
// DATA_AGAIN: dropped frame or something similar
|
2016-01-16 20:19:52 +00:00
|
|
|
int video_get_frame(struct dec_video *d_video, struct mp_image **out_mpi)
|
|
|
|
{
|
|
|
|
*out_mpi = NULL;
|
|
|
|
if (d_video->current_mpi) {
|
|
|
|
*out_mpi = d_video->current_mpi;
|
|
|
|
d_video->current_mpi = NULL;
|
2016-02-01 20:32:01 +00:00
|
|
|
return DATA_OK;
|
2016-01-16 20:19:52 +00:00
|
|
|
}
|
2016-02-01 20:32:01 +00:00
|
|
|
if (d_video->current_state == DATA_OK)
|
|
|
|
return DATA_AGAIN;
|
2016-01-16 20:19:52 +00:00
|
|
|
return d_video->current_state;
|
|
|
|
}
|