[Cin] vmodule.c and caching of decoded video?

[Good Guy]

Why do we cache?

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.

There is more than one kind of cache.  there are at least three general
caches in use normally.
1) the time line picon data (thumbnails) is cached.
2) file codec input in cached.
3) renderengine results are cached.
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.

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.

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.

gg





On Sat, Mar 14, 2020 at 10:16 AM Andrew Randrianasulu <
randrianasulu at gmail.com> wrote:

> Question:
>
> I was looking at old CinCV repo and found there this commit:
>
>
> https://repo.or.cz/cinelerra_cv/ct.git/commit/1be2d5c765349982fa1d9b72bdcaaa0377fff05f
> r743
> <https://repo.or.cz/cinelerra_cv/ct.git/commit/1be2d5c765349982fa1d9b72bdcaaa0377fff05fr743>:
> Enable caching of frames even when not rendering static frames
>
> diff --git a/cinelerra/vmodule.C b/cinelerra/vmodule.C
>  index 65efb0a..841fb40 100644 (file)
>
> --- a/cinelerra/vmodule.C
> +++ b/cinelerra/vmodule.C
> @@ -235,12 +235,12 @@ SET_TRACE
>
>  // file -> temp
>  // Cache for single frame only
> -                               if(renderengine &&
> renderengine->command->single_frame())
> +//                             if(renderengine &&
> renderengine->command->single_frame())
>                                         source->set_cache_frames(1);
>  SET_TRACE
>                                 result = source->read_frame((*input));
>  SET_TRACE
> -                               if(renderengine &&
> renderengine->command->single_frame())
> +//                             if(renderengine &&
> renderengine->command->single_frame())
>                                         source->set_cache_frames(0);
>
>  //printf("VModule::import_frame 1 %lld %f\n", input_position, frame_rate);
> @@ -306,10 +306,10 @@ SET_TRACE
>                         {
>  //printf("VModule::import_frame 30 %p\n", output);
>  // Cache single frames only
> -                               if(renderengine &&
> renderengine->command->single_frame())
> +//                             if(renderengine &&
> renderengine->command->single_frame())
>                                         source->set_cache_frames(1);
>                                 result = source->read_frame(output);
> -                               if(renderengine &&
> renderengine->command->single_frame())
> +//                             if(renderengine &&
> renderengine->command->single_frame())
>                                         source->set_cache_frames(0);
>  //printf("VModule::import_frame 40\n");
>                         }
>
> cehtehs branch of CinelerraCV
>
> in modern CinGG same function done a bit differently, but still only
> enables caching of single frames. Why?
>
>
> https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/cinelerra/vmodule.C;h=6659dd4529e5305b11a053fc4b9c4b6ee47b9a03;hb=HEAD
>
>  292                         int use_cache = renderengine &&
>  293                                 renderengine->command->single_frame();
>
> search for more instances of use_cache ....
>
> Of course there might be some bug somewhere preventing  such usage -
> but I really like to see this commented, then ...
>
> Ah, it was  disabled again in
>
> https://repo.or.cz/cinelerra_cv/ct.git/commit/c8d7b9183ac263d540ccbc15b125fc7aaad65311
> (part of big 2.1 merge)
>
> I wonder what will hapen if I enable this .. :}
> Something else to try ....
>
> As far as I understand, anync decoding  by itself also disabled in CinGG,
> looking at same module?
> But even normal decoding still may leave few frames around, and Cin may
> reuse them,
> for example for backward playback, no?
>
> Having some clarification about  what each mode was supposed to do at the
> top of file will be great ....
> Unfortunately, I don't understand Cin enough for making those top
> comments.. I think.
> This idea  obviously can be low priority - just add new module comment
> each time you edited
> said module ..so, after some time thwy all will contain brief description
> of their functions
> and quircks/historical artifacts, I think
>
> PS; I spend a lot of time trying to debug this bc2000 playback crash - so
> yes, threading is
> not as simple in impl as I made it on (virtual) paper .. :/
>
> --
> Cin mailing list
> Cin at lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20200315/bba1ff91/attachment.html>