Unusal high Cooktimes for MovieFileInTOP

Bugs
1

Diving deeper in to timecode and how to use it to drive stuff I came up with the following, relatively simple setup using the timerCHOP. DemoFile attached at the bottom.

Segments-Table in to a timerCHOP in to a moviefileinTOP. (The infoDat workarround is fixed in the current release.)

grafik
grafik2503×967 224 KB

And I am suprised how simple this setup is.
In my current setup I use a external driver for my timerCHOP. As there currently is a bug with acumulating cookTimes when the external driver is longer then the driven timer, I simply appended a long last segment which is empty.
Only issue is that the movieFileInTOP has a huge spike in cooktime when reaching the last “empty” segment.

WHile operation everything fine:

grafik
grafik2124×691 135 KB

The last, empty segment we jump to almost 1 ms.

grafik
grafik1185×661 73.7 KB

In another instance of the project itself this can even result in reported cooktimes of up to 3ms

grafik
grafik1017×594 66.8 KB

movieFile_HighCooktimes.tox (2.5 KB)

2

I wonder if maybe this is because the python expression isn’t optimized.

image

re-evaluating the expression once per frame might be creating a drag.

i built a very small setup that evaluates to no file but stays optimized and the cook time is much lower (attached)
optexpr_moviePlayback.toe (3.7 KB)

3

If it would be the expression that is slowing it down it should also be as slow when there is a value to be evaluated, which is not the case. As long as there is a file that is displayed, everything works totaly fine.

For now I will just give it a 1x1 transparent TIFF instead of an empty string.

grafik
grafik1417×701 105 KB

4

Totally,

Even if it’s not the issue here, it’s interesting to me that the ‘segment’ member of the timer class can’t be optimized. I modified your externalTimer example to get an optimized expression into the moviefileinTOP and the idle load actually got slightly worse :roll_eyes: .

movieFile_HighCooktimes.fm.toe (5.5 KB)

i’m going to keep that transparent TIFF hack in my back pocket. thanks for sharing.

edit: i did some further tests with using the ‘segment’ output channel rather than the class member, and it seems like the issue is related to evaluation of ‘segment’ in some way. if you use nulls to check needless cooks on the referencing CHOPs the moviefileinTOP stops cooking altogether. from a performance standpoint that seems like an overall win since you only evaluate the segment when it changes, rather than doing so every frame.

5

hey, for me its segment 2 thats higher cook time. its also different codec.first two ar stills tiff and jpeg container, third file is h.264 and mp4 container… could that be the case?

I had expreience with significant rise of cook time with mp4 containers before.

also since its segments, I did a prototype implementation of playlist behavior expliting segments, however encountered some weird behavior when got to solving seeking logic, goTo function did not really work properly when more then 1 segment … was busy times so moved to handle this with single timer and outside logic… maybe its relevant to you now…

I will also chk again as missed to report bk then

6

Hi @alphamoonbase,

some combination of not being able to open the file and an always cooking reference as shown by @flowb - eventually it goes down - as if there is another timeout additional to File Open Timeout? we’ll have a look…

cheers
Markus