Decreased seeking performance about mpc-hc HOT 17 CLOSED

Fixed in 1.8.4

from mpc-hc.

I'm coming from v1.7.13 and saw a new team took over which released v1.8.3:

MPC-HC (64-bit)

Build information:
Version: 1.8.3 (40b2210)
Compiler: MSVC v19.14.26433
Build date: Oct 5 2018 09:09:55

Unfortunately, the seek time when jumping forward/backward is AWFUL! I guess I suffer from the same problem as other people here.

Is there anything we can do to fix this bug? It's driving me nuts... I had to revert to v1.7.13 ;(
Alternatively, can someone tell me which version was the last that worked correctly?

from mpc-hc.

Can you give a link to a file that gives you seek problems?

from mpc-hc.

Unfortunately no, but please find below the MediaInfo of one defective file.

Also I have analysed the keyframes of some defective files using ffprobe, and they do have I-frames. One file every 240 frames, another file every 250 frames.

I also tried other, unrelated files, and they don't have this seeking issue.

General
Complete name                  : xxxxx.mp4
Format                         : MPEG-4
Format profile                 : Base Media
Codec ID                       : isom (isom/iso2/avc1/mp41)
File size                      : 565 MiB
Duration                       : 10 min 29 s
Overall bit rate               : 7 524 kb/s
Movie name                     : xxxxx
Writing application            : Lavf57.56.100
Comment                        : xxxxx

Video
ID                             : 1
Format                         : AVC
Format/Info                    : Advanced Video Codec
Format profile                 : High@L4
Format settings, CABAC         : Yes
Format settings, RefFrames     : 4 frames
Codec ID                       : avc1
Codec ID/Info                  : Advanced Video Coding
Duration                       : 10 min 29 s
Bit rate                       : 7 390 kb/s
Width                          : 1 920 pixels
Height                         : 1 080 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Constant
Frame rate                     : 25.000 FPS
Color space                    : YUV
Chroma subsampling             : 4:2:0
Bit depth                      : 8 bits
Scan type                      : Progressive
Bits/(Pixel*Frame)             : 0.143
Stream size                    : 555 MiB (98%)
Writing library                : x264 core 142
Encoding settings              : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=36 / lookahead_threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Audio
ID                             : 2
Format                         : AAC
Format/Info                    : Advanced Audio Codec
Format profile                 : LC
Codec ID                       : 40
Duration                       : 10 min 29 s
Bit rate mode                  : Constant
Bit rate                       : 128 kb/s
Channel(s)                     : 2 channels
Channel positions              : Front: L R
Sampling rate                  : 48.0 kHz
Frame rate                     : 46.875 FPS (1024 SPF)
Compression mode               : Lossy
Stream size                    : 9.61 MiB (2%)
Default                        : Yes
Alternate group                : 1

from mpc-hc.

Options > Tweaks > Jump Distances
If you change the middle value to 11000. Does that solve your problem if you seek using the arrow keys (= medium jump)?

It seems I need to add an extra option to allow/disallow very inaccurate fast seeks.

from mpc-hc.

I tried this, and it doesn't solve the issue. Tweaking the value and seeking with the keyboard, it's as slow with latest versions, and instantaneous with previous ones.

from mpc-hc.

I need a sample file to properly fix this. I don't care if it is porn or whatever.

Link can be shared privately by mailing to: [email protected]

from mpc-hc.

Should be fixed now. There is a new option that allows bigger inaccuracy.

from mpc-hc.

This looks great, thanks!

Personally, I prefer fast seeking over accurate seeking, especially with "latest keyframe".
This way it feels fast, it is actually fast, and yet you don't miss the seekpoint.

from mpc-hc.

I'm sorry, I just tried the new 1.8.1 and it still has the slow seeking. Tried with AllowInaccurateFastseek setting enabled/disabled, and latest/nearest keyframe.

Just to rule this out, I compared to 1.7.13.112, both use LAV internal.

from mpc-hc.

Of course: is there anything I could do, to help figuring out the issue?

from mpc-hc.

I will look at it again this weekend. I can reproduce.

from mpc-hc.

It is not fault of player, but because of bug in FFmpeg code that is used by the internal codecs. Finding exact cause will take a bit longer.

from mpc-hc.

That's interesting to know. Are you sure it's a bug in the decoder and not in the encoding? Are you in touch with the FFmpeg team?

from mpc-hc.

Any news?

from mpc-hc.

I confirm 1.8.4 fixed the issue, great!

I guess it's fixed by LAV update (8cdd2e0), which in turn has an updated ffmpeg…
and the actual fix is clsid2/FFmpeg@60d12a4, great work!

Thus, do we have to keep the AllowInaccurateFastseek option introduced in 1.8.1 (13d5bb4)?
It was introduced as an attempt to fix the issue, but didn't fix it.
So it seems to be useless, and we should better remove it for simplification?

from mpc-hc.

Oooooooooooooooh! It works great again!

thank you, Thank You, THANK YOU!!!

from mpc-hc.