Scene Proxies in the Video Sequence Editor #54259

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:

In #54048#485268, @ideasman42 wrote:
Looked into this and for now building proxies doesn't support anything besides movie, so disabling support for this.

6535f668b4

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

Skipping frames whilst rendering.
Properties side panel scrolls up after changing proxy location in the File Explorer.
Overwrite don't have the same behaviour as Overwrite does in the render setting (in the properties editor)
and inconsistent functionality .

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:

In #54048#485618, @ChristopherAnderssarian wrote:
So, @ideasman42 does this invalidate my bug report? #53792
Also, is it a good idea to disable this considering the Proxy/Timecode Panel option still there (or are you still working on this)?

With no information or feedback in the Blender Manual or when trying to create proxies (nothing happens), you are going to get users confused on a essential feature that worked (works fine in cycles for me (not the file names the crashing)) in 2.79 and now doesn't with no apparent reason why.

In 6535f668b4, @ideasman42 wrote:

...generating proxies currently only works for movies...

No... they don't. They worked for Scenes before. (and they work for images for that matter)

...cancel until other types of sequence strips are supported...

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:

Having the functionality back as it was before.
An open task to deal with the Other proxy issues.

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

**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: > In #54048#485268, @ideasman42 wrote: > Looked into this and for now **building proxies doesn't support anything besides movie, so disabling support for this.** > > 6535f668b4 *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](https://archive.blender.org/developer/F2418016/0001-2565.mkv) and **Other proxy issues** - Skipping frames whilst rendering. - Properties side panel scrolls up after changing proxy location in the File Explorer. - Overwrite don't have the same behaviour as Overwrite does in the render setting (in the properties editor) - and [inconsistent functionality ](https://developer.blender.org/F2418236). 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 ](https://docs.blender.org/manual/en/dev/editors/movie_clip_editor/properties/proxy.html) is still there and does nothing. and as I said in my query to @ideasman42's decision to disable this: > In #54048#485618, @ChristopherAnderssarian wrote: > So, @ideasman42 does this invalidate my bug report? #53792 > Also, is it a good idea to disable this considering the Proxy/Timecode Panel option still there (or are you still working on this)? > > With no information or feedback in the Blender Manual or when trying to create proxies (nothing happens), `you are going to get users confused on a essential feature that worked` (works fine in cycles for me (not the file names the crashing)) in 2.79 `and now doesn't with no apparent reason why. ` ___ > In 6535f668b4, @ideasman42 wrote: >>...generating proxies currently only works for movies... *No... they don't. They worked for Scenes before. (and they work for images for that matter)* >>...cancel until other types of sequence strips are supported... *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: - Having the functionality back as it was before. - An open task to deal with the *Other proxy issues.* ___ **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](https://archive.blender.org/developer/F2412783/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

Adding @Sergey & @mont29 as after a quick search seem to be the most active on the subject of VSE Proxies.

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...

In #54259#516699, @ChristopherAnderssarian wrote:
I'd love to help. Though I can just about (barely) read code.

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 by index_rebuild_ffmpeg_proc_decoded_frame
along with index_rebuild_fallback as an "alternative", which uses imbuf to get images, then AVI_write_frame to make proxies

old 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.

In #54259#516845, @snuq wrote:
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:

write support for generating proxies for all types of sequences
have 2 or 3 generators - movie, images (+) other sequences
Possibility to use motion PNG codec to support transparency/lossless proxies
merge proxy API to one place
possibility to invalidate proxy (useful mainly for effects)
multithreading (POC: D3484)

Maybe change UI:

add default proxy settings in userpref, so adding new sequence can use these
rebuild all/invalid/selected operator
show state(validity etc) / progress in timeline (POC: D3484)

@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

In #54259#526451, @iss wrote:
I can provide windows build

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

This option properly should rename "Build JPEG quality" to "Bitrate percentage"

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:

All strips use the PNG codec by default - it renders transparent video proxies for me. I have to manually change it to MJPEG on every video strip
There is no way to change the video codec or other proxy parameters on all selected strips with Alt like you can do on any property does not work in the Proxies panel (E.g. Alt click on "25%" to set all selected strips to use 25% proxies... well it's not a field so no way to use alt enter)

I'll stay available for testing and feedback if you need it.

Thank you for feedback!

Thanks for the test-build. I had to run it in compatibility mode for Windows 7 to get it to run on Windows 8.

strange, but thanks for info.

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.

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...

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?

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

All strips use the PNG codec by default - it renders transparent video proxies for me. I have to manually change it to MJPEG on every video strip
There is no way to change the video codec or other proxy parameters on all selected strips with Alt like you can do on any property does not work in the Proxies panel (E.g. Alt click on "25%" to set all selected strips to use 25% proxies... well it's not a field so no way to use alt enter)

Sorry, forgot about this. But it's a quick to fix.
I will update this soon.

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

Since the only way to view the scene is with the cache you don't have the option to just read directly from a file. You have to have this cached, taking up that dedicated resource.
What happens when the cache garbage collection comes? There's no way to lock sequences from being cleared. Not everyone has the means to throw a 10 TiB SD card at the problem.

Persistency

The cache, whether that be RAM or Disk, are temporary. When Blender crashes it's all gone, you can't start working until you have manually fetched and created all the view proxies you need, BY HAND.
(nitpick) Some editors might not have access to certain hardware needed to render using different features.
(nitpick) There have been rendering differences with different hardware in the past and will be in the future so having something that keeps getting refreshed on different hardware is not guaranteed to be consistent.

Invalidation

If you change parts of a scene you have to re-render the entire strip, you can't re-render the frames you want to update.

Features

Proxy (View proxy) sizes can't be rendered from one full resolution image. The original image is rendered, resized and discarded.
The cache files themselves can't be used for anything else. They are created for a single purpose and then destroyed.

Use Case

With proxies there's a lower barrier to entry for editing, i.e. resources are not used to interact with or modify/render from source files. You can have a server render/create all the files and proxies you need, and then edit with a potato PC that only needs to worry about displaying an image. IIRC Level One Techs said on one of their streams they did this. I'm sure you can imagine now primarily editing with scene strips.

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...

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** - Since the only way to view the scene is with the cache you don't have the option to just read directly from a file. You have to have this cached, taking up that dedicated resource. - What happens when the cache garbage collection comes? There's no way to lock sequences from being cleared. Not everyone has the means to throw a 10 TiB SD card at the problem. **Persistency** - The cache, whether that be RAM or Disk, are temporary. When Blender crashes it's all gone, you can't start working until you have manually fetched and created all the view proxies you need, BY HAND. - (nitpick) Some editors might not have access to certain hardware needed to render using different features. - (nitpick) There have been rendering differences with different hardware in the past and will be in the future so having something that keeps getting refreshed on different hardware is not guaranteed to be consistent. **Invalidation** - If you change parts of a scene you have to re-render the entire strip, you can't re-render the frames you want to update. **Features** - Proxy (View proxy) sizes can't be rendered from one full resolution image. The original image is rendered, resized and discarded. - The cache files themselves can't be used for anything else. They are created for a single purpose and then destroyed. **Use Case** - With proxies there's a lower barrier to entry for editing, i.e. resources are not used to interact with or modify/render from source files. You can have a server render/create all the files and proxies you need, and then edit with a potato PC that only needs to worry about displaying an image. IIRC Level One Techs said on one of their streams they did this. I'm sure you can imagine now primarily editing with scene strips. 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](https://archive.blender.org/developer/D6786) and in concept for [D5524: VSE: Disk cache](https://archive.blender.org/developer/D5524), so I hope you don't intend to permanently axe this...

Changed status from 'Resolved' to: 'Confirmed'

In #54259#934758, @ChristopherAnderssarian wrote:
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

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.

==== Performance ====

Since the only way to view the scene is with the cache you don't have the option to just read directly from a file.

Not true in case of disk cache - it reads directly from file.

There are more problems currently:

relatively slow compression method (not multithreaded)
issue with prefetching locking main thread. I suppose this is due to using single mutex, while I should use RW mutex. Also I suppose this will happen on cold reads.
Large files for scenes - proxies were limited to using 8-bit image, while cache will store what it has been provided with (usually 32-bit image for scene). This is more issue with color management than with cache itself.

On the other hand disk cache tries to solve:

slow cold reads with a lot of files - 100 images per file.
limitation of using 8-bit image with color transformation already applied - you should be able to do edits in arbitrary colorspace and bit depth.

==== Persistency ====

What happens when the cache garbage collection comes? There's no way to lock sequences from being cleared.

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.

The cache, whether that be RAM or Disk, are temporary.

Not true in case of disk cache.

(nitpick) Some editors might not have access to certain hardware needed to render using different features.

(nitpick) There have been rendering differences with different hardware in the past and will be in the future so having something that keeps getting refreshed on different hardware is not guaranteed to be consistent.

Not sure what you mean by these 2 points. Issue would apply to proxies as well.

==== Invalidation ====

If you change parts of a scene you have to re-render the entire strip.

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't re-render the frames you want to update.

You can. in chunks of 100.

==== Features ====

Proxy (View proxy) sizes can't be rendered from one full resolution image. The original image is rendered, resized and discarded.

I don't understand this point.

The cache files themselves can't be used for anything else. They are created for a single purpose and then destroyed.

This point has been raised in persistency.

==== Use Case ====

With proxies there's a lower barrier to entry for editing, i.e. resources are not used to interact with or modify/render from source files. You can have a server render/create all the files and proxies you need, and then edit with a potato PC that only needs to worry about displaying an image. IIRC Level One Techs said on one of their streams they did this. I'm sure you can imagine now primarily editing with scene strips.
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.

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.

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...

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...

> In #54259#934758, @ChristopherAnderssarian wrote: > 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* 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. > ==== Performance ==== > - Since the only way to view the scene is with the cache you don't have the option to just read directly from a file. Not true in case of disk cache - it reads directly from file. There are more problems currently: - relatively slow compression method (not multithreaded) - issue with prefetching locking main thread. I suppose this is due to using single mutex, while I should use RW mutex. Also I suppose this will happen on cold reads. - Large files for scenes - proxies were limited to using 8-bit image, while cache will store what it has been provided with (usually 32-bit image for scene). This is more issue with color management than with cache itself. On the other hand disk cache tries to solve: - slow cold reads with a lot of files - 100 images per file. - limitation of using 8-bit image with color transformation already applied - you should be able to do edits in arbitrary colorspace and bit depth. > ==== Persistency ==== > - What happens when the cache garbage collection comes? There's no way to lock sequences from being cleared. 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. > - The cache, whether that be RAM or Disk, are temporary. Not true in case of disk cache. > - (nitpick) Some editors might not have access to certain hardware needed to render using different features. > - (nitpick) There have been rendering differences with different hardware in the past and will be in the future so having something that keeps getting refreshed on different hardware is not guaranteed to be consistent. Not sure what you mean by these 2 points. Issue would apply to proxies as well. > ==== Invalidation ==== > - If you change parts of a scene you have to re-render the entire strip. 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't re-render the frames you want to update. You can. in chunks of 100. > ==== Features ==== > - Proxy (View proxy) sizes can't be rendered from one full resolution image. The original image is rendered, resized and discarded. I don't understand this point. > - The cache files themselves can't be used for anything else. They are created for a single purpose and then destroyed. This point has been raised in persistency. > ==== Use Case ==== > - With proxies there's a lower barrier to entry for editing, i.e. resources are not used to interact with or modify/render from source files. You can have a server render/create all the files and proxies you need, and then edit with a potato PC that only needs to worry about displaying an image. IIRC Level One Techs said on one of their streams they did this. I'm sure you can imagine now primarily editing with scene strips. > 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. 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. > You've basically done the work in [D6786: VSE: Refactor proxy loading](https://archive.blender.org/developer/D6786) and in concept for [D5524: VSE: Disk cache](https://archive.blender.org/developer/D5524), so I hope you don't intend to permanently axe this... 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...

In #54259#935345, @iss wrote:

In #54259#934758, @ChristopherAnderssarian wrote:
There are a few things to understand about the differences of a cache and specifically Scene strip proxies:

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.

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 ;)

Since the only way to view the scene is with the cache you don't have the option to just read directly from a file.

Not true in case of disk cache - it reads directly from file.

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.

Easiest solution would be to use disk cache as storage engine and add possibility to be localized.

Not sure what you mean by localized.

The cache, whether that be RAM or Disk, are temporary.

Not true in case of disk cache.

My mistake, I see this is not true now.

(nitpick) Some editors might not have access to certain hardware needed to render using different features.

(nitpick) There have been rendering differences with different hardware in the past and will be in the future so having something that keeps getting refreshed on different hardware is not guaranteed to be consistent.

Not sure what you mean by these 2 points. Issue would apply to proxies as well.

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.

==== Invalidation ====

If you change parts of a scene you have to re-render the entire strip.

Technically you don't because only 100 images are stored in 1 file. There needs to be compromise between granularity and perfornance.

(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

==== Features ====

Proxy (View proxy) sizes can't be rendered from one full resolution image. The original image is rendered, resized and discarded.

I don't understand this point.

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.

==== Use Case ====

With proxies there's a lower barrier to entry for editing, i.e. resources are not used to interact with or modify/render from source files. You can have a server render/create all the files and proxies you need, and then edit with a potato PC that only needs to worry about displaying an image. IIRC Level One Techs said on one of their streams they did this. I'm sure you can imagine now primarily editing with scene strips.
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.

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).

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.

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.

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).

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...

oops, I guess we need to communicate better :)

> In #54259#935345, @iss wrote: >> In #54259#934758, @ChristopherAnderssarian wrote: >> There are a few things to understand about the differences of a cache and specifically Scene strip proxies: > 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. 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 ;) >> - Since the only way to view the scene is with the cache you don't have the option to just read directly from a file. > Not true in case of disk cache - it reads directly from file. 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. >Easiest solution would be to use disk cache as storage engine and add possibility to be localized. Not sure what you mean by localized. >> - The cache, whether that be RAM or Disk, are temporary. > Not true in case of disk cache. My mistake, I see this is not true now. >> - (nitpick) Some editors might not have access to certain hardware needed to render using different features. >> - (nitpick) There have been rendering differences with different hardware in the past and will be in the future so having something that keeps getting refreshed on different hardware is not guaranteed to be consistent. > Not sure what you mean by these 2 points. Issue would apply to proxies as well. I was thinking about [Supported Features and Limitations ](https://docs.blender.org/manual/en/dev/render/cycles/gpu_rendering.html#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. >> ==== Invalidation ==== >> - If you change parts of a scene you have to re-render the entire strip. > Technically you don't because only 100 images are stored in 1 file. There needs to be compromise between granularity and perfornance. (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 >> ==== Features ==== >> - Proxy (View proxy) sizes can't be rendered from one full resolution image. The original image is rendered, resized and discarded. > I don't understand this point. 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. >> ==== Use Case ==== >> - With proxies there's a lower barrier to entry for editing, i.e. resources are not used to interact with or modify/render from source files. You can have a server render/create all the files and proxies you need, and then edit with a potato PC that only needs to worry about displaying an image. IIRC Level One Techs said on one of their streams they did this. I'm sure you can imagine now primarily editing with scene strips. >> 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. > > 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). 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. >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. Well you can see how and why the task was born from [this unanswered comment ](https://developer.blender.org/T54048#485618). 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 ](https:*blender.chat/channel/vse?msg=rCRtwaguemy7qgajf) unless I was mistaken *(but then you wouldn't have removed the comment explaining why something doesn't work)*. > 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... 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

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations