Saving .jpeg with FFmpeg sometimes saves frame +1

[Spaarpott]

I have a lot of issues to go through, so in order to make it easier for me to help you, I ask that you please try these things first

• Try with the newest version from GitHub
• Read the documentation and FAQ, Known issues, Troubleshooting
• Search for your problem under Issues or Discussions
• If you have an issue only with one particular file, use this form instead

Operating System

Windows 10

Steps to reproduce

To reproduce:
Open a few files and go to a frame in which the next frame is totally different (scene change).
Save the frame before the scene change to .jpeg with FFmpeg setting, and compare.

Expected behavior

Should be:
Both settings, should save the frame which is showing on screen.

Actual behavior

I discovered a bug in the frame capture:
When you capture a frame to jpeg with the Snapshot capture method 'FFmpeg', in some files, it saves the next frame, instead of the one on screen in LosslessCut.
If you save the frame to jpeg with the Snapshot capture method "HTML Video Tag" in those files, it saves the correct frame, which shows on screen in LosslessCut.

It seems random in which file it happens.
AVC or HEVC files directly from my Camera and Phone, I found all have this problem.
I've tested some files from internet, AVC and HEVC files, .mp4 or .mkv extensions. 4K, 1280x960, 1280x720.
Some files have this problem, some don't.
I've did a test with a .mkv file in 1280x720 AVC which has the correct frame, but when I encoded this correct AVC file to a HEVC .mkv (with Handbrake v1.6.1 with RF26.5) it took the next frame. In this new handbrake file, to select the same frame on screen, it was already +1 in the HEVC file, compared to the AVC file. So when it saves, it saves +2 to the original file.

Share log

ffmpeg log.txt

Saving as HTML Video Tag, does not give a extra line in the Javascript Console.

[mifi]

I managed to reproduce this problem. For me it's not just +1 frame, but 4 frames off! With this file (from https://ffmpeg.org/pipermail/ffmpeg-user/2017-September/037074.html)

• Observe that the scene change happens at 3.167 according to losslesscut preview
• seek backwards to frames at 3.125, 3.083, 3.042, 3.000 and capture ffmpeg snapshot at each time
• observe that all of these snapshots are after the scene changes
• Only at 2.958 do we get a snapshot before the scene change

I also tested with IINA and in that app, the scene change happens at time 3.125 (one frame off from losslesscut).

So what we see is that this command captures a snapshot after the scene change, although it's 4 frames before the apparent scene change:

ffmpeg -ss 3.000 -i 'Tears_400_x265.mp4' -vframes 1 -y 'snap.jpeg'

Changing -ss before -i instead of after doesn't make any difference.

I'm thinking it could either be:

1. a bug in the chromium html5 video player (e.g. the preview is showing the wrong frame according to the time) - this is unlikely because IINA also reports approx the same time (off by just 1 frame)
2. a bug in the currentTime value that the html5 video reports to us (also unlikely because of IINA result)
3. a bug in ffmpeg when it comes to seeking to a frame / capturing a frame

TBH I'm a bit lost here, because I can't find much on google about frame-accurate seeking in ffmpeg.

[Spaarpott]

I have the same +4 frames with your file.
I suppose it's the 3rd option indeed, a bug within the -ss command.

I also have this when cutting a video with keyframe cut. Mostly with screengrabs from OBS-studio, encoded with NVENC.
If I cut on the keyframe or 1 frame further, it takes not this keyframe, but the keyframe 10 seconds before.
So when I choose the keyframe to cut, I set the Losslesscut cursor 4 or 5 frames further, to have the output start on the correct keyframe.

So maybe this problem is not only for the Jpeg, but also for the video copy export?

[mifi]

closing this in favor of #1216