summaryrefslogtreecommitdiffstats
path: root/demux/demux.c
Commit message (Collapse)AuthorAgeFilesLines
* demux: fix seek ranges of imagesGuido Cella13 days1-1/+1
| | | | | | | | | | | When a video-reconfig occurs with an image, the cache is not used because find_cache_seek_range() checks if the start time was initialized, but for images it stays at MP_NOPTS_VALUE. This makes rotating large network images slow because they are re-downloaded on every rotation. Fix this by setting the timestamps of image cache ranges by altering a condition.
* demux: clarify the meaning of still_imageGuido Cella2024-02-111-1/+1
| | | | | Clarify that ffmpeg sets AV_DISPOSITION_STILL_IMAGE for sparse videos like https://s3.amazonaws.com/tmm1/music-choice.ts, not for images.
* demux: add missing NULL checkKacper Michajłow2023-11-181-0/+1
| | | | It is assigned to NULL above is !stream.
* demux: always update the cache on initDudemanguy2023-11-121-1/+1
| | | | | | | | | | | | | cd59ea8afab6381951a3ae19a43e422906d02164 removed an arbitrary start offset added to the timer. However, it turns out that demux secretly depends on this. When updating cache to actually read bytes from the stream, there's a diff >= MP_TIME_S_TO_NS(1) check to make it only update once every second. With the old MP_START_TIME macro, the initial time value would always be at least 1e10, so this would also be true. Since we don't have that offset anymore, now the initial time is less than that so it is not updated and properties like file-size are 0. Just be sure to always update if the last_speed_query is 0 (i.e. we just started the player). Fixes #12869.
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-051-100/+98
|
* demux: make hysteresis-secs respect cache-secsNRK2023-10-301-1/+3
| | | | | | | | | | | | currently hysteresis-secs only works when the demuxer-max-bytes fills up. but it's possible for the cache-secs/demuxer-readahead-secs to be reached first. in those cases, hysteresis-secs doesn't work and keeps buffering non-stop. but the goal of this option was to save power by avoiding non-stop buffering so go ahead and make it respect cache-secs as well. additionally remove some redundant repetition from the docs.
* demux: cosmeticsNRK2023-10-301-6/+5
| | | | | - brace goes to next line for multi-line conditional - sort standard headers some more
* various: sort some standard headersNRK2023-10-201-5/+5
| | | | | | | | | | | | since i was going to fix the include order of stdatomic, might as well sort the surrouding includes in accordance with the project's coding style. some headers can sometime require specific include order. standard library headers usually don't. but mpv might "hack into" the standard headers (e.g pthreads) so that complicates things a bit more. hopefully nothing breaks. if it does, the style guide is to blame.
* osdep: remove atomic.hNRK2023-10-201-1/+1
| | | | | | | replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with explicit _Atomic qualified types. also add missing config.h includes on some files.
* demux: convert cache updates to nanosecondsDudemanguy2023-10-161-6/+6
| | | | As a bonus, we can remove the awkward and horribly named MP_SECOND_US.
* demux: change the default of metadata-codepage to autoDudemanguy2023-10-071-1/+1
| | | | | | | There's really no reason not to do this especially since sub-codepage already defaults to auto. Also change logging in charset_conv since telling us that the data is UTF-8 if the passed codepage value is "auto" or "utf-8" is really not useful information (that's the expectation).
* demux: move parent_stream_info before the gotoDudemanguy2023-10-011-9/+9
| | | | | | Previously if the demuxer didn't exist, then it could jump down and try to free sinfo.filename before it was ever set thus segfaulting. Just always set the struct unconditionally so we're always sure to free it.
* Revert "demux: constify a struct member"Dudemanguy2023-10-011-2/+3
| | | | | | | | | | Some demuxers actually close the stream right after they are finished opening like cue. Since the stream->url is no longer copied with this commit, that means it gets thrown away after the stream closes. This leads to a use after free. We still need to allocate stream->url so fix this another way. This reverts commit 3e85df3b2d89d6a27806d677b6b8a99055cb1fcc.
* demux: fix erroneous condition in lazy_stream_needs_waitDudemanguy2023-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Yeah another try at this. So when inspecting lazy_stream_needs_wait, I realized it had a curious !ds->reader_head condition. Actually, this is what is messing everything up. This was originally added in cf2b7a4997299ff9e0ff91d4273cd294686b001f for showing large negative sub delay values correctly. It worked because the packet will eventually be discarded during playback causing ds->reader_head not exist and thus the next one will correctly be read ahead as needed. But for the "switching subtitle tracks while paused" case, this is actually bad. As the stream is read, eventually you'll find a packet and set the reader_head. But it's not going to be the correct packet (unless you're looking for the very first one), so you need to read more. This won't happen because of the !ds->reader_head check and unlike the sub delay case, nothing will eventually discard that packet since playback isn't occuring. So read_packet exits earlier than it should and isn't tried again, so the subtitle that you want won't show since the returned packet has the wrong pts. All that needs to be done here is to delete this one condition. There's already checks in place to make sure that it's not read past the desired timestamp and for the sub delay case (the only other time this logic is used), it makes no difference since you won't read past the specified pts in the first place.
* Revert "demux: improve stream selection state"Dudemanguy2023-09-301-9/+8
| | | | | | | | The stream selection state wasn't improved. I didn't realize this messed with caches. All in all, just not a good idea. Back to drawing board I guess. This reverts commit f40bbfec4fcd2d9a787a4d98ec7698a646e5607e.
* timer: rename mp_time_us_to_timespec to reflect what it actually doesKacper Michajłow2023-09-291-1/+1
|
* demux: improve stream selection stateDudemanguy2023-09-271-8/+9
| | | | | | | | | | | | | | | | | | | | | | | This replaces the previous commit and makes more sense. The internal demux marked tracks as eager depending on their type and for subtitles it would always lazily read them unless there happened to be no available av stream. However, we want the sub stream to be eager if the player is paused. The existing subtitle is still preserved on the screen, but if the user changes tracks that's when the problem occurs. So to handle this case, propagate the mpctx->paused down to the stream selection logic. This modifies both demuxer_refresh_track and demuxer_select_track to take that boolean value. A few other parts of the player use this, but we can just assume false there (no change in behavior from before) since they should never be related to subtitles. The core player code is aware of its own state naturally, and can always pass the appropriate value so go ahead and do so. When we change the pause state, a refresh seek is done on all existing subtitle tracks to make sure their eager state is the appropriate value (i.e. so it's not still set to eager after a pause and a track switch). Slightly invasive change, but it works with the existing logic instead of going around it so ultimately it should be a better approach. We can additionally remove the old force boolean from sub_read_packets since it is no longer needed.
* Revert "demux: eagerly read subtitle streams when switching tracks while paused"Dudemanguy2023-09-271-8/+3
| | | | | | | Actually, I thought of a better way of handling this shortly after merging this. Revert it and redo it in the next commit. This reverts commit c2c157ebeca3d072d4f48ff36228d01ebe888699.
* demux: eagerly read subtitle streams when switching tracks while pausedDudemanguy2023-09-271-3/+8
| | | | | | | | | | | | | | | | | a323dfae426e43451f4d3e08a9a63cb7d1c1ace9 almost fixed subtitle tracks disappearing when paused but it actually missed one part: the behavior of demux_read_packet_async_until. It's a bit unintuitive, but for subtitle streams, that function would only return the very first packet regardless of whatever pts you pass to it. So the previous commit worked on the very first subtitle, but not actually any of the others (oops). This is because subtitle streams never marked as eager and thus never actually read farther ahead. While the video is playing, this is OK, but if we're paused and switching subtitle tracks then the stream should be eagerly read. Luckily, the logic is already there in the function for this. All we have to do add an extra argument to demux_read_packet_async_until to force the stream to be read eagerly and then it just works. Be sure to unset the eager flag when we're done. Actually fixes the bug for real this time.
* demux: make demux opts publicDudemanguy2023-09-221-43/+17
| | | | | | | Several parts of the code need to access options here. There's no point in hiding it demux.c so just expose it in the demux.h header. This means pulling it out of demux_internal and putting it in the demuxer struct instead.
* options: move some demux-specific opts to demux optsDudemanguy2023-09-221-0/+8
| | | | | These options are only ever accessed by the demuxer and have no need to be in MPOpts. Move them to demux.c instead.
* options: remove a few options marked with .deprecation_messageDudemanguy2023-09-211-4/+1
| | | | | | | | | | | A bit different from the OPT_REPLACED/OPT_REMOVED ones in that the options still possibly do something but they have a deprecation message. Most of these are old and have no real usage. The only potentially controversial ones are the removal of --oaffset and --ovoffset which were deprecated years ago and seemingly have no real replacement. There's a cryptic message about --audio-delay but who knows. The less encoding mode code we have, the better so just chuck it.
* various: fix various typos in the code baseAlexander Seiler2023-03-281-7/+7
| | | | Signed-off-by: Alexander Seiler <seileralex@gmail.com>
* demux: propagate hls_bitrate and program_id in generated caption tracksrcombs2023-03-031-0/+2
|
* demux_lavf: report program_idrcombs2023-03-031-0/+1
| | | | 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-211-14/+14
| | | | | | 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.
* demux: remove unused codeKacper Michajłow2023-02-021-4/+0
|
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-121-1/+1
| | | | | | | | 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-121-2/+1
| | | | | MP_HANDLE_OOM also aborts but calls assert() first, which will result in an useful message if compiled in debug mode.
* 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: 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
|
* osdep: rename MP_UNREACHABLENiklas Haas2021-11-031-1/+1
| | | | | 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-031-1/+1
| | | | | | | | | 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.
* 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
| | | | | | | dump_cache() calls qsort() to order an array of pointers, while the comparator forgets it's receiving pointers to pointers. Since cache-dumping over multiple cache ranges is fairly rare, this seems to have gone unnoticed.
* demux: undeprecate --cache-secssfan52021-04-081-2/+1
| | | | | It serves a purpose and a rework of the cache won't be coming anytime soon. This partially reverts commit 8427292eb7c4074e1205c3d73c53c9e82569325f.
* demux: Move demuxer help to new standard mechanismPhilip Langdale2021-03-281-1/+4
| | | | | Previously, demux help was handled as a special case in main.c and this is no longer necessary.
* demux: add function to refresh a track without (de-)selecting itsfan52020-11-271-0/+20
|
* Revert "demux: add a POS"wm42020-10-081-4/+0
| | | | | | This reverts commit 4f18e7927bacd2e887f8cca48a967804ce7adf86. It was a mistake, and barely anyone needs this.
* demux: add a POSwm42020-10-081-0/+4
| | | | | | I regret doing this so much, it's fucking garbage. Fixes: #5100
* command, demux: make drop-buffers reset state even harderwm42020-09-171-2/+9
| | | | Leave nothing left when it's executed.
* demux: don't let --sub-create-cc-track add a track for attached pictureswm42020-04-131-1/+1
| | | | | | | | Unfortunately, attached pictures (from tags etc.) are treated as video tracks. That meant --sub-create-cc-track added a CC track for them as well. Stop doing that. See: #7608
* stats: some more performance graphswm42020-04-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
* demux: average reported download speed some morewm42020-03-211-1/+5
| | | | | | Currently, this reported the number of received bytes per second. Improve this slightly by averaging over 2 seconds (but still updating every second).
* options: fix OPT_BYTE_SIZE upper limitswm42020-03-181-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | As an unfortunate disaster, min/max values use the type double, which causes tons of issues with int64_t types. Anyway, OPT_BYTE_SIZE is often used as maximum for size_t quantities, which can have a size different from (u)int64_t. OPT_BYTE_SIZE still uses in64_t, because in theory, you could use it for file sizes. (demux.c would for example be capable of caching more than 2GB on 32 bit platforms if a file cache is used. Though for some reason the accounting code still uses size_t, so that use case is broken. But still insist that it _could_ be used this way.) There were various inconsistent attempts to set m_option.max to a value such that the size_t/int64_t upper limit is not exceeded. Due to the double max field, this didn't really work correctly. Try to fix this with the M_MAX_MEM_BYTES constant. It's a good approximation, because on 32 bit it should allow 2GB (untested, also would probably exhaust address space in practice but whatever), and something "high enough" in 64 bit. For some reason, clang 11 still warns. But I think this might be a clang bug, or I'm crazy. The result is correct anyway.
* options: change option macros and all option declarationswm42020-03-181-27/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* options: change how option range min/max is handledwm42020-03-131-4/+6
| | | | | | | | | | | | | | | | | Before this commit, option declarations used M_OPT_MIN/M_OPT_MAX (and some other identifiers based on these) to signal whether an option had min/max values. Remove these flags, and make it use a range implicitly on the condition if min<max is true. This requires care in all cases when only M_OPT_MIN or M_OPT_MAX were set (instead of both). Generally, the commit replaces all these instances with using DBL_MAX/DBL_MIN for the "unset" part of the range. This also happens to fix some cases where you could pass over-large values to integer options, which were silently truncated, but now cause an error. This commit has some higher potential for regressions.
* demux: bump --cache-secs default valuewm42020-03-071-1/+1
| | | | | | Change to it 1000 hours, which is "infinite" enough. (Hesitant to use INFINITY, as that is not in the option's range. The option parser rejects it because it causes only problems in API users and so on.)
* demux: mark recently added debug option as deprecatedwm42020-03-071-1/+2
| | | | | It was the intention to remove it again after a release or two; mark it was deprecated so nobody thinks it gets to stay.
* demux: deprecate --cache-secswm42020-03-051-1/+2
| | | | | Because it's confusing and useless. If nobody complains, we'll have one weird cache configuration option less.
* demux: another hack to deal with track switching refreshwm42020-02-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The demuxer cache employs a strange method to make track switching instant with caching enabled. Normally this would mean you have to wait until the cache has played out (and you get new packets, including packets from the newly selected track), or you have to perform a slow high level seek (decoding video again etc.). The strange method is that it performs a demuxer-level seek with