summaryrefslogtreecommitdiffstats
path: root/player/video.c
Commit message (Collapse)AuthorAgeFilesLines
* player: flush decoder even if cover art is decodedwm42015-04-241-1/+1
| | | | | | | | | | | | | | | Fixes PNG cover art not showing up immediately (for example when running with --pause). libavformat exports embedded cover art as a single packet. For example, a PNG attachment simply contains the PNG image, which can be sent to the decoder. Normally you would expect that the PNG decoder would return 1 frame for 1 packet, without any delays. But this stopped working, and it incurs a 1 frame delay. This is perfectly legal (even if unexpected), so let our code feed the decoder packets until we get something back. (In theory feeding the packet instead of a real flush packet is still somewhat questionable.)
* player: don't show A/V desync message in non-sense situationswm42015-04-241-2/+2
| | | | | | | last_av_difference can be MP_NOPTS_VALUE under certain circumstances (like no video timestamp yet). This triggered the desync message, because fabs(MP_NOPTS_VALUE) is quite a large value. We don't want to show a message in this situation.
* player: cleanup update_fps() functionwm42015-04-201-12/+5
| | | | | It was called only in 2 places, one of them redundant (the container FPS can not change).
* video: cleanup some old log messageswm42015-04-201-0/+2
| | | | | These are basically MPlayer leftovers, and barely useful due to being redundant with other messages. The FPS message is used somewhere else.
* video: do not show decoder framedrops if they're not requestedwm42015-04-161-1/+2
| | | | | | | | | | | libavcodec makes it impossible to distinguish dropped frames (requested with AVCodecContext.skip_frame), and cases when the decoder simply does not return a frame by default (such as with VP9, which has invisible reference frames). This confuses users when decoding VP9 video. It's basically a cosmetic issue, so just paint it over by ignoring them if framedropping is disabled.
* player: silence spam in verbose mode when playing audio with cover artwm42015-04-141-1/+1
| | | | | | When playing cover art, it conceptually reaches EOF as soon as the image was put on the VO, causing the EOF message to be repeated every time new audio was decoded. Just silence the message.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: cleanup stereo mode parsingwm42015-04-021-1/+1
| | | | | | | | | Use OPT_CHOICE_C() instead of the custom parser. The functionality is pretty much equivalent. (On a side note, it seems --video-stereo-mode can't be removed, because it controls whether to "reduce" stereo video to mono, which is also the default. In fact I'm not sure how this should be handled at all.)
* video: fix seek-to-last-framewm42015-03-261-3/+1
| | | | | Accidentally broken in 79779616; we really need to check for true EOF, not just whether there are no frames yet.
* video: make frame skipping code slightly more readablewm42015-03-251-13/+8
|
* video: refactor aspects of queue and EOF handlingwm42015-03-251-41/+62
| | | | | Instead of touching the 2-entry queue in mpctx->next_frame directly, move some of it to functions.
* video: use less technical language for PTS warningwm42015-03-231-1/+1
| | | | | | | "Non-monotonic" isn't even 100% correct; it's missing "strictly" (for briefness I guess), and also the message is printed if the PTS jumps forward. So just print something that is likely a bit easier to understand.
* video: fix update of vo-configured propertywm42015-03-231-0/+1
| | | | It obviously needs to be updated after the VO was destroyed.
* player: warn against non-monotonic video PTS only oncewm42015-03-181-8/+9
| | | | | | | | For some reason there were two points in the code where it warned against non-monotonic video PTS. The one in video.c triggered on PTS going backwards or making large jumps forwards, while dec_video.c triggered on PTS going backwards or PTS not changing. Merge them into a single check, which warns against all cases.
* player: use symbolic constant for seek precisionwm42015-03-041-2/+4
| | | | Meh.
* player: adjust A/V desync messagewm42015-02-261-3/+3
| | | | | | Broken drivers are an issue rather often. Maybe this gives the user an idea that this could be the reason. (We can't dump much more info on a 80x24 terminal.)
* vf_vapoursynth: add display refresh rate propertyJulian2015-02-131-0/+2
| | | | | This value is not necessarily trustworthy (it might change) and can be 0.
* player: remove --fixed-vowm42015-02-031-1/+1
| | | | | | | In ancient times, this was needed because it was not default, and many VOs had problems with it. But it was always default in mpv, and all VOs are required to deal with it. Also, running --fixed-vo=no is not useful and just creates weird corner cases. Get rid of it.
* player: dump audio jitter to stats filewm42015-02-011-4/+5
| | | | | This allows us to plot the difference between video timestamps, and the adjusted video timestamps due to syncing video to audio speed.
* player: minor simplification in A/V-sync related codewm42015-01-301-3/+2
| | | | Just minor things.
* Revert "player: allow seeking audio between video frames"wm42015-01-301-9/+1
| | | | | | | | This reverts commit 7b3feecbc23e3e0b0d9cf66f02af53d127a0b681. It's broken, hr-seek never ends at a video position before seek pts. Not sure what I was thinking, although it did work anyway when artificially forcing a video frame to display before seek pts.
* player: print desync message on negative A/V-sync toowm42015-01-301-1/+1
| | | | | | | | At least there is _some_ problem if this happens. It would mean that audio is playing slower than video. Normally, video is synced to audio, so if audio stops playback completely, video will not advance at all. But using things like --autosync, it's well possible that this kind of desync happens.
* player: rearrange some A/V-sync related codewm42015-01-301-6/+5
| | | | | | | | | | | | Move the update_avsync_before_frame() call further down. Moving it closer to where the time_frame value is used (and which the function updates) should make the code more readable. With this change, there's no need anymore to reset the time_frame value on the video reconfig path. Move the update_avsync_after_frame() up. Now no meaningful amount of time passes since the previous get_relative_time() call anymore, and the second one can be removed.
* player: use correct type for some relative timeswm42015-01-301-3/+3
| | | | | | We use double for these things everywhere, just this code didn't. It likely doesn't matter much, and this code is for an optional feature too.
* player: remove redundant variablewm42015-01-291-4/+5
| | | | | | mpctx->audio_delay always has the same value as opts->audio_delay. (This was not the case a long time ago, when the audio-delay property didn't actually write to opts->audio_delay. I think.)
* player: allow seeking audio between video frameswm42015-01-281-1/+9
| | | | | | | | | | | | | | | This allows seeking audio between two video frames that are relatively far away. The implementation of this is a bit subtle. It pretend the audio position is different, and the actual PTS adjustment happens in audio.c with this line: sync_pts -= mpctx->audio_delay - mpctx->delay; Effectively this is the same as setting sync_pts to hrseek_pts after this line, though. (I'm actually not sure if this could be written in a more straightforward way; probably yes.)
* player: mention mpv encoding support for transcoding in desync. warningwm42015-01-191-1/+1
|
* video: fix waiting for last frame/format reconfigwm42015-01-191-1/+1
| | | | | | | | | | | We still need to send the VO a duration in these cases. Disabling framedrop has logically absolutely nothing to do with these cases; it was overlooked in commit 918b06c4. So we always send the frame duration (or a guess for it), and check whether framedropping is actually enabled in the VO code. (It would be cleaner to send framedrop as a flag, but I don't care about that right now.)
* player: respect --untimed on last framewm42015-01-161-1/+3
| | | | | | | | | | | | | | The last video frame is another case that has a separate code path, although it's pretty similar to the one in commit 73e5aa87. Fix this in a different way, which also takes care of the last frame case, although without context the code becomes slightly more tricky. As further cleanup, move the decision about framedropping itself to the same place, so the check in vo.c becomes much simpler. The check for the vo->driver->encode flag, which is remvoed completely, was redundant too. Fixes #1480.
* player: respect --untimed on video format changeswm42015-01-161-1/+1
| | | | | | | | | | | If the video format changes (e.g. different frame size), a special code path is entered to wait until the currently displayed frame is done. Otherwise, the frame before the change would be destroyed by the vo_reconfig() call. This code path didn't respect --untimed; correct this. Fixes #1475.
* video: fix timeline with some container formatswm42015-01-061-0/+2
| | | | | | Using edl or --merge-files with .avi files didn't work, because the DTS was not offset. Only the PTS was adjusted, which led to nonsense timestamps.
* video: batch query_format callswm42015-01-031-2/+1
| | | | | | | There are currently 568 pixel formats (actually fewer, but the namespace is this big), and for each format elaborate synchronization was done to call it synchronously on the VO. This is completely unnecessary, and we can do with just a single call.
* vf_vapoursynth: pass through container FPS valuewm42015-01-031-10/+8
| | | | | | | | This is basically a hack; but apparently a needed one, since many vapoursynth filters insist on having a FPS set. We need to apply the FPS override before creating the filters. Also change some terminal output related to the FPS value.
* video: better pipelining with vf_vapoursynthwm42015-01-031-3/+24
| | | | | | | | | | Most of this is explained in the code comments. This change should improve performance with vapoursynth, especially if concurrent requests are used. This should change nothing if vf_vapoursynth is not in the filter chain, since non-threaded filters obviously can not asynchronously finish filtering of frames.
* vo_opengl_cb: pass context directlywm42014-12-311-3/+1
| | | | | This is simpler than setting the context after VO creation, which requires the code to check for the context on every entrypoint.
* video: pass some VO params as structwm42014-12-311-3/+6
| | | | | Not particularly elegant, but better than adding more and more stuff to the relevant function signatures.
* player: fix a typo in message outputwm42014-12-241-1/+1
| | | | This typo has been around for over a year. Oops.
* client API: expose OpenGL rendererwm42014-12-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
* player: when seeking past EOF with --keep-open, seek to last framewm42014-12-071-4/+16
| | | | | | | | | | | | | | | | | | | | | It feels strange that seeking past EOF with --keep-open actually leaves the player at a random position. You can't even unpause, because the demuxer is in the EOF state, and what you see on screen is just what was around before the seek. Improve this by attempting to seek to the last video frame if EOF happens. We explicitly don't do this if EOF was reached normally to increase robustness (if the VO got a frame since the last seek, it obviously means we had normal playback before EOF). If an error happens when trying to find the last frame (such as not actually finding a last frame because e.g. the demuxer misbehaves), this will probably turn your CPU into a heater. There is no logic to prevent reinitiating the last-frame search if the last-frame search reached EOF. (Pausing usually prevents that EOF is reached again after a successful last-frame search.) Fixes #819.
* Remove some superfluous NULL checkswm42014-11-211-3/+0
| | | | | | | | In all of these situations, NULL is logically not allowed, making the checks redundant. Coverity complained about accessing the pointers before checking them for NULL later.
* player: print anamorphic size only if video is anamorphicwm42014-11-021-2/+5
| | | | Has been annoying me since forever.
* player: update meaning of drop_frame_cntwm42014-11-011-2/+2
| | | | | Rename the variable, update comments, and update the documentation of the property which returns its value.
* player: show AV-desync message in all framedrop modeswm42014-11-011-2/+1
| | | | | | | | | | | | This was shown only if decoder-framedropping was enabled, and only if at least 50 frames were dropped by it. Since drop_frame_cnt used to mean "number of late frames", this code made sense, but this is not the case anymore: drop_frame_cnt can be even 0, all while video gets hopelessly behind audio. One problem with this is that short desync spikes (which usually can probably dealt with) will also cause this message to be shown. If it gets triggered too often, the code will need to be adjusted.
* client API: better error reportingwm42014-10-281-1/+4
| | | | Give somewhat more information on playback failure.
* video: send MPV_EVENT_VIDEO_RECONFIG on uninitwm42014-10-241-0/+1
| | | | | This event basically means "something about video changed", and uninit is certainly an important change.
* player: fix exiting if both audio and video fail initializingwm42014-10-231-4/+2
| | | | | | | | | | | | | The player was supposed to exit playback if both video and audio failed to initialize (or if one of the streams was not selected when the other stream failed). This didn't work; for one this check was missing from one of the failure paths. And more importantly, both checked the current_track array incorrectly. Fix these issues, and move the failure handling code into a common function. CC: @mpv-player/stable
* player: fix --frameswm42014-10-141-1/+3
| | | | | | | | | This could produce an extra frame, because reaching the maximum merely signals the playloop to exit, without strictly enforcing the limit. Fixes #1181. CC: @mpv-player/stable
* player: signal EOF when using --frameswm42014-10-101-1/+1
|
* video: try harder to decode cover art picture only oncewm42014-10-091-2/+7
| | | | | | | | | | | | | | | | | For cover art, we pretend that the video stream is infinite, but also stop decoding once we have an image on the VO (this seems advantageous for the case when strange filters are inserted or the VO image gets lost). Since a while ago, the video chain started decoding 2 images though ("Non-monotonic video pts: 0.000000 <= 0.000000"), which is annoying and wasteful. Improve this by handling a certain corner case at initialization, which will decode a second image while the first one is still stuck in the filter chain. Also, just in case there are filters which buffer a lot, also force EOF filtering (which means we tell the filters to flush buffered frames). CC: @mpv-player/stable
* player: remove central uninit_player() function and flags messwm42014-10-031-9/+23
| | | | | | | | | | | | | | Each subsystem (or similar thing) had an INITIALIZED_ flag assigned. The main use of this was that you could pass a bitmask of these flags to uninit_player(). Except in some situations where you wanted to uninitialize nearly everything, this wasn't really useful. Moreover, it was quite annoying that subsystems had most of the code in a specific file, but the uninit code in loadfile.c (because that's where uninit_player() was implemented). Simplify all this. Remove the flags; e.g. instead of testing for the INITIALIZED_AO flag, test whether mpctx->ao is set. Move uninit code to separate functions, e.g. uninit_audio_out().
* player: don't print audio/video init failure message twicewm42014-10-021-2/+2
| | | | | | | The messages "Audio: no audio" and "Video: no video" could be printed twice each if initializing them failed. Prevent his silliness. CC: @mpv-player/stable
* video: change automatic rotation and 3D filter insertionwm42014-09-271-6/+3
| | | | | | | | | | | | | | | | | | | | | We inserted these filters with fixed parameters, which was ok. But this also didn't change image parameters for the filters down the filter chain and the VO. For example, if rotation by 90° was requested by the file, we would insert a filter and rotate the video, but the VO would still receive image parameters that direct rotation by 90°. This wasn't a problem, but it could become one. Fix this by letting the filters automatically pick up the image params. The image params are reset on application. (We could probably also always try to apply and reset image params in a filter, instead of having special "auto" parameters. This would probably work, and video.c would insert a "rotate=0" filter. But I'm afraid this would be confusing and the current solution is cosmetically slightly nicer.) Unfortunately, the vf_stereo3d.c change turned out a big mess, but once the "internal" filter is fully replaced with libavfilter, most of this can be radically simplified.
* player: rate-limit OSD text updatewm42014-09-251-1/+2
| | | | | | | | | | | | | | | There's no need to update OSD messages and the terminal status if nobody is going to see it. Since the player doesn't block on video display anymore, this update happens to often and probably burns slightly more CPU than necessary. (OSD redrawing is handled separately, so it's just mostly useless text processing and such.) Change it so that it's updated only on every video frame or all 50ms (whatever comes first). For VO OSD, we could in theory try to lock to the OSD redraw heuristic or the display refresh rate, but that's more complicated and doesn't work for the terminal status.
* video: filter new frames at a better time (2)wm42014-09-221-7/+9
| | | | | | | | | | | | | | | | | We generally want 2 things: 1. minimal wakeups for decoding each frame 2. minimal number of frames decoded on continuous seeking Commit 35810cb8 changed this a bit, and fixed 1. But it broke 2., and now it decodes 2 frames instead of 1 when you keep seeking (arrow key held down or such). This made seeking appear slower. Fix this by making the logic more explicit. In particular, call the filters only if we actually try to get a new frame. When playing with --no-audio and all other distractions disabled (like OSC), it still wakes up 2 times per frame - but the second time is merely because the VO didn't accept the new frame yet.
* video: actually count decoder-dropped frameswm42014-09-201-4/+7
| | | | | | | | | Normally, feeding a packet to the decoder should always return a frame _if_ we received a frame before. So while we can't know exactly whether a frame was dropped, at least the normal case is easily detectable. This means we display something closer to the actual framedrop count, instead of a bad guess.
* video: improve decoder-based framedropping modewm42014-09-201-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the "old" framedropping mode (derived from MPlayer). At least in the mplayer2/mpv source base, it stopped working properly years ago (or maybe it never worked properly). For one, it depends on the video framerate, which assume constant framerate. Another problem was that it could lead to freezing video display: video could get so much behind that it couldn't recover from framedrop. Make some small changes to improve this. Don't use the current audio position to check how much we are behind. Instead, use the last known A/V difference. last_av_difference is updated only when a video frame is scheduled for display. This means we can keep stop dropping once we're done catching up, even if video is technically still behind. What helps us here that this forces a video frame to be displayed after a while. Likewise, we reset the dropped_frames count only when scheduling a new frame for display as well. Some inspiration was taken from earlier work by xnor (see issue #620), although the implementation turned out quite different. This still uses the demuxer-reported (possibly broken) FPS value. It also doesn't account for filters changing FPS. We can't do much about this, because without decoding _and_ filtering, we just can't know how long a frame is. In theory, you could derive that from the raw packet timestamps and the filter chain contents, but actually doing this is too involved. Fortunately, the main thing the FPS affects is actually the displayed framedrop count.
* player: reset last_av_difference if not applicablewm42014-09-201