Corrupt frame when seeking HEVC encoded with x265 2.8 or later

[bodayw]

mpv version and platform

mpv v0.29.1 on Windows/macOS/Linux

Reproduction steps

Open any video encoded with x265 2.8 or later in mpv and click on the progress bar to seek.

Expected behavior

It should show the target frame just fine.

Actual behavior

Almost on every seek, mpv will show a corrupt frame, similar to the screenshot in #3440.

If mpv is running in command line mode, it will also print this error message:

[ffmpeg/video] hevc: Could not find ref with POC 0

So it seems that mpv failed to find the last I-frame, resulting a "corrupt" partially encoded frame being shown.

Some observations:

• The issue is not platform-dependent. We could reproduce with latest mpv builds on Windows/macOS/Linux, with x265 2.8 and 2.9 compiled and files encoded on Windows/Linux;
• The issue only happens with HEVC files encoded with x265 2.8 or later, while everything seems fine with HEVC encoded with at least x265 2.5, 2.6 and 2.7;
• The issue happens no matter --hr-seek is set to absolute (default), yes, or no;
• Tried setting --hr-seek-demuxer-offset=5 and it did help to reduce the chance of showing a corrupt frame, but couldn't eliminate it completely;
• We've tried MPC-HC/MPC-BE/PotPlayer/VLC/ffplay and couldn't reproduce the issue;
• In all tests software decoding is used, so not really sure if this is related to HEVC hardware decoder breaks after seeking in macOS 10.14 (Mojave) #6152 and such.

Log file

https://0x0.st/sEyI.txt

(See line 2393-2399 when seeking occurs)

Sample files

https://0x0.st/sEyJ.mkv
https://0x0.st/sEyy.mkv

(The first file is encoded with x265 2.8, second one is x265 2.7 which doesn't have the problem)

[wfwf1997]

I've found a change in x265 that may cause the problem:
Set IDR's NAL type to NAL_UNIT_CODED_SLICE_IDR_N_LP if it does not have associated leading pictures
commit:
https://bitbucket.org/multicoreware/x265/commits/b9f5b5d7bf95c2a4dda1cec51fc104f9122f374b
(GitHub's mirror: videolan/x265@58b5f9d)

Also, I think it's pretty weird that if I use --start to seek to that frame at the start of playing, no corrupt frame appears.

[mc4man]

I have older mpv packages around, this issue appears in a 0.28 build from last dec.25 but not in a 0.27+ git from a few weeks prior. The main difference was a newer ffmpeg source.
At least here this ffmpeg commit causes the issue in mpv, any ffmpeg source prior to is fine.
(- tested with the 0.28 mpv source that showed the issue
FFmpeg/FFmpeg@05c1c79

[mc4man]

Can also be seen in vlc when using ffmpeg-4.0.x though not in some other players like totem. mplayer or ffplay

[bodayw]

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/10bc4c3a7df7bb26303067b97311b7eeedfd453e

@wfwf1997 identified the bug in ffmpeg and submitted a patch, which has been merged to the main ffmpeg git repo yesterday, see link above.

This issue should be resolved now if you build mpv with ffmpeg git, or one can wait for the next ffmpeg (and then mpv) release.