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

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.

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.

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 :

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)

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 ?

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.

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" ?