https://bugs.kde.org/show_bug.cgi?id=526525
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |CONFIRMED CC| |[email protected] Ever confirmed|0 |1 --- Comment #2 from [email protected] --- Confirmed the crash. Beyond the mistake that causes this specific crash, I think it warrants a bit of a reflection on proxies for subclips. Currently we don't really have support for proxying only a subclip, we'd proxy the whole thing and take a view on that proxy for the subclip. While this approach simple, it probably doesn't meet users' needs: I assume the reason why someone would want to proxy a subclip is for efficiency reasons (imagine a super long master clip and you only need a small portion) However, supporting proxy for subclips would be non trivial. Consider the following: you cut the clip, add it to the bin, proxy it (assuming we proxy only the subclip), insert the subclip back to the timeline, and then re-extend it to its original length. That would be problematic because we now don't have proxy frames for what's out of the subclips original boundaries. I see a few ways forward: 1. Keep the current behavior (while fixing the crash of course): as I said, simple but not optimally efficient. 2. Allow proxy on subclips, but disallow resizing them past the boundaries of the subclip. That avoids the trap above but changes behavior 3. [NOT RECOMMENDED] Allow proxy on subclips and do some complicated stitching on the backend to recover non-proxy source clips when resized past the subclip boundaries. I think this is both very bug-prone and also not user-friendly - it'd be hard to understand why some frames are served fast while others aren't, in the same clip. I think we should do #1 right away to fix the crash. Whether we go for #2 (or #3... ) afterwards is a bigger decision, curious to here jb's opinion on this. -- You are receiving this mail because: You are watching all bug changes.
