Openshot-qt: Attempting to extend a video's duration (a strange behavior) produces strange behavior.

[Just-Curious]

System Details:

• Operating System / Distro: ? Windows 10 Pro, Version 1709, Build 16299.309
• OpenShot Version: ? 2.4.1

Originally added to topic https://github.com/OpenShot/openshot-qt/issues/894#issuecomment-377658191. That topic has been closed.

If the right hand edge of a timeline video is dragged to the right (impossible), the display length shrinks. Doing this repeatedly leaves a "blank" area on the timeline that, in fact, contains the "missing" video. Dragging a video to the timeline and allowing it to "snap in", will result in it snapping to the correct ending of the original video. Adjusting the time scale corrects the display.

https://youtu.be/JcSmhuKoaCA

[peanutbutterandcrackers]

Awesome! Thank you for this well-documented report, good sir!

@ferdnyc - I am pretty sure you'll be able to fix this in an afternoon, good sir! :)

[Just-Curious]

@peanutbutterandcrackers
Here's a well-documented report that you may also be able to have someone fix some afternoon:
https://github.com/OpenShot/openshot-qt/issues/362

[peanutbutterandcrackers]

Well, lets hope @ferdnyc will have some free time soon. OpenShot is a community effort. We are all squireling time away to help out with what we can. And @ferdnyc is a brilliant programmer who has made quite a lot of Pull Requests fixing and enhancing OpenShot in the last couple of months. But it seems that he's been busy of late. Perhaps we'll soon see the return of the super-contributor. :)

[ferdnyc]

Yeah, I had noticed this one a while ago, but then lost track of it. Thanks for filing the report, it's good to have it in the system.

As you discovered, it's purely a timeline-rendering issue — the clip still has the same duration, and in reality is still the same length on the timeline, it's just being drawn slightly too short. Dragging the clip to another track, or another position on the same track, will cause it to be drawn at the proper length, as will changing the zoom level. Anything that refreshes the timeline rendering, basically. And all interactions (snapping, slicing, etc.) will continue to function properly over the full length, even the hidden portion.

Because it's purely a visual thing (the issue doesn't affect the software's function in any way, only the UI, and can easily be worked around) it's not the highest-priority issue. But I'll try and take a look, it _might_ be simple to fix and it would be nice to whack it.

That #362 issue I haven't looked into, but based on the description I suspect that one's _not_ as simple a fix; the clarity or completeness of a report isn't a reliable indicator of the underlying problem's complexity.

And @ferdnyc is a brilliant programmer

I'm really not, there's no need for unnecessary buildup. (Even if I was, nobody on this project could say with any authority — I think I've submitted maybe 15 lines of code changes, so far? Everything else has been documentation.) I'm well aware of my limitations. The reason I'd never even consider tackling that whole exploded-frames timeline thing is that I know _just_ enough to understand how critical an efficient implementation would be, in order for the performance to be acceptable... and I also know that's it's well beyond my abilities.

But it seems that he's been busy of late.

Actually I've still been spending a fair amount of time on OpenShot. It's just that it's all been spent working through this backlog of bug reports sitting in my inbox. "Hey, could you take a look at this?" only takes a few seconds to write,. But actually doing so can take up a half hour or more of my time, attempting to reproduce, investigating, and responding to the report. (Not this one, this one was immediately clear, and like I said I'd already encountered it.)

[ferdnyc]

I'm so _close_ to this one I can almost taste it, but the logic for handling resize events is just so _weird_. I know where it must be going wrong, but I can't quite puzzle out _why_ it's wrong or (more to the point) what the "right" version would even look like. :tired_face:

[peanutbutterandcrackers]

...still a brilliant programmer by my standards. :D

[DylanC]

Just a note for myself - Happens with video/audio clips and not images.

[ferdnyc]

Just a note for myself - Happens with video/audio clips and not images.

Ooh, you've spotted something interesting, actually. There's something very similar that _does_ happen with Images (and Titles), during a resize event — but because they don't have a "maximum" size, they can't be affected by that aspect of this bug. This just got even more interesting.

All types of clips show a recalculation of length _following_ a resize, though. (Unrelated: I just noticed the snapline isn't active during a resize, for some reason. *sigh* Always another thing...) If you grab the right edge of an Image or Title Clip, drag it around a bit, and then let go, what you'll see is that every time you release at the end of the drag, the Clip will grow by a small amount. (I'm guessing that small amount is one frame. It's snapping to the next — not _nearest_, but ALWAYS next — frame boundary.) The same thing also happens on A/V clips, as they _also_ correct their length at the end of a resize... unless the release occurs while the Clip is at the limit of its allowed length, in which case the post-release correction DOESN'T occur!

So, I think the _actual_ source of this bug isn't in the code that computes max Clip length (which is where I went looking for it), but rather the code that handles resize processing and auto-adjusts to frame boundaries at the end of a resize, which (for whatever reason) is balking one frame before the place where the length _should_ be capped, when there is a cap in play.

[DylanC]

So, I think the actual source of this bug isn't in the code that computes max Clip length (which is where I went looking for it), but rather the code that handles resize processing and auto-adjusts to frame boundaries at the end of a resize, which (for whatever reason) is balking one frame before the place where the length should be capped, when there is a cap in play.

Yep, I think this one is going to be horrible after reading this.. but hopefully not. I do know it won't be as easy to fix as the previous bug I solved.

I have the correct section of code but I'm just playing around with different solutions for now...

[DylanC]

@ferdnyc - I fixed this issue now. (or at least I think I did) Maybe have a look at my PR and try the fix on your own codebase? Works for clips like video/audio and images can still expand nicely.

[ferdnyc]

Yep, I think this one is going to be horrible after reading this..

Every one of these is you saying, "I think this is going to be awful... never mind, fixed." (In this case, 54 minutes later.) You're not Scottying these, by any chance, are you? :rofl:

Anyway, sorry — been distracted all morning with the sound of my own bloviating, once again. I'll take a poke at #1914 ASAP, which is some time today.

[DylanC]

@Just-Curious - A fix has been pushed in for this but it may not be perfect yet. (still very much improved)