BUG? Playhead don't stop at the end of the last frame

Help
1

Hello everybody, I noticed an unexpected behavior with the position of the playhead on the timeline.

How to reproduce the observed behavior
Put almost a clip in the timeline. Then move the playhead to the beginning of the clip or of the whole sequence. Press to start playing, and wait until the playhead reaches the end of the sequence.

Observed result
The playhead stops at the end of the sequence, but at the beginning of the last frame.

Expected result
The playhead should stop at the end of the last frame of the last clip in the sequence.

Correlated problem: Inconsistency when appending clips.
Let the playhead reach the end of the sequence so it stops (at the beginning of the last frame). Now open a clip in the Clip monitor, select an In and Out point. Click the Insert clip command or press V. The clip is inserted in the timeline where the playhead was positioned, and the last frame is moved to the end of the sequence.
While this is correct (the program inserts the clip), it creates an inconsistent and unexpected shift of the last frame because what was expected was that the playhead stops at the end of the last frame.

Furthermore,
if, after the playhead stopped at the end of the sequence, the playhead is forcefully moved past the last frame by pressing one single time the right arrow key (on the keyboard, the Project monitor shows a black screen since there are no more frames to show), and V is pressed to insert a clip, the playhead remains at the end of the last frame.
This remains consistent even when multiple clips are appended in the timeline pressing V (insert, not overwrite) multiple times.
Which is the expected behavior: inserting a clip when no other frames follow, it is equivalent to appending the clip to the sequence.

My expectation was that when the playhead reaches the end of the sequence it should move past the last frame, and the Project monitor should display a black screen (in DaVinci Resolve they show a symbol, like a ripped film).

Am I doing something wrong or missed something?
Thank you.

2

Sorry I forgot to provide information about the version and system:

Kdenlive: 25.04.2
MLT: 7.33.0
FFmpeg
KDE Frameworks: 6.14.0
Qt: Using 6.8.3 and built against 6.8.3
Windows 10 Version 22H2
Build ABI: x86_64-little_endian-llp64
Kernel: winnt 10.0.19045

3

It doesn’t stop at the “beginning of the last frame”, it stops after playing the last frame, because there is nothing else to play after that.

By convention, we show the playhead on the left side of the currently rendered frame.

it creates an inconsistent and unexpected shift of the last frame because what was expected was that the playhead stops at the end of the last frame

You’re confusing “where you want it to be when editing” with “where it is during playback”.

See the discussion here: Function "Go to end of a clip" doesn't work properly. - #2 by Ron for the difference between “clip end” and “project end”.

4

First off thanks for replying. From your answer and what I read from the other thread you linked (Function “Go to end of a clip” doesn’t work properly - thank you for that, I missed it) it is clear I was doing anything wrong.
And I think this is not as it should be. I really like this product and I’d like to possibly provide some constructive contribution with this discussion.

It doesn’t stop at the “beginning of the last frame”, it stops after playing the last frame, because there is nothing else to play after that.

By convention, we show the playhead on the left side of the currently rendered frame.

So what happens when you play a clip made of 1 frame? I tested it: the playhead doesn’t move. Which is not that much intuitive: it seems the video has not been played at all. In fact it wasn’t: the frame counter indicates zero, not one.
And if you press CTRL+V to insert another clip, that “last” single frame is pushed toward the right side.
It’s logic: the counter is at zero, so it inserts it from zero.

You’re confusing “where you want it to be when editing” with “where it is during playback”.

I’m not sure if there is some kind of misunderstanding here but, well, where it is during playback is exactly where one expects to operate his editing.
In fact when a clip is inserted pressing CTRL+V the clip is inserted where it is during playback (see test above with 1 frame clip).
So “where it is when editing” and “where it is during playback” (rightfully) match.

IMHO dzidel has rightfully found himself at odds with this behavior.

While it could be an option that a command was designed to bring you at the last frame of a clip, calling it “end of the clip” is not so intuitive.
Making a parallel with a tape recording machine or a film projector, a mechanical fact happens: if you fast forward to the end of the tape/film, you reach the actual end of that tape/film, not the last frame.
However this is a different problem, not super intuitive but there are other commands (CTRL+End/Home and ALT+Right_arrow/Left_arrow) to reach the desired outcome.

What I’m pointing out is a problem related to playback.

5

A clip made of 1 frame is a still image. It makes perfect sense that the playhead doesn’t move. If it moved, you wouldn’t be “playing” that image, you’d have fallen into the void.

if you fast forward to the end of the tape/film, you reach the actual end of that tape/film

And that’s what happens if you play or navigate to the end of a clip, it stops at the actual end of the clip. Not somewhere in the void after the clip. If it didn’t stop at the actual end of the clip then the “playback time” would be one frame longer than the actual clip/sequence.

If that’s not intuitive to you, then, well, sorry - fix your intuition. That’s how learning works.

If you want to insert a clip in the void after where playback ends, then move your insert point there. That these are two different things isn’t a complicated concept.

6

A clip made of 1 frame is a still image. It makes perfect sense that the playhead doesn’t move.

A still image is a frame anyway and must be played. Full stop. This is how work ALL other competing products. And this is how logically should work.

If it moved, you wouldn’t be “playing” that image, you’d have fallen into the void.

No, once the image has been played THEN it fall into the void. Which is logically correct.

Let’s make the tape/film parallel simpler getting rid of the “fast forward” that clearly induced some confusion. If you play a film till the end it falls into the void. Because there is no more footage to play. That is what should be expected and correct behavior.

Again, why the counter remains at zero?
With Premiere Pro, Final Cut, Resolve, and other editing software I used/tested the playhead moves and the counter goes to 1 (in the case of 1 frame video or one-frame still image).

It is not my intuition, it seems almost another one had the same intuition, and I’m pretty sure a lot of people have the same “intuition” because it follows a logic path.
If I ask you to count a deck of 10 cards do you end responding 9 or 10?
Zero cards, no cards, no frames.
One card, one frame.
You played any: zero. You played the only one: one.

7

Really? You’re going to make me explain fencepost errors to you?

There are 10 cards, the first is card 0, and the last is card 9. If you want to play “card 10” you need 11 cards. Once you play card 9 the game has ended.

If you don’t understand that, then of course you’re confused. But you being confused doesn’t make it wrong.

8

LOL People don’t count from zero. People think zero is null, nothing. People count starting from one. And this is what they expect to see when they counted the deck of cards or the number of frames in a film.

But there’s more. You are actually falling into a mistake. Look at this:

for(i = 0; i < 10; i++) { playedframes(i); playframe(i); }

When i == 0 no frames has been played and i points to the first frame to play. When i == 9 it points to the last frame which has not been played yet.
The cycle is complete only when the last frame has been played.

So, how many played frames the function playedframes displays after this cycle?

Answer is 9. While at the beginning it indicated 0 (no played frames). So the function misses ONE frame, because the total number of frames is 10, not 9.

Therefore the correct procedure would be this:

for(i = 0; i < 10; i++) { playedframes(i); playframe(i); } playedframes(i);

Note that this pseudo-code is for illustrative purpose only, If I were to write the code for this I would do it differently, something like:

z = sizeOf(frames); // get array size
playedframes(i = 0); // reset playhead and counter
for(;i < z; i++) {
playframe(frames(i)); // play frame
playedframes(i+1); // update playhead position and frame count
}

where playedframes not only displays the played frames, but also positions the playhead ready to the next frame. And to do this I add 1 exactly to avoid to fall into the fencepost error.
That also means it falls into the void when the last frame has played, which is logically correct since no more frames are available to play.

So yeah, it seems you fell into the classic fencepost error.

I want to add that when I first published this post I didn’t thought it would ended up this way. I was moved by the genuine intention of either understanding what I was doing wrong with the software or, if I was correct, giving a small contribution to help improve the project.
What I got in return was a disrespectful guy who has rant incontinence.
Dude, relax and drink less coffee. I’m still eager to be friendly and helpful.