summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* stream: silence failed seek message on terminationwm42018-12-061-1/+2
| | | | | | Seems to happen often with ytdl pseudo-DASH streams, so whatever. I couldn't reproduce it and check what triggers it, I just remember seeing the error message and found it annoying.
* stream: somethingwm42018-12-061-3/+4
|
* vo, vo_gpu, glx: correct GLX_OML_sync_control usagewm42018-12-063-84/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I misunderstood how this extension works. If I understand it correctly now, it's worse than I thought. They key thing is that the (ust, msc, sbc) tripple is not for a single swap event. Instead, (ust, msc) run independently from sbc. Assuming a CFR display/compositor, this means you can at best know the vsync phase and frequency, but not the exact time a sbc changed value. There is GLX_INTEL_swap_event, which might work as expected, but it has no EGL equivalent (while GLX_OML_sync_control does, in theory). Redo the context_glx sync code. Now it's either more correct or less correct. I wanted to add proper skip detection (if a vsync gets skipped due to rendering taking too long and other problems), but it turned out to be too complex, so only some unused fields in vo.h are left of it. The "generic" skip detection has to do. The vsync_duration field is also unused by vo.c. Actually this seems to be an improvement. In cases where the flip call timing is off, but the real driver-level timing apparently still works, this will not report vsync skips or higher vsync jitter anymore. I could observe this with screenshots and fullscreen switching. On the other hand, maybe it just introduces an A/V offset or so. Why the fuck can't there be a proper API for retrieving these statistics? I'm not even asking for much.
* demux_mkv: simplify avi compat. codec_tags.c GUID lookupwm42018-12-061-13/+3
| | | | | | | The redundancy here always annoyed me. Back then I didn't change it because it's hard to test and I just had fixed something. This doesn't matter anymore, so simplify it, without testing and with the risk that something breaks (why care).
* demux: remove some dead codewm42018-12-062-10/+0
| | | | | No idea what that shit is. Likely forgotten when timed metadata was introduced, and some of the old mechanisms were replaced.
* demux: add another stream recording featurewm42018-12-065-4/+53
| | | | | | --record-file is nice, but only sometimes. If you watch some sort of livestream which you want to record, it's actually much nicer not to record what you're currently "seeing", but anything you're receiving.
* demux_lavf: to get effective HLS bitratewm42018-12-061-1/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, this could be easily done with custom I/O. In practice, all the halfassed garbage in FFmpeg shits itself and fucks up like there's no tomorrow. There are several problems: 1. FFmpeg pretends you can do custom I/O, but in reality there's a lot that custom I/O can do. hls.c even contains explicit checks to disable important things if custom I/O is used! In particular, you can't use the HTTP keepalive functionality (needed for somewhat decent HLS performance), because some cranky asshole in the cursed FFmpeg dev. community blocked it. 2. The implementation of nested I/O callbacks (io_open/io_close) is bogus and halfassed (like everything in FFmpeg, really). It will call io_open on some URLs without ever calling io_close. Instead, it'll call avio_close() on the context directly. From what I can tell, avio_close() is incompable to custom I/O anyway (overwhelmed by their own garbage, the fFmpeg devs created the io_close callback for this reason, because they couldn't fix their own fucking garbage). This commit adds some shitty workaround for this (technically triggers UB, but with that garbage heap of a library we depend on it's not like it matters). 3. Even then, you can't proxy I/O contexts (see 1.), but we can just keep track of the opened nested I/O contexts. The bytes_read is documented as not public, but reading it is literally the only way to get what we want. A more reasonable approach would probably be using curl. It could transparently handle the keep-alive thing, as well as propagating cookies etc. (which doesn't work with the FFmpeg approach if you use custom I/O). Of course even better if there were an independent HLS implementation anywhere. FFmpeg's HLS support is so embarrassing pathetic and just goes to show that they belong into the past (multimedia from 2000-2010) and should either modernize or fuck off. With FFmpeg's shit-crusted structures, todic communities, and retarded assholes denying progress, probably the latter. Did I already mention that FFmpeg is a shit fucked steaming pile of garbage shit? And all just to get some basic I/O stats, that any proper HLS consumer requires in order to implement adaptive streaming correctly (i.e. browser based players, and nothing FFmshit based).
* demux, stream: readd cache-speed in some other formwm42018-12-067-1/+70
| | | | it's more like an input speed rather than a cache speed, but who cares.
* vo: use a struct for vsync feedback stuffwm42018-12-067-36/+52
| | | | So new useless stuff can be easily added.
* vo_gpu: glx: use GLX_OML_sync_control for better vsync reportingwm42018-12-067-0/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the extension to compute the (hopefully correct) video delay and vsync phase. This is very fuzzy, because the latency will suddenly be applied after some frames have already been shown. This means there _will_ be "jumps" in the time accounting, which can lead to strange effects at start of playback (such as making initial "dropped" etc. frames worse). The only reasonable way to fix this would be running a few dummy frame swaps at start of playback until the latency is known. The same happens when unpausing. This only affects display-sync mode. Correct function was not confirmed. It only "looks right". I don't have the equipment to make scientifically correct measurements. A potentially bad thing is that we trust the timestamps we're receiving. Out of bounds timestamps could wreak havoc. On the other hand, this will probably cause the higher level code to panic and just disable DS. As a further caveat, this makes a bunch of assumptions about UST timestamps. If there are delayed frames (i.e. we skipped one or more vsyncs), the latency logic is mostly reset. There is no attempt to make the vo.c skipped vsync logic to use this. Also, the latency computation determines a vsync duration, and there's no effort to reconcile or share the vo.c logic for determining vsync duration.
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-0598-3147/+3936
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * demux, stream: rip out the classic stream cachewm42018-08-3127-1467/+49
| | | | | | | | | | | | The demuxer cache is the only cache now. Might need another change to combat seeking failures in mp4 etc. The only bad thing is the loss of cache-speed, which was sort of nice to have.
| * rendezvous: fix a typowm42018-08-311-1/+1
| |
| * demux: allow cache sizes > 2GBwm42018-08-241-4/+8
| | | | | | | | | | There was no reason to limit this. Only some int fields had to be changed to size_t.
| * demux_lavf: v4l streams are not seekablewm42018-08-241-0/+2
| | | | | | | | | | | | | | FFmpeg is retarded enough not to give us any indication whether it is (unless we query fields not in the ABI/API). I bet FFmpeg developers love it when library users have to litter their code with duplicated information.
| * player: don't print status line again when quittingwm42018-08-111-2/+5
| | | | | | | | | | | | | | | | Quitting is slightly asynchronous, so the status line can be updated again. Normally, that's fine, but if quitting comes with a message (such as with quit_watch_later), it will print the status line again after the message, which looks annoying. So flush and clear the status message if it's updated during quitting.
| * HACK: prefetch subtitles on track switch a bit morewm42018-06-301-1/+4
| | | | | | | | To get overlapping shit etc.
| * player: don't cache subtitles across deselectionwm42018-06-302-6/+6
| | | | | | | | | | This means reselection triggers full reinit. This is better if you have options that "edit" subtitles or whatever.
| * player: fix coding stylewm42018-05-241-3/+3
| | | | | | | | | | I'm also not sure whether this condition doesn't subtly break a lot of things.
| * m_config: remove a redundant conditionwm42018-05-241-3/+1
| | | | | | | | Always true, because a few lines above it checks for the same thing.
| * demux_lavf: drop obscure genpts optionwm42018-05-242-11/+0
| | | | | | | | | | This code shouldn't even exist in libavformat. If you still need it, you can enable it via --demuxer-lavf-o.
| * vo: remove bogus #ifwm42018-05-241-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | If anyone happened to build with GL disabled, this could lead to option changes not always refreshing the screen. Since vo_gpu is always enabled now (just not necessarily any backend for it), we can drop the #if completely. (The way this works is a bit idiotic - the option cache exists only to grab the change notification, which will trigger a redraw and make vo_gpu update its own second copy of them. But at least it avoids some layering issues for now.)
| * terminal-unix: stop trying to read when terminal disappearswm42018-05-241-2/+4
| | | | | | | | | | | | | | | | Avoids 100% CPU usage due to terminal code retrying read(). Seems like this was "forgotten" (or there was somehow the assumption poll() would not signal POLLIN anymore). Fixes #5842.
| * options: add --http-proxywm42018-05-242-0/+11
| | | | | | | | Often requested, trivial.
| * command: avoid some direct MPOpts write accesseswm42018-05-241-7/+7
| | | | | | | | | | | | | | | | | | | | | | This is working towards a change intended in the future: nothing should write to the option struct directly, but use functions that raise proper notifications. Until this is complete it will take a while, and this commit does not change all cases of direct access, just some simple ones. In all of these 3 changes, the actual write access is done by the generic property-option bridge.
| * m_config: fix build with emulated stdatomicwm42018-05-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | C11 can access atomic variables normally (in which case they use the strictest memory access semantics). But the mpv stdatomic wrapper for C99 compilers does not allow it, because it couldn't give any guarantees. This means we always need to access them with atomic macros. While we're at, use relaxed semantics for the m_config_cache field, since because it's accessed from a single thread only (essentially used in a non-atomic way). Switch the comparison arguments to make the formatting look slightly less weird.
| * m_config: make m_config_cache_update() return more fine grainedwm42018-05-241-3/+7
| | | | | | | | | | | | | | | | | | Although the new code actually fires update notifications only when needed, m_config_cache_update() itself returned a rather coarse change value, which could indicate change even if none of the cached options were changed. On top of that, some code (like vo_gpu) calls the update function on every frame, which would reconfigure the renderer even on unrelated option changes.
| * player: get rid of mpv_global.optswm42018-05-2416-63/+75
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
| * vd_lavc: move hwdec opts to local config, don't use global MPOptswm42018-05-244-43/+50
| | | | | | | | | | | | | | The --hwdec* options are a good fit for the vd_lavc local option struct. This annoyingly requires manual prefixing of most of these options with --vd-lavc (could be avoided by using more sub-struct craziness, but let's not).
| * path: don't access global option structwm42018-05-244-7/+20
| | | | | | | | | | | | | | The path functions need to access the option that forces non-default config directories. Just add it as a field to mpv_global - it seems justified. The accessed options were always enforced as immutable after init, so there's not much of a change.
| * m_config: add a special define to access main configwm42018-05-242-5/+7
| | | | | | | | | | | | | | | | Passing NULL to mp_get_config_group() returns the main option struct. This is just a dumb hack to deal with inconsistencies caused by legacy things (as I'll claim), and will probably be changed in the future. So before littering the whole code base with hard to find NULL parameters, require using callers an easy to find separate define.
| * ao: use a local option structwm42018-05-246-19/+44
| | | | | | | | Instead of accessing MPOpts.
| * player: remove deprecated vo/ao auto profileswm42018-05-242-9/+2
| | | | | | | | | | These were deprecated almost 2 years ago. Now they happen to be in the way.
| * m_config: optimize initialization of each optionwm42018-05-241-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Options with dynamic memory allocations (such as strings) require some care. They need to be fully copied on initialization, and if a static default value was declared, we must not free that value either. Instead of going through the entire thing even for simple types like integers, really run it only for options with dynamic allocations. To distinguish types which use dynamic allocations, we can use the fact that they require a free callback (otherwise they would leak). As a result initialization of simple types becomes chaper, and the init function does nothing at all if src==dst for a simple type. (It's funny how mplayer had M_OPT_TYPE_DYNAMIC since 2002, until we replaced it by the same heuristic as used here in commit 3bb134969eb6. It's also funny how the new check was used only for some asserts, and finally removed in commit 7539928c1c. I guess at this time I felt like having uniform code was more important than pointless micro-optimizations.) The src==NULL case is removed because it can't happen.
| * m_config: remove extra default_data fieldwm42018-05-243-20/+29
| | | | | | | | Just wastes memory (a few KB, because there are so many options).
| * m_config: remove unused fieldswm42018-05-242-8/+2
| |
| * build: prefer C11 modewm42018-05-241-1/+6
| | | | | | | | | | | | C99 still works, but in theory we're using C11 features already, such as stdatomic.h. gcc/clang let us use it in C99 mode too, but using C11 is at least more proper.
| * m_config: reduce redundant option change notificationswm42018-05-241-1/+1
| |
| * m_config: remove an old temporary hackwm42018-05-242-308/+336
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actually rewrite most of the option management code. This affects how options are allocated, and how thread-safe access to them is done. One thing that is nicer is that creating m_config_cache does not need to ridiculously recreate and store the entire option list again. Instead, option metadata and option storage are now separated. m_config contains the metadata, and m_config_data all or parts of the actual option values. (m_config_cache simply uses the metadata part of m_config, which is immutable after creation.) The mentioned hack was introduced in commit 1a2319f3e4cc4, and is the global state around g_group_mutex. Although it was "benign" global state, it's good that it's finally removed.
| * osdep: add portable C11-like alignof() macrowm42018-05-241-0/+5
| |
| * m_config: remove outdated commentwm42018-05-241-1/+0
| |
| * m_config: check for int16_t offset overflowwm42018-05-241-1/+3
| | | | | | | | | | | | | | | | For some reason shadow_offset is a int16_t variable (to save some space or something), which means the static part of the entire option list must be below 32KB. This is fine, but still add a check against overflows. (Currently it's 3.6KB. This does not include dynamic allocations like strings.)
| * m_config: remove an unused functionwm42018-05-242-15/+0
| |
| * m_option: remove an unused fieldwm42018-05-242-13/+0
| |
| * m_config: cosmetics: fix 2 typoswm42018-05-241-2/+2
| |
| * input: remove now unused "abort command" and cancel infrastructurewm42018-05-245-75/+7
| | | | | | | | The previous commit removed all uses.
| * player: make playback termination asynchronouswm42018-05-248-32/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, stopping playback aborted the demuxer and I/O layer violently by signaling mp_cancel (bound to libavformat's AVIOInterruptCB mechanism). Change it to try closing them gracefully. The main purpose is to silence those libavformat errors that happen when you request termination. Most of libavformat barely cares about the termination mechanism (AVIOInterruptCB), and essentially it's like the network connection is abruptly severed, or file I/O suddenly returns I/O errors. There were issues with dumb TLS warnings, parsers complaining about incomplete data, and some special protocols that require server communication to gracefully disconnect. We still want to abort it forcefully if it refuses to terminate on its own, so a timeout is required. Users can set the timeout to 0, which should give them the old behavior. This also removes the old mechanism that treats certain commands (like "quit") specially, and tries to terminate the demuxers even if the core is currently frozen. This is for situations where the core synchronized to the demuxer or stream layer while network is unresponsive. This in turn can only happen due to the "program" or "cache-size" properties in the current code (see one of the previous commits). Also, the old mechanism doesn't fit particularly well with the new one. We wouldn't want to abort playback immediately on a "quit" command - the new code is all about giving it a chance to end it gracefully. We'd need some sort of watchdog thread or something equally complicated to handle this. So just remove it. The change in osd.c is to prevent that it clears the status line while waiting for termination. The normal status line code doesn't output anything useful at this point, and the code path taken clears it, both of which is an annoying behavior change, so just let it show the old one.
| * player: change the role of the "stop_play" and "playing" variablewm42018-05-245-18/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this, mpctx->playing was often used to determine whether certain new state could be added to the playback state. In particular this affected external files (which added tracks and demuxers). The variable was checked to prevent that they were added before the corresponding uninit code. We want to make a small part of uninit asynchronous, but mpctx->playing needs to stay in the place where it is. It can't be used for this purpose anymore. Use mpctx->stop_play instead. Make it never have the value 0 outside of loading/playback. On unloading, it obviously has to be non-0. Change some other code in playloop.c to use this, because it seems slightly more correct. But mostly this is preparation for the following commit.
| * demux: add a way to destroy the demuxer asynchronouslywm42018-05-242-8/+93
| | | | | | | | |