# Accessing cues using [position] to <jit.movie> weirdness

Jitterbeginner

chapelier fou
Mar 16 2023 | 1:50 pm
Disclaimer : video is not my usual domain, so I might lack some basic knowledge.
But still, I'm working on a project where I need no be able to cut video loops into 16 equal slices and access to these slices with accuracy. So I made a video loop displaying numbers from 0 to 16, equally spread in time to work it out. In my example, it displays numbers from 1 to 14, then pauses for 2 ticks. Why is this happening ?

• Source Audio
Mar 16 2023 | 2:50 pm
Your video example has 63 frames, this is frames and what they show : in coll format, index is frame number, data is the number shown. 0, 1; 1, 1; 2, 1; 3, 1; 4, 2; 5, 2; 6, 2; 7, 2; 8, 3; 9, 3; 10, 3; 11, 3; 12, 4; 13, 4; 14, 4; 15, 4; 16, 5; 17, 5; 18, 5; 19, 5; 20, 6; 21, 6; 22, 6; 23, 6; 24, 7; 25, 7; 26, 7; 27, 7; 28, 8; 29, 8; 30, 8; 31, 8; 32, 9; 33, 9; 34, 9; 35, 10; 36, 10; 37, 10; 38, 10; 39, 11; 40, 11; 41, 11; 42, 11; 43, 12; 44, 12; 45, 12; 46, 12; 47, 13; 48, 13; 49, 13; 50, 13; 51, 14; 52, 14; 53, 14; 54, 14; 55, 15; 56, 15; 57, 15; 58, 15; 59, 16; 60, 16; 61, 16; 62, 16; 63, 16; (last frame light red color) ------- You were better off with 16 frames and counter recalling frame by frame. your position float makes no sense at all.
But , that is advice for this specific case, where you display pictures and not really video.... If you really were up to slice larger video into 16 equal slices, then it is another story.
Share
• Rob Ramirez
Mar 16 2023 | 3:06 pm
unfortunately viddll engine still has some issues with h264 files, especially accessing the final frames. The easy workaround, especially for your case usecase of accessing frames on demand, is to make sure that playback is stopped when accessing these frames. So add the argument @autostart 0 to your jit.movie object. Doing that allowed me to access all the frames using your technique.
• chapelier fou
Mar 16 2023 | 3:08 pm
Thanks.
At first, I don't think you're right, as [position] is a between 0. 1., normalized to the whole file length. It makes perfect sense to me (and works).
Then, yes, I plan to make this on video, with variable playing rates. Following patch appears to work quite nicely :
• Rob Ramirez
Mar 16 2023 | 3:22 pm
cool, yes avf player doesn't seem to suffer the same h264 issues as viddll. another workaround for viddll is to load the last second or so into memory with loadram -1 message (ensuring you have enough cache to do that via the cache_size attribute)
• chapelier fou
Mar 16 2023 | 3:28 pm
Thanks @RobRamirez Good to know that it's a known issue. To be honest I have no idea why I should use viddll or avf, I don't even know what it is. I firstly tried viddll as as was working with .gif files, but I think that making .mov files instead of .gif files with a rate of 0 is perfectly viable for my use. Does loadram (not available with avl) really make a difference on a macbook pro with an SSD, with reading files less than 10MB ?
• Julien Bayle
Mar 17 2023 | 6:35 pm
You can probably find some references post related to my project FRGMENTS: https://julienbayle.net/works/frgments/ Example: (actually not the best one as there are massive glitches, but we had a total control on retrieving THAT frame if we wanted that) https://vimeo.com//242240872 We had shot videos of people rotating in the studio We wanted to be able to retrieve EACH frame precisely. Combination of loadram, hap etc gives us that.
• chapelier fou
Mar 18 2023 | 3:51 pm
Thanks Julien. Still a few things to figure out. For instance, [frame \$1] works really really bad ([frame_true \$1] on the other hand is accurate). What do you mean by "some references post related to my project FRGMENTS" ?