2009-05-08 21:51:13 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2009-05-08 21:51:13 +00:00
|
|
|
*
|
demux/stheader: change license to LGPL
All authors of the current code have agreed.
For most of its life, MPlayer used Microsoft structs like WAVEFORMATEX
to describe media content. It appears these were copied from wine in
61c5a99851e. Copyright is unclear, but mpv completely removed use of
these structs anyway. (demux_mkv.c still contains code to read these
fields from a byte stream, but the struct is fully gone.)
42f97b2b820: cehoyos (who probably didn't agree with LGPL) applied a
patch by someone who agreed. It's unknown whether cehoyos modified the
patch (and thus his copyright would apply), but the changed code was
removed anyway. (The code was first moved somewhere else, then removed.)
efd53eed614: the patch author was not asked. Although the mkv_sh_sub_t
struct was later moved to stheader.h, the added field was removed
without replacement.
f6878753fbd: nick, who could not be reached, added an include guard, but
the guard was changed several times later, and it's probably not
copyrightable anyway.
afb0fd5ea17: the same nick adds a field that was later replaced and
finally removed again in 8cd6b20571.
2017-05-10 11:15:29 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2009-05-08 21:51:13 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2009-05-08 21:51:13 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
demux/stheader: change license to LGPL
All authors of the current code have agreed.
For most of its life, MPlayer used Microsoft structs like WAVEFORMATEX
to describe media content. It appears these were copied from wine in
61c5a99851e. Copyright is unclear, but mpv completely removed use of
these structs anyway. (demux_mkv.c still contains code to read these
fields from a byte stream, but the struct is fully gone.)
42f97b2b820: cehoyos (who probably didn't agree with LGPL) applied a
patch by someone who agreed. It's unknown whether cehoyos modified the
patch (and thus his copyright would apply), but the changed code was
removed anyway. (The code was first moved somewhere else, then removed.)
efd53eed614: the patch author was not asked. Although the mkv_sh_sub_t
struct was later moved to stheader.h, the added field was removed
without replacement.
f6878753fbd: nick, who could not be reached, added an include guard, but
the guard was changed several times later, and it's probably not
copyrightable anyway.
afb0fd5ea17: the same nick adds a field that was later replaced and
finally removed again in 8cd6b20571.
2017-05-10 11:15:29 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2009-05-08 21:51:13 +00:00
|
|
|
*
|
demux/stheader: change license to LGPL
All authors of the current code have agreed.
For most of its life, MPlayer used Microsoft structs like WAVEFORMATEX
to describe media content. It appears these were copied from wine in
61c5a99851e. Copyright is unclear, but mpv completely removed use of
these structs anyway. (demux_mkv.c still contains code to read these
fields from a byte stream, but the struct is fully gone.)
42f97b2b820: cehoyos (who probably didn't agree with LGPL) applied a
patch by someone who agreed. It's unknown whether cehoyos modified the
patch (and thus his copyright would apply), but the changed code was
removed anyway. (The code was first moved somewhere else, then removed.)
efd53eed614: the patch author was not asked. Although the mkv_sh_sub_t
struct was later moved to stheader.h, the added field was removed
without replacement.
f6878753fbd: nick, who could not be reached, added an include guard, but
the guard was changed several times later, and it's probably not
copyrightable anyway.
afb0fd5ea17: the same nick adds a field that was later replaced and
finally removed again in 8cd6b20571.
2017-05-10 11:15:29 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2009-05-08 21:51:13 +00:00
|
|
|
*/
|
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#ifndef MPLAYER_STHEADER_H
|
|
|
|
#define MPLAYER_STHEADER_H
|
2002-03-03 18:47:29 +00:00
|
|
|
|
2011-01-16 18:03:08 +00:00
|
|
|
#include <stdbool.h>
|
|
|
|
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/common.h"
|
2013-04-06 20:43:12 +00:00
|
|
|
#include "audio/chmap.h"
|
2017-08-21 12:56:07 +00:00
|
|
|
#include "video/mp_image.h"
|
2014-09-25 00:22:44 +00:00
|
|
|
|
2008-04-16 01:23:38 +00:00
|
|
|
struct MPOpts;
|
2009-04-19 14:37:03 +00:00
|
|
|
struct demuxer;
|
2002-09-22 00:43:14 +00:00
|
|
|
|
|
|
|
// Stream headers:
|
2002-01-16 12:24:36 +00:00
|
|
|
|
2012-08-03 10:24:55 +00:00
|
|
|
struct sh_stream {
|
|
|
|
enum stream_type type;
|
|
|
|
// Index into demuxer->streams.
|
|
|
|
int index;
|
2013-04-29 20:34:36 +00:00
|
|
|
// Demuxer/format specific ID. Corresponds to the stream IDs as encoded in
|
|
|
|
// some file formats (e.g. MPEG), or an index chosen by demux.c.
|
2012-08-03 10:24:55 +00:00
|
|
|
int demuxer_id;
|
2014-10-21 11:16:48 +00:00
|
|
|
// FFmpeg stream index (AVFormatContext.streams[index]), or equivalent.
|
|
|
|
int ff_index;
|
2012-08-03 10:24:55 +00:00
|
|
|
|
2016-01-12 22:48:19 +00:00
|
|
|
struct mp_codec_params *codec;
|
2012-10-28 23:06:51 +00:00
|
|
|
|
2012-08-03 10:24:55 +00:00
|
|
|
char *title;
|
2013-02-09 14:15:28 +00:00
|
|
|
char *lang; // language code
|
2012-12-10 17:52:06 +00:00
|
|
|
bool default_track; // container default track flag
|
2015-06-27 20:02:24 +00:00
|
|
|
bool forced_track; // container forced track flag
|
2018-04-16 01:39:45 +00:00
|
|
|
bool dependent_track; // container dependent track flag
|
2018-07-26 19:53:14 +00:00
|
|
|
bool visual_impaired_track; // container flag
|
|
|
|
bool hearing_impaired_track;// container flag
|
2021-10-14 14:36:57 +00:00
|
|
|
bool image; // video stream is an image
|
2024-02-09 08:01:29 +00:00
|
|
|
bool still_image; // video consists of multiple sparse still images
|
2014-09-01 21:47:27 +00:00
|
|
|
int hls_bitrate;
|
2023-02-21 21:23:29 +00:00
|
|
|
int program_id;
|
core: completely change handling of attached picture pseudo video
Before this commit, we tried to play along with libavformat and tried
to pretend that attached pictures are video streams with a single
frame, and that the frame magically appeared at the seek position when
seeking. The playback core would then switch to a mode where the video
has ended, and the "remaining" audio is played.
This didn't work very well:
- we needed a hack in demux.c, because we tried to read more packets in
order to find the "next" video frame (libavformat doesn't tell us if
a stream has ended)
- switching the video stream didn't work, because we can't tell
libavformat to send the packet again
- seeking and resuming after was hacky (for some reason libavformat sets
the returned packet's PTS to that of the previously returned audio
packet in generic code not related to attached pictures, and this
happened to work)
- if the user did something stupid and e.g. inserted a deinterlacer by
default, a picture was never displayed, only an inactive VO window)
- same when using a command that reconfigured the VO (like switching
aspect or video filters)
- hr-seek didn't work
For this reason, handle attached pictures as separate case with a
separate video decoding function, which doesn't read packets. Also,
do not synchronize audio to video start in this case.
2013-07-11 17:23:56 +00:00
|
|
|
|
2016-08-12 19:39:32 +00:00
|
|
|
struct mp_tags *tags;
|
|
|
|
|
2015-03-20 21:07:26 +00:00
|
|
|
bool missing_timestamps;
|
|
|
|
|
demux, demux_mkv: fix seeking in cache with large codec delay
In this scenario, the demuxer will output timestamps offset by the codec
delay (e.g. negative timestamps at the start; mkv simulates those), and
the trimming in the decoder (often libavcodec, but ad_lavc.c in our
case) will adjust the timestamps back (e.g. stream actually starts at
0).
This offset needs to be taken into account when seeking. This worked in
the uncached case. (demux_mkv.c is a bit tricky in that the index is
already in the offset space, so it compensates even though the seek call
does not reference codec_delay.) But in the cached case, seeks backwards
did not seek enough, and forward they seeked too much.
Fix this by adding the codec delay to the index search. We need to get
"earlier" packets, so e.g. seeking to position 0 really gets the initial
packets with negative timestamps.
This also adjusts the seek range start. This is also pretty obvious: if
the beginning of the file is cached, the seek range should start at 0,
not a negative value. We compare 0-based timestamps to it later on.
Not sure if this is the best approach. I also could have thought
about/checked some corner cases harder. But fuck this shit.
Not fixing duration (who cares) or end trimming, which would reduce the
seek range and duration (who cares).
2019-05-22 20:27:07 +00:00
|
|
|
double seek_preroll;
|
|
|
|
|
core: completely change handling of attached picture pseudo video
Before this commit, we tried to play along with libavformat and tried
to pretend that attached pictures are video streams with a single
frame, and that the frame magically appeared at the seek position when
seeking. The playback core would then switch to a mode where the video
has ended, and the "remaining" audio is played.
This didn't work very well:
- we needed a hack in demux.c, because we tried to read more packets in
order to find the "next" video frame (libavformat doesn't tell us if
a stream has ended)
- switching the video stream didn't work, because we can't tell
libavformat to send the packet again
- seeking and resuming after was hacky (for some reason libavformat sets
the returned packet's PTS to that of the previously returned audio
packet in generic code not related to attached pictures, and this
happened to work)
- if the user did something stupid and e.g. inserted a deinterlacer by
default, a picture was never displayed, only an inactive VO window)
- same when using a command that reconfigured the VO (like switching
aspect or video filters)
- hr-seek didn't work
For this reason, handle attached pictures as separate case with a
separate video decoding function, which doesn't read packets. Also,
do not synchronize audio to video start in this case.
2013-07-11 17:23:56 +00:00
|
|
|
// stream is a picture (such as album art)
|
|
|
|
struct demux_packet *attached_picture;
|
2012-08-03 10:24:55 +00:00
|
|
|
|
2013-07-11 17:20:25 +00:00
|
|
|
// Internal to demux.c
|
|
|
|
struct demux_stream *ds;
|
2012-08-03 10:24:55 +00:00
|
|
|
};
|
|
|
|
|
2016-01-12 22:48:19 +00:00
|
|
|
struct mp_codec_params {
|
|
|
|
enum stream_type type;
|
|
|
|
|
|
|
|
// E.g. "h264" (usually corresponds to AVCodecDescriptor.name)
|
|
|
|
const char *codec;
|
|
|
|
|
2024-04-10 19:24:06 +00:00
|
|
|
// Usually corresponds to AVCodecDescriptor.long_name
|
|
|
|
const char *codec_desc;
|
|
|
|
|
|
|
|
// Corresponding codec profile
|
|
|
|
const char *codec_profile;
|
|
|
|
|
2024-04-15 19:11:08 +00:00
|
|
|
// E.g. "h264" (usually corresponds to AVCodec.name)
|
|
|
|
const char *decoder;
|
|
|
|
|
|
|
|
// Usually corresponds to AVCodec.long_name
|
|
|
|
const char *decoder_desc;
|
|
|
|
|
2016-01-12 22:48:19 +00:00
|
|
|
// Usually a FourCC, exact meaning depends on codec.
|
|
|
|
unsigned int codec_tag;
|
|
|
|
|
|
|
|
unsigned char *extradata; // codec specific per-stream header
|
|
|
|
int extradata_size;
|
|
|
|
|
|
|
|
// Codec specific header data (set by demux_lavf.c only)
|
2016-03-31 20:00:45 +00:00
|
|
|
struct AVCodecParameters *lav_codecpar;
|
2016-01-12 22:48:19 +00:00
|
|
|
|
2016-08-19 12:19:46 +00:00
|
|
|
// Timestamp granularity for converting double<->rational timestamps.
|
|
|
|
int native_tb_num, native_tb_den;
|
|
|
|
|
2017-12-26 05:09:26 +00:00
|
|
|
// Used by an obscure bug workaround mechanism. As an exception to the usual
|
|
|
|
// rules, demuxers are allowed to set this after adding the sh_stream, but
|
|
|
|
// only before the demuxer open call returns.
|
|
|
|
struct demux_packet *first_packet;
|
|
|
|
|
2016-01-12 22:48:19 +00:00
|
|
|
// STREAM_AUDIO
|
2011-07-03 07:30:50 +00:00
|
|
|
int samplerate;
|
2013-04-06 20:43:12 +00:00
|
|
|
struct mp_chmap channels;
|
2014-09-24 20:55:50 +00:00
|
|
|
bool force_channels;
|
2014-05-26 22:15:41 +00:00
|
|
|
int bitrate; // compressed bits/sec
|
2014-09-24 23:56:51 +00:00
|
|
|
int block_align;
|
2014-07-05 14:45:41 +00:00
|
|
|
struct replaygain_data *replaygain_data;
|
2001-04-06 01:18:59 +00:00
|
|
|
|
2016-01-12 22:48:19 +00:00
|
|
|
// STREAM_VIDEO
|
video: add insane hack to work around FFmpeg/Libav insanity
So, FFmpeg/Libav requires us to figure out video timestamps ourselves
(see last 10 commits or so), but the methods it provides for this aren't
even sufficient. In particular, everything that uses AVI-style DTS (avi,
vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal
frame delay is broken. In this case, libavcodec will shift the packet-
to-image correspondence by the codec delay, meaning that with a delay=1,
the first AVFrame.pkt_dts is not 0, but that of the second packet. All
timestamps will appear shifted. The start time (e.g. the time displayed
when doing "mpv file.avi --pause") will not be exactly 0.
(According to Libav developers, this is how it's supposed to work; just
that the first DTS values are normally negative with formats that use
DTS "properly". Who cares if it doesn't work at all with very common
video formats? There's no indication that they'll fix this soon,
either. An elegant workaround is missing too.)
Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV.
Since these timestamps are not reorderd, we wouldn't need to sort them,
but it's less code this way (and possibly more robust, should a demuxer
unexpectedly output PTS).
The original intention of all the timestamp changes recently was
actually to get rid of demuxer-specific hacks and the old timestamp
sorting code, but it looks like this didn't work out. Yet another case
where trying to replace native MPlayer functionality with FFmpeg/Libav
led to disadvantages and bugs. (Note that the old PTS sorting code
doesn't and can't handle frame dropping correctly, though.)
Bug reports:
https://trac.ffmpeg.org/ticket/3178
https://bugzilla.libav.org/show_bug.cgi?id=600
2013-11-28 14:10:45 +00:00
|
|
|
bool avi_dts; // use DTS timing; first frame and DTS is 0
|
2016-08-19 12:53:01 +00:00
|
|
|
double fps; // frames per second (set only if constant fps)
|
2016-08-19 12:19:46 +00:00
|
|
|
bool reliable_fps; // the fps field is definitely not broken
|
2015-12-19 19:04:31 +00:00
|
|
|
int par_w, par_h; // pixel aspect ratio (0 if unknown/square)
|
2013-11-23 20:36:20 +00:00
|
|
|
int disp_w, disp_h; // display size
|
2014-04-20 19:29:22 +00:00
|
|
|
int rotate; // intended display rotation, in degrees, [0, 359]
|
2014-08-30 21:24:46 +00:00
|
|
|
int stereo_mode; // mp_stereo3d_mode (0 if none/unknown)
|
2023-11-04 02:55:38 +00:00
|
|
|
struct pl_color_space color; // colorspace info where available
|
|
|
|
struct pl_color_repr repr; // color representaion info where available
|
|
|
|
struct mp_rect crop; // crop to be applied
|
2001-04-06 01:18:59 +00:00
|
|
|
|
2024-05-08 01:21:42 +00:00
|
|
|
bool dovi;
|
|
|
|
uint8_t dv_profile;
|
|
|
|
uint8_t dv_level;
|
|
|
|
|
2016-01-12 22:48:19 +00:00
|
|
|
// STREAM_VIDEO + STREAM_AUDIO
|
|
|
|
int bits_per_coded_sample;
|
2023-10-28 05:41:57 +00:00
|
|
|
char *format_name; // pixel format (video) or sample format (audio)
|
2016-01-12 22:48:19 +00:00
|
|
|
|
|
|
|
// STREAM_SUB
|
|
|
|
double frame_based; // timestamps are frame-based (and this is the
|
|
|
|
// fallback framerate used for timestamps)
|
|
|
|
};
|
2006-11-13 18:38:29 +00:00
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#endif /* MPLAYER_STHEADER_H */
|