summaryrefslogtreecommitdiffstats
path: root/player/video.c
Commit message (Collapse)AuthorAgeFilesLines
* player: log if video is considered an imagewm42016-08-211-0/+1
| | | | It's a heristic that can fail, so better log it.
* player: refresh very low framerate video on filter changeswm42016-08-191-1/+3
| | | | | | | Limit the max. time the refresh is delayed. Make it refresh at all if image mode is enabled. Fixes #3435.
* vf_rotate: allow arbitrary rotationwm42016-08-191-2/+2
| | | | | | | vf_rotate selects the correct filter for 90° rotation, but it can be extended to use lavfi's vf_rotate as fallback. See #3434.
* video: don't discard video frames after endptswm42016-08-181-3/+5
| | | | | | | | | | | | Instead of letting it keep decoding by trying to find a new frame, "plug" the frame queue by not removing it. (Or actually, by putting it back instead of discarding it.) Matters for seamless looping (following commits), and possibly some other corner cases. The added function vf_unread_output_frame() is a bit of a sin, but still reasonable, since its implementation is trivial.
* player: add option to control duration of image displaywm42016-08-171-12/+22
| | | | | | | | | | | | | The --image-display-duration option controls how long an image is displayed. It's also possible to display the image forever (until manual user interaction stops playback). With this, the core drops the old method to "drain" video (i.e. waiting for the last frame duration on end of playback). Instead, we reuse MPContext.time_frame. The old mechanism was disabled for non-images anyway. Fixes #3425.
* player: allow passing flags to queue_seek()wm42016-08-151-1/+1
| | | | | | | | | | | | Change the last parameter from a bool to an int, which is supposed to take bit-flags. The at this point only flag is MPSEEK_FLAG_DELAY, which replaces the previous bool parameter. The old false parameter becomes 0, the old true parameter becomes MPSEEK_FLAG_DELAY. Since the old "immediate" parameter is now essentially inverted, two coalesced immediate and delayed seeks end up as delayed instead of immediate. This change doesn't matter, since there are no relative immediate seeks anyway.
* player: fix display-sync timing if audio take long on resumewm42016-08-071-0/+6
| | | | | | | | | | | | | | | | | In display-sync mode, the very first video frame is idiotically fully timed, even though audio has not been synced yet at this point, and the video frame is more like a "preview" frame. But since it's fully timed, an underflow is detected if audio takes longer than the display time of the frame (we send the second frame only after audio is done). The timing code will try to compensate for the determined desync, but it really shouldn't. So explicitly discard the timing info in this specific case. On the other hand, if the first frame still hasn't finished display, we can pretend everything is ok. This is a hack - ideally, we either would send a frame without timing info (and then send it again or so when playback starts properly), or we would add real pause support to the VO, and pause it during syncing.
* player: disable DS with spdif transcoding toowm42016-07-241-2/+5
| | | | | | Otherwise it behaves dumb. (Although you could argue it shouldn't try to guess whether speed changes work, but instead simply disable DS if they don't work.)
* video: respect --deinterlace=autowm42016-07-121-1/+2
| | | | | | | | | | | | | | | | | | | | --deinterlace=auto is the default, and has the obscure semantics that deinterlacing is disabled, unless the user has manually inserted a deinterlacing filter. While in software decoding this doesn't matter, and we will happily insert 2 yadif filters (if the user has already added one), or not remove the yadif filter (if deinterlacing is disabled, but the user has added the filter manually), this is different with hardware deinterlacer filters. These support VFCTRL_SET_DEINTERLACE for toggling deinterlacing filtering at runtime. It exists mainly for legacy reasons, and possibly because it makes switching deinterlacing modes more efficient. It might also gives us an entry-point for VO deinterlacing, maybe. For whatever reasons this mechanism exists, we still support and use it. This commit fixes that video.c always used VFCTRL_SET_DEINTERLACE to disable deinterlacing, even if --deinterlace=auto was set. Fix this by checking the value of the option directly.
* video: fix midstream video configuration changeswm42016-07-081-0/+1
| | | | | | | Commit 771a8bf5 added code to avoid unnecessary vf_reconfig() calls for unrelated reasons, but forget to consider that it has to be called at least once if the input format changes. As a consequence it got "stuck" due to not being able to decode more frames.
* video: limit number of frames sent to VO to the VO requested amountwm42016-07-071-1/+3
| | | | | | | | | | vo_frame can have more than 1 frame - the extra frames are future references, which are sometimes useful for filtering (vo_opengl interpolation). There's no harm in reducing the number of frames sent to the VO requested amount of future frames, so do that. Doesn't actually reduce the number of concurrently in use frames in practice.
* video: fix deinterlace filter handling for VFCTRL_SET_DEINTERLACE filterswm42016-07-061-18/+20
| | | | | | | | | | | | | | | | | | | | Some filters support VFCTRL_SET_DEINTERLACE. This affects most hardware deinterlace filters. They can be inserted by the user manually, or auto- inserted by vf.c itself as conversion filter (vf_d3d11vpp). In these cases, we shouldn't insert or remove filters outselves, and instead VFCTRL_SET_DEINTERLACE should be invoked to switch the mode. This wasn't done correctly in the recently refactored code and could have broken with --deinterlace. (The refactor only considered switching via property in this case.) Fix it by making it a proper part of the filter_reconfig() function, and making set_deinterlacing() (which is called by the property handler) merely call filter_reconfig() in all cases to do the real work. We can even avoid rebuilding the filter chain - though only if no other auto-filters are inserted. It probably also provides a slightly cleaner way to implement functionality in the VO while still inserting video filter fallbacks correctly if required.
* video: fix deinterlace filter handling on pixel format changeswm42016-07-061-7/+4
| | | | | | | | | | | | | | | | | The test scenario at hand was hardware decoding a file with d3d11 and with deinterlacing enabled. The file switches to a non-hardware dedocdeable format mid-stream. This failed, because it tried to call vf_reconfig() with the old filters inserted, with was fatal due to vf_d3d11vpp accepting only hardware input formats. Fix this by always strictly removing all auto-inserted filters (including the deinterlacing one), and reconfiguring only after that. Note that this change is good for other situations too, because we generally don't want to use a hardware deinterlacer for software decoding by default. They're not necessarily optimal, and VAAPI VPP even has incomprehensible deinterlacer bugs specifically with software frames not coming from a hardware decoder.
* player: rewrite deinterlace filter auto-insertionwm42016-07-051-22/+82
| | | | | | | | | | | | | | Instead of using the "vf" command code (which changes filters at runtime on user input), use the general filter-insertion code. The latter was added later, and is more suitable for automatically inserted filters. The old code failed in particular when using watch-later saving, which stored the filter list in the resume config file. If a user changed the hardware decoding mode via command line, the stored filter chain was out of date and could cause failure due to not working with hardware or software decoding mode. Storing the deinterlace filter in the filter list was unavoidable, because it was part of the user state. (The new code only edits the actually instantiated filters.)
* video: refactor how VO exports hwdec device handleswm42016-05-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
* player: always show the first frame in DS modewm42016-04-241-0/+4
| | | | Fixes bogus frame drop counter in cover art mode.
* player: assume video forwards timestamps jumps only with some formatswm42016-04-241-1/+1
| | | | | | | | | Another crappy fix for timestamp reset issues. This time, we try to fix files which have very weird but legitimate frame durations, such as cdgraphics. It can have many short frames, but once in a while there are potentially very long frames. Fixes #3027.
* player: cleaner determination of current playback PTSwm42016-04-231-1/+0
| | | | | In particular, this won't overwrite the playback PTS in coverart mode, which actually fixes relative seeks.
* player: fix breakage when combining 3D and rotate auto-filterswm42016-03-281-9/+5
| | | | | | | | | | | This would get stuck in reconfiguring the filter chain forever, because params was mutated ("params.rotate = 0;"). This was used as input for vf_reconfig(), but the filter chain input must always be equivalent to the decoder output, or filter chain reconfiguration will be triggered. The line of code to reset the rotation is from a time when this used to work differently. Also remove the unnecessary try_filter() parameter.
* player: remove auto-inserted filters before adding them againwm42016-03-281-1/+11
| | | | | | | Makes certain cases of runtime changes actually work. Also change the label for the stereo3d filter and make it consistent with the rotate one.
* player: minor simplificationwm42016-02-271-3/+4
| | | | | | No need to pass endpts down in such a dumb way. Also remove an outdated comment somewhere.
* player: slightly simplify how demuxer streams are enabled/disabledwm42016-02-251-1/+1
| | | | | Instead of having reselect_demux_streams() look at all streams, make it look at the current stream that is being enabled/disabled.
* audio/video: expose codec info as separate fieldwm42016-02-151-0/+1
| | | | | Preparation for the timeline rewrite. The codec will be able to change, the stream header not.
* video: remove pointless parameter indirectionwm42016-02-151-1/+1
| | | | This is always the same value.
* 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.
*