FIX : 472 / Small refactor of partial-movie-files handling

[huguesdevimeux]

List of Changes

• Refactored partial movie files handling. See explanation below.
• Added some extra logs that output partial movie files stuff, to make debugging easier.

Motivation

• This fixes [scene caching] partial movie file not found #472

Explanation for Changes

#472 undercovers two issues :

• The first one is related to SceneFileWriter. To write a new partial movie file, it used to take in order the next hash in animation_hashes list of a scene. SceneFileWriter keeps its own index of partial movie files, independently of Scene. I think some code is better than my explanations : See get_next_partial_movie_file method, and scene_file_writer own index is self.index_partial_movie_file .

https://github.com/ManimCommunity/manim/blob/master/manim/scene/scene_file_writer.py#L189-L210

This is bad, very bad, in some particular cases, like when the first animation is skipped as already cached. Then, the list of partial movie file is updated, but as sceneFIleWriter has its own index, sceneFIleWriter will think it's the first animation instead of the second one. I know, it's tricky. I fixed this by getting rid of this index. The index is now scene.num_plays.

• Manim didn't make any difference between animation skipped because cached and animation skipped because of -n. The first ones have to be rendered in the final movie, the second one not. This is now fixed. If an animation has to be skipped because of a flag, the animation_hashes_list will be appened by None, and by the hash otherwise. Like this, the index (scene.num_plays) is not bigger than animation_hashes list.

Testing Status

tests for -n flag exited with no issue.
It's impossible to proper test this, as we have no possibility to test caching yet.

Acknowledgement

• [ x] I have read the Contributing Guidelines

[cobordism]

Manim didn't make any difference between animation skipped because cached and animation skipped because of -n. The first ones have to be rendered in the final movie, the second one not.

True that the animation doesn't have to be rendered, but the end result of it (the final svg) does. right?

[huguesdevimeux]

True that the animation doesn't have to be rendered, but the end result of it (the final svg) does. right?

It depends on which animation you are talking about. If the animation is cached, then it should appear on the final video.if the animation is purposely skipped with for example -n, then it should not be on the final video.

[huguesdevimeux]

I think I adressed all the changes requests. Feel free to review !

[cobordism]

True that the animation doesn't have to be rendered, but the end result of it (the final svg) does. right?

It depends on which animation you are talking about. If the animation is cached, then it should appear on the final video.if the animation is purposely skipped with for example -n, then it should not be on the final video.

Not entirely.
If my first five animations are write animations for text, and I render the scene with -n 5, then the text should be visible in the first frame of the output video. i.e. we skip the write animation but we still see the resulting image.

[huguesdevimeux]

I don't think your idea of how partial movie files work is correct.
Partial movie files are basically the final movie cut in several parts, which correspond to each animation (i.e, each play.wait call). So, partial movie file n + 1 contains all the objects that were on the screen at animation n.

Example :

class PartialMovieFiles(Scene):
    def construct(self):
        self.play(ShowCreation(Tex("A", color=RED)))
        self.play(ShowCreation(Tex("B", color=GREEN).shift(DOWN)))
        self.play(ShowCreation(Tex("C", color=BLUE).shift(2 * DOWN)))

Partial movie file for second self.play

As you can see, there is the red A on the screen, at the beginning.

[cobordism]

As you can see, there is the red A on the screen, at the beginning.

then we've been in agreement all along but only just found out :D

[cobordism]

I am not is a position to review the code itself, however I have tested the code and all my compilation errors have disappeared... i.e. the code seems to work :)

The only errors I found was when supplying a -n flag with a number higher than the number of animations in the video. In other words, if my video has 6 animation and I run manim -pl -n 7 then, instead of exiting gracefully, I get the error:

/home/cobordism/Documents/renderings/videos/example2/480p15/partial_movie_files/TestZoom1/partial_movie_file_list.txt: Invalid data found when processing input

and then, instead of stopping, the -p flag kicks in and proceeds to play the previously rendered video that is already in the media dir.

...but since that is a strange edge case for the -n flag, I think that is something we can address another PR

[behackl]

There seems to be some problem with the pipeline on macOS, but these errors are unrelated to this PR.

Good to go!