Cycling through video tracks seeks forward, breaks video output or crashes

[AgentOak]

mpv version and platform

mpv git-efa9fe8 (C) 2000-2016 mpv/MPlayer/mplayer2 projects
 built on Thu Aug  4 20:27:09 CEST 2016
ffmpeg library versions:
   libavutil       55.28.100
   libavcodec      57.48.100
   libavformat     57.41.100
   libswscale      4.1.100
   libavfilter     6.47.100
   libswresample   2.1.100
ffmpeg version: 3.1.1

on Manjaro 16.06.1 x64.
Also happens with the 2016-07-10 version from mpv.srsfckn.biz (mpv 0.18.1-git-1e00bcc / ffmpeg N-80954-g70d9b2e) on Windows 7 x64.

Reproduction steps

1. Have any file that only contains a video track (or use --no-audio, reproduces it as well)
2. Run mpv as mpv --no-config --force-window <videofile>
3. Pause the video at some point, so the problem becomes visible
4. Use _ to cycle between vid 0 (no video output) and vid 1 (the video track of the input file)

Actual behavior

Depending on the file, different problems occur when cycling back to vid 1. You can easily make out similarities, based on the container and video codec.

mkv+H.264: The player seeks forward several seconds (I assume until the next keyframe) and the following errors occur a varying number of times and in varying order:

[ffmpeg/video] h264: Missing reference picture, default is 0
[ffmpeg/video] h264: co located POCs unavailable
[ffmpeg/video] h264: mmco: unref short failure
[ffmpeg/video] h264: Missing reference picture, default is 65538
[ffmpeg/video] h264: reference picture missing during reorder

mkv+MPEG-4: The player seeks forward several seconds and (some of) the following errors occur:

[ffmpeg/video] mpeg4: time_increment_bits 4 is invalid in relation to the current bitstream, this is likely caused by a missing VOL header
[ffmpeg/video] mpeg4: time_increment_bits set to 10 bits, based on bitstream analysis
[ffmpeg/video] mpeg4: Error, header damaged or not MPEG-4 header (f_code=0)
[ffmpeg/video] mpeg4: header damaged
[ffmpeg/video] mpeg4: Context scratch buffers could not be allocated due to unknown size.
[ffmpeg/video] mpeg4: time_increment_bits 10 is invalid in relation to the current bitstream, this is likely caused by a missing VOL
 header
[ffmpeg/video] mpeg4: time_increment_bits set to 16 bits, based on bitstream analysis
[ffmpeg/video] mpeg4: Context scratch buffers could not be allocated due to unknown size.
[vd] Error while decoding frame!
[ffmpeg/video] mpeg4: looks like this file was encoded with (divx4/(old)xvid/opendivx) -> forcing low_delay flag
[ffmpeg/video] mpeg4: warning: first frame is no keyframe
[vd] Error while decoding frame!
[ffmpeg/video] mpeg4: low_delay flag set incorrectly, clearing it

mp4: Sometimes same as mkv, but usually simply goes [lavf] EOF reached. and exits
avi: Same errors as with mkv, but doesn't seek forward. Instead video output becomes corrupted until the next keyframe.

When an audio track is active however, the player usually only seeks forward by one frame and no errors occur.

As it happens with a wide variety of file formats and with almost any video I tried, I don't think it is necessary to provide any example files.

Workaround

Say you want to use the cycle function to compare two video files, a.mkv and b.mkv, load one of the files as both input and external-file:
mpv --force-window --external-file a.mkv --external-file b.mkv a.mkv
Only cycle between the video tracks of the external files:
_ cycle-values "vid" 2 3 in input.conf
None of the above errors ever occur and the player never seeks forward even a single frame, no matter how often you cycle the video track.

Log files

Full output of opening the player with an mkv+H.264 file (no audio) as input and cycling between vid 0 and 1 several times: http://sprunge.us/iNBZ

[ghost]

I see no crashes here.

Video track switching doesn't work ideally because it essentially just disables/enables returning packets mid-stream, instead of performing a seek to ensure consistent packets are returned. (This leads to the decoder outputting a bunch of error messages, until decoding can be resumed normally from the next key frame.)

For mkv (with mpv's internal mkv demuxer) there is actually a mechanism that tries to deal with this, but apparently it doesn't work if there's no other stream that can serve as reference (like an audio stream).

Not really a bug, but a feature request.

[AgentOak]

I considered the [lavf] EOF reached. with mp4 a crash, since it's not expected to do that.

But why does it work perfectly when cycling only between video tracks loaded from external files? Where's the difference that leads to cycling not working with the main input file?
For example, this works as well:
mpv --no-audio --force-seekable --external-file a.mkv --external-file b.mkv null://

[ghost]

I considered the [lavf] EOF reached. with mp4 a crash,

No, a crash means the OS kills the process due to an internal error.

But why does it work perfectly when cycling only between video tracks loaded from external files?

Because external files are seeked when the first track from them is enabled. (They'd have the same issue if you played multiple streams from it.)

[ghost]

Well, I'll probably try to come up with an improvement tomorrow. But before that: why do you even want to do this? Normally, video track switching is "good enough".

[AgentOak]

I regularly encode videos and want to compare the source and output to make sure the quality is all right. Or compare two encodes to see how or if certain encoder settings make a difference in quality.
Until now I have always picked a few scenes, taken screenshots of it, then opened the other file, navigated to the exact same frame numbers, taken screenshots again and compared them. Video track switching would be much more convenient. Plus I'd have easy access to functionality like gamma, video-zoom and various upscaling modes.

[ghost]

That's rather questionable, but ok.

Keep in mind that if the timestamps are even just a little different, switching video tracks might be off by a frame.