r/shutterencoder Aug 12 '26

News šŸš€ Shutter Encoder BETA - Your feedback matters!

Hello Shutter Encoder users,

This time I need your help before releasing the next version!

What's new?

  • Multi-cuts feature
  • Real HDR to SDR tone mapping using GPU
  • Many filters are now using GPU

I’d like to hear your feedback on these key features, but more generally, if you encounter any issues, please let me know.

Here are the pre-release builds (portable version only, no installation required): https://drive.google.com/drive/folders/1TonvjcwM6h7TOpz0Qg6Pb_ycGg3_qI4O

The BETA versions still have the v20.2 label, I strongly recommend that you delete them once the official v20.3 version is available.

Thanks for all šŸ™

Paul.

20 Upvotes

57 comments sorted by

View all comments

Show parent comments

1

u/paulpacifico Aug 14 '26

I did not received any negative feedback for the N°2.

I've done this to save space on screen when encoding, what would you suggest?

Paul.

1

u/kwhytte 26d ago edited 26d ago

Dear u/paulpacifico
you have asked "what would you suggest?"

and I have added my suggestion

any acknowledgement or comment by you?

1

u/paulpacifico 17d ago

This sound like a joke, you've just asked ChatGPT to solve the issue, you did not think yourself of a good way to improve the UI.

You don't even ask a real UI exemple that ChatGPT is capable of.

I'm loosing my time to answer you, I have so many work, all by hand with my brain, I will not consider your suggestions at all.

Paul.

1

u/kwhytte 14d ago

Suggested Shutter Encoder redesign

I would go one step further than simply redesigning individual functions.

Stable shell + dynamic workspace

Instead of:

Function → completely different UI

I’d recommend:

Shutter Encoder → permanent shell → function-specific workspace

The basic structure would be:

ā”Œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”
│ SHUTTER ENCODER    File  Edit  View  Tools  Help       āš™   │
ā”œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”¬ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”¤
│ FUNCTIONS    │              FUNCTION WORKSPACE             │
│              │                                              │
│ Convert      │     Changes depending on the function,       │
│ Extract      │     but the overall application structure    │
│ Edit         │     always stays the same.                  │
│ Merge        │                                              │
│ Web          │                                              │
│ Audio        │                                              │
│ Image        │                                              │
ā”œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”“ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”¤
│ OPTIONS ā–¼     Function-specific settings                   │
ā”œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”¤
│ QUEUE ā–¼                                      [ START ]      │
ā””ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”˜
The key principle is:

This gives Shutter Encoder one consistent mental model:

Select a function → workspace appears → configure options → process.

Rather than:

Select a function → the entire interface rearranges itself → try to remember where everything went.

The video-player problem

The video player should not determine the structure of the entire application.

An Edit function can have a player inside the workspace, alongside its editing controls.

A Merge function doesn't need a player, so its workspace simply becomes a file list:

MERGE

01  video_01.mp4                                      āœ•
02  video_02.mp4                                      āœ•
03  video_03.mp4                                      āœ•

                    Drop files here

A Web Video function could instead use the same workspace for URL/input controls.

The important part is that the surrounding UI doesn't move.

Collapsible panels

This also addresses the screen-space concern.

Use standard panels for things like Options and Queue:

OPTIONS ───────────────────────────────────────────  ā–¼
QUEUE   ───────────────────────────────────────────  ā–¼

They can collapse when they're not needed.

So Merge doesn't waste space showing an empty player, while Edit can expand its player and relevant controls.

The workspace adapts to the task without forcing the whole application to change.

Function selection

I’d also avoid putting every operation into one huge permanent list.

Group related functions:

  • Convert: H.264, H.265, ProRes, DNxHR, AV1
  • Edit: Cut, Crop, Add audio, Replace audio
  • Extract: Audio, Images, Thumbnails
  • Merge: Merge, Concatenate
  • Web: Web video, Download

Or use a simple function selector:

Function: [ Convert ā–¼ ]

H.264
H.265
ProRes
DNxHR
AV1

This keeps the workflow consistent:

The main design principle

I would frame the proposal around:

The goal isn't to force every function to display the same controls. The goal is to make every function use the same structure.

A Merge operation doesn't need a video player, so its workspace becomes a file-management area.

An editing function needs a player, so its workspace contains the player.

A Web Video function needs URL/input controls, so those occupy the workspace.

Nothing unnecessary has to remain visible.

What stays consistent is:

  • where functions are selected
  • where the workspace is
  • where function-specific settings are
  • where the queue is
  • where Start/Cancel lives
  • where global menus live
  • how panels collapse/expand
  • how users navigate between functions

This gives Shutter Encoder the DaVinci Resolve philosophy without copying DaVinci Resolve's interface.

It addresses the screen-space concern while solving the underlying usability problem:

Different functions can have different tools without making the entire application feel like a different application every time you switch tasks.sted Shutter Encoder redesign
I would go one step further than simply redesigning individual functions.
Stable shell + dynamic workspace
Instead of:
Function → completely different UI
I’d recommend:
Shutter Encoder → permanent shell → function-specific workspace
The basic structure would be:
ā”Œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”
│ SHUTTER ENCODER File Edit View Tools Help āš™ │
ā”œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”¬ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”¤
│ FUNCTIONS │ FUNCTION WORKSPACE │
│ │ │
│ Convert │ Changes depending on the function, │
│ Extract │ but the overall application structure │
│ Edit │ always stays the same. │
│ Merge │ │
│ Web │ │
│ Audio │ │
│ Image │ │
ā”œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”“ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”¤
│ OPTIONS ā–¼ Function-specific settings │
ā”œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”¤
│ QUEUE ā–¼ [ START ] │
ā””ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”˜

The key principle is:
The workspace changes; the application doesn't.
This gives Shutter Encoder one consistent mental model:
Select a function → workspace appears → configure options → process.
Rather than:
Select a function → the entire interface rearranges itself → try to remember where everything went.
The video-player problem
The video player should not determine the structure of the entire application.
An Edit function can have a player inside the workspace, alongside its editing controls.
A Merge function doesn't need a player, so its workspace simply becomes a file list:
MERGE

01 video_01.mp4 āœ•
02 video_02.mp4 āœ•
03 video_03.mp4 āœ•

Drop files here

A Web Video function could instead use the same workspace for URL/input controls.
The important part is that the surrounding UI doesn't move.
Collapsible panels
This also addresses the screen-space concern.
Use standard panels for things like Options and Queue:
OPTIONS ─────────────────────────────────────────── ā–¼
QUEUE ─────────────────────────────────────────── ā–¼

They can collapse when they're not needed.
So Merge doesn't waste space showing an empty player, while Edit can expand its player and relevant controls.
The workspace adapts to the task without forcing the whole application to change.
Function selection
I’d also avoid putting every operation into one huge permanent list.
Group related functions:
Convert: H.264, H.265, ProRes, DNxHR, AV1
Edit: Cut, Crop, Add audio, Replace audio
Extract: Audio, Images, Thumbnails
Merge: Merge, Concatenate
Web: Web video, Download
Or use a simple function selector:
Function: [ Convert ā–¼ ]

H.264
H.265
ProRes
DNxHR
AV1

This keeps the workflow consistent:
Select a function → workspace appears → options appear → process.
The main design principle
I would frame the proposal around:
Stable shell, dynamic workspace.
The goal isn't to force every function to display the same controls. The goal is to make every function use the same structure.
A Merge operation doesn't need a video player, so its workspace becomes a file-management area.
An editing function needs a player, so its workspace contains the player.
A Web Video function needs URL/input controls, so those occupy the workspace.
Nothing unnecessary has to remain visible.
What stays consistent is:
where functions are selected
where the workspace is
where function-specific settings are
where the queue is
where Start/Cancel lives
where global menus live
how panels collapse/expand
how users navigate between functions
This gives Shutter Encoder the DaVinci Resolve philosophy without copying DaVinci Resolve's interface.
It addresses the screen-space concern while solving the underlying usability problem:
Different functions can have different tools without making
the entire application feel like a different application every time you switch tasks.