Maybe a seeking error after 2.40
vxzms opened this issue · comments
@misakikasumi get a seeking error when using ffms2_api4, I also reproduced this problem in 2.40
, 2.23.1
looks fine.
When seeking a video, there is a high probability that the wrong frame will be returned in test.
The test environment is Windows + Vapoursynth / Aegisub + ffms2 / lsmashsource. Here is the test (sample video link):
- Dump video to y4m by
vspipe dump_y4m.vpy seek-test.y4m
dump_y4m.vpy:core.ffms2.Source("seek-test.mkv").set_output()
- Make a comparison of these outputs at same frame:
a.core.ffms2.Source("seek-test.mkv")
b.core.lsmas.LWLibavSource("seek-test.mkv")
c.core.ffms2.Source("seek-test.y4m")
d.core.lsmas.LWLibavSource("seek-test.y4m")
e. Aegisub openseek-test.mkv
use the same ffms2 version as VS
In the test, a and e results are always the same.
outputs of b, c and d are always the same.
a and c are likely to be different.
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?
Also can you test with master, particularily after: 5da8f49
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.
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 🙂 .
I definitely suspect an FFmpeg behavior change, then.
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.
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.
@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
@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
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.
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.
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.
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.
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… 😿
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?
OK, I'll look into doing that this week.