load video with LWLibavSource causes video clip repeat and freeze
#78
Comments
|
There's something unusual with this file, if you remux it by extract then mux, or using ffmpeg, the problem is gone. The file is not faulty I guess, since it plays with out issue, but something unusual makes it interfere with the seeking mechanism of lsmas. Linear decode seems fine. |
|
Thanks for the reply.
So you mean that different decoders have different seeking mechanisms? Can I ask the reason? For speed up? Because in my opinion, the seek operation should be a common function. |
|
When I test the sample you provided, the bug is not happening when doing linear decoding, but only happens when seeking to frame 48. There's some difference in seeking between this and akarin fork which may be why it's not happening in akarin's fork. |
|
I've tested the full movie in these cases, and all of them work fine, no bug happens:
I'm not sure whether these infos can help. If you need other test result, please let me know, I am willing to test and provide it. Or if you need the full video, also let me know, but I don't know how to share it with you :<. |
The issue is that somehow newer mkvmerge generates way less cue points than ffmpeg and older versions of mkvmerge. This makes av_seek_frame much less reliable. For the specific test case mentioned in #14, rap for frame 32 is frame 24, however, the best av_seek_frame can do is just seek to the very beginning of the video track. lsmas does not depend on fully reliable av_seek_frame, however, in this particular cases, because the mkv is using PTS as seeking method, lsmas will not attempt to call correct_current_frame_number to correct for the mis-seek, which means it will assume the current position (frame 0) as actually the rap (frame 24), then it follows that it will return frame 8 as frame 32. To fix this, we must call correct_current_frame_number even for SEEK_PTS_BASED formats. This fixes much of the issues, except for the first few frames. Then there is another issue lurking in correct_current_frame_number: when it finds that the current packet has a dts of AV_NOPTS_VALUE, it will always abort. Unfortunately, as frame 0 typically has such a dts, it will not correct the current frame number when the actual current is frame 0. We fix this by disregarding pkt->dts == AV_NOPTS_VALUE when the seek mode is not just SEEK_DTS_BASED (note that mkv has a seek mode of SEEK_DTS_BASED | SEEK_POS_CORRECTION, which means that we can reliably use the pkt->pos field to determine the current frame.) Fixes AkarinVS/L-SMASH-Works#14. Signed-off-by: akarin <[email protected]> (cherry picked from commit AkarinVS/L-SMASH-Works@95de1ab) Related #78.
It turns out not only the first frame could have invalid DTS, there are mkv files in the wild that contains first few frames with an invalid DTS. It's beyond me how mkvmerge could have created such a file given that mkv are supposed to be seeking by DTS. Next time, if you face such a mkv, you can: 1. mkvextract the video and then remux with mkvmerge to force it to recreate cue points for all IDR.. 2. add `--cue 0:all` to mkvmerge and remux the broken mkv to fix it. Fixes AkarinVS/L-SMASH-Works#14. Signed-off-by: akarin <[email protected]> (cherry picked from commit AkarinVS/L-SMASH-Works@d73d2dc) Related #78.
|
Try the attached version. |
|
Thanks for your work, @Asd-g . But I work on linux system, so can you provide the |
|
Build with the latest changes but use this FFMpeg version. |
Hi, recently I use this lib to do some encode work. It works well. But fails on a specific video. I load the video with the following code:
After running
vspreview test.pyand playing back the video in vspreview, I noticed that the video freezes and repeats. Here’s a screen recording of the issue._20241201_113350.webm
When I play the video in MPV, the problem doesn’t occur. And I play the video with mpv, the problem not happen. I also tried using
ffms2andAkarinVS/L-SMASH-Works, both works fine.Here is the sample of this video: https://files.catbox.moe/trc2xg.mkv
Here is the reproduce code:
Jump to frame 48, lsmash/ffms2 have different output.
Here is the mediainfo of this video:
The text was updated successfully, but these errors were encountered: