mirror of
https://github.com/mpv-player/mpv
synced 2025-02-21 07:16:56 +00:00
7d0e0b3a5c
If you have a EDL stream with separate sources for audio and video stream (like ytdl_hook now creates), you can get the problem that the video stream seeks to a different position than audio due to different key frame granularity. In particular, if you seek backward, the video might undershoot the seek target by a lot. Then video will resume from an earlier position than audio, and the player plays silence. This is annoying. Fix this by explicitly implementing a heuristic to detect separate audio/video streams, determining where a video seek ends up, and then seeking the audio stream to the video destination. This also makes sure to not seek audio with SEEK_FORWARD, so it will always seek before the video position. Non-precise seeks still skip audio to the video target, so this helps with ensuring that audio is present at the final seek target. The implementation is very annoying, because the only way to determine the seek target is to actually read a packet. Thus a 1-packet queue needs to be added. In theory, we could get the seek target from the index of the video file (especially if it's mp4), but libavformat does not have public API that exports this index, so we're stuck with this roundabout generic method. Note that this is only for non-precise seeks. If precise seeks are done, the problem is handled by the frontend by skipping unwanted video frames. But non-precise seeking should still work. (Personally I prefer non-precise seek mode by default because they're still significantly faster.) It also needs to be said that this is the 4th implementation of this seek adjustment thing in mpv. The 1st implementation is in the frontend (look for MPContext.seek_slave). This works only if the external audio stream is known as such on the frontend level. The 2nd implementation is in the demuxer level packet cache (top of execute_cache_seek()). This is similar to code that any demuxer needs to handle non-precise seeks sufficiently nicely. The 3rd is in demux_mkv.c. Since mkv is an interleaved format, this implementation mostly consists on trying to pick index entries for video packets if a video stream is selected. Maybe these "redundant" implementations could be avoided by exposing separate streams through the demuxer API (and making them individually seekable) or something like this, but this is messy and not without problems for multiple reasons. So for now this commit is the best way to fix the observed behavior. |
||
|---|---|---|
| .. | ||
| codec_tags.c | ||
| codec_tags.h | ||
| cue.c | ||
| cue.h | ||
| demux_cue.c | ||
| demux_edl.c | ||
| demux_lavf.c | ||
| demux_libarchive.c | ||
| demux_mf.c | ||
| demux_mkv_timeline.c | ||
| demux_mkv.c | ||
| demux_null.c | ||
| demux_playlist.c | ||
| demux_raw.c | ||
| demux_timeline.c | ||
| demux.c | ||
| demux.h | ||
| ebml.c | ||
| ebml.h | ||
| matroska.h | ||
| packet.c | ||
| packet.h | ||
| stheader.h | ||
| timeline.c | ||
| timeline.h | ||