RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-21 14:22:17 +00:00
Code Issues Releases Wiki Activity
3d367e009c
mpv/demux/packet.h

67 lines
2.3 KiB
C
Raw Normal View History

core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
/*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* This file is part of mpv.
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
*
demux/packet: change license to LGPL All contributors have agreed. In 3a43f13fcec1, someone who potentially disagreed reverted a commit by someone else (restoring the original state). This shouldn't matter for Copyright, and all of the affected code was rewritten/removed anyway.
2017-04-21 11:33:23 +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.
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* mpv is distributed in the hope that it will be useful,
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
demux/packet: change license to LGPL All contributors have agreed. In 3a43f13fcec1, someone who potentially disagreed reverted a commit by someone else (restoring the original state). This shouldn't matter for Copyright, and all of the affected code was rewritten/removed anyway.
2017-04-21 11:33:23 +00:00
* GNU Lesser General Public License for more details.
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
*
demux/packet: change license to LGPL All contributors have agreed. In 3a43f13fcec1, someone who potentially disagreed reverted a commit by someone else (restoring the original state). This shouldn't matter for Copyright, and all of the affected code was rewritten/removed anyway.
2017-04-21 11:33:23 +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/>.
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
*/
#ifndef MPLAYER_DEMUX_PACKET_H
#define MPLAYER_DEMUX_PACKET_H
demux, vd_ffmpeg: fix demux keyframe flag, set AV_PKT_FLAG_KEY There was some confusion about the "flags" field in demuxer packets. Demuxers set it to either 1 or 0x10 to indicate a keyframe (and the field was not used to indicate anything else). This didn't cause visible problems because nothing read the value. Replace the "flags" field with a boolean "keyframe" field. Set AV_PKT_FLAG_KEY based on this field in packets fed to libavcodec video decoders (looks like PNG and ZeroCodec are the only ones which depend on values from demuxer; previously this was hardcoded to true for PNG). Make demux_mf set the keyframe field in every packet. This matters for PNG files now that the demuxer flag is forwarded to libavcodec. Fix logic setting the field in demux_mkv. It had probably not been updated when adding SimpleBlock support. This probably makes no difference for any current practical use.
2012-07-24 21:23:27 +00:00
#include <stdbool.h>
demux: move packet functions to a separate source file
2014-07-05 14:45:28 +00:00
#include <stddef.h>
demux: rename demux_packet.h to packet.h This always bothered me.
2013-11-18 17:46:44 +00:00
#include <inttypes.h>
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
// Holds one packet/frame/whatever
typedef struct demux_packet {
int len;
packet: cosmetics: reorder fields
2016-02-15 19:39:17 +00:00
unsigned char *buffer;
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
double pts;
demux: export dts from demux_lavf, use it for avi Having the DTS directly can be useful for restoring PTS values. The avi file format doesn't actually store PTS values, just DTS. An older hack explicitly exported the DTS as PTS (ignoring the [I assume] genpts generated non-sense PTS), which is not necessary anymore due to this change.
2013-11-25 22:13:01 +00:00
double dts;
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
double duration;
demux, vd_ffmpeg: fix demux keyframe flag, set AV_PKT_FLAG_KEY There was some confusion about the "flags" field in demuxer packets. Demuxers set it to either 1 or 0x10 to indicate a keyframe (and the field was not used to indicate anything else). This didn't cause visible problems because nothing read the value. Replace the "flags" field with a boolean "keyframe" field. Set AV_PKT_FLAG_KEY based on this field in packets fed to libavcodec video decoders (looks like PNG and ZeroCodec are the only ones which depend on values from demuxer; previously this was hardcoded to true for PNG). Make demux_mf set the keyframe field in every packet. This matters for PNG files now that the demuxer flag is forwarded to libavcodec. Fix logic setting the field in demux_mkv. It had probably not been updated when adding SimpleBlock support. This probably makes no difference for any current practical use.
2012-07-24 21:23:27 +00:00
bool keyframe;
packet: cosmetics: reorder fields
2016-02-15 19:39:17 +00:00
int64_t pos; // position in source file byte stream
int stream; // source stream index
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
// segmentation (ordered chapters, EDL)
demux: get rid of demux_packet.new_segment field The new_segment field was used to track the decoder data flow handler of timeline boundaries, which are used for ordered chapters etc. (anything that sets demuxer_desc.load_timeline). This broke seeking with the demuxer cache enabled. The demuxer is expected to set the new_segment field after every seek or segment boundary switch, so the cached packets basically contained incorrect values for this, and the decoders were not initialized correctly. Fix this by getting rid of the flag completely. Let the decoders instead compare the segment information by content, which is hopefully enough. (In theory, two segments with same information could perhaps appear in broken-ish corner cases, or in an attempt to simulate looping, and such. I preferred the simple solution over others, such as generating unique and stable segment IDs.) We still add a "segmented" field to make it explicit whether segments are used, instead of doing something silly like testing arbitrary other segment fields for validity. Cached seeking with timeline stuff is still slightly broken even with this commit: the seek logic is not aware of the overlap that segments can have, and the timestamp clamping that needs to be performed in theory to account for the fact that a packet might contain a frame that is always clipped off by segment handling. This can be fixed later.
2017-10-24 17:33:01 +00:00
bool segmented;
struct mp_codec_params *codec; // set to non-NULL iff segmented is set
double start, end; // set to non-NOPTS iff segmented is set
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
packet: cosmetics: reorder fields
2016-02-15 19:39:17 +00:00
// private
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
struct demux_packet *next;
packet: cosmetics: reorder fields
2016-02-15 19:39:17 +00:00
struct AVPacket *avpacket; // keep the buffer allocation and sidedata
demux: improve and optimize cache pruning and seek range determination The main purpose of this commit is avoiding any hidden O(n^2) algorithms in the code for pruning the demuxer cache, and for determining the seekable boundaries of the cache. The old code could loop over the whole packet queue on every packet pruned in certain corner cases. There are two ways how to reach the goal: 1) commit a cardinal sin 2) do everything incrementally The cardinal sin is adding an extra field to demux_packet, which caches the determined seekable range for a keyframe range. demux_packet is a rather general data structure and thus shouldn't have any fields that are not inherent to its use, and are only needed as an implementation detail of code using it. But what are you gonna do, sue me? In the future, demux.c might have its own packet struct though. Then the other existing cardinal sin (the "next" field, from MPlayer times) could be removed as well. This commit also changes slightly how the seek end is determined. There is a note on the manpage in case anyone finds the new behavior confusing. It's somewhat cleaner and might be needed for supporting multiple ranges (although that's unclear).
2017-11-04 22:02:25 +00:00
double kf_seek_pts; // demux.c internal: seek pts for keyframe range
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
} demux_packet_t;
demux_mkv: rewrite packet reading to avoid 1 memcpy() This directly reads individual mkv sub-packets (block laces) into a dedicated AVBufferRefs, which can be directly used for creating packets without a additional copy of the packet data. This also means we switch parsing of block header fields and lacing metadata to read directly from the stream, instead of a memory buffer. This could have been much easier if libavcodec didn't require padding the packet data with zero bytes. We could just have each packet reference a slice of the block data. But as it is, the only way to get padding without a copy is to read the laces into individually allocated (and padded) memory block, which required a larger rewrite. This probably makes recovering from broken mkv files slightly worse if the transport is unseekable. We just read, and then check if we've overread. But I think that shouldn't be a real concern. No actual measureable performance change. Potential for some regressions, as this is quite intrusive, and touches weird obscure shit like mkv lacing. Still keeping it because I like how it removes some redundant EBML parsing functions.
2017-11-05 15:36:18 +00:00
struct AVBufferRef;
demux: move packet functions to a separate source file
2014-07-05 14:45:28 +00:00
struct demux_packet *new_demux_packet(size_t len);
demux: always use AVPacket This is a simplification, because it lets us use the AVPacket functions, instead of handling the details manually. It also allows the libavcodec rawvideo decoder to use reference counting, so it doesn't have to memcpy() the full image data. The change in av_common.c enables this. This change is somewhat risky, because we rely on the following AVPacket implementation details and assumptions: - av_packet_ref() doesn't access the input padding, and just copies the data. By the API, AVPacket is always padded, and we violate this. The lavc implementation would have to go out of its way to make this a real problem, though. - We hope that the way we make the AVPacket refcountable in av_common.c is actually supported API-usage. It's hard to tell whether it is. Of course we still use our own "old" demux_packet struct, just so that libav* API usage is somewhat isolated.
2014-08-24 15:45:28 +00:00
struct demux_packet *new_demux_packet_from_avpacket(struct AVPacket *avpkt);
demux: move packet functions to a separate source file
2014-07-05 14:45:28 +00:00
struct demux_packet *new_demux_packet_from(void *data, size_t len);
demux_mkv: rewrite packet reading to avoid 1 memcpy() This directly reads individual mkv sub-packets (block laces) into a dedicated AVBufferRefs, which can be directly used for creating packets without a additional copy of the packet data. This also means we switch parsing of block header fields and lacing metadata to read directly from the stream, instead of a memory buffer. This could have been much easier if libavcodec didn't require padding the packet data with zero bytes. We could just have each packet reference a slice of the block data. But as it is, the only way to get padding without a copy is to read the laces into individually allocated (and padded) memory block, which required a larger rewrite. This probably makes recovering from broken mkv files slightly worse if the transport is unseekable. We just read, and then check if we've overread. But I think that shouldn't be a real concern. No actual measureable performance change. Potential for some regressions, as this is quite intrusive, and touches weird obscure shit like mkv lacing. Still keeping it because I like how it removes some redundant EBML parsing functions.
2017-11-05 15:36:18 +00:00
struct demux_packet *new_demux_packet_from_buf(struct AVBufferRef *buf);
demux: move packet functions to a separate source file
2014-07-05 14:45:28 +00:00
void demux_packet_shorten(struct demux_packet *dp, size_t len);
void free_demux_packet(struct demux_packet *dp);
struct demux_packet *demux_copy_packet(struct demux_packet *dp);
demux: estimate total packet size, deprecate packet number limits It's all explained in the DOCS changes. Although this option was always kind of obscure and pointless. Until it is removed, the only reason for setting it would be to raise the static default limit, so change its default to INT_MAX so that it does nothing by default.
2017-04-14 17:19:44 +00:00
size_t demux_packet_estimate_total_size(struct demux_packet *dp);
demux: move packet functions to a separate source file
2014-07-05 14:45:28 +00:00
demux_mkv: refactor packet parsing Makes it somewhat more uniform, and breaks up the awfully deep nesting. This implicitly changes multiple small details, rather than only moving code around. In particular, this computes the packet fields first and parses them afterwards, which is needed for the next commit.
2015-02-05 20:52:07 +00:00
void demux_packet_copy_attribs(struct demux_packet *dst, struct demux_packet *src);
demux_mkv: implement audio skipping/trimming This mechanism was introduced for Opus, and allows correct skipping of "preroll" data, as well as discarding trailing audio if the file's length isn't a multiple of the audio frame size. Not sure how to handle seeking. I don't understand the purpose of the SeekPreRoll element. This was tested with correctness_trimming_nobeeps.opus, remuxed to mka with mkvmerge v7.2.0. It seems to be correct, although the reported file duration is incorrect (maybe a mkvmerge issue).
2014-11-03 19:00:34 +00:00
int demux_packet_set_padding(struct demux_packet *dp, int start, int end);
demux_mkv: passthrough BlockAdditions for libvpx alpha Dumb but simple thing. Requires the FFmpeg libvpx decoder wrapper, as its native decoder doesn't support alpha.
2017-01-31 13:48:10 +00:00
int demux_packet_add_blockadditional(struct demux_packet *dp, uint64_t id,
void *data, size_t size);
demux_mkv: implement audio skipping/trimming This mechanism was introduced for Opus, and allows correct skipping of "preroll" data, as well as discarding trailing audio if the file's length isn't a multiple of the audio frame size. Not sure how to handle seeking. I don't understand the purpose of the SeekPreRoll element. This was tested with correctness_trimming_nobeeps.opus, remuxed to mka with mkvmerge v7.2.0. It seems to be correct, although the reported file duration is incorrect (maybe a mkvmerge issue).
2014-11-03 19:00:34 +00:00
core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpeg Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
2011-08-20 17:25:43 +00:00
#endif /* MPLAYER_DEMUX_PACKET_H */
Reference in New Issue Copy Permalink