summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux_playlist: sort files before directoriesChristoph Heinrich2023-07-061-22/+45
|
* demux_playlist: add option to control recursive directory loadingChristoph Heinrich2023-07-061-9/+40
| | | | | | | | | | | Directories were always loaded recursively, which can be slow (e.g. one of the subdirectories is a mounting point to a slow device) and can unexpectedly expand into a massive playlist. Due to the problems described in 503dada42f1ea1007768da0dc6a41b67cdf89400, this defaults to recursive loading. ref. https://github.com/mpv-player/mpv/issues/9652
* various: correctly ignore cache files with --no-configDudemanguy2023-07-061-1/+4
| | | | | | | | | | | | --no-config should prevent loading user files of any type: configs, cache, etc. For cache files, this case wasn't properly handled and it was assumed they would always get something. vo_gpu's shader cache actually already handles this, so it was left untouched. In theory, demuxer cache should never have this issue because saving it to disk is disabled by default (and likely that will never change), but go ahead and change it for consistency's sake. Fixes some segfaults with --no-config and various combinations of settings (particularly --vo=gpu-next).
* demux/demux_lavf: avoid leaking AVFormatContext during demux_open_lavfLeo Izen2023-06-181-12/+18
| | | | | | | If demux_open_lavf fails between calling avformat_alloc_context() and assigning the context to priv->avfc, it will never be properly freed. Fixes #11793.
* demux/demux_lavf: strip URL parameters before matching extensionKacper Michajłow2023-05-301-1/+4
| | | | | | | Unfortunately Content-Type matching seems to be not enough as there are mistagged streams. Try to match extension and pass-through URL. Fixes #11700
* demux/demux_lavf: pass-through mime_typeKacper Michajłow2023-05-161-0/+1
| | | | | | This fixes HLS playback. After FFmpeg@954d16f check is strict as per RFC8216 requirement and demuxer need to have this information to work properly.
* demux/demux_lavf: pass-through filename for HLSKacper Michajłow2023-05-161-2/+3
| | | | | | | Fixes local HLS playback. After FFmpeg@6b1f68c commit HLS is only processed if file extension matches RFC8216 requirement.
* Revert "demux/demux_lavf: pass dummy filename when an HLS mimetype is detected"Kacper Michajłow2023-05-161-27/+2
| | | | | | This reverts commit acababec208ec4f26c1462228a9ec1d4aac2c815. Now it has been fixed upstream FFmpeg@6b1f68c.
* demux/demux_lavf: pass dummy filename when an HLS mimetype is detectedLeo Izen2023-05-141-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass "dummy.m3u8" filename to work around FFmpeg commit 6b1f68ccb04d791f0250e05687c346a99ff47ea1 which broke their HLS demuxer and its ability to probe. Since the above commit, libavformat will check the filename of the file to be probed and reject it if it doesn't end with a valid HLS extension i.e. m3u8,hls,m3u (never mind that .hls is not a valid HLS extension). In addition to a bug with query strings, this also breaks mpv functionality as mpv explicitly doesn't tell libavformat the filename when probing, in order to properly detect the file based only on their contents. The [HLS specification](https://www.rfc-editor.org/rfc/rfc8216.txt) aka RFC 8216, specifies in section 4 that "Each Playlist file MUST be identifiable either by the path component of its URI or by HTTP Content-Type." Notably, it does not require both, so this FFmpeg commit is noncompliant. We work around this noncompliance by checking the MIME type ourselves. If the mimetype matches one of the valid HLS mimetypes (and also application/x-mpegurl, a legacy pre-standardization type), then we pass "dummy.m3u8" to libavformat in order to work around its overly strict checking of filenames. Without this patch, we are unable to play many HLS streams, including a few from the ytdl hook. This patch restores those ability to play those streams when built against FFmpeg master. Do note that if the server sends an invalid content-type header then we cannot implement this workaround so those streams will still fail to play.
* player: use XDG_CACHE_HOME by defaultDudemanguy2023-05-091-3/+5
| | | | | | | | | | | | This adds cache as a possible path for mpv to internally pick (~/.cache/mpv for non-darwin unix-like systems, the usual config directory for everyone else). For gpu shader cache and icc cache, controlling whether or not to write such files is done with the new --gpu-shader-cache and --icc-cache options respectively. Additionally, --cache-on-disk no longer requires explicitly setting the --cache-dir option. The old options, --cache-dir, --gpu-shader-cache-dir, and --icc-cache-dir simply set an override for the directory to save cache files. If unset, then the cache is saved in XDG_CACHE_HOME.
* various: fix various typos in the code baseAlexander Seiler2023-03-281-7/+7
| | | | Signed-off-by: Alexander Seiler <seileralex@gmail.com>
* demux_lavf: update to handle deprecation of `io_close`Philip Langdale2023-03-281-2/+24
| | | | | | | | `io_close2` was introduced as a superior replacement for `io_close` in ffmpeg 5.0, and then deprecated in 6.0. The difference is that `io_close2` can return errors. In our case, we're just calling through to the original function anyway, so we don't need to do more than pass the return value back.
* demux_mkv: support ARIB captionsrcombs2023-03-141-0/+38
|
* demux: propagate hls_bitrate and program_id in generated caption tracksrcombs2023-03-031-0/+2
|
* demux_lavf: report program_idrcombs2023-03-033-0/+5
| | | | This can be useful in stream selection.
* demux: constify a struct membersfan52023-02-241-3/+2
| | | | | Fixes a segfault when an invalid demuxer is given due to uninitialized use of `filename` after goto.
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-214-28/+28
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-204-7/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* demux: remove unused codeKacper Michajłow2023-02-021-4/+0
|
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-122-3/+3
| | | | | | | | In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
* various: replace if + abort() with MP_HANDLE_OOM()sfan52023-01-122-4/+2
| | | | | MP_HANDLE_OOM also aborts but calls assert() first, which will result in an useful message if compiled in debug mode.
* demux_mf: replace unsafe string functionssfan52023-01-121-4/+3
|
* demux: new packet should not point to source buffer when copying dataPhilip Langdale2023-01-061-1/+0
| | | | | | | In `new_demux_packet_from`, we initialise a new packet and allocate a buffer which we copy the source data into. But I was then assigning the original source pointer as the packet's buffer, rather than keeping the newly allocated one. Whoops.
* demux: actually initialise packet buffer when creating new packetPhilip Langdale2023-01-061-0/+1
| | | | | | | | When I refactored the code here to stop using stack allocated AVPackets, I forgot to assign `dp->buffer` after initialising the AVPacket. Fixes #11097
* demux: boost read EBU R128 gain values to ReplayGain's reference levelSimon Ruderich2023-01-041-0/+5
| | | | | | | | | | | | | Without this change the same track encoded as Opus - which requires R128 tagging - and e.g. Vorbis with ReplayGain tagging have different volumes. This is caused by ReplayGain 2 having a higher reference level of -18 dB LUFS, while EBU R128 has a lower reference level of -23 dB LUFS. For the results of gain application to match, the read EBU R128 values need to be boosted according to the difference in reference levels. Patch inspired by mpd's source code.
* demux: add --demuxer-hysteresis-secs option to save power with cachingSultan Alsawaf2022-12-301-3/+14
| | | | | | | | | | | | | | | | | | | | | | Buffering ahead nonstop into the cache results in nonstop disk or network activity to read stream data from wherever it may originate. Currently, there's no way to configure the demuxer to back off once it's buffered ahead enough data, since the cache limit will be perpetually not-reached as a stream continues to play, until the entire stream is eventually buffered. On a laptop with an i9-12900H with decoding performed by the iGPU, watching a locally-saved 1080p video which hasn't been buffered into the page cache consumes approximately 15 W even with caching enabled. When configuring a hysteresis to make the demuxer back off, power consumption drops to 9 W when watching the same video, resulting in a whopping 6 W of power savings. To make it possible to attain significant power savings via caching, add a --demuxer-hysteresis-secs option to configure a hysteresis to make the demuxer back off until there's only the configured number of seconds remaining in the cache from the current playback position. This feature is disabled by default.
* demux: replace deprecated usage of stack allocated AVPacketsPhilip Langdale2022-12-242-24/+45
| | | | | | | | | | | | | In the previous change, I replaced the callsites that used `av_init_packet`, but there are a handful of places that use stack allocated packets with no initialisation. In one case, I just switched to heap allocation as it's only done once per stream at most. In the other case, I removed our usage of the AVPackets as a convenience mechanism to transfer data into a heap allocated packet. Instead, I inlined the data copying.
* ffmpeg: increase minimum required version to 4.4Philip Langdale2022-12-011-4/+0
| | | | | | | | | Now that 0.35 has been released, we can consider increasing our minimum required ffmpeg version. Currently, we think 4.4 is the most recent version we can move to (from the current requirement of 4.0). This allows us to remove a few conditionals. There are more that we won't be able to remove unless we move further up to 5.1.
* demux/codec_tags: support more WAVEFORMATEXTENSIBLE tagsLeo Izen2022-11-011-8/+78
| | | | | | | | | This patch adds support for two extra WAVEFORMATEXTENSIBLE GUID tags that can appear inside RIFF headers. It also adds support for extra codec IDs that may appear as their own unique wSubFormats inside RIFF headers, such as ATRAC9 inside matroska, as one example. Fixes #10757.
* demux_mkv: add AVS2 and AVS3 to tag listNicolas F2022-10-211-0/+2
| | | | | | | Add support for playing back AVS2 and AVS3 video streams inside mkv containers if ffmpeg was compiled with avs2/avs3 support. Fixes: #10695
* demux_mf: add support for QOI, PHM and HDR imagesPaul B Mahol2022-10-151-0/+3
|
* demux_lavf: extract is_image functionGuido Cella2022-09-201-8/+13
|
* demux_lavf: detect avif imagesGuido Cella2022-09-201-1/+2
| | | | | Detect avif files with 1 frame as images. This works because AV1 videos and AVIF animations have nb_frames 0 or > 1.
* demux_lavf: switch to AVChannelLayout when availableJan Ekström2022-06-121-0/+14
|
* demux: stop iterating over demuxers as soon as a match is foundEmanuele Torre2022-05-211-1/+3
|
* demux: add support for r128 replaygain tagsdatasone2022-04-281-0/+13
|
* various: fix typosCœur2022-04-251-1/+1
|
* build: remove aviocontext bytes_read checkDudemanguy2022-01-251-4/+0
| | | | | | | | | | | | | | | | This define was always just a stopgap for that two month period (August 2021 - October 2021) where the bytes_read field in ffmpeg was completely missing. Before that time, it was a private member in a struct (which mpv used). Afterwards, it officially became public. Fortunately, the lack of this field never actually made it into a release, so it could have only possibly affected people building from the master branch. Since ffmpeg 5.0 came out recently, and it's been plenty of months since that two month window, we can go ahead and drop this check. This finishes up the work done in 78cfeee2b93830f2988508a653b508336147b79d. Sidenote: the cached ffmpeg version in the mingw ci were from that time period when the bytes_read field was missing. The N in the workflow is bumped to force a full rebuild and fresh clone of ffmpeg.
* demux/packet: replace deprecated av_init_packet()sfan52022-01-101-7/+5
|
* demux_lavf: properly forward dovi config recordNiklas Haas2022-01-091-0/+13
| | | | | | This needs to be forwarded from the AVStream to the AVPacket itself, so that it reaches the decoder. There exists an FFmpeg function for this, we just need to call it. (Also add some logging)
* demux_edl: rename ebml_defs.c to ebml_defs.incDudemanguy2021-11-141-1/+1
| | | | | | | | | | | The extension is completely arbitrary since ebml_defs.c isn't a real c file that actually is compiled at any point in time. It's just used as an include. The reason for changing the extension is because meson needs to add this to its list of sources for dependency/ordering purposes. Understandably, meson will try to compile any .c file added to a c project executable object. Obviously, this compilation will never succeed, and this shouldn't be compiled anyways. Just make it .inc instead.
* osdep: rename MP_UNREACHABLENiklas Haas2021-11-032-2/+2
| | | | | It was pointed out on IRC that the name is misleading, since the actual semantics of the macro is to assert first.
* osdep: add MP_UNREACHABLENiklas Haas2021-11-032-2/+2
| | | | | | | | | This seems to work on gcc, clang and mingw as-is, but I made it conditional on __GNUC__ just in case, even though I can't figure out which compilers we care about that don't export this define. Also replace all instances of assert(0) in the code by MP_UNREACHABLE(), which is a strict improvement.
* {wscript,demux_lavf}: clean up last bits of !FFMPEG_STRICT_ABIJan Ekström2021-10-261-6/+4
| | | | | | | | | | | | | | | | | The bytes_read struct member in AVIOContext is now officially public, so its usage no longer has to be specified as non-compliance with FFmpeg's ABI/API rules. That said, unfortunately there was a short period of time between August 2021 and October 2021 where the struct member did not exist in FFmpeg's git master, so keep a feature check for it alive for now to enable building with those versions. Thankfully, no release version of FFmpeg will be without this field, so it should be possible to drop this check with time. Finally, simplify the function in case the struct member is not found. After all, there is zero reason to iterate through the AVIO contexts if we cannot get the information we require.
* player: add track-list/N/image sub-propertyGuido Cella2021-10-145-1/+9
| | | | | | | | | | | | | | | | | | | | | | This exposes whether a video track is detected as an image, which is useful for profile conditions, property expansion and lavfi-complex. The lavf demuxer sets image to true when the existing check detects an image. When the lavf demuxer fails, the mf one guesses if the file is an image by its extension, so sh->image is set to true when the mf demuxer succeds and there's only one file. The mkv demuxer just sets image to true for any attached picture. The timeline demuxer just copies the value of image from source to destination. This sets image to true for attached pictures, standalone images and images added with !new_stream in EDL playlists, but it is imperfect since you could concatenate multiple images in an EDL playlist (which should be done with the mf demuxer anyway). This is good enough anyway since the comment of the modified function already says it is "Imperfect and arbitrary".
* demux_lavf: improve image detectionGuido Cella2021-10-141-9/+9
| | | | | | | | | | | | | | | | | | | | This moves the image check to where the number of frames is available of comparison, which allows not detecting jpg and png videos as images, and detecting 1-frame gifs as images. This works with the mjpeg and png videos in the FATE suite, though unfortunately the bmp video is still detected as an image since it has nb_frames = 0. aliaspix streams are also now considered images. Attached pictures are now treated like standalone images, so audio with attached pictures now has mf-fps as container-fps instead of unavailable, which makes it consistent with external cover art, which was already being assigned mf-fps. Unfortunately images in a codec commonly used for videos are never detected, and detection was inaccurate even using the now private codec_info_nb_frames field in AVStream, and mediainfo gets them wrong too, so I guess it's just a lost cause.
* Revert "player: add track-list/N/image sub-property"Jan Ekström2021-10-025-42/+10
| | | | | | | | Unfortunately, this functionality in large part based on a struct member that was made private in FFmpeg/FFmpeg@7489f632815c98ad58c3db71d1a5239b5dae266c in May. Unfortunately, this was not noticed during review. This reverts commit 0862664ac952d21fef531a8923a58ae575268fc5.
* player: add track-list/N/image sub-propertyGuido Cella2021-10-025-10/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This exposes whether a video track is detected as an image. This is useful for profile conditions, property expansion and lavfi-complex, and is more accurate than any detection even Lua scripts can perform, since they can't differentiate between images and videos without container-fps and audio and with duration 1 (which is the duration set by the mf demuxer with the default --mf-fps=1). The lavf demuxer image check is moved to where the number of frames is available for comparison, and is modified to check the number of frames and duration instead of the video codec. This doesn't misdetect videos in a codec commonly used for images (e.g. mjpeg) as images, and can detect images in a codec commonly used for videos (e.g. 1-frame gifs). pix files are also now detected as images, while before they weren't since the condition was checking if the AVInputFormat name ends with _pipe, and alias_pix doesn't. Both nb_frames and codec_info_nb_frames are checked because nb_frames is 0 for some video codecs (hevc, av1, vc1, mpeg1video, vp9 if forcing --demuxer=lavf), and codec_info_nb_frames is 1 for others (mpeg, mpeg4, wmv3). The duration is checked as well because for some uncommon codecs and containers found in FFMpeg's FATE suite, libavformat returns nb_frames = 0 and codec_info_nb_frames = 1. For some of them it even returns duration = 0, so they are blacklisted in order to never be considered images. The extra codecs that would have to be blacklisted without checking the duration are AV_CODEC_ID_4XM, AV_CODEC_ID_BINKVIDEO, AV_CODEC_ID_DSICINVIDEO, AV_CODEC_ID_ESCAPE130, AV_CODEC_ID_MMVIDEO, AV_CODEC_ID_NUV, AV_CODEC_ID_RL2, AV_CODEC_ID_SMACKVIDEO and AV_CODEC_ID_XAN_WC3, while the containers are film-cpk, ivf and ogg. The lower limit for duration is 10 because that's the duration of 1-frame gifs. Streams with codec_info_nb_frames 0 are not considered images because vp9 and av1 have nb_frames = 0 and codec_info_nb_frames = 0, and we can't rely on just the duration to detect them because they could be livestreams without an initial duration, and actually even if we could for these codecs libavformat returns huge negative durations like -9223372036854775808. Some more images in the FATE suite that are really frames cut from a video in an uncommon codec and container, like cine/bayer_gbrg8.cine, could be detected by allowing codec_info_nb_frames = 0, but then any present and future video codec with nb_frames = 0 and codec_info_nb_frames = 0 would need to be added to the blacklist. Some even have duration > 10, so to detect these images the duration check would have to be removed, and all the previously mentioned extra codecs and containers would have to be added added to the blacklists, which means that images that use them (if they exist anywhere) will never be detected. These FATE images aren't detected as such by mediainfo either anyway, nor can a Lua script reliably detect them as images since they have container-fps and duration > 0 and != 1, and you probably will never see files like them anywhere else. For attached pictures the lavf demuxer always set image to true, which is necessary because they have duration > 10. There is a minor change in behavior for which audio with attached pictures now has mf-fps as container-fps instead of unavailable, but this makes it consistent with external cover art, which was already being assigned mf-fps. When the lavf demuxer fails, the mf one guesses if the file is an image by its extension, so sh->image is set to true when the mf demuxer succeds and there's only one file. Even if you add a video's file type to --mf-type and open it with the mf protocol, only the first frame is used, so setting image to true is still accurate. When converting an image to the extensions listed in demux/demux_mf.c, tga and pam files are currently the only ones detected by the mf demuxer rather than lavf. Actually they are detected with the image2 format, but it is blacklisted; see d0fee0ac33a. The mkv demuxer just sets image to true for any attached picture. The timeline demuxer just copies the value of image from source to destination. This sets image to true for attached pictures, standalone images and images added with !new_stream in EDL playlists, but it is imperfect since you could concatenate multiple images in an EDL playlist (which should be done with the mf demuxer anyway). This is good enough anyway since the comment of the modified function already says it is "Imperfect and arbitrary".
* demux_mkv: enable AVCodec parser timestamp usage for parsed audioDan Oscarsson2021-09-211-0/+4
| | | | | | | | | Without this, cases where the parser cannot return data right away will end up utilizing the following fed packet's timestamps. This will in turn cause an unnecessary offset in the audio stream timestamps. An example of such buffered parser in libavcodec is the EAC3 one.
* demux_playlist: extend maximum line size (again) to 2MAvi Halachmi (:avih)2021-09-061-1/+1
| | | | | | | | | | | | | | | | | | Last time it was extended was de3ecc60 from 8K to 512K two years ago. The issue currently is that youtube EDL files can get very big. Size of about 520K (one line), was observed, at the time of writing: mpv https://youtube.com/watch?v=DBzFQgSMHdQ --ytdl-format=299 ytdl_hook.lua is unaffected by this because EDL lists don't go through the file reader at demux_playlist.c (where each line was limited to 512K before this commit), however, EDL files on disk which are loaded with --playlist=file.edl do. Increase the limit to 2M so that such EDL files can also be loaded from disk. Fixes #9186
* demux: acquire lock before calling update_bytes_readShreesh Adiga2021-07-131-2/+2
| | | | | | | | in->byte_level_seeks field is written and modified inside update_bytes_read at the same time when demux_get_reader_state is executing, which locks the demux thread mutex. This results in a data race, reported by Thread Sanitizer when playing mp3 file of sufficient long length.
* recorder: add support for attachments (fonts)TheAMM2021-07-081-1/+10
| | | | | | Though, only when the output format is matroska, to avoid muxing errors. This is quite useful when the input has ASS subtitles, as they tend to rely on embedded fonts.
* demux, dump-cache: fix demux cache range sortingTheAMM2021-07-081-2/+2
| | |