summaryrefslogtreecommitdiffstats
path: root/mpvcore/player
Commit message (Collapse)AuthorAgeFilesLines
* Move mpvcore/player/ to player/wm42013-12-1723-13324/+0
|
* Replace mp_tmsg, mp_dbg -> mp_msg, remove mp_gtext(), remove set_osd_tmsgwm42013-12-168-36/+25
| | | | | | | | | The tmsg stuff was for the internal gettext() based translation system, which nobody ever attempted to use and thus was removed. mp_gtext() and set_osd_tmsg() were also for this. mp_dbg was once enabled in debug mode only, but since we have log level for enabling debug messages, it seems utterly useless.
* command: mess with previous commitwm42013-12-161-11/+9
| | | | | | Nothing actually used the returned length. Since the remaining time can easily become 0 or negative (e.g. incorrectly estimated file duration), the time_remaining function still needs 2 return values, though.
* command: scale osd’s time remaining by the current speedVivek Jain2013-12-162-6/+28
| | | | Signed-off-by: wm4 <wm4@nowhere>
* input: move some command flags into a bitfieldwm42013-12-161-15/+12
|
* player: don't temporarily disable terminal handling when reloading fileswm42013-12-153-20/+11
| | | | | | | | | | There's no reason why we should do this. For some reason, the existing code reset terminal handling to default after unloading a file, just to initialize it again when loading a new file. Might be related to github issue #412, although I don't think it helps, since the default SIGTERM handler _should_ kill the mpv process. (It's still a nice simplification, though.)
* player: don't store subtitle renderer in osd_statewm42013-12-154-12/+14
| | | | | | | | This doesn't have much value. It can't be accessed by anything else than the actual subtitle renderer (sd_ass.c). sd_ass.c could create the renderer itself, except that we apparently want to save memory (and some font loading time) when using ordered chapters or multiple subtitle tracks.
* dvdnav: fix incorrect clipping of highlightswm42013-12-151-6/+6
|
* matroska: add --ordered-chapters-files optionwm42013-12-141-2/+16
| | | | | This option takes a playlist. The playlist will then be used as list of potential segment files for use with ordered chapters.
* Allow some options taking filenames to refer to mpv config dirwm42013-12-141-1/+4
| | | | | | | | | | Add the mp_get_user_path() function, and make it expand special path prefixes. Use it for some things in mpv which take filenames (--input-config, --screenshot-template, opengl icc-profile suboption). This allows accessing files in the mpv config dir without hardcoding the config path by prefixing the path with ~~/. Details see manpage additions.
* dvdnav: crappy hack to respect timed still frameswm42013-12-141-1/+24
| | | | | | Before this, they were displayed forever. Since some dvd screens seem not to allow escaping from the still frame using the menu, this could get you stuck forever.
* dvdnav: block when libdvdnav requests draining bufferswm42013-12-141-5/+13
| | | | | | | | | | | Not sure how this should work. Using libdvdnav with a large FIFO doesn't make sense either: data and control commands use the same stream, so if you want to send input to libdvdnav, you just have to read from libdvdnav all the time to get a reaction, which is not compatible with maintaining a buffer that could remain full for a long time. I have no idea either whether this improves or worsens anything, though it might be more correct.
* dvdnav: improve a commentwm42013-12-131-1/+1
|
* dvb: prevent seek when reopening the demuxerwm42013-12-131-1/+3
| | | | | | Since dvb input is not seekable anyway, this would probably just flush the stream buffer, but at least it'll avoid a bogus message about seeking errors.
* dvdnav: support mouse interactionwm42013-12-131-3/+16
|
* Add prelimimary (basic, possibly broken) dvdnav supportwm42013-12-127-22/+238
| | | | | | | | | | | | | | | | | | | | | | | | | This readds a more or less completely new dvdnav implementation, though it's based on the code from before commit 41fbcee. Note that this is rather basic, and might be broken or not quite usable in many cases. Most importantly, navigation highlights are not correctly implemented. This would require changes in the FFmpeg dvdsub decoder (to apply a different internal CLUT), so supporting it is not really possible right now. And in fact, I don't think I ever want to support it, because it's a very small gain for a lot of work. Instead, mpv will display fake highlights, which are an approximate bounding box around the real highlights. Some things like mouse input or switching audio/subtitles stream using the dvdnav VM are not supported. Might be quite fragile on transitions: if dvdnav initiates a transition, and doesn't give us enough mpeg data to initialize video playback, the player will just quit. This is added only because some users seem to want it. I don't intend to make mpv a good DVD player, so the very basic minimum will have to do. How about you just convert your DVD to proper video files?
* 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.
* 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.
* 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.
* command: add a revert_seek commandwm42013-12-011-1/+38
| | | | As discussed on IRC.
* 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-302-6/+7
| | | | | | | | | | | | | | 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-301-0/+79
|
* command: change the syntax and semantics of the "run" commandwm42013-11-301-2/+6
| | | | | | | 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.
* build: add options for enabling and disabling any libquvi versionsNikoli2013-11-291-1/+1
| | | | Makes packaging a bit simpler.
* 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.
* command: allow "current" as argument to playlist_remove commandwm42013-11-281-0/+2
| | | | Feature request from github issue #376.
* input: use separate type for command definitionswm42013-11-281-1/+1
| | | | | | | | | | | | | 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.
* 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
|
* 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.
* demux: export dts from demux_lavf, use it for aviwm42013-11-251-2/+1
| | | | | | | | | 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
| | | | | | | | | | | | | | | Instead of passing the PTS as separate field, pass it as part of the usual data structures. Basically, this removes strange artifacts from the API. (It's not finished, though: the final decoded PTS goes through strange paths, and filter_video() finally overwrites the decoded mp_image's pts field with it.) We also stop using libavcodec's reordered_opaque fields, and use AVPacket.pts and AVFrame.pkt_pts. This is slightly unorthodox, because these pts fields are not "really" opaque anymore, yet we treat them as such. But the end result should be the same, and reordered_opaque is marked as partially deprecated (it's not clear whether it's really deprecated).
* player: warn if PTS association mode switcheswm42013-11-251-2/+2
| | | | | | | | | | | | | | | | | This normally shouldn't happen. It does happen with VfW-muxed mkv files, and would normally happen with avi files (except that we force the correct association mode using an explicit hack for avi). This is usually prepended by warnings like: Decreasing video pts: 0.125000 < 0.167000 and after the switch, there should be no warnings anymore. Background: avi likes to use DTS for timestamps instead of PTS. Basically, there are no proper timestamps in the file, only frame numbers. And Matroska is insane and stores the made-up DTS instead of a proper PTS. This will be handled properly later.
* player: close demuxer before streamwm42013-11-241-2/+3
| | | | | Demuxer might access stream even when closing. For now, this is not a real problem (because it didn't actually happen), but it's cleaner.
* osd: remove mp_osd_res.video_par fieldwm42013-11-241-1/+0
| | | | | | This is not needed anymore, because we decided that the PAR of the decoded video matters, and not the PAR of the filtered video that arrives at the VO.
* Rename sub.c/.h to osd.c/.hwm42013-11-247-7/+7
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* Reduce stheader.h includes, move stream types to mp_common.hwm42013-11-234-2/+4
|
* audio: respect --end/--length with spdif passthroughwm42013-11-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | In theory, we can't really do this, because we don't know when a spdif frame ends. Spdif transports compressed audio through audio setups that were originally designed for PCM only (which includes the audio filter chain, the AO API, most audio output APIs, etc.), and to reach this goal, spdif pretends to be PCM. Compressed data frames are padded with zeros, until a certain data rate is reached, which corresponds to a pseudo-PCM format with 2 bytes per sample and 2 channels at 48000 Hz. Of course an actual spdif frame is significantly larger than a frame of the PCM format it pretends to be, so cutting audio data on frame boundaries (as according to the pseudo-PCM format) merely yields an incomplete and broken frame, not audio that plays for the desired duration. However, sending an incomplete frame might still be much better than the current behavior, which simply ignores --end/--length (but still lets the video end at the exact end time). Should this result in trouble with