Bug 410486 - extract frame extracts wrong frame
Summary: extract frame extracts wrong frame
Status: RESOLVED WORKSFORME
Alias: None
Product: kdenlive
Classification: Applications
Component: Rendering & Export (other bugs)
Version First Reported In: 19.04.3
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-01 15:37 UTC by tdo
Modified: 2021-04-06 04:33 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:
fritzibaby: Brainstorm+


Attachments
shellscript re-extracting frames from original source video files based on frame image file names (6.27 KB, application/x-shellscript)
2019-08-01 15:37 UTC, tdo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tdo 2019-08-01 15:37:18 UTC
Created attachment 121887 [details]
shellscript re-extracting frames from original source video files based on frame image file names

SUMMARY

"Extract frame" and "Extract frame to project" functionality on a clip exports wrong frame ... probably the previous I frame or some other frame.


STEPS TO REPRODUCE
1. use any mp4/H.264 video clip
2. select some frame within
3. export frame to project
4. cross-check exported frame with currently selected frame


OBSERVED RESULT

Different frame (earlier I-frame) got exported than selected in the clip.


EXPECTED RESULT

Correct frame which is selected gets exported.


VERSIONS

kdenlive-19.04.3-x86_64.appimage
OS ffmpeg 4.1.3-0ubuntu1


ADDITIONAL INFORMATION

When running ffmpeg manually for extracting frames, it will extract the *correct* frame based on the framenumber as specified in the exported frame's image file name. This leads to the assumption that this is in fact a problem with the current Kdenlive version(s), directly or indirectly, as older versions, especially the stable pre-refactor branch work correctly. Kdenlive appimage uses the appimage-internal ffmpeg as far as I can see from the config environment dialog.

For reference, I've attached a shell script that automatically re-extracts the frames from the original video source files based on the frame image filenames and the project framerate deduced from the specified kdenlive project file. This shows that the problem is inside Kdenlive (or MLT?), but not with ffmpeg (unless we suspect my ffmpeg version 4.1.3-0ubuntu1 to be much different from the appimage's ffmpeg).
Comment 1 Jean-Baptiste Mardelle 2019-08-02 05:45:18 UTC
Should be fixed in 19.08. You can test the beta AppImage:
https://files.kde.org/kdenlive/unstable/kdenlive-19.07.90-beta-x86_64.appimage.mirrorlist
Comment 2 tdo 2019-08-02 15:29:56 UTC
Better, but not yet completely correct: it is off by one frame, at least with the 29.97fps source clip I'm currently working with. The updated appimage captures one frame *too early*, at least for the frame I randomly tested.

Maybe this could be some rounding issue that's different between what the clip playback monitor does and the updated frame extraction calculation?

For reference: when running my script on the frame I randomly tested, it extracts the same frame as shown in the clip monitor.

Tested with today's 19.07.90-beta-x86_64.appimage.
Comment 3 farid 2021-03-07 20:14:03 UTC
Do you still experience this with latest appimage, can you please test and let us know?
Comment 4 Bug Janitor Service 2021-03-22 04:33:36 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Bug Janitor Service 2021-04-06 04:33:31 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!