Maybe a seeking error after 2.40 about ffms2 HOT 19 CLOSED

OK, I'll look into doing that this week.

from ffms2.

regression introduced by 13d9f.

from ffms2.

Can you be a bit more specific on what types of files this affects? You've only said "a video" - and it definitely isnt all videos, (not e.g. MP4 AFAICT). Is it specific to Matroska? H.264 in Matroska? Blu-ray H.264 in Matroska?

from ffms2.

Also can you test with master, particularily after: 5da8f49

from ffms2.

It is not specific to Matroska. In fact, I originally spot this with several Blu-ray m2ts files. The sample mkv file is actually a m2ts remux.

from ffms2.

from ffms2.

It definitely does not affect all AVC files, at least not via the C API - I've had petabytes of videos run via that + tests (albeit almost totally only MP4s) running though it since that commit when in. I've not tested via the VS plugin, though.

I have a few possible suspicions:

• It's posible it may not affect MP4 so I didn't notice (all the unit tests are MP4s, and I mostly only send those though).
• May be specific to the kinds of flags you'd get in a Blu-ray (fields, or fake fields).
• It's possible FFmpeg's behavior changed since 2018 and made that commit no longer work - particularily if the delay calculation is no longer valid, it could trip the PAFF check.

I am leaning towards the third possibility, since I would have expected this to come up sooner in the previous 3 years since that commit, otherwise. That also means it will be a giant headache to debug...

I will check into it this week - any further info is of course welcome 🙂 .

from ffms2.

I used Vapoursynth-R54, ffms3000 and lsmas to reproduce it many times, both avc and hevc, mkv and mp4.

from ffms2.

I definitely suspect an FFmpeg behavior change, then.

from ffms2.

from ffms2.

Option 1 is how the tests I generally run are generated, interestingly enough.

Also, thanks for clarifying it is off-by-one, and testing. I'll try and dig into this.

from ffms2.

It should affect all avc video files. The latest master branch (rev 9525fcd) also exhibits this issue. I wrote a script to test ffms2 against lsmas. https://github.com/AkarinVS/weird-scripts/blob/master/ffms2/issue394.vpy

You can try this build. I have no issues with it. Here quick test between the different version. It would be great if the latest upstream builds fix the regressions.

from ffms2.

@TbtBI that is interesting, since that is a very recent build - long after the supposed source of seeking issues...

I notice the fork of ffmpeg used in that build has: HomeOfAviSynthPlusEvolution/FFmpeg@95dfde1

from ffms2.

@TbtBI that is interesting, since that is a very recent build - long after the supposed source of seeking issues...

I notice the fork of ffmpeg used in that build has: HomeOfAviSynthPlusEvolution/FFmpeg@95dfde1

There are included patches too in the link of that build. It seems reverted back some commits:
https://forum.doom9.org/showthread.php?p=1879358#post1879358
https://forum.doom9.org/showthread.php?p=1921589#post1921589

from ffms2.

Some of those contain revert, but that big diff contains a bunch of changes that seem to come form nowhere, without context? That's... kind of a mess.

from ffms2.

I think this should fix it - if anyone of @vxzms @misakikasumi @AkarinVS can test it on problematic files.

diff --git a/src/core/videosource.cpp b/src/core/videosource.cpp
index 006099e..f838380 100644
--- a/src/core/videosource.cpp
+++ b/src/core/videosource.cpp
@@ -630,7 +630,7 @@ bool FFMS_VideoSource::DecodePacket(AVPacket *Packet) {
     // H.264 (PAFF) and HEVC can have one field per packet, and decoding delay needs
     // to be adjusted accordingly.
     if (CodecContext->codec_id == AV_CODEC_ID_H264 || CodecContext->codec_id == AV_CODEC_ID_HEVC) {
-        if (!PAFFAdjusted && DelayCounter > Delay && LastDecodedFrame->repeat_pict == 0 && Ret != 0) {
+        if (!PAFFAdjusted && DelayCounter > Delay && LastDecodedFrame->interlaced_frame == 1 && LastDecodedFrame->repeat_pict == 0 && Ret != 0) {
             int OldBFrameDelay = Delay - (CodecContext->thread_count - 1);
             Delay = 1 + OldBFrameDelay * 2 + (CodecContext->thread_count - 1);

Also, do you happen to have any files you know hit this bug that are less copyrighted? I want to add a unit test, but seek-test.mkv is copyrighted, obviously.

from ffms2.

Also, do you happen to have any files you know hit this bug that are less copyrighted? I want to add a unit test, but seek-test.mkv is copyrighted, obviously.

https://samples.mplayerhq.hu/MPEG-4/CDR-Dinner_LAN_800k.mp4 also can reproduce when use ffms3000.

After a reminder from TbtBI, I build ffms2 master that looks fine when use vcpkg’s ffmpeg before test your diff. I'm not sure ffmpeg that myrsloik and akarin used, you can wait for them test it if you have patience.

@dwbuiten

Sorry, it’s my mistake, I used the wrong repo to create the wrong binary.

FFSM2 mater branch can reproduce the error, I test your diff, it works fine on my test video.

But I get error when test https://samples.mplayerhq.hu/MPEG-4/MPEGSolution_stuart.mp4.

from ffms2.

After a reminder from TbtBI, I build ffms2 master that looks fine when use vcpkg’s ffmpeg before test your diff. I'm not sure ffmpeg that myrsloik and akarin used, you can wait for them test it if you have patience.

Gosh… Everyone builds his own ffmpeg… Totally messed up… 😿

from ffms2.

I also experienced this issue (and know many other people who did), especially with hevc videos encoded with open-gop=1. I tested at least 3 different videos that are showing this bug on the current master, and the proposed change fixed it for all of them.

Also, do you happen to have any files you know hit this bug that are less copyrighted? I want to add a unit test, but seek-test.mkv is copyrighted, obviously.

I made a test video out of Big Buck Bunny 3D, which is licensed under the Creative Commons Attribution License. The subtitle file has different lines synchronized with all the video cuts. In my case (using ffms2 from Aegisub - specifically this fork, with a custom ffms2 subproject), seeking to the end of Line 3 already shows the third frame of the following shot, instead of the last frame of the current shot. Many later lines behave similarly. The proposed patch fixes all of them.

So, is there a chance of getting this fix committed to master?

from ffms2.