<div dir="ltr"><div>Why do we cache?</div><div><br></div><div>The caches are short term memory for various operations that may need to be repeated in a short time domain.  The need fo repeat the frame result may vary depending on the situation.  For example, if you are editing and trying to explore the effect of a plugin or auto tweak, then the cache is of little or no value, since you are exploring new data on every single frame render.  Or, maybe you have seen all of that, and are now interested in the continuous playback, and now those cache frames are very interesting.  It just depends on your intent.  Usually, singe frames are not so expensive that they can not be rendered quickly enough, and continuous playback is helped by caching since you may be reviewing the aggregate result.</div><div><br></div><div>There is more than one kind of cache.  there are at least three general caches in use normally.</div><div>1) the time line picon data (thumbnails) is cached.</div><div>2) file codec input in cached.</div><div>3) renderengine results are cached.</div><div>The vrender operation is reading the cache from the renderengine.  This generally helps, like when the asset is single frame, like a png file being repeated for 3 seconds.</div><div><br></div><div>All of the caches need to be purged or expired as time and changes demand cache reconstruction.  The item being removed is usually called a victim.  This vernacular is not widely used in cinelerra, but is normal for cpu and hw cache designs.  The heuristic used to select the next victim is not always last in first out.  A common variant is to include access frequency and item costs as factors in the decision. Hardware usually evicts entire cache lines and reloads memory with cache load bursts, but  in clnelerra the base algorithm is just to claim the oldest (least recently used) item.</div><div> </div><div>file.C (read_frame) for codec input, resourcepixmap.C, resourcethread.C  are the basic cinelerra routines involved in picon caching, and a/vmodule use the renderengine caches to access previous/current frame output.</div><div><br></div><div>gg</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 14, 2020 at 10:16 AM Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Question:<br>
<br>
I was looking at old CinCV repo and found there this commit:<br>
<br>
<a href="https://repo.or.cz/cinelerra_cv/ct.git/commit/1be2d5c765349982fa1d9b72bdcaaa0377fff05fr743" rel="noreferrer" target="_blank">https://repo.or.cz/cinelerra_cv/ct.git/commit/1be2d5c765349982fa1d9b72bdcaaa0377fff05f<br>
r743</a>: Enable caching of frames even when not rendering static frames<br>
<br>
diff --git a/cinelerra/vmodule.C b/cinelerra/vmodule.C<br>
 index 65efb0a..841fb40 100644 (file)<br>
<br>
--- a/cinelerra/vmodule.C<br>
+++ b/cinelerra/vmodule.C<br>
@@ -235,12 +235,12 @@ SET_TRACE<br>
<br>
 // file -> temp<br>
 // Cache for single frame only<br>
-                               if(renderengine && renderengine->command->single_frame())<br>
+//                             if(renderengine && renderengine->command->single_frame())<br>
                                        source->set_cache_frames(1);<br>
 SET_TRACE<br>
                                result = source->read_frame((*input));<br>
 SET_TRACE<br>
-                               if(renderengine && renderengine->command->single_frame())<br>
+//                             if(renderengine && renderengine->command->single_frame())<br>
                                        source->set_cache_frames(0);<br>
<br>
 //printf("VModule::import_frame 1 %lld %f\n", input_position, frame_rate);<br>
@@ -306,10 +306,10 @@ SET_TRACE<br>
                        {<br>
 //printf("VModule::import_frame 30 %p\n", output);<br>
 // Cache single frames only<br>
-                               if(renderengine && renderengine->command->single_frame())<br>
+//                             if(renderengine && renderengine->command->single_frame())<br>
                                        source->set_cache_frames(1);<br>
                                result = source->read_frame(output);<br>
-                               if(renderengine && renderengine->command->single_frame())<br>
+//                             if(renderengine && renderengine->command->single_frame())<br>
                                        source->set_cache_frames(0);<br>
 //printf("VModule::import_frame 40\n");<br>
                        }<br>
<br>
cehtehs branch of CinelerraCV<br>
<br>
in modern CinGG same function done a bit differently, but still only <br>
enables caching of single frames. Why?<br>
<br>
<a href="https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/cinelerra/vmodule.C;h=6659dd4529e5305b11a053fc4b9c4b6ee47b9a03;hb=HEAD" rel="noreferrer" target="_blank">https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/cinelerra/vmodule.C;h=6659dd4529e5305b11a053fc4b9c4b6ee47b9a03;hb=HEAD</a><br>
<br>
 292                         int use_cache = renderengine &&<br>
 293                                 renderengine->command->single_frame();<br>
<br>
search for more instances of use_cache ....<br>
<br>
Of course there might be some bug somewhere preventing  such usage - <br>
but I really like to see this commented, then ...<br>
<br>
Ah, it was  disabled again in<br>
<a href="https://repo.or.cz/cinelerra_cv/ct.git/commit/c8d7b9183ac263d540ccbc15b125fc7aaad65311" rel="noreferrer" target="_blank">https://repo.or.cz/cinelerra_cv/ct.git/commit/c8d7b9183ac263d540ccbc15b125fc7aaad65311</a><br>
(part of big 2.1 merge)<br>
<br>
I wonder what will hapen if I enable this .. :}<br>
Something else to try ....<br>
<br>
As far as I understand, anync decoding  by itself also disabled in CinGG, looking at same module?<br>
But even normal decoding still may leave few frames around, and Cin may reuse them, <br>
for example for backward playback, no? <br>
<br>
Having some clarification about  what each mode was supposed to do at the top of file will be great ....<br>
Unfortunately, I don't understand Cin enough for making those top comments.. I think.<br>
This idea  obviously can be low priority - just add new module comment each time you edited <br>
said module ..so, after some time thwy all will contain brief description of their functions<br>
and quircks/historical artifacts, I think<br>
<br>
PS; I spend a lot of time trying to debug this bc2000 playback crash - so yes, threading is <br>
not as simple in impl as I made it on (virtual) paper .. :/<br>
<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>