Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplified view for beginners for a cleaner and distractions free interface #546

Closed
markusd1984 opened this issue Dec 11, 2020 · 28 comments
Closed

Comments

@markusd1984
Copy link

Simplified to show the bare minimum so it's even easier to use for first time users / beginners,

assuming people usually will either click play and paus or select a point in the timeline, only seeing the timecode in one place e.g. within the timeline, having the start/end cut point buttons available as well as the Segment section, export button and maybe still include a keyframe forward/backward for more accuracy.

Perhaps an advanced view button (so it's not just configurable in the settings but one can switch between simple/advanced view, show/hide advanced functionality).

image

@mifi
Copy link
Owner

mifi commented Dec 11, 2020

As a quick improvement i will change this:

Screenshot 2020-12-11 at 16 55 47

@markusd1984
Copy link
Author

No harm in pointing the key buttons on the first screen, but certainly I see the tension between power users (hence all feature enhancements) vs the beginner/non techy people who once a video is loaded just need to see the buttons they need to use without the bells and whistles. Can be overwhelming. 😄

@mifi
Copy link
Owner

mifi commented Dec 11, 2020

Yea I agree it can be overwhelming. It's a good idea. I'm thinking something like this:

Default when starting losslesscut:
Screenshot 2020-12-11 at 21 19 03

Normal mode:
Screenshot 2020-12-11 at 21 18 13

mifi added a commit that referenced this issue Dec 11, 2020
@markusd1984
Copy link
Author

markusd1984 commented Dec 11, 2020

haha I like the baby picture, brilliant! :D

I'd exclude the yin yang (really who uses the discard segment edit mode, most people won't, it's not visually intuitive 😄)

and please add the key frame icons and point out in the start screen that "left/right keys move timeline frame by frame" (just play and pause or clicking into timeline won't always be enough or as efficient).

Tbh. the camera icon (without jpg/png toggle) is not too bad to be included as well, some might use that to take a screengrab for sharing (instead of using a screenshot).

@mifi
Copy link
Owner

mifi commented Dec 13, 2020

Yea I agree

@mifi
Copy link
Owner

mifi commented Dec 13, 2020

Screenshot 2020-12-13 at 17 23 27

@markusd1984
Copy link
Author

markusd1984 commented Dec 13, 2020

Nice! Just wondering if "seek" is rather a technical term and whether a simple synonym could be used instead, but tbh. It might not even require any explanation at all given that everybody will be familiar with playing back a timeline and thus mainly need to know how to set in/out cut points and the baby to emphasize the advance interface.
People will be able to just click the seeking icons and figure out what they do (since there aren't too many icons to click on with the simple UI 😄 ) and better to have minimal instructions on the start screen so chance of them being read are much higher (Help will reveal extra information anyway).

Also the keys as a symbol for keyframes is quiet clever :) but intuitively may be interpreted to lock/unlock something, instead of frame by frame, hence wondering if we could use a more clear symbol, e.g. a vertical bar with a full arrow could be ideal (since the bar is already used/displayed in the timeline and thus become familiar) <| |>
(Similar to the other button just other way around).

The baby, should it not read "toggle simple/advanced mode"?
Or "toggle advanced mode" given it starts with simple mode, and when toggled to advanced without a file loaded show "toggle simple mode" (for consistency) 😀

@markusd1984
Copy link
Author

@mifi please include the camera icon 😊

@markusd1984
Copy link
Author

sorry forgot about frame vs keyframe cut :) full arrow with bar for frames and full arrows for keyframes looks simple.

image

@mifi
Copy link
Owner

mifi commented Dec 13, 2020

I agree, i removed the seek help text. Most people understand how players work. (even youtube has the same key bindings.)

I'm not sure about <| |> because it doesn't really symbolize a keyframe. the term keyframe is used extensively around losslesscut. I see some other software also using key symbols. since there are two keys in opposite directions maybe the user will understand they don't symbolize unlocking? Also I believe usually locked/unlocked locks are used for symbolizing locking, not keys.

I'm not sure if simple mode is the right word. I'm also not sure if advanced mode is the right either. Because when the baby is activated (blue), it means advanced mode is deactivated, which seems confusing since blue symbolizes activated.

the camera will show when a file is opened that has a video track.

@markusd1984
Copy link
Author

markusd1984 commented Dec 13, 2020

The bar and full arrow signifies one frame (small step) forward / backward, thus i think a perfect match, which I have seen in others apps before.

A whole Keyframe could be double bars or a thicker bar with full arrow, signifying a bigger step at a time forward/backward.

Much better then keys as non techy people have no idea what keyframes are. 😀 but they will get the concept of going back forth in smaller steps for accuracy.

My point re baby first most was that it seems you're happy to start the app with them simple mode (which I think is better as most beginners will keep it rather than making an effort in changing to a simple view) and therefore the instruction should point out to toggle to enable the advanced view.

View is probably a better word, that's all it is (a different UI). Simple Vs Advanced seems like basic terms everybody should be familiar with. 😊

@markusd1984
Copy link
Author

markusd1984 commented Dec 13, 2020

image

UPDATED (to include the current basic arrows option 1, second single/thick bars or 3 single/double bars)

@mifi
Copy link
Owner

mifi commented Dec 13, 2020

Sure, looks nice, just need to find or make a vector version (preferably svg) of these icons

@mifi
Copy link
Owner

mifi commented Dec 13, 2020

I like the fat bars variant better

@markusd1984
Copy link
Author

Me too, even though the full pointer in the first picture look more simple / less busy overall, we probably should use bars for both frames and keyframes for consistency then, as in pic 3. 😄

Just wondering if for a simple view we should show frames instead of keyframes buttons, given if one plays the timeline and pauses to make a cut they may end up at a single frames anyway right?

Meaning only one wants to use Keyframe cut on purpose as they understand how it works and thus uses the Keyframe selection intentionally and needs/utilizes then the advanced view (rather then as default for simple view).

@markusd1984
Copy link
Author

markusd1984 commented Dec 14, 2020

deleted accidental post

@mifi
Copy link
Owner

mifi commented Dec 14, 2020

Keyframe cut is the default and recommended way to cut for most files though, because it doesn't leave empty parts at the beginning of videos.

@markusd1984
Copy link
Author

Let's stick to revealing frame by frame then in the advanced view.

Not fully sure if I understand how the cutting mode works along side using frame vs keyframe cut points?

  1. E.g. keyframe cut mode but selecting an actual frame to cut, will that automatically still cut at the nearest keyframe instead?

  2. If yes, would it be helpful to enforce that in that mode that even if one select a frame in the timeline (play-pause, click or frame by frame button) that it automatically snaps the segment cut to the nearest keyframe instead?

  3. And for the advanced view offer the option to override this to allow for frame by frame cut points and only there offer the frame buttons as well?

  4. Lastly just to clarify, the risk of empty part at the beginning of the videos meaning this would never occur in segments later in the timeline, only in the first 1-2 seconds of the video right?
    In other words, if we were to cut the beginning of the video to the first keyframe than all other segments should not have this issue in the normal cut mode and thus allow for more accurate - frame by frame - segments (selections)?

@mifi
Copy link
Owner

mifi commented Dec 14, 2020

  • E.g. keyframe cut mode but selecting an actual frame to cut, will that automatically still cut at the nearest keyframe instead?

Yes, it will cut at the nearest keyframe before the selected cutpoint

  • If yes, would it be helpful to enforce that in that mode that even if one select a frame in the timeline (play-pause, click or frame by frame button) that it automatically snaps the segment cut to the nearest keyframe instead?

It's not that easy because, depending on the particular video file, if the marker is exactly on a keyframe, ffmpeg will instead cut on the keyframe before that keyframe. So usually with keyframe cut, the user needs to cut a few frames after the wanted keyframe, and the cut will happen from that keyframe. But I haven't found consistently how much this offset needs to be for all video codecs. I'm not sure which files need Normal Cut, but I know some people had more success with that before. THere was a lot of discussion here: #13

4. Lastly just to clarify, the risk of empty part at the beginning of the videos meaning this would never occur in segments later in the timeline, only in the first 1-2 seconds of the video right?

no, this applies to all keyframes.

mifi added a commit that referenced this issue Dec 14, 2020
mifi added a commit that referenced this issue Dec 14, 2020
mifi added a commit that referenced this issue Dec 14, 2020
@markusd1984
Copy link
Author

markusd1984 commented Dec 14, 2020

@mifi Does the timeline not know where the keyframes are?
So that it could move the segment cut point at the last frame of the previous keyframe (a frame just before the keyframe you want to keep in the segment)?

Or are they just discovered during export?

@mifi
Copy link
Owner

mifi commented Dec 14, 2020

Yes the timeline knows where the keyframes are, however cutting at the last frame after the previous keyframe does not always result in the keyframe being included. sometimes need to cut 2 frames before, sometimes 5, we don't know. I experimented with a feature like this where cutpoints would snap to the nearest keyframe (or a few frames before), but I could never make it work consistently with common codecs.

@markusd1984
Copy link
Author

Would selecting the first frame of the previous keyframe then be the safest or closest approach for what to use during export to ensure the next keyframe is being used during keyframe cut mode but visually on the timeline put the segment marker on the first frame of the keyframe we expect to be included/start from in the export?

Thus if we then look at the start of the segment and realise we might cut to late make a decision of trying to selecting one or two previous keyframes to ensure the audio of the spoken word is included/or a pause prior it - e.g. using the keyframe buttons.

@mifi
Copy link
Owner

mifi commented Dec 14, 2020

I think for keyframe cut it could be possible to snap the start cutpoints to the nearest keyframe (exact). Then when sending the command to ffmpeg, we could send the time in the middle between the selected keyframe and the next keyframe

mifi added a commit that referenced this issue Dec 15, 2020
@markusd1984
Copy link
Author

markusd1984 commented Dec 15, 2020

worth to try - I understand though the above is only for out points then as for in points I would think is the opposite process, where it would be in between the middle of the selected keyframe and previous keyframe, to ensure the selected frame is used in the export or not ( being the first keyframe of that segment in the export)?

Why actually middle and not the first frame? I Understood the mixed test results with the last frame of previous keyframe but is the same unreliability true for the first frame that you have to pick the middle? 😄

simple vs advanced view
Looking good! Perhaps worthwhile in the Advanced UI to show also quick help explanation for the frame vs keyframes buttons and point out the cut modes keyframe cut vs normal cut, to point them out and provide some context why these buttons are made available. e.g. see settings for info.

@Shakil-Shahadat
Copy link
Contributor

Please check out the new media icons in the Bootstrap Icons v1.2.0.

@mifi
Copy link
Owner

mifi commented Jan 24, 2021

worth to try - I understand though the above is only for out points then as for in points I would think is the opposite process, where it would be in between the middle of the selected keyframe and previous keyframe, to ensure the selected frame is used in the export or not ( being the first keyframe of that segment in the export)?

no, as far as i understand, the keyframe issue is for the "cut from" time. The "cut to" time can be set to a point anywehere between keyframes as far as i know.

Why actually middle and not the first frame? I Understood the mixed test results with the last frame of previous keyframe but is the same unreliability true for the first frame that you have to pick the middle? 😄

yes sometimes the first frame after keyframe causes ffmpeg to instead use the keyframe before that keyframe.

@markusd1984
Copy link
Author

markusd1984 commented Jan 25, 2021

I will continue the conversation here for now to try and come to a full conclusion to determined whether a change in UI behaviour would make sense/is feasible or not for snap on keyframe during keyframe cut mode (as #13 deals with the actual ffmpeg commands).

Testing - timecode vs frame issue
I started doing some testing with keyframe cut vs normal, using a video with numbered keyframes, which I found a great sample for here, just a 24fps video with AVC code though, prefer to create and test also with 25, 30 and 60fps, being the most common used rates.

I got a bit confused at first with just reading the timeline with frame numbers, which I think seems to use 48 frames / 2 secs per keyframe, because when clicking the next keyframe it shows frame nr 50 (which is why I almost took this as the keyframe to containg 49 frames) but when clicking back one frame (to view the last frame of the first keyframe) it shows frame nr. 48, thus indeed 48frames per keyframe. (or is this 50 frames per keyframe????)
But the issue here also is that frame 49 is not even displayed! Also the first frame shows frame nr. 0 (00:00.00) just as the the next frame shows frame nr. 0 again (00:00:01). 2nd keyframe starts with time code 00:02:02, perhaps the timecode displayed is also wrong?

The correct behaviour would be for jumping to the the 2nd keyframe and see frame nr. 49 and timecode to display 0:02.01 instead of 0:02.02. The issue seems to be that a new keyframe displays not the first frame of that keyframe but the second one instead?

Testing - export results
kc @ 00:00.19 which shows actually frame 18 -> segment starts with frame 00 but time code 00:01.06, clicking to the next frame shows timecode 00:00.03 and to contain one unplayable frame before the first full keyframe.

nc @ 00:00.19 which shows actually frame 18 -> segment starts with frame 50 but time code 00:01.06, 29 frames seem to be included prior the first full keyframe but not playable.

Perhaps this is one of the codecs you said where normal cut mode doesn't work yet to render the exact frames lossy #126.
I will try other samples soon too to see if the timecode issue and export results issue is same for other frame rates.

@mifi
Copy link
Owner

mifi commented Jan 15, 2022

I think the issue with frame inaccuracy is handled in issue #330 (comment)

So I will close this because it's done afaik!

@mifi mifi closed this as completed Jan 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants