VSE: indicate missing media in timeline/playback #116821
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#116821
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
(feature/improvement request from talking with @ZedDB)
Both of these are primarily because in a shared production, someone might not easily notice that some media is missing. Quoting:
More detail:
This was how it used to look when source media was missing in Scene strips:
This is how it is looking in 4.0:
I don't know who and why it was changed, but IMO covering the entire header area is problematic, since the header color is an indication of the strip type. Without this indication, if ex. more strip types get thumbnails(they should), then all strips with missing media will look the same. And that is a problem.
The thin red line has the saturation level of the selected items and will therefore stand out. This should be enough indication, as long it is still visible at all zoom levels.
And currently, is there actually a bug where the red line isn't drawn if all strip texts are switched off.
IMO, should all strips have the same kind of missing media indication.
When it was looking like in your shot? I just tested all the way back to 3.0, and it the missing data red area is the whole "title bar".
Should they? To me it sounds like these are separate and different problems. E.g. a scene strip missing a scene is "the blend file is broken and needs to be fixed". Whereas a movie strip referencing a file that does not exist, in an existing project is more likely a "you have renamed a file" or "the file is on a network share that is down", i.e. the fix is outside the blender (or a temporary issue, like network being down).
We could also call it Broken Strip Indicator and keep it consistent across strip types.
I would agree with @tintwotin, that scene data missing blocks and files should be represented in the same way.
Just a note, that in future strips may be using datablocks for movies and image sequences, because we want to have 3 point editing system.
Alright. So then, should it be:
From what I can tell, most other video applications turn the whole strip "some sort of red" in the timeline to indicate the broken state. I guess that's more visible in complex timelines than just a "red line at top". I quite like striped diagonal overlay, but I also know nothing about video workflows.
I would be fine with either option. Personally I think red stripes as in #116869 are fine as they are hard to overlook, though it makes filename bit hard to read. On the other hand even full red title bar is quite hard to overlook.
Some images from Google. Looking at these, the Final Cut way actually makes most sense to me, since it is coloring the content area of the strip red. And that makes sense since it is the content missing, and not the strip. Doing it this way, both the readability of the header text and the header color is preserved(however, the red color still needs to be visible when the strip is very narrow in height).
(A note: in most NLEs the tracks are specified specific kind of strip types, so audio is only in audio tracks etc. which means you can look at the track to see the strip type. In Blender all strip types can be in any channel, which is why the strip type color is important in Blender)
Moderation edit: Removed screenshots. Please check https://devtalk.blender.org/t/copyright-guidelines-for-devtalk/17331
During the development of this feature Aras and I purposely didn't use the "missing data block" error indicator because:
I personally think that is it is best to keep the data block error separate as if you open up a big edit that somehow has both errors, it can be quite easy for the user to get confused and think that they have more messed up media files when instead they need to fix things from inside Blender.
IE:
For missing media, the most likely solution if to fix it outside Blender. Either by shuffling around files structures or making sure that you are properly connected to a network drive.
For missing data blocks, the solution is most likely done inside of Blender. Either by assigning a datablock to something that didn't have a data block defined in the first place or linking/appending the relevant block to the .blend file.
Even if the proper solution is to shuffle around .blend files, I think it good to make the distinction in the UI so people can at a glance know "Oh, I need to fix media files" or "Oh, I need to fix .blend files".
Edit:
Note that I have already run this past some artists in the Blender studio and they are fine and agree with this.
Then how about coloring the content area of the strip in two different colors for missing data-block and missing file?
For the preview, the same colors could be used.
Remember that user can assign any color to strip, and different themes use different color presets, so any color we pick can potentially be lost in some theme somewhere. There needs to be something recognizable besides color that communicates this. Thats why I like original proposal with zebra strips best
Then the diagonal zebra stripes should only be in the content area of the strip and in two colors(if separating data-block from missing file is necessary).
We should make sure that the error is as visible as possible and so it is not easily confused with something else. Therefore striping the whole strip area is the best solution.
It is not possible to have missing datablocks and missing media data at the same time either so the errors should never overlap.
I think the current solution makes it quite clear what you are dealing with at a glance:
If you only have the error in the content area, it will be much easier to confuse the error for something else IMO.
When looking for missing files, it is essential to be able to read the path in the strip header, and you can't read the path text if the stripes are covering that area.
In our production test files, there is usually not enough room to be able to see the path in the strip header:
So I think in practice most people will probably click on the stips and read the path from the n-panel.
If the strip is long enough, then I think it is readable enough if you select it:
What if we also do drop-shadow on strip title when error to make it more readable
Checking several file paths with this look will drive most people insane:
(Also, isn't that color is too much Barbie? Why not a plain red?)
I do agree that there could (or should be) do some improvements to how text is displayed on the strips.
However I think this is not related to this specific missing media issue.
In my example where I used meta strips you can see that it is already quite easy to get hard to read text even without the stripes.
So I think we should probably split that out and make an other task/PR for that.
This doesn't work. And it is very much related to this suggested change:
I think you should aim for a solution which:
The feature has already gone through a few rounds of artist feedback.
For example:
Readability of the strip header were not of a higher priority than marking the strip as broken.
Especially since the header is usually not readable either way in production edits.
That is the feedback I got from multiple artists.
Even as it is now, they didn't think it was too horrible to read the text of the active strip.
Same as above. Especially since the strip color can be changed by the user so it can't reliably be used to identify the type of strip.
The artist were also able to identify the strip color without much of an issue even with the stripes.
This was also specifically requested in the feedback we got from artists. Sometimes they want to work on something and not be annoyed by warnings in case they need to do something ASAP.
The color was initally going to be red. However after feedback it was changed to purple to match how we display missing textures. The stripe color was kept red as the general consensus was that it made more sense in the timeline to have red to indicate errors.
Pls, include the UI team in the design decisions, such as these.
I have.
I've gotten a green light from Julian already.
@JulianEisel / @ZedDB I would suggest waiting for Pablo to be back (tomorrow?) and run this by him.
Blender also uses the stripped language for invalid baked simulations. I think we should try to unify the language used (in terms of spacing, and how we use/combine the colors).
In the image, current patch:
Bonus image, combining locking and missing media:
Some experiments I did locally, kinda similar what @tintwotin wrote above:
Various cases:
Same with all text labels display turned off (previously the "missing scene" case did not have any indicator of being "broken" in this case):
Same zoomed out, so that strip heights are too small to display either content (thumbnails for valid strips) or text labels:
Screnshot of Sprite Fright Edit data set, zoomed out:
Note that the current decision to have the different errors not share the same striped visuals were also to make it easier for certain to color blind people to see the difference.
Here is the above proposal with simulated blue blindness:
The color strips have a separating line between strip header and strip content:
This could also work well with the stripes:
The prop_search widget can be pointing to strips, and when the strips disappear from the timeline it goes red, so in other words if something is missing, solid red is the indication:
However, if a scene is missing, there is no indication in the sidebar panel widget, that something is missing(except New, which seems odd?):
