Blender VSE Glitsches when Seeking/Scrubbing clips with split cuts #100672

New Issue

Michael · 2022-08-28T12:09:32+02:00

Michael commented

2022-08-28 12:09:32 +02:00

System Information
Operating system: Ubuntu 20.04
Graphics card: nvidia rtx 3070

Blender Version
Broken: Blender 3.2.2 and blender-3.4.0-alpha+master.2a2ca3292a93-linux.x86_64-release
Worked: i don't know

Short description of error
Doing lots of seeking/scrubbing and performing split cuts makes the preview glitsch (frames jumping, being displaced or frozen)
I filed another bugreport (#100495) reporting the same issue. This bug turned out to be due to a broken video file. However I sill experience some glitsches in the preview when scrubbing/seeking through other files, doing split cuts to it and then previewing it. When using current alpha glitsches often go away when refreshing the vse. However I still feel this is a bug since a glitsch in the preview can lead to editing mistakes and refreshing before/after each edit would be very tedious.

Exact steps for others to reproduce the error

Based on the default startup or an attached .blend file (as simple as possible).

Open new blendfile and load factory settings
Import SmartphoneRobot_Final.
(do not generate proxies)
Delete audio
extend preview range to include the whole clip
move towards the end of the file and do lots of scrubbing (with mouse and cursor keys)
do some (many) split cuts
repeat those two steps a view times
preview everything, you will see glitsches / frames jumping etc.

What i usually do is, try to split at the exact frame where there is a new szene in die clip. sometimes I find the cuts to be a few frames off when examining it later (this is probably not important to reproduce it but makes the problem obvious)
Problems are more obvious with SmartphoneRobot_FiNAL but I included another file that is not perfect. Both videos where rendered using blender vse with power seqeuncer render preset.
Attached blend files where created in current alpha. Attached video files where rendered using blenders current version back in april 2020 / february 2021.
Since my last bug report was due to a "broken" file I looked into my old work files and I have no reason to believe these two sample files where also re-encoded at some point. But please investigate this.
Alpha_SmartphoneRobotTest.blend

VPS_DIYTouchCube_Tutorial.mp4

SmartphoneRobot_FINAL.mp4

Alpha_RGBTouchCubeTest.blend

**System Information** Operating system: Ubuntu 20.04 Graphics card: nvidia rtx 3070 **Blender Version** Broken: Blender 3.2.2 and blender-3.4.0-alpha+master.2a2ca3292a93-linux.x86_64-release Worked: i don't know **Short description of error** Doing lots of seeking/scrubbing and performing split cuts makes the preview glitsch (frames jumping, being displaced or frozen) I filed another bugreport (#100495) reporting the same issue. This bug turned out to be due to a broken video file. However I sill experience some glitsches in the preview when scrubbing/seeking through other files, doing split cuts to it and then previewing it. When using current alpha glitsches often go away when refreshing the vse. However I still feel this is a bug since a glitsch in the preview can lead to editing mistakes and refreshing before/after each edit would be very tedious. **Exact steps for others to reproduce the error** Based on the default startup or an attached .blend file (as simple as possible). Open new blendfile and load factory settings Import SmartphoneRobot_Final. (do not generate proxies) Delete audio extend preview range to include the whole clip move towards the end of the file and do lots of scrubbing (with mouse and cursor keys) do some (many) split cuts repeat those two steps a view times preview everything, you will see glitsches / frames jumping etc. What i usually do is, try to split at the exact frame where there is a new szene in die clip. sometimes I find the cuts to be a few frames off when examining it later (this is probably not important to reproduce it but makes the problem obvious) Problems are more obvious with SmartphoneRobot_FiNAL but I included another file that is not perfect. Both videos where rendered using blender vse with power seqeuncer render preset. Attached blend files where created in current alpha. Attached video files where rendered using blenders current version back in april 2020 / february 2021. Since my last bug report was due to a "broken" file I looked into my old work files and I have no reason to believe these two sample files where also re-encoded at some point. But please investigate this. [Alpha_SmartphoneRobotTest.blend](https://archive.blender.org/developer/F13425122/Alpha_SmartphoneRobotTest.blend) [VPS_DIYTouchCube_Tutorial.mp4](https://archive.blender.org/developer/F13425120/VPS_DIYTouchCube_Tutorial.mp4) [SmartphoneRobot_FINAL.mp4](https://archive.blender.org/developer/F13425121/SmartphoneRobot_FINAL.mp4) [Alpha_RGBTouchCubeTest.blend](https://archive.blender.org/developer/F13425124/Alpha_RGBTouchCubeTest.blend)

Michael commented

2022-08-28 12:09:32 +02:00

Added subscriber: @Michael-47

Michael commented

2022-08-28 12:13:12 +02:00

Added subscriber: @iss

Richard Antalik commented

2022-08-29 22:31:48 +02:00

Thanks for files.
As far as I can see, this is same issue as #95683.

The issue is, that ffmpeg does only allow to seek based on time, but internally it does not, which can result in incorrect frame being displayed. Also due to nature how video encoding works, seeking backwards frame by frame is not possible.

Before 2.93 version, there was quite big offset applied to seeking, which is why playback was quite slow.

From what I have read there is no way to correct for undesirable ffmpeg behavior. But I have done few tests applying small seek offset does not seem to affect performance too much, even in worst case scenario. I will do some measurements to quantify possible regression. I think it is better to lose few percent of FPS to prevent such inaccuracies as they are not so rare. Challenge may be finding how big this offset must be, so that users would not encounter this issue.

For now will merge to original report

Thanks for files. As far as I can see, this is same issue as #95683. The issue is, that ffmpeg does only allow to seek based on time, but internally it does not, which can result in incorrect frame being displayed. Also due to nature how video encoding works, seeking backwards frame by frame is not possible. Before 2.93 version, there was quite big offset applied to seeking, which is why playback was quite slow. From what I have read there is no way to correct for undesirable ffmpeg behavior. But I have done few tests applying small seek offset does not seem to affect performance too much, even in worst case scenario. I will do some measurements to quantify possible regression. I think it is better to lose few percent of FPS to prevent such inaccuracies as they are not so rare. Challenge may be finding how big this offset must be, so that users would not encounter this issue. For now will merge to original report

Richard Antalik commented

2022-08-29 22:31:56 +02:00

Closed as duplicate of #95683

Richard Antalik closed this issue

2022-08-29 22:31:56 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender VSE Glitsches when Seeking/Scrubbing clips with split cuts #100672