summaryrefslogtreecommitdiffstats
path: root/player/video.c
Commit message (Collapse)AuthorAgeFilesLines
* player: remove dead codewm42016-02-121-1/+1
| | | | Fixes CID 1350055 and CID 1350054.
* player: fix crash if no video decoder can be initializedwm42016-02-101-0/+1
| | | | Caused by the recent refactoring for complex filters.
* player: force refresh seek when changing audio filterswm42016-02-091-0/+2
| | | | | | | | | | | | | Unfortunately I see no better solution. The refresh seek is skipped if the amount of buffered audio is not overly huge. Unfortunately softvol af_volume insertion still can cause this issue, because it's outside of the normal dynamic filter chain changing code. Move the video refresh call to reinit_video_filters() to make it more uniform along with the audio code.
* player: remove some further current_track dependencieswm42016-02-051-3/+3
| | | | Now it's used for initialization only for audio and video.
* player: add complex filter graph supportwm42016-02-051-28/+62
| | | | | | | | | | | | | | | | See --lavfi-complex option. This is still quite rough. There's no support for dynamic configuration of any kind. There are probably corner cases where playback might freeze or burn 100% CPU (due to dataflow problems when interaction with libavfilter). Future possible plans might include: - freely switch tracks by providing some sort of default track graph label - automatically enabling audio visualization - automatically mix audio or stack video when multiple tracks are selected at once (similar to how multiple sub tracks can be selected)
* player: move audio and video decoder init to separate functionswm42016-02-051-22/+41
| | | | Preparation.
* player: use different variable to indicate coverartwm42016-02-011-10/+7
| | | | Slightly better.
* audio/video: merge decoder return valueswm42016-02-011-2/+2
| | | | | | Will be helpful for the coming filter support. I planned on merging audio/video decoding, but this will have to wait a bit longer, so only remove the duplicate status codes.
* player: refactor: some more minor decoder/output decouplingwm42016-01-291-8/+12
| | | | | | These changes don't make too much sense without context, but are preparation for later. Then the audio_src/video_src fields will be actually be NULL under circumstances.
* player: fix initial audio sync in certain caseswm42016-01-291-2/+0
| | | | | | | | | | | | | | | | | Regression caused by commit 3b95dd47. Also see commit 4c25b000. We can either use video_next_pts and add "delay", or we just use video_pts. Any other combination breaks. The reason why the assumption that delay==0 at this point was wrong exactly because after displaying the first video frame (usually done before audio resync) a new frame might be "added" immediately, resulting in a new video_next_pts and "delay", which will still amount to video_pts. Fixes #2770. (The reason why display-sync was blamed in this issue is because enabling display-sync in the options forces a prefetch by 2 instead of 1 frames for seeks/playback restart, which triggers the issue, even if display-sync is not actually enabled. In this case, display-sync is never enabled because the frames have a unusually high frame duration. This is also what exposed the initial desync issue.)
* video: fix coverart switchingwm42016-01-271-2/+3
| | | | | | If cover art is re-enabled during playback, the covert art picture (which has pts==0) will be discarded. Add another corner case to the list.
* video: slightly improve video stream switchingwm42016-01-261-0/+5
| | | | | Resync newly switched video streams to the current playback position. (Normal seeks will reset playback_pts to NOPTS.)
* video: limit maximum number of VO frames correctlywm42016-01-241-1/+1
| | | | | Otherwise, vo_frame.frames can be unintentionally overflown, leading to undefined behavior in corner cases.
* video: don't wait for last video frame in the normal casewm42016-01-221-4/+8
| | | | | | | | | | | | | | | | | | Even though the timing logic is correct, it tends to mess with looping videos and such in unappreciated ways. It also has to be admitted that most file formats seem not to properly define the duration of the last video frame (or libavformat does not export it in a useful way), so whether or not we should use the demuxer reported framerate for the last frame is questionable. (Still, why would you essentially just discard the last frame?) The timing logic is kept, but disabled for video with "normal" FPS values. In particular, we want to keep it for displaying images, which implicitly set the frame duration to 1 second by reporting 1 FPS. It's also good for slide shows with mf://. Fixes #2745.
* player: fix some oversights in video refactoringwm42016-01-221-5/+10
| | | | | | | | | | vo_chain_uninit() isn't supposed to care much about the decoder (although decoders and outputs still go strictly together, so there is not much of an actual difference now). Also unset track.d_video correctly. Remove a stale declaration from dec_video.h as well.
* player: refactor: eliminate MPContext.d_audiowm42016-01-221-1/+1
|
* audio: refactor: work towards unentangling audio decoding and filteringwm42016-01-221-2/+2
| | | | | | | | | Similar to the video path. dec_audio.c now handles decoding only. It also looks very similar to dec_video.c, and actually contains some of the rewritten code from it. (A further goal might be unifying the decoders, I guess.) High potential for regressions.
* player: refactor: eliminate MPContext.d_videowm42016-01-171-38/+42
| | | | | | | | | | | | | | Eventually we want the VO be driven by a A->V filter, so a decoder doesn't even have to exist. Some features definitely require a decoder though (like reporting the decoder in use, hardware decoding, etc.), so for each thing which accessed d_video, it has to be redecided if and how it can access decoder state. At least the "framedrop" property slightly changes semantics: you can now always set this property, even if no video is active. Some untested changes in this commit, but our bio-based distributed test suite has to take care of this.
* video: refactor: disentangle decoding/filtering some morewm42016-01-161-84/+53
| | | | | | | | | | | This moves some code related to decoding from video.c to dec_video.c, and also removes some accesses to dec_video.c from the filtering code. dec_video.ch is starting to make sense, and simply returns video frames from a demuxer stream. The API exposed is also somewhat intended to be easily changeable to move decoding to a separate thread, if we ever want this (due to libavcodec already being threaded, I don't see much of a reason, but it might still be helpful).
* video: refactor: slightly disentangle video filteringwm42016-01-151-43/+32
|
* video: decouple filtering/decoding slightly morewm42016-01-141-65/+80
| | | | | | | | | | | | | | | | | | | Lots of noise to remove the vfilter/vo fields from dec_video. From now on, video filtering and output will still be done together, summarized under struct vo_chain. There is the question where exactly the vf_chain should go in such a decoupled architecture. The end goal is being able to place a "complex" filter between video decoders and output (which will culminate in natural integration of A->V filters for natural integration of libavfilter audio visualizations). The vf_chain is still useful for "final" processing, such as format conversions and deinterlacing. Also, there's only 1 VO and 1 --vf option. So having 1 vf_chain for a VO seems ideal, since otherwise there would be no natural way to handle all these existing options and mechanisms. There is still some work required to truly decouple decoding.
* video: refactor: shuffle code aroundwm42016-01-141-0/+71
| | | | | | struct dec_video should have nothing to do with video filters or outputs, and this huge chunk of code was somehow stuck directly in dec_video.c.
* video: refactor: handle video format fixups closer to decoderwm42016-01-141-3/+5
| | | | | | | | | | Instead of handling this on filter chain reinit, do it directly after the decoder. This makes the code less entangled. In particular, this gets rid of the really weird "override params" concept in the video filter code. The last_format/fixed_formats have some redundance with decoder_output, but unfortunately the latter has a slightly different use.
* player: simplify backsteppingwm42016-01-121-7/+14
| | | | | | | | | | | | | | Basically reimplement it. The old implementation was quite stupid, and was probably done this way because video filtering and output used to be way less decoupled. Now we can reimplement it in a very simple way: when backstepping, seek to current time, but keep the last frame that was supposed to be discarded when reaching the target time. When the seek finishes, prepend the saved frame to the video frame queue. A disadvantage is that the new implementation fails to skip over timeline boundaries (ordered chapters etc.), but this never worked properly anyway. It's possible that this will be fixed some time in the future.
* player: handle hrseek framedrop correctlywm42016-01-121-1/+1
| | | | | This was non-sense and checked the option instead of the actual flag. Possibly could lead to incorrect hr-seeks.
* demux: merge sh_video/sh_audio/sh_subwm42016-01-121-2/+2
| | | | | | | | | | This is mainly a refactor. I'm hoping it will make some things easier in the future due to cleanly separating codec metadata and stream metadata. Also, declare that the "codec" field can not be NULL anymore. demux.c will set it to "" if it's NULL when added. This gets rid of a corner case everything had to handle, but which rarely happened.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* player: detect audio PTS jumps, make video PTS heuristic less aggressivewm42016-01-091-12/+0
| | | | | | | | | | | | | | | | | | | | | | This is another attempt at making files with sparse video frames work better. The problem is that you generally can't know whether a jump in video timestamps is just a (very) long video frame, or a timestamp reset. Due to the existence of files with sparse video frames (new frame only every few seconds or longer), every heuristic will be arbitrary (in general, at least). But we can use the fact that if video is continuous, audio should also be continuous. Audio discontinuities can be easily detected, and if that happens, reset some of the playback state. The way the playback state is reset is rather radical (resets decoders as well), but it's just better not to cause too much obscure stuff to happen here. If the A/V sync code were to be rewritten, it should probably strictly use PTS values (not this strange time_frame/delay stuff), which would make it much easier to detect such situations and to react to them.
* video: fix debug messagewm42016-01-061-1/+1
| | | | Should not be a warning, and the message text was also very useless.
* video: do not disable hr-seek framedrop too earlywm42015-12-301-7/+5
| | | | | | This didn't make too much sense, and just made seeking slower. Strictly suggest the decoder to drop a frame if its PTS is before the seek target.
* sub: change how subtitles are readwm42015-12-291-1/+5
| | | | | | | | Slightly change how it is decided when a new packet should be read. Switch to demux_read_packet_async(), and let the player "wait properly" until required subtitle packets arrive, instead of blocking everything. Move distinguishing the cases of passive and active reading into the demuxer, where it belongs.
* video: switch from using display aspect to sample aspectwm42015-12-191-2/+5
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* player: remove redundant checkwm42015-12-051-1/+1
| | | | Found by Coverity.
* player: don't make display-sync panic on timestamp discontinuitieswm42015-12-041-2/+2
|
* player: resync audio only on larger timestamp discontinuitieswm42015-12-041-2/+2
| | | | | | | | | Helps with files that have occasional broken timestamps. For larger discontinuities, e.g. caused by actual timestamp resets, we still want to realign audio. (I guess in general, this should be removed and replaced by a more general resync-on-desync logic, but not now.)
* vo_opengl: fix interpolation with display-syncwm42015-11-281-1/+2
| | | | | | | | | | | | | | | | | | | | At least I hope so. Deriving the duration from the pts was not really correct. It doesn't include speed adjustments, and becomes completely wrong of the user e.g. changes the playback speed by a huge amount. Pass through the accurate duration value by adding a new vo_frame field. The value for vsync_offset was not correct either. We don't need the error for the next frame, but the error for the current one. This wasn't noticed because it makes no difference in symmetric cases, like 24 fps on 60 Hz. I'm still not entirely confident in the correctness of this, but it sure is an improvement. Also, remove the MP_STATS() calls - they're not really useful to debug anything anymore.
* player: fix commit 50bb209awm42015-11-281-1/+1
| | | | Well, this was stupid.
* vo: change vo_frame field unitswm42015-11-271-1/+2
| | | | | | | This was just converting back and forth between int64_t/microseconds and double/seconds. Remove this stupidity. The pts/duration fields are still in microseconds, but they have no meaning in the display-sync case (also drop printing the pts field from opengl/video.c - it's always 0).
* player: always disable display-sync on desyncswm42015-11-271-22/+12
| | | | | | | | | | | | | | | Instead of periodically trying to enable it again. There are two cases that can happen: 1. A random discontinuity messed everything up, 2. Things are just broken and will desync all the time Until now, it tried to deal with case 1 - but maybe this is really rare, and we don't really need to care about it. On the other hand, case 2 is kind of hard to diagnose if the user doesn't use the terminal. Seeking will reenable display-sync, so you can fix playback if case 1 happens, but still get predictable behavior in case 2.
* player: make display-vdrop mode do what the manpage claimswm42015-11-261-4/+7
| | | | | Don't change video speed in this mode, which is closer to the claim on the manpage that it's close to the behavior of the "audio" mode.
* player: log some more display-sync informationwm42015-11-251-3/+6
|
* player: use demuxer ts offset to simplify timeline ts handlingwm42015-11-161-4/+0
| | | | | | | | | Use the demux_set_ts_offset() added in the previous commit to base each timeline segment to use timestamps according to its relative position within the overall timeline. As a consequence we don't need to care about these timestamps anymore, and everything becomes simpler. (Another minor but delicious nugget of sanity.)
* player: account for minor VO underrunswm42015-11-141-2/+2
| | | | | | | | | If the player sends a frame with duration==0 to the VO, it can trivially underrun. Don't panic, but keep the correct time. Also, returning the absolute time from vo_get_next_frame_start_time() just to turn it into a float with relative time was silly. Rename it and make it return what the caller needs.
* player: fix audio drift computation at different playback speedswm42015-11-141-8/+9
| | | | | This computed nonsense if the user set a playback speed other than 1 (in addition to the display-sync speed change).
* player: stricter framedrop thresholdwm42015-11-131-3/+2
| | | | | | 80ms allowable desync was a bit too much. It'd allow for a range of 160ms, which everyone can notice. It might also be a bother to apply compensation resampling speed for that long.
* player: try to compensate actual audio driftwm42015-11-131-0/+40
| | | | | | | | | | | | | | | | We always let audio slowly desync until a threshold is reached, and then pushed it back by applying a maximum compensation speed. Refine what comes afterwards: instead of playing with the nominal video speed, use the actual required audio speed for keeping sync as measured by the A/V difference. (The "actual" speed is the ideal speed with A/V differences added.) Although this works in theory, it's somewhat questionable how much this works in practice. The ideal time value is actually not exact, but is the time at which the frame is scheduled (could be compensated by using the time_left calculations in handle_display_sync_frame()). It doesn't account for speed changes or catastrophic discontinuities. It uses only 10 past frames.
* player: change display-sync audio speed only if neededwm42015-11-131-38/+48
| | | | | | | | | | As long as it's within the desync tolerance, do not change the audio speed at all for resampling. This reduces speed changes which might be caused by jittering timestamps and similar cases. (While in theory you could just not care and change speed every single frame, I'm afraid that such changes could possibly cause audio artifacts. So better just avoid it in the first place.)
* player: remove display_sync_disable_counterwm42015-11-131-10/+8
| | | | We can implement it differently and drop a tiny bit of state.
* command: add vsync-ratio propertywm42015-11-131-4/+7
| | | | | | | | This is very "illustrative", unlike the video-speed-correction property, and thus useful. It can also be used to observe scheduling errors, which are not detected by the core. (These happen due to rounding errors; possibly not evne our fault, but coming from files with rounded timestamps and so on.)
* player: compute required display-sync speed change differentlywm42015-11-131-22/+36
| | | | | | | | | | | | | Instead of looking at the current frame duration for the intended speedup, look at all past frames, and find a good average speed. This ties in with not wanting to average _all_ frame durations, which doesn't make sense in VFR situations. This is currently done in the most naive way possible, but already sort of works for VFR which switches between frame durations that are integer multiples of a base rate. Certainly more improvements could be made, such as trying to adjust directly on FPS changes, instead of averaging everything, but for now this is not needed at all.
* player: smooth out frame durations by averaging themwm42015-11-131-1/+1
| | | | | | | | | | | | | | | | | | Helps somewhat with muxer-rounded timestamps. There is some danger that this introduces a timestamp drift. But since they are averaged values (unlike as when using an incorrect container framerate hint), any potential drift shouldn't be too brutal, or compensate itself soon. So I won't bother yet with comparing the results with the real timestamp, unless we run into actual problems. Of course we still prefer potentially real timestamps over the approximated ones. But unless the timestamps match the container FPS, we can't know whether they are (no, checking whether the they have microsecond components would be cheating). Perhaps in future, we could let the demuxer export the timebase - if the timebase is not 1000 (or divisible by it), we know that millisecond-rounded timestamps won't happen.
* player: refactor display-sync frame duration calculationswm42015-11-131-103/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of get_past_frame_durations(), which was a bit too messy. Add a past_frames array, which contains the same information in a more reasonable way. This also means that we can get the exact current and past frame durations without going through awful stuff. (The main problem is that vo_pts_history contains future frames as well, which is needed for frame backstepping etc., but gets in the way here.) Also disable the automatic disabling of display-sync if the frame duration changes, and extend the frame durations allowed for display sync. To allow arbitrarily high durations, vo.c needs to be changed to pause and potentially redraw OSD while showing a single frame, so they're still limited. In an attempt to deal with VFR, calculate the overall speed using the average FPS. The frame scheduling itself does not use the average FPS, but the duration of the current frame. This does not work too well, but provides a good base for further improvements. Where this commit actually helps a lot is dealing with rounded timestamps, e.g. if the container framerate is wrong or unknown, or if the muxer wrote incorrectly rounded timestamps. While the rounding errors apparently can't be get rid of completely in the general case, this is still much better than e.g. disabling display-sync completely just because some frame durations go out of bounds.
* player: always require a future frame with display-sync enabledwm42015-11-131-2/+6
| | | | | | We need a frame duration even on start, because the number of vsyncs the frame is shown is predetermined. (vo_opengl actually makes use of this property in certain cases.)
* player: less naive roundingwm42015-11-111-1/+1
|
* player: use input instead of output format for spdif checkwm42015-11-041-1/+1
| | | | | | This check disables the display-sync resample method. If the filters convert PCM to AC3, we can still insert a filter to change speed. This is because filters are inserted at the beginning of the filter chain.
* player: move audio speed adjustment codewm42015-11-041-54/+60
| | | | | | | | | Move it (in a cosmetic sense), and also move its invocation to below all the video handling. All other changes remain cosmetic, in