Status:
Functionality should be quite complete, only problem is preprocess cache, since preprocess ibufs may vary in size. But if you enable caching preprocess for some strips, prefetch may have problems (may try to fetch more, then cache capacity - wasted effort). It should be easy to detect such event and stop prefetching, which may be a way to go...

@Mal Duffin (mal_cando), Thanks for patch!
Are these properties set dynamically? there may be some cases, where we would want to keep just one thread - if we utilize multiple threads for actual rendering, for example D3934 or D3597.

Still work in progress...
Scene copying was not modified yet.
Also haven't look at undo bug.

In D3934#89994, @Brecht Van Lommel (brecht) wrote:

I think the approach is generally fine. Would be nice to see a more cleaned up patch to review in more detail.

Here is win32 build:
https://drive.google.com/file/d/1JDzIHHNA9qWvoXvVIShf9e-7l8bm-re5/view?usp=sharing

I forgot, @Brecht Van Lommel (brecht), you was also involved :)

In D3597#89058, @Christopher Anderssarian (Christopher_Anderssarian) wrote:

@Richard Antalik (ISS)
I've been playing around with your 'test patch D3597'

• The progress bar on the audio strip visually suggests that a proxy is being generated for the audio, even though it's not. (I would remove it)

This would be easy to solve.

In D3621#88926, @Pablo Vazquez (pablovazquez) wrote:

This has been a request for ages! Do you think you can make sure the patch works against the latest? A lot has changed since August. It will make it easier for developers to review.

can this be considered?
https://blender.community/c/rightclickselect/74bbbc/increase-vse-transform-strip-rotation-limits

In D3621#88926, @Pablo Vazquez (pablovazquez) wrote:

This has been a request for ages! Do you think you can make sure the patch works against the latest? A lot has changed since August. It will make it easier for developers to review.

In D3597#86749, @Jens Ruda (jaker) wrote:

I try to compile this, but the diff file no longer works (can't patch). Can anyone guide me? Is it for the master branch? Is there any chance that this can work in Blender 2.80?

Can there perhaps be some clip on channel 32 unnoticed?
In python you can move strip beyond this limit, but it wont play.

This happened to me some time ago, but I don't know how I dealt with this.
either I had to redo everything from beginning, or what you can try, I changed source file to some random file, then changed it back to what it should be (should reload anims?).

I would try to disable proxies(before you preview strip) if you are using them.
And maybe try to recover backups - should be named *.blend1

Convert old files to new format - triggered by manipulation with sequence individually.
This is done in BKE_sequence_calc_sound_disp() instead of do_versions()

Add codec selection to set selected strip proxies operator

I would remove scaling and color grading from sequencer panel on strips and get rid of preprocessing stage. Also it seemed to me, that this stage has it's own cache - useless and waste of resources.
Use effects!

Thank you for feedback!

If anyone wants to test patch D3597 here is 32bit windows build
https://drive.google.com/open?id=1Gc5lrk08hK2XsCg94JVzJDE9ZJCMseak

finished refactoring, movieclip still uses its own job manager, but could maybe use unified...
I don't know if there was multiview support, but now is.

Refactor proxy API, 1st pass

My understanding of backward and forward compatibility was kinda reversed - from application point of view, to support newer files.
So if this is not the case, I will consider different approach here

Fix issue with not deleting original proxy file
Add dirty mutex, so it is very unlikely to crash building proxies by human interaction, but I have to look deeper, how it is usualy done in blender.
For multithreading I am using my wm_jobs "hack" but I think, that it may be useful for this kind of job manager to be able to run more than one jobs.

Fix HUGE memory leak (still some bytes left, but not gigs of them at least :)
Add PNG / MJPEG codec selection to UI
Render smaller imbufs instead of post-scaling
Render everything to fixed size - so 25% proxy no longer means 25% of source resolution, but it is 25% of "project" resolution (scene->r.xsch)

I found some quite stupid mistakes - sorry for that

should I mark inlines as done and then update diff?

I can "convert" old files, by adjusting offsets when loading.
When I load files blend file saved by blender compiled with this diff, it's much worse - there can be sequences with 0 length
I can "convert" offsets back when saving.

fix minor issues, that slipped

Hi, it's richardantalik at google mail

Just a notice to anyone interested:
I started working on this and will need a week or 2 to polish it

rebase on top of latest master

Fixed audio glitching when pitch is animated, also sequence position / length is stable now. I was not able to reproduce these 1 frame offsets that I remember seeing last time.

In T54259#516845, @hudson barkley (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.

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.

Hi,
I currently know about 3 issues:
Cutting of strip leaves gaps sometimes and strip can "jump" channel when changing/animating pitch.
Now I noticed, that when I have startofs, it slowly shrinks, when changing pitch.

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

Now "strips" should be fixed to the timeline when changing pitch,
fix sequence slide operator, at least to the point that it is usable,
fix playback position when playing not from start.

Hello.
I was proposing change(D3484) for VSE proxy system.

Hello,
To disable this behavior, you can comment line 698 in rna_sequencer.c - do_sequence_frame_change_update(scene, seq);
But it is glitchy.

added fetures discussed in T50843 with @Joerg Mueller (nexyon) :

I understand what you want to do...
I was thinking that this will add a "layer of abstraction" for all functions that use sound strips. But this abstraction has to be present somewhere, so I don't really object to this variant.
I will try to make some patch during weekend.

Thanks for quick reaction!
I will try to explain myself a bit.

And adding a quick and dirty proof of concept: https://youtu.be/zB7wXox8VX0

I wrote patch D3496 to stretch waveforms of seq, so if you cut it based on waveform it behaves consistently with expectation.

I tested swapping sound files - it worked OK, because another function is handling this and new waveform is at different memory address.
Undoing this action will therefore correctly swap waveforms back.

I didn't want to spam, so I edited my post.
Can you please take a look at suggested modifications?

VFont linking solved this by adding newlibadr lookup in function lib_link_scene in file readfile.c

			Sequence *seq;
			SEQ_BEGIN (sce->ed, seq)
			{
				...

I am testing this diff on 2.79.4
When I close and open blend file, VFont reference of text seq data is loaded with old memory address, but VFont block from blend file is loaded to new location. Sometimes on the "old memory address" there is random data, which will cause blender to crash.