Maniphest T71734

VSE rendering of movie gets progressively slower
Closed, ArchivedKNOWN ISSUE
Actions

Assigned To
Richard Antalik (ISS)
Authored By
Guillaume M (mathers)
Nov 21 2019, 5:07 PM
Tags
  • BF Blender
  • Video Sequencer
  • Performance
Subscribers
Guillaume M (mathers)
Jacques Lucke (JacquesLucke)
Philipp Oeser (lichtwerk)
Richard Antalik (ISS)

Description

System Information
Operating system: Ubuntu 18.04.3 LTS
Graphics card: nVidia GM204GL [Quadro M4000]

Blender Version
Broken: 2.80, downloaded today from blender.org

Short description of error
When rendering a movie strip in the VSE, the render time for each frame gets progressively longer.
Here is a graph of the render time for a simple h264 file loaded in the VSE, and re-exported as another h264 file with some minor transforms (crop and scale)

This pattern seems to indicate a form of reset happens regularly. Upon inspection, these discontinuities happen for each I frame found in the h264 source. Therefore I assume that for each rendered frame, the image is reconstructed from the previous I frame, which requires evaluating each intermediate B and P frames. Is there any way to cache these frames ?

If we can't fix this, we may want to add to the wiki that you can get a very significant speed increase by encoding input files as motion jpegs, or at least reducing the time between I frames.

Event Timeline

Guillaume M (mathers) created this task.Nov 21 2019, 5:07 PM
Germano Cavalcante (mano-wii) added projects: Video Sequencer, Performance.Nov 22 2019, 7:06 PM
Richard Antalik (ISS) changed the task status from Unknown Status to Archived.Nov 25 2019, 9:26 AM
Richard Antalik (ISS) claimed this task.
Richard Antalik (ISS) added a subscriber: Richard Antalik (ISS).

@Guillaume M (mathers)

Is there any way to cache these frames ?

Not directly.
We can cache each frame, or we can use proxies, which are designed to overcome this specific issue.

Caching B and P frames would speed up read from HDD, they should be pretty small however, so not much performance would be gained. It is the math involved to reconstruct the frame that is biggest problem here IMO.

If we can't fix this, we may want to add to the wiki that you can get a very significant speed increase by encoding input files as motion jpegs, or at least reducing the time between I frames.

Do you mean Blender manual?
In similar fashion there is https://docs.blender.org/manual/en/latest/troubleshooting/3d_view.html#performance
It would be very nice touch to create such page for VSE.

I doubt, that most first-time users would read it, but this problem should be explained.

What I don't want to do is to automatically start building proxies. Pethaps as a user preference this would be OK even by default.

Closing as invalid because if this task should exist it should be a TODO with relevant description.

Guillaume M (mathers) added a comment.Nov 25 2019, 9:55 AM

Just pointing out that this is an issue for rendering, not preview !

Proxies are not used during render afaik. I agree the math involved to reconstruct the frame is the biggest problem, therefore keeping a cache of the last polled frames during render should solve this problem. This is not covered by the VSE preview cache, and would give a huge performance boost during renders.

Richard Antalik (ISS) changed the task status from Archived to Unknown Status.Nov 25 2019, 1:46 PM
In T71734#816823, @Guillaume M (mathers) wrote:

Just pointing out that this is an issue for rendering, not preview !

Thanks for correcing me.

Rendering job disregards any proxies and caches for quality reasons.
I think that in this case it is simple one-frame-per-stream anim cache, that is used to reconstruct next frame. I would say, that it does not make much sense disabling anim cache.

I can look in history, if and why it was disabled. It may be side effect of unrelated change.

Jacques Lucke (JacquesLucke) added a subscriber: Jacques Lucke (JacquesLucke).Jan 15 2020, 2:53 PM

@Richard Antalik (ISS) so is this a bug, known issue or something else?

Richard Antalik (ISS) changed the subtype of this task from "Report" to "Known Issue".Jan 15 2020, 2:55 PM
Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Needs Information from Developers.Jan 15 2020, 7:05 PM
Philipp Oeser (lichtwerk) added a subscriber: Philipp Oeser (lichtwerk).

(just trying to get this out of the "Needs Triage" limbo...)

Richard Antalik (ISS) added a comment.Jan 15 2020, 7:37 PM

Actually I have not tried to reproduce this yet, will do tomorrow just to be sure

Richard Antalik (ISS) added a comment.Nov 25 2020, 5:47 PM

@Guillaume M (mathers) I am going over old untriaged reports and found this. Sorry I haven't followed up on this sooner.

In any case I remember that I was trying to reproduce this issue with various h264 files, even ones that are optimized for streaming with terribly low I frame frequency and I wasn't able to reproduce this issue. Do you by any chance have sample file for this report?

Guillaume M (mathers) added a comment.Nov 25 2020, 6:23 PM

Hi @Richard Antalik (ISS), I don't think I can find that file again, but if I think this report is obsolete: since then several layers of caching were added so I wouldn't be surprised if the issue just disappeared in the refactoring. I'll let you know if I encounter something similar with a more recent version.

Richard Antalik (ISS) closed this task as Archived.Nov 25 2020, 7:16 PM

Cache isn't used for rendering, so I wouldn't be surprised if this issue still existed.

Again sorry for letting this so long without answer. If you find the file feel free to upload here.

Closing for now.