Scene Proxies in the Video Sequence Editor #54259
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
11 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#54259
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?
System Information
Windows 7 Ultimate, 64-bit, 32GB, 5960x, Nvidia Quadro FX 1800 (Primary) & GeForce 9800 GTX+ (Secondary)
Blender Version
Broken: (2.79a) Official builds
Worked: (2.79) Official builds
Short description of error
To cut a long story short @ideasman42 disabled Scene proxies in the Video Sequence Editor because:
This shocked me, have I been using Blender wrong? Because I've been happily doing this for months.
I don't quite understand the rationale behind the removal of is.
The main problem for me is that I have projects (made in 2.79 and earlier) that rely on scene proxies and when opening them up in 2.79a viewing or creating them doesn't work.
Now there are issues with Scene Proxies most notably the aforementioned (#54048) one and it can be really bad:
0001-2565.mkv
and
Other proxy issues
But I've always treated this as an incomplete feature, (same way I treat NetRender, it's somewhat stable but is inconsistent. e.g. blender/blender-addons#52502) throwing in a bug report due to just crashing (#53792) and have been fine.
But now with the update, the Proxy/Timecode Panel is still there and does nothing. and as I said in my query to @ideasman42's decision to disable this:
No... they don't. They worked for Scenes before. (and they work for images for that matter)
What do you mean by this? That it's officially 'supported', documented?
Now that I've been trying to research around a bit, is this an incomplete feature or has it slowly gotten broken in time?
There's #43857 which uses a scene proxy. So there must be other uses who uses this right? Or was this just an example?
I would love to use this with Eevee; having the proxies rendered in no time and my GPU not getting taxed.
What I think to be good next steps:
Exact steps for others to reproduce the error
Zipped folder with a working Blender file and proxy:
Tested in Ubuntu VM both 2.79 and 2.79a with reproducible behaviour.^
Tested on a separate laptop with both 2.79 and 2.79a with reproducible behaviour.^
(Note: In my Ubuntu VM I had to toggle Textured Solid button in the Scene Preview/Render Panel to get the proxy showing in 2.79.)
(^ Reproducible behaviour being: fully working in 2.79 and not working at all in 2.79a)
Blender_VSE_Testing_Scene_Proxy.zip
I'm sure this was just a misunderstanding.
Yours,
A passionate Blender user
Added subscribers: @ChristopherAnderssarian, @ideasman42
@ideasman42 //Polite nudge.
Just would like this looked over before 2.79b release... //
Added subscribers: @mont29, @Sergey
So...
It has been well over a month since I first asked about the code change (#54048#485618) and a month since this task's submission.
I completely understand if no administrator can undertake this (code quest, moving etc..), all I ask is for this to be looked over.
And after some advice/motivation I guess I'll keep nagging about it untill something happens.
I mean this has slipped past the release of 2.79a and 2.79b so I'm writing this early in hopes this will not get missed in 2.80 or maybe in a 2.79c release.
In the interest of saving time (whatever the modern day equivalent of telephone tag is)
If it is decided to reinstate scene proxies
I can:
Create tasks (from other proxy issues)
Give details on the issues/behaviour/bugs
Give expected behaviour
Show use cases (2.80, Eevee,..etc)
Give opinions on behaviour/functionality/design
Give functionality (expected limitations)
Anything else? Any other information required?
If it is decided to completely remove (and not support) scene proxies
Then: feel free to
bigbadbugreport
my reports (#54259, #53792)
and please remove the Proxy/Timecode Panel from properties.
and a valid reason for the removal of this!.
Is it possible to get this looked over before 2.8 beta?
Added subscriber: @iss
Hello.
I was proposing change(D3484) for VSE proxy system.
As I looked at code I realized, that the way we are generating names for proxies may lead to problems, so I was thinking about redoing that part already.
Do you want me to help?
Added subscriber: @snuq
I am also interested in a resolution to this bug.
I would say that if this is to be truly removed, in addition to the removal of the proxy panel, the 'proxy' property in the python api should be removed for this sequence type.
I have a vse addon that (among other things) will automatically enable proxies on sequences that have proxy support, and right now the scene sequence type does still have all the proxy settings.
@ International Space Station
I'd love to help. Though I can just about (barely) read code.
But I'm fine to bounce off ideas from.
In terms of the VSE (and the MCE's) Video Proxy naming and structure.
I'm not quite sure if @mont29's asset manager (#46049) will cover
this in anyway, shape or form.
Unless you would like to tackle some of the other issues?
But yeah... any help will be appreciated.
I have looked at the code, where the problem lies - the main problem is that we want to generate MJPEG video for proxies instead of a bunch of jpeg images. Making filename would be quite silly reason for dropping functional feature...
That's about my position as well :)
what I found is:
index_rebuild_ffmpeg
creates avi proxies from movies, seems by converting them to image with ffmpeg API, then packed to proxy AVI byindex_rebuild_ffmpeg_proc_decoded_frame
along with
index_rebuild_fallback
as an "alternative", which uses imbuf to get images, thenAVI_write_frame
to make proxiesold system (images) used function
seq_proxy_build_frame
which also uses imbuf (AFAIK generated images will use imbuf)So last two functions probably can be glued (at least with my skills) together...
I will look into that and post patch eventually.
From my use of video proxies (in VSE and MCE) if a video is an image sequence
there is no frame rate or time code so it's rendered as an image sequence.
But for a video there is a frame rate so it's kept as a video.
Though I do agree that it can be a bit chaotic to have image sequences, video files, and timecode files.
I think #54117's issue stems from this.
In terms of performance I would assume that AVI MJPEG video files are superior to
read (Sequentially) over images (Random) if the drive ever got fragmented.
Also all video proxies are rendered at 25 fps (even if below 25 fps) not quite sure why or for what reason.
For the scene strip proxies - you're going to be rendering a scene - so you've got a timebase/framerate to render the (.avi) proxy.
But would it be possible to resume rendering of a AVI MPEG proxy?
No, we want only AVIs for proxies.
For consistency sake, I would generate AVI even for image, just 1 frame long video maybe for speed reasons.
Also if it was up to me, I would like to make it possible, so every image generating sequence could have proxy.
We can make proxies at arbitrary frame rate, because we are reading them frame by frame, not constrained to timeline.
The code for generating images already exists, we can look at rendering code maybe, thing is, that we need not to output images, but pack them into a video.
Now there are two engines to do this - internal AVI encoder and FFMPEG.
It seems, that internal AVI enc will happily eat rendered frames and output a video, but it may be possible, that devs would prefer FFMPEG, which seems to need to define video stream, image format and stuff like that.
I will definitely need to play with this for a little while, until I get familiar with the code
Image proxies can be useful tho, what about transparent images/sequences? It would be nice if these were proxied in a way to preserve that transparency.
We can encode alpha channel in video, but I am not sure if we can read it back. But it should be possible in theory at least.
Or we can encode alpha in separate BW video, but that's ugly.
Anyway I have run a trial, and successfully created AVI proxies of scene, meta, and effect sequences using internal AVI encoder. Maybe colorspace was totally off, but I have an output at least :)
I have looked in the ffmpeg portion and I don't get this timecode files - is this even applicable outside of the movies? Doesn't look like it is...
What I would like to do is:
Maybe change UI:
@Sergey, you seems to be most involved in this. I know, that focus is on 2.8 branch, but can you please leave some comment about what do you think about this?
Added subscriber: @OscarNebeAbad
Added subscriber: @davidmcsween
I was sad to see this functionality lost as well, I used it to preview scenes with a compositor performing image manipulation. It was (almost?) the only way to buffer the compositor for a play-blast.
Just a notice to anyone interested:
I started working on this and will need a week or 2 to polish it
https://developer.blender.org/D3597
If you really really need this - it does work in current state.
please report issues :)
I can provide windows build, probably will try posting it on graphicall, I just need upload permission
Yes please :)
If anyone wants to test patch D3597 here is 32bit windows build
https://drive.google.com/open?id=1Gc5lrk08hK2XsCg94JVzJDE9ZJCMseak
Added subscriber: @tintwotin
Thanks for the test-build. I had to run it in compatibility mode for Windows 7 to get it to run on Windows 8.
It renders quick and you can't really live without the moving bars on the strips once you tried them. Great feature!
Also great with the option to select PNG and MJPEG(maybe other I-frame codecs like DNxHD and ProRes also could be included?).
This option properly should rename "Build JPEG quality" to "Bitrate" or something like that or else it will be confusing to ex. have JPEG quality in PNGs.
Unrelated to this commit, but IMHO the "checkbox and overwrite button" should be moved closer to the "Rebuild Proxy..." button and a "Delete proxy(ies)" button/function would be very nice to have. Maybe when viewing proxies, strips missing proxies, at the current % resolution, could have a red bar on top?
In my eyes this is a must-have-patch: No more rendering proxies in the "dark". Proxy generation at a great speed and selectable codecs for proxies.
Added subscriber: @GDQuest
How about just "quality" ?
This is an excellent patch indeed, and a must-have for the VSE: big time saver, the progress bars on the strip are a much welcome addition. I haven't had any issues with the parallel rendering so far. The only minor issues or wishes I've found are linked to the proxies panel, and related to Blender's UX:
I'll stay available for testing and feedback if you need it.
Thank you for feedback!
strange, but thanks for info.
Quality parameter is not used with PNG codec.
I don't really know, how bitrate works with PNG as it is lossless, maybe it works with compression.
Adding codecs should be easy, PNG to me seemed like good choice for highest performance - not too much disk bandwidth and also CPU usage seems quite OK. But it's only 8-bit...
I don't want to make UI changes in this patch, that are not necessary for it's function
Delete proxies seems like a good idea
Sorry, forgot about this. But it's a quick to fix.
I will update this soon.
Thanks much Richard ?
I sincerely hope it gets merged then, it's a must-have for VSE users. Like all your patches ?
Added subscriber: @mathers
Re-assigning, as @iss is working on this.
Added subscriber: @cedartea
I would love to see this implemented in 2.8.1! The inability to render a scene makes it impossible to composite and edit all in the same blender workflow because you're not able to cache to disk your composite work through proxies. Otherwise you'll have to depend on a cache to ram which gets very expensive very fast.
Is there any progress on bringing back proxies to scenes?
Sorry, it wasn't as smooth as I would hope it would be, so early 2.82 it should be in.
D5524: VSE: Disk cache is diff implementing mostly same functionality.
Since D5524: VSE: Disk cache is committed and providing technically same functionality as old proxies, I will close this report.
If there are any issues with using disk cache, please report these.
Changed status from 'Confirmed' to: 'Resolved'
There are a few things to understand about the differences of a cache and specifically Scene strip proxies:
Note: scene strips are treated as being in rendered view for the purpose of this post
Performance
Persistency
Invalidation
Features
Use Case
The nature of scene strips means that there has to be a way to use them with no unnecessary overhead for it to be a usable feature. Sure one approach is to try and make up for lost functionality in other tools/features, but removing one line of code and fixing the directory naming issue is far easier than trying to work around the above bullet points.
You've basically done the work in D6786: VSE: Refactor proxy loading and in concept for D5524: VSE: Disk cache, so I hope you don't intend to permanently axe this...
Changed status from 'Resolved' to: 'Confirmed'
I wanted to check if this was actually the case in older versions, but for some reasons I can not build scene proxy in any version prior to 2.79.
Not true in case of disk cache - it reads directly from file.
There are more problems currently:
On the other hand disk cache tries to solve:
Originally I designed disk cache to be bound to project. This is not the case with current implementation. Easiest solution would be to use disk cache as storage engine and add possibility to be localized.
This would mean, that if you want to archive project with caches/proxies, you can.
If you don't want to be bothered with management and just do stuff once and discard all files, you can.
Not true in case of disk cache.
Not sure what you mean by these 2 points. Issue would apply to proxies as well.
Technically you don't because only 100 images are stored in 1 file. There needs to be compromise between granularity and perfornance.
So far I have seen, changes in 3D editor always invalidate whole cache (physics simulations for example). Unless we can make more granular invalidation, one either can accept this limitation, or do corrections manually.
With proxies there was no invalidation at all. This is still the case for disk cache (for changes outside of VSE).
You can. in chunks of 100.
I don't understand this point.
This point has been raised in persistency.
This is in line with disk cache intended use. Is the point, that render farm is creating images, and you want to use that instead of some weird format? We coud have interface to do this (we do have it, but it's broken/disabled). Seems that intention was only to disable generating proxies, not using them.
I think that I have mainly misunderstood point of this report and even the problem itself, so I will reopen this.
In any case, I will leave my reply in a whole to adress your points. If you started with last point I wouldn't probably write so much...
Did the attached .zip folder work? with the versions stated?
You need to make sure you're using project storage, as there's no strip stored anywhere ;)
Okay so, yes you can just read from the disk cache (by disabling all the cache setting) but then you can't write new images to the cache (for the strip)
The larger picture is; you have to use the RAM cache to make/update the disk cache to be able to use it.
Not sure what you mean by localized.
My mistake, I see this is not true now.
I was thinking about Supported Features and Limitations on different hardware that would change the render result, but I don't run into this issue, so I thought I can't really comment on it.
(I could say the strip was 100 frames, but that would be me being assholistic)
Fine, but remember:
Best case: Need to update 100 frames. Delete one file, render 100 frames, zero frames unnessasaerally rendered
Worst case: Need to update 2 frames. Delete two files, render 200 frames, 198 frames unnessasaerally rendered
The way view proxies work is: the image is rendered at full resolution, rescaled, saved then the original deleted. You would have to do this process multiple time to get the sizes you need.
The way normal strip proxies work: the image is rendered at full resolution, rescaled to multiple sizes that are specified, saved then the original deleted.
It can feel weird (if under the premise that proxies have been replaced by this) that it's gone from a known format that you can easily interact with, modify, view, create your own, make changed to, ect.. to a seemingly proprietary format that only the VSE can use. I'm my eyes the Disk cache is just a RAM dumping system only intended for performance. Now this is fine if it's its own thing, but if this is replacing proxies I see that as a step backwards for functionality.
Well you can see how and why the task was born from this unanswered comment . It's to get an answer as to why this was disabled and not fixed.
I wasn't sure what you ment when you closed is task, so I tried to [clarify ]] which got me confused because of what I saw in [ https:*developer.blender.org/D6786#160860 | d6786 unless I was mistaken (but then you wouldn't have removed the comment explaining why something doesn't work).
oops, I guess we need to communicate better :)
Currently, Scene Strips have no proxies(as reported here) but also no caching, no prefetching, no thumbnails, no access to ex. 3d or compositor outputs in the same scene, and very poor performance.
As the scene strips are the only way to have an unrendered workflow integrated with the rest of Blender editors, the scene strips are essential for Blender to even have a Video Sequence Editor integrated, so I hope that Scene strips are going to be prioritized as such.
Over the years(since 2.79) the main approach has been to limit and cripple Scene strip functionality when problems are encountered. If this continues and scene strips are finally removed, you might as well remove the VSE too and do the video editing in some proprietary software...
Added subscriber: @GaryRitchie
Added subscriber: @wknowleskellett