Video Scrub

Hi there,

What’s the best and most efficient way to playback a video by explicitly setting the index, whether that’s moving forwards or backwards?

Using a video (h264 quicktime) and setting it to specify index mode and with a sin function driving the index, makes touch designer skip frames every now and then, as I am guessing it has to decode the video before jumping into that specific frame.
Is it just a matter of using a more appropriate codec/format for the video?

Last night I was trying to achieve this using a texture3D TOP, thinking that if I have all the frames cached out it would be much faster to do display any of the frames on demand. But with that, how can I go from a texture3d back to one frame?

thanks

Playing videos backwards is difficult, Ive never had any luck with it, although some people mention using Animation codec to get some results or Photo JPEG.

I’d put your clips on an SSD and give those two plus HAP a try and see which gives you best results with quality.

Yeah backward isn’t the best in Touch.

I do have a couple of different glitchers/loops though based on the tex3d and cache TOPs. Cache is simpler to deal with. Just connect and input and set the number of frames to store. If you want precise scrubbing then turn it off before changing the index.

cheers
Keith

the cache node can do the job. But as Keith mentioned I have to switch it off before scrubbing.

thank you for the input
georgios

I’ve been trying to get this working with cache TOP, but it turns out more like a crash TOP… I noticed however that the moviein TOP has a “Pre-Read Frames” parameter that seems to do the same job. With Pre-Read Frames, I am able to smoothly scrub the moviein TOP’s index directly, skipping cache TOP. This is only a 150 frame test clip however. I am wondering if there is a reason to use cache vs pre-read. I intend to scrub much longer slow-mo videos. Similar idea: [url]https://vimeo.com/18499643[/url]

Most discussions of this topic that I’ve seen recommend cache TOP, and some even advise against Pre-Read Frames, ([url]http://www.derivative.ca/Forum/viewtopic.php?p=23267#p23267[/url]), but I just can’t seem to set up the cache without a crash. I’ve been trying to get it, but must be missing some crucial, maybe-esoteric, detail. This is my first real TouchDesigner project beyond playing around, so I haven’t learned many of the tricks/tropes in this environment yet. (Coming from Quartz Composer world…)

If relevant: Running Touch 088 64bit in Win8.1Pro on a BootCamped 15" retina MBP.

Thanks for the info thus far,

_Will

I believe its because you can only pre-read frames forward in time. Codecs aren’t designed to pre-read frames backwards, so when you scrub backwards you’re basically decoding from scratch everytime you move the playhead. Whereas if you use the Cache TOP, you can make a reservoir of backwards frames.

What kind of crash are you getting? Can you remake the setup of it crashing and post it?

Thanks for that info, more important for us is which build you are using? Is it easily reproducible? If the crash creates a .dmp file, please send to support@derivative.ca and we’ll try to find the cause of it.

Thanks again

for what its worth here, you definitely dont want to use a standard flavor of h264 as it compresses video frames temporally, so scrubbing forward / backward is difficult since only the keyframes (or whatever h264 calls them) contain a full frame of information. As Elburz mentioned you’ll want to go with something more like photo-jepg which basically only compresses the details within a frame, not across time, so you should see decent performance (but larger files). I think there may be a way to enable ‘intra frame only’ compression within H264 however but I havent tried or fully looked into it. I suspect you’ll end up with rather large files similar to photo-jpeg. not sure about HAP…

Thanks for the replies, and sorry for delay on my end. Busyness is the business.

Build 13370. Having trouble finding .dmp filepath… noob problems. I’m at a gig right now (using OSX), but I’ll try to recreate the crash and upload that and .dmp files ASAP.

I’m still confused as to the difference between pre-read and cache. Seems like both decode the video into individual frames and store in RAM. I’ve been trying with HAP and PJPEG, but confused why that would matter if the frames are indeed decoded and stored in RAM. I’d be scrubbing the frames in RAM, not the file, right?

Thanks Again!

Two different pre-read parameters people are talking about:

One is on the moviein TOP (pre-read Frames). This is where the codec counts for being able to play the “movie file” backwards. Has nothing to do with the cache TOP. I’ve found HAP play’s decently backwards (still not perfect) as well as animation codec (big hit on disk space and bandwidth though). I found setting this to zero helps with backwards playback. The purpose of the moviein pre-read frames feature is to have a small buffer of frames in memory so if the file reader misses a frame because of a disk bottleneck then the moviein doesn’t miss a frame.

The pre-read on the cache TOP is a feature that will load a bunch of frames into GPU memory and will allow you to scrub those frames backwards or forwards (in the cache TOP). It will load the number of set frames (of a moviein TOP) into memory and you are correct, the codec will have nothing to do with the performance of this method (except for how long it will takes to do the pre-read)

I’ve also found the pre-read on the cache TOP to be buggy in the past and have seen it cause crashes. The dump file if it exists will be in your projects folder.

cheers
Keith

The hippotizer guys swear by MPEG2 for scrubbing & reliable playback, its a good choice if you encode with I-frame only

I would of thought their new directx GPU based(DXV,HAP,AIM) codec would be the new standard.

I remember mpeg2 was also quite good for serato video. Gotta admit I haven’t really used it much.

I believe they are in the process, or already have switched to Flex, which is their own propriety codec. It was in development they showed me, but they said it will be available as a quicktime component in the future, which hopefully is good news for compatibility.