VSE 2.0: Default media display #78987

New Issue

Sergey Sharybin · 2020-07-16T14:22:42+02:00

Sergey Sharybin commented

2020-07-16 14:22:42 +02:00

The current behavior of the media display in the VSE preview output follows image editors behavior, where final image has its own zoom level, position in the preview region.

For the video editing it is better to have default behavior when preview fits the entire area, always giving as many pixels of preview as possible.

The current behavior can still be used for verifying some details.

The current behavior of the media display in the VSE preview output follows image editors behavior, where final image has its own zoom level, position in the preview region. For the video editing it is better to have default behavior when preview fits the entire area, always giving as many pixels of preview as possible. The current behavior can still be used for verifying some details. ![vse_improvements_01.jpg](https://archive.blender.org/developer/F8699045/vse_improvements_01.jpg) ![vse_improvements_03.jpg](https://archive.blender.org/developer/F8699047/vse_improvements_03.jpg)

Sergey Sharybin commented

2020-07-16 14:22:42 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Sergey Sharybin commented

2020-07-16 14:22:42 +02:00

Added subscribers: @Sergey, @fsiddi, @iss, @dfelinto

tintwotin commented

2020-08-12 10:58:04 +02:00

Added subscriber: @tintwotin

tintwotin commented

2020-08-12 10:58:04 +02:00

Auto-fit: https://developer.blender.org/D7887
Gif:

Maybe the (ugly)striped line could be removed if the black bars mode is introduced?

Auto-fit: https://developer.blender.org/D7887 Gif: ![AUTO-FIT- [x].gif](https://archive.blender.org/developer/F8772526/AUTO-FIT_1_.gif) Maybe the (ugly)striped line could be removed if the black bars mode is introduced?

blender-admin commented

2020-08-12 11:05:40 +02:00

This issue was referenced by 6fe609d4c3

This issue was referenced by 6fe609d4c3d0e2f820af577dc9a2affc4cf4ef0a

Sergey Sharybin commented

2020-08-12 11:09:38 +02:00

Thanks for the patch, but it is implemented in a wrong and not acceptable way: you should not do layout specific operations from drawing code. There is a dedicated callback in the area to perform layout-specific tasks. Note the lag of like 1 frame of the picture when you resize the area, it should not be happening.

Here is a dump from my local branch with the implementation: P1580.
It contains bad-level-access to disable zoom-to-fit functionality when navigation operations are used in the preview area. This requires better solution, which ideally should not cause duplication of code with operations defined in the View2D code.

Thanks for the patch, but it is implemented in a wrong and not acceptable way: you should not do layout specific operations from drawing code. There is a dedicated callback in the area to perform layout-specific tasks. Note the lag of like 1 frame of the picture when you resize the area, it should not be happening. Here is a dump from my local branch with the implementation: [P1580](https://archive.blender.org/developer/P1580.txt). It contains bad-level-access to disable zoom-to-fit functionality when navigation operations are used in the preview area. This requires better solution, which ideally should not cause duplication of code with operations defined in the View2D code.

tintwotin commented

2020-08-12 11:14:40 +02:00

No worries. I'm not coding Blender-patches anymore. As this implementation is using code from the VSE backdrop, the problems you address, maybe also be visible there.

tintwotin commented

2020-08-12 14:01:10 +02:00

Maybe this is the wrong place to bring this up, but since it is also Preview related, I will. When moving the active strip or it's handels, it is industry standard to preview the frames affected by the operation in the preview(or else the users will simply not know at what frame they're cutting). Ex rolling a clip, the current frame from both sides should be visible during the operation(ex. from an old add-on attempt): {F8773081}(But the double preview should be within the normal preview, and not in a split preview area, so it would also work in backdrop etc.)

Roll: Show the inside and the outside frame(like the video above).
Dual Roll: Show 4 previews with first and last frames inside and outside of active strip.
Slide: Show the two frames from the lower strips surrounding the active strip.
Slip: Show the first and last frame inside the active strip.
@iss has a function for this in his Blade Tool, but it needs to be more generic to also fit the purposes above: https://developer.blender.org/D7379

Maybe this is the wrong place to bring this up, but since it is also Preview related, I will. When moving the active strip or it's handels, it is industry standard to preview the frames affected by the operation in the preview(or else the users will simply not know at what frame they're cutting). Ex rolling a clip, the current frame from both sides should be visible during the operation(ex. from an old add-on attempt): {[F8773081](https://archive.blender.org/developer/F8773081/44238239_1519972678105753_6709217105125834752_n.mp4)}(But the double preview should be within the normal preview, and not in a split preview area, so it would also work in backdrop etc.) Roll: Show the inside and the outside frame(like the video above). Dual Roll: Show 4 previews with first and last frames inside and outside of active strip. Slide: Show the two frames from the lower strips surrounding the active strip. Slip: Show the first and last frame inside the active strip. @iss has a function for this in his Blade Tool, but it needs to be more generic to also fit the purposes above: https://developer.blender.org/D7379

Sergey Sharybin commented

2020-08-13 15:32:16 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Sergey Sharybin closed this issue

2020-08-13 15:32:16 +02:00

Sergey Sharybin self-assigned this 2020-08-13 15:32:16 +02:00

Sergey Sharybin commented

2020-08-13 15:32:16 +02:00

@tintwotin, thanks for the feedback, but this is not how we handle feedback about related topics. Tasks are used to organize work, structure it in concrete steps. Having discussions of seemingly related topics just makes tasks unmanageable.

The feature has been implemented in 6fe609d4c3, so this task can be closed now.

@tintwotin, thanks for the feedback, but this is not how we handle feedback about related topics. Tasks are used to organize work, structure it in concrete steps. Having discussions of seemingly related topics just makes tasks unmanageable. The feature has been implemented in 6fe609d4c3, so this task can be closed now.

tintwotin commented

2020-08-13 16:06:32 +02:00

Super great that this feature already has been comitted. Thank you.

On my comment above, I know that posting that stuff on devtalk is advised, but I also know from experience that in reality it leads to nothing(same thing with RCS).

So with nowhere to share my findings through several of years working on/with the vse, that knowledge is pretty useless...

Super great that this feature already has been comitted. Thank you. On my comment above, I know that posting that stuff on devtalk is advised, but I also know from experience that in reality it leads to nothing(same thing with RCS). So with nowhere to share my findings through several of years working on/with the vse, that knowledge is pretty useless...

Richard Antalik referenced this issue

2023-12-11 20:13:34 +01:00

VSE 2.0: The Big Picture #78986

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

VSE 2.0: Default media display #78987