summaryrefslogtreecommitdiffstats
path: root/mpvcore
Commit message (Collapse)AuthorAgeFilesLines
* video: display last frame, drain frames on video reconfigwm42013-12-103-10/+87
| | | | | | | | | | | | | | | | | | | | | | Until now, the player didn't care to drain frames on video reconfig. Instead, the VO was reconfigured (i.e. resized) before the queued frames finished displaying. This can for example be observed by passing multiple images with different size as mf:// filename. Then the window would resize one frame before image with the new size is displayed. With --vo=vdpau, the effect is worse, because this VO queues more than 1 frame internally. Fix this by explicitly draining buffered frames before video reconfig. Raise the display time of the last frame. Otherwise, the last frame would be shown for a very short time only. This usually doesn't matter, but helps when playing image files. This is a byproduct of frame draining, because normally, video timing is based on the frames queued to the VO, and we can't do that with frames of different size or format. So we pretend that the frame before the change is the last frame in order to time it. This code is incorrect though: it tries to use the framerate, which often doesn't make sense. But it's good enough to test this code with mf://.
* video: move VO reinit from filter chain to playerwm42013-12-101-30/+56
| | | | | | | | | This gets rid of the vf_vo pseudo-filter. It ends the idea of MPlayer's architecture that the VO is just a (terminating) video filter. It didn't really work for us with respect to video timing (the "end" of the video chain isn't really made for video timing, and making it do so would be awkward), and now we're removing it entirely. We will be able to fix some things, such as properly draining video on reconfiguration.
* video: move handling of brightness and deinterlacing controlwm42013-12-102-6/+7
| | | | | Handling of brightness/gamma/saturation/etc. and deinterlacing is moved from vf_vo.c to dec_video.c.
* video: move video filter chain initialization from decoder to playerwm42013-12-103-21/+41
| | | | | | | | | | | | | This should help fixing some issues (like not draining video frames correctly on reinit), as well as decoupling the decoder, filter chain, and VO code. I also wanted to make the hardware video decoding fallback work properly if software-only video filters are inserted. This currently has the issue that the fallback is too violent, and throws away a bunch of demuxer packets needed to restart software decoding properly. But keeping "backup" packets turned out as too hacky, so I'm not doing this, at least not yet.
* options: allow hwaccel formats in -vf format/noformatwm42013-12-071-1/+1
| | | | | | | There are 3 users of the image format option type: demux_raw, vf_format, vf_noformat. Allow the hwaccel formats (like vdpau etc.) in general, so that the filters can use it. This won't work for demux_raw, so explicitly reject these formats there.
* video: create a separate context for video filter chainwm42013-12-074-23/+22
| | | | | | This adds vf_chain, which unlike vf_instance refers to the filter chain as a whole. This makes the filter API less awkward, and will allow handling format negotiation better.
* command: fix compilation with MinGWwm42013-12-071-1/+3
| | | | | This include header is needed for the fork/exec code, which is inactive on Windows anyway.
* player: load external subs for uncompressed rar archiveswm42013-12-061-3/+10
| | | | | | | | | | | | Uncompressed rar archives can be transparently opened, but the filename the player doesn't have the direct filename (but something starting with rar://... instead). This will lead to external subtitles not being loaded. This doesn't handle multi-volume rar files, but in that cases just use the --autosub-match=fuzzy option. Fixes #397 on github.
* video: remove --flipwm42013-12-052-3/+0
| | | | | | | | | | | | | | | | The --flip option flipped the image upside-down, by trying to use VO support, or if not available, by inserting a video filter. I'm not sure why it existed. Maybe it was important in ancient times when VfW based decoders output an image this way (but even then, flipping an image is a free operation by negating the stride). One nice thing about this is that it provided a possible path for implementing video orientation, which is a feature we should probably support eventually. The important part is that it would be for free for VOs that support it, and would work even with hardware decoding. But for now get rid of it. It's useless, trivial, stands in the way, and supporting video orientation would require solving other problems first.
* video: allow hardware decoding only for certain codecswm42013-12-051-1/+1
| | | | | | | | | | In particular, this disables mpeg4. There are some files out there that use GMC, a usually rarely used and ineffective feature, which is not supported by most hardware decoders. In these cases the hw decoder outputs garbage, while software decoding works perfectly fine. We can't really fallback to software decoding in these cases, because we don't know that something is wrong in the first place. I can't see any advantages of hw decoding of mpeg4, so it's better to disable it.
* options: remove legacy hacks for sub-option handlingwm42013-12-044-76/+13
|
* ad_lavc: expose an option to enable threadingwm42013-12-042-0/+2
|
* vd_lavc: factor out libavcodec thread setupwm42013-12-042-0/+20
|
* av_common: add timebase parameter to mp_set_av_packet()wm42013-12-042-20/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | If the timebase is set, it's used for converting the packet timestamps. Otherwise, the previous method of reinterpret-casting the mpv style double timestamps to libavcodec style int64_t timestamps is used. Also replace the kind of awkward mp_get_av_frame_pkt_ts() function by mp_pts_from_av(), which simply converts timestamps in a way the old function did. (Plus it takes a timebase parameter, similar to the addition to mp_set_av_packet().) Note that this should not change anything yet. The code in ad_lavc.c and vd_lavc.c passes NULL for the timebase parameters. We could set AVCodecContext.pkt_timebase and use that if we want to give libavcodec "proper" timestamps. This could be important for ad_lavc.c: some codecs (opus, probably mp3 and aac too) have weird requirements about doing decoding preroll on the container level, and thus require adjusting the audio start timestamps in some cases. libavcodec doesn't tell us how much was skipped, so we either get shifted timestamps (by the length of the skipped data), or we give it proper timestamps. (Note: libavcodec interprets or changes timestamps only if pkt_timebase is set, which by default it is not.) This would require selecting a timebase though, so I feel uncomfortable with the idea. At least this change paves the way, and will allow some testing.
* vf_vo: don't abuse option strings to set VOwm42013-12-041-4/+4
| | | | Whoever thought this was a good idea should be punched.
* vf_yadif: change options, reroute to vf_lavfiwm42013-12-041-3/+0
| | | | | | Also remove the ability to disable deinterlacing at runtime. You can still disable deinterlacing at runtime by using the ``D`` key and its automatical filter insertion/removal.
* options: add option to disable using right Alt key as Alt GrVivek Jain2013-12-024-0/+17
| | | | | | | | | mpv was hardcoded to always consider the right Alt key as Alt Gr, but there are parituclar combinations of platforms and keyboard layouts where it's more convenient to treat the right Alt as a keyboard modifier just like the left one. Fixes #388
* input: don't emit command when using multiple mouse buttons at oncewm42013-12-011-5/+21
| | | | | | | | | | | | | | | | | | | | | | This is for key bindings that use multiple mouse buttons at once. (Yes, this is weird, but MPlayer always had this feature, and apparently there are people using it!) Before this commit, clicking another mouse button while still holding the previous mouse button forced the command bound to the previous mouse button to be emitted. This is usually needed to make sure the input consumer (the player and the OSC) stays in sync with the actual mouse button state. If there's no command sent, the OSC in particular would think the button is still held down. However, sending the command is undesired behavior if you want to use these multiple-key binds. Solve this by emitting commands in this situation only if a key down command was sent earlier. Since mouse button key bindings are normally executed on key-up only, this happens with special commands like script_dispatch only (used by the OSD to track mouse buttons, but also used for other OSC bindings). See github issue #390.
* input: improve some commentswm42013-12-011-4/+4
| | | | | I have the feeling some of these were written before everything was changed all over again.
* command: add a revert_seek commandwm42013-12-013-1/+40
| | | | As discussed on IRC.
* options: add options that set defaults for af/vf/ao/vowm42013-12-014-4/+34
| | | | | | | | There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
* Prevent creating zombieswm42013-11-301-3/+14
| | | | | | | | | | | | | | | | The "run" input command does fork+exec to spawn child processes. But it doesn't cleanup the child processes, so they are left as zombies until mpv terminates. Leaving zombie processes around is not very nice, so employ a simple trick to let pid 1 take care of this: we fork twice, and when the first fork exits, the second fork becomes orphaned and becomes pid 1's child. It becomes pid 1's responsibility to cleanup the process. The advantage is that we don't need extra logic to cleanup the spawned process, which could have an arbitrary lifetime. This is e.g. described here: http://yarchive.net/comp/zombie_process.html Also use _exit() instead of exit(). It's not really sane to run cleanup handlers (atexit() etc.) inside a forked process.
* Use O_CLOEXEC when creating FDswm42013-11-303-12/+18
| | | | | | | | | | | | | | This is needed so that new processes (created with fork+exec) don't inherit open files, which can be important for a number of reasons. Since O_CLOEXEC is relatively new (POSIX.1-2008, before that Linux specific), we #define it to 0 in io.h to prevent compilation errors on older/crappy systems. At least this is the plan. input.c creates a pipe. For that, add a mp_set_cloexec() function (which is based on Weston's code in vo_wayland.c, but more correct). We could use pipe2() instead, but that is Linux specific. Technically, we have a race condition, but it won't matter.
* command: add a cycle_values input commandwm42013-11-303-1/+84
|
* command: change the syntax and semantics of the "run" commandwm42013-11-302-6/+20
| | | | | | | See the changes in input.rst for explanations. Technically speaking, this also gets rid of some undefined behavior: passing NULL as a vararg (execl()) is always a bug.
* input: require space before '#' commentswm42013-11-301-8/+5
| | | | | | | | | | So e.g. show_text abc#def will now print "abc#def" instead of "#def". It's simpler, more consistent with how ";" and other things are handled, and also possibly avoids bothering the user with extra escaping.
* input: rearrange command parsingwm42013-11-301-44/+31
| | | | This simplifies some things as preparation for the next commits.
* build: add options for enabling and disabling any libquvi versionsNikoli2013-11-291-1/+1
| | | | Makes packaging a bit simpler.
* Take care of some libavutil deprecations, drop support for FFmpeg 1.0wm42013-11-292-4/+4
| | | | | | | | | | | | | | PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants) enum PixelFormat -> enum AVPixelFormat Losen some version checks in certain newer pixel formats. av_pix_fmt_descriptors -> av_pix_fmt_desc_get This removes support for FFmpeg 1.0.x, which is even older than Libav 9.x. Support for it probably was already broken, and its libswresample was rejected by our build system anyway because it's broken. Mostly untested; it does compile with Libav 9.9.
* player: always reset some variables on seekwm42013-11-291-4/+4
| | | | | | These were confined to the video path, but resetting them even if no video is available shouldn't really matter. Always resetting them makes the logic easier to follow, I think.
* video: restore printing warning on decreasing filter PTSwm42013-11-291-2/+2
| | | | | | | | Recently, the check was moved, so it was printed only for source video PTS (since that's easier, and filters should normally behave sane). But it turns out it's trivial to print a warning in the filter case too by reusing the code that normally checks for PTS forward jumps without needing any additional code, so, fine, restore warning in this case.
* build: make pthreads mandatorywm42013-11-282-15/+3
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* command: allow "current" as argument to playlist_remove commandwm42013-11-282-1/+6
| | | | Feature request from github issue #376.
* input: use separate type for command definitionswm42013-11-284-54/+79
| | | | | | | | | | | | | Introduce a mp_cmd_def struct to define commands, instead of using mp_cmd for this. This way each command parameter can be a m_option, instead of m_option plus some more stuff. Define the ARG_ macros directly in terms of the OPT_ macros. Not sure if this makes it easier to read (maybe not, even if it looks simpler), but at least it makes it easier to add other option types. Another idea was adding a name for each parameter (so you could have named parameters), but not today.
* player: simple hack to make backstep code somewhat more robustwm42013-11-281-3/+12
| | | | | | | | | | | | | | | | | | | The hr-seek code assumes that when seeking the demuxer, the first image decoded after the seek will have a PTS exactly equal to the demuxer seek target time, or before that target time. Incorrect timestamps, implicitly dropped initial frames, or broken files/demuxers can all break this assumption, and lead to hr-seek missing the seek target. Generally, this is not much a problem (the user won't notice being off by one frame), but it really shows when using the backstep feature. In this case, backstepping would simply hang. Add a simple hack that basically forces a minimal value for the --hr- seek-demuxer-offset option (which is 0 by default) when doing a backstep-seek. The chosen minimum value is arbitrary. There's no perfect value, though in general it should perhaps be slightly longer than the frametime, which the chosen value is more than enough for typical framerates.
* video: add heuristic to prevent framedrop during hrseek if pts brokenwm42013-11-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | | Using --start with files that use DTS only, or which simply have broken PTS timestamps, would incorrectly drop frames and possibly not execute the seek correctly. Add yet another heuristic to detect this. The intent is that --start and hr-seeks in general should work correctly, but in order to keep things fast, we still want to allow frame dropping during hr-seek if there are no problems doing so. Do this by disabling frame dropping by default, but re-enabling it if there are no problems found for a while. As a consequence, --start might be somewhat slower, but normal user interaction should remain as fast as before. Note that there's something subtle about the added code: the has_broken_packet_pts field is checked even before the first packet is fed to dec_video.c, so the field must not be set to 0 right on start. It's not initially set to 0 anyway, because the heuristic requires decoding some images before enabling frame drop anyway. Note 2: it's not clear whether frame dropping during hr-seek really helps; I didn't benchmark it.
* video: replace d_video->pts field, change PTS jump checkswm42013-11-274-26/+18
| | | | | | | | | | | | | The d_video->pts field was a bit strange. The code overwrote it multiple times (on decoding, on filtering, then once again...), and it wasn't really clear what purpose this field had exactly. Replace it with the mpctx->video_next_pts field, which is relatively unambiguous. Move the decreasing PTS check to dec_video.c. This means it acts on decoder output, not on filter output. (Just like in the previous commit, assume the filter chain is sane.) Drop the jitter vs. reset semantics; the dec_video.c determined PTS never goes backwards, and demuxer timestamps don't "jitter".
* video: if PTS is missing, make something up using the frameratewm42013-11-271-7/+0
| | | | | | Also get rid of the PTS check _after_ filters. This means if there's a video filter which unsets PTS, no warning will be printed. But we assume that all filters are well-behaved enough by now.
* video: refactor PTS code, add fall back heuristic to DTSwm42013-11-272-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the PTS handling code to make it cleaner, and to separate the bits that use PTS sorting. Add a heuristic to fall back to DTS if the PTS us non-monotonic. This code is based on what FFmpeg/Libav use for ffplay/avplay and also best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non- monotonic, but DTS is sorted. The code is pretty much the same as in Libav [1]. I'm not sure if all of it is really needed, or if it does more than what the paragraph above mentions. But maybe it's fine to cargo-cult this. This heuristic fixes playback of mpeg4 in ogm, which returns packets with PTS==DTS, even though the PTS timestamps should follow codec reordering. This is probably a libavformat demuxer bug, but good luck trying to fix it. The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit inelegant, but maybe better than trying to mess the PTS back into the decoder callback again. [1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
* Move some code from player to audio/video reset functionswm42013-11-272-11/+0
|
* cosmetics: rename video/audio reset functionswm42013-11-272-4/+4
| | | | | | | | | | These used the suffix _resync_stream, which is a bit misleading. Nothing gets "resynchronized", they really just reset state. (Some audio decoders actually used to "resync" by reading packets for resuming playback, but that's not the case anymore.) Also move the function in dec_video.c to the top of the file.
* video: unbreak --no-correct-pts with demuxers that use DTSwm42013-11-262-2/+2
|
* av_common: fix typo in commentStefano Pigozzi2013-11-261-1/+1
|
* player: don't use a loop when no loop is neededwm42013-11-261-4/+1
| | | | | This used a really weird idiom: a loop that iterates only once, so you can use break; to jump out of the block.
* player: move code for skipping 0-sized video packets to demuxerwm42013-11-261-10/+1
| | | | | | | | | | These packets have to be explicitly dropped, because usually libavcodec uses 0-sized packets to flush delayed frames, meaning just passing through these packets would have bad consequences. Normally, libavformat doesn't output 0-sized packets anyway. But I don't want to take any chances, so don't delete it, and just move it out of the way to demux.c.
* build: make cygwin use *nix timersStefano Pigozzi2013-11-261-1/+1
|
* sub: respect detected language for fuzzy-matched external subtitleswm42013-11-251-6/+9
| | | | | | | Solve this by passing through the language to the player, which then uses the generic subtitle selection code to make a choice. Fixes #367.
* player: only pause for waiting on cache if it makes sensewm42013-11-251-1/+3
| | | | | | | | | If the value for --cache-on-pause is larger than --cache-min, and the cache runs below --cache-on-pause, but above --cache-min, the logic would demand to pause the player and then unpause immediately again. This doesn't make much sense, and alternating the pause state in each playloop iteration has negative consequences. Add an explicit check to avoid this situation.
* video: move timestamp determination code to dec_videowm42013-11-251-42/+0
| | | | | | | | | | This means the code that tries to figure out the timestamp from demuxer and decoder output is now all in dec_video.c. We set the final timestamp on the returned image (mp_image.pts), as well as the d_video->pts field. The way the player uses d_video->pts field is still a bit messy. Maybe this could be cleaned up later.
* video: disable PTS sorting fallback by defaultwm42013-11-251-0/+1
| | | | | | | | | | | | | | | | It appears PTS sorting was useful only for avi files (and VfW-muxed mkv). Maybe it was historically also important for decoders with broken or non-existent PTS reordering (win32 codecs?). But now that we handle demuxers which outputs DTS only correctly, it just seems dead weight. Disable it by default. The --pts-association-mode option is now forced to always use the decoder's PTS value. You can still enable the old default (auto) or force sorting. But we will probably remove this option entirely at some point. Make demux_mkv export timestamps at DTS when it's in VfW mode. This is needed to get correct timestamps with the new default mode. demux_lavf already does that.
* demux: export dts from demux_lavf, use it for aviwm42013-11-253-4/+25
| | | | | | | | | 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.
* player: merge no-correct-pts with correct-pts codewm42013-11-252-52/+12
| | | | | | Now the --no-correct-pts mode is like the normal mode, just with different timestamp calculations. The semantics should be about the same as before this commit.
* player: change semantics of --no-correct-ptswm42013-11-251-26/+8
| | | | | | | | | | | | | Before this commit, this mode estimated the frame time by subtracting successive packet PTS values. This is complete non-sense for video codecs which use reordering. The code compensated frame times for these non-sense using the FPS value, but confused the rest of the player with non-sense jumping around timestamps. So, all in all this mode is not very useful. Repurpose this mode for fixed frame rate playback. This gives almost the same behavior as the old mode with forced framerate (--fps option). The result is simpler and often more robust.
* video: pass PTS as part of demux_packet/AVPacket and mp_image/AVFramewm42013-11-251-13/+8
| | | | | | | | | | |<