Just guessing here, but it seems to me changing the Set Proxy Size, when no proxies are generated, is still changing the resolution, properly mirroring the Resolution % in the Output options:

However values above 50% will actually lower the play-rate performance(properly because of scaling):

That could be some of the reason for a file is playing much slower when it is used as a proxy file.

If this is the case, the question is, if the swapping of generated proxies merged with Resolution % is a good idea, or if it is better to separate the proxy file swapping from the live-rescaling(Resolution %)? Or in other words, the Enum for selecting should be preserved file swapping and the Preview Resolution % should have a separate widget(like in Output options)?

This way users might avoid some of the performance loss when using the current 'Set Proxy Size' function in the 50%, 75% and 100% proxy resolutions. As mentioned in the first post about this problem a HD 29.97 proxy file played with the accurate framerate, when played from the Sequencer Timeline(so there is no need for the Resolution % on top of the file swapping).

Or alternatively check if the image resizing for the VSE could be optimized? Resizing is lowering the playrate in many areas of the VSE, and for sure causing poor playback.

But as I wrote, I just guessing here, so could this be some the reason for the performance drop?

It looks like you @Sergey Sharybin (sergey) back in the day, did some work on the (vse?) proxy system?

If you did, do you know if there are any logic explanations for playing a clip as proxy at 100%(unscaled) delivers a much worse playback rate compared to playing the very same clip directly in the VSE timeline?

I haven't been able to reproduce this bug in blender 2.81 can you please confirm that it still exists.

Wow when posting, I can only choose between Resolved, Invalid or Archived. That must surely be a bug on Phabricator?

I tried 100% and there is no performance loss

Did you try with a clip or a frame rate(ex. 100 fps) that your hardware is not capable at playing at full speed?

In T70415#819679, @Richard Antalik (ISS) wrote:

I could reproduce this, but I haven't opened this because I wanted to confirm cause of this.

But I can confirm that this is bug and the cause is in sequencer.c

/* dirty hack to distinguish 100% render size from PROXY_100 */
if (render_size == 99) {
  render_size = 100;
}

The preview_render_size should be replaced with enums and we wont need to use this hack.

Indeed. In best case we could re-use IMB_ functions and enums.

I have done this quickly in the past, haven't been too happy with solution though. I think, that in that time I wasn't aware of DNA versioning so that's why I dropped it.

Can you test this

@Eitan Traurig (EitanSomething) I'm not entirely sure what you did here, and what you want me to test?
Throwing some files around, it seems that the scaling of files with no encoded proxy files has been removed eg. the quality and framerate is the same no matter what Proxy Render Size is set. (Is this preview scaling to be used in a separate enum?)

When there are encoded proxy files, and the 'Proxy Render Size' is set to 'No proxy, full render' or 'Scene render size' it is actually using the 25% proxies - and not the source file. This means that I'm currently not able to compare the play rates of the proxy files played as proxies and as clips played directly in the time line(No proxy, full render).

I sent the wrong diff

Here is the patch D6368

The reason why proxy files at 25% are slower when added to timeline is because the VSE thinks its original size and runs

rectx = (render_size * (float)scene->r.xsch) / 100.0f + 0.5f;
recty = (render_size * (float)scene->r.ysch) / 100.0f + 0.5f;

BKE_sequencer_new_render_data(
    bmain, depsgraph, scene, rectx, recty, proxy_size, false, &context);
context.view_id = BKE_scene_multiview_view_id_get(&scene->r, viewname);

with render_size and proxy_size set to 100 when it should be 25 that is where the slowdown is.

Test files to reproduce Speed difference between using 25% proxy and proxy file added to timeline.
Steps to reproduce

• Add Blender.mp4
• Set Frame rate to more than what your computer will be able to play at
• Turn on proxy for the Movie
• Build 25% proxy
• Set proxy render size to 25%
• Turn on prefetch frame
• Play Video and take down average FPS
• Delete the video
• Add the Proxy_25.avi file
• Set proxy render size to no proxy, full render
• Set Frame rate to more than what your computer will be able to play at
• Play Video and take down average FPS

Average FPS of Proxy_25.avi in the timeline should be lower than using render proxy 25% of Blender.mp4.

@Eitan Traurig (EitanSomething)
File you provided played at 90 FPS without proxy and 280 FPS with 25% proxy
Proxy file itself plays at 300FPS

This is because proxy of 1920 x 1060 clip has size of 480 x 272
However 1920 * 0.25 = 480
and 1040 * 0.25 = 265

480 x 272 is different to 480 x 265, therefore clip has to be scaled. This is limitation of MJPEG format.

@Richard Antalik (ISS) @Eitan Traurig (EitanSomething)

That clip plays here at 18 fps when there is a resolution mismatch 1060 vs. 1080.
Using Movie Strip > Set Render Size(so render resolution fits source) the playpack rate jumps to 25 fps.
(Disabling Cache and Cache Drawing)

Playing an encoded proxy file at 25% as proxy plays at 65 fps.
Playing the same file directly in the timeline(No Proxy) it plays at 35 fps.

Does the reason for this hack still exist

/* JPEG requires this */
width = round_up(width, 8);
height = round_up(height, 8);

@Eitan Traurig (EitanSomething)
I think I have read that somewhere in ffmpeg docs, but that would have to be ages ago, so I assumed this to be the case. But just to be sure, I re-tested this by simply rendering at 960x540 (and other arbitrary sizes, that do contradict such rule), and it worked correctly.

So this very well may be historic issue.

You can try to comment this out and try building proxy of any size. None should work if those lines are necessary.

Marking with 2.82 since there is an accepted fix for this bug, just waiting for commit.