Export Video is Choppy

Thanks for you quick reply Raganmd!
I was using the export dialogue from the file menu, it does not seem to care whether the real-time check box is flagged or not it still insists on playing while exporting.

What’s your codec setting?

I have just tried it with all codec options with the same result. Very choppy playback while exporting and a mangled output file. It is important to note that what I am doing with the network is so processor intensive that it would not even play at all. That is why I was hoping to capture it to a file. If your work is limited by real-time capabilities then the limit for what you can achieve with the software is much lower.

Hmmm.

It’s hard to diagnose what’s happening here - I pretty regularly render out test files at large resolutions… both that run in reatlime, and ones that don’t. Any chance that you’re using a variable like absTime.seconds or absTime.frame in your project somewhere?

Basically what I am doing is having a video with its cue position controlled by audio data. The audio data converts to DAT then back to CHOP before driving the video cue. With view to altering mathematically the DAT. The question on my mind now is… is touch supposed to do real-time playback while exporting to a file and when it is exporting to the file is it saving it to that file like any conventional video editor or is it streaming the real-time content to the file along with its performance problems. I have managed to export a simpler network without problems but as soon as the real-time shows any level of strain, so does the output file. This suggests that it is indeed streaming the content to the file in real-time rather than saving it conventionally and I really can’t understand why that would be useful when exporting projects. Perhaps this is just the bugs you would expect to see from a beta application. Which begs the question, why the price tag?

Time references are especially tricky here for slow processes.

me.time.frame or me.time.seconds will lock to the timeline and should provide the right increment for non-realtime rendering. Similarly, a speed CHOP or timer should increment correctly for sequencing frames.

Could be some other tricksy bits here as well with respect to time. :confused:
I’d be happy to look over your toe file if you want another set of eyes on tracking down the issue.

If the realtime flag is on the file will be streamed to disk.

If the relatime flag is off then each frame completes before being added to the file.

The movie export dialogue will automatically turn off realtime during export, then turn realtime back on when complete.

The touch environment itself is really a large openGL context. You can disable rendering for the environment with the ui class:

ui.redrawMainWindow = False

derivative.ca/wiki099/index … e=UI_Class

This, of course, will make it appear as though touch isn’t responding… when in fact it’s just not drawing. While this could be enabled for the export process it would look to the user like the entire application was frozen.

You can certainly do this yourself if you want to write an export function with a timer, but you’d need to do something like:

turn off realtime
disable redraw
turn on the movie file out TOP

when the process completes

turn off the movie file out TOP
enable draw
turn on realtime

For your use case, you might first try changing your audio file in’s play mode to “locked to timeline” rather than the default “sequential.” This should ensure that your audio file is bound to frame time… though I suspect that might still present issues, but is worth a try.

Ahh nice… Thanks for digging that up. I will give that a try. I am keen to have the software full fill my expectations any way that is achieved because I am quite fond of the work flow and possibilities. Is it likely that these things will be fixed in the next version? You really should be able to have it export to a file quietly and correctly.

With the presence of Python as a scripting language, you can make Touch behave in nearly any way you’d like… the catch here is that it’s often the responsibility of the programmer to determine what that behavior looks like.

With respect to the sequential par… if it was default locked to timeline, then any given loaded file would only play as long as the timeline (10 seconds in a default project). That would be great for your particular use case, but wouldn’t be ideal for the programmer / artist just wanting to play a full audio file. The same behavior carries over to the movie file in TOP - which is also set to play sequentially by default. From a timeline perspective it might make sense to bind playback to the project time, but if you wanted a file to just free play it would look like the application was not behaving as expected.

All that to say that sometimes one person’s bug is another person’s feature / expected behavior when it comes to programming.

Here is an analogy. It is the most exciting chair in the world but you can’t really sit on it. I will look out for versions beyond 1.0 and perhaps by then it will be something I can justify adding to my work flow. Thanks for your help.

TouchDesigner is a development environment. While it comes with a lot of prebuilt tools and helpful functionality, it’s essentially software development and you need to learn to operate the system before you can really get much out of it. It’s less of a chair and more of a rocket ship, and if you don’t know how to operate a rocket ship, sitting in it’s chair isn’t going to do much except disappoint you.

I wouldn’t place offline rendering on the first few things to do, because there can be a lot of moving parts. Like Matthew mentioned, I’ve also made very high res and intensive offline renders, you just need to become more familiar with the tool. I didn’t go through the full thread but I think Matthew mentioned most of the things I’d bet that it was. Turning off realtime, locking your control channels to the timeline so that they consistently reproduce same results, etc.

If you give it some time Im sure you’ll actually become quite happy with TouchDesigner. TouchDesigner is stable, powerful, and used in 24/7 commercial environments, so it’s quite far beyond 1.0.

In my experience with TouchDesigner and other programming/development environments,
the best solution to record your video in real-time is to have an external capture device; you can find a lot from pretty cheap PCIe interfaces with HDMI input, to very expensive players/recorders often used in broadcast or similar.

Even though, as raganmd pointed out, TD offers pretty cool features to record your stuff in real-time.
My favourite is to use h.264 on the GPU with high bitrate; you can easily record 2k/60fps with nerly lossless quality (not properly lossless like ProRes or DNxHD quality…but doable).

Obviously you need a good GPU and the best quality achievable is closely related to stuff you have in your GL scene.

If you’r aim is to have uncompressed videos, the best solution is to save money for a good device or find someone which can rent you one of those machines.

Hope I was helpful,
cheers

It is still unclear to me. Does touch designer rely on real-time capture of itself to write to a file and if so is there a way which I can export to a file while offline. The wiki says that it can but I am not seeing it because every time I render I am seeing it play. I would like to try the previous suggestion of changing the ui.redrawMainWindow setting to false but I can not find this with the search. Can you tell me where this setting is so I can try it as disabled?

Yes and No.
If the realtime flag is on, yes.
If the realtime flag is off, no. The UI will still render, but each frame will complete before writing to disk. This does not, however, mean that there will be no stutters in your file. You must take careful precautions to ensure that all elements are driven by frame time rather than free running. Operators that read files are often set to “sequential” allowing them to free play without being bound to the projects timeline.

The redraw command is not a setting, it’s a method called via Python.
In order to take full advantage of the:

ui.redrawMainWindow = False

You need run this command either from the TextPort or from a text DAT. This requires a familiarity with how Python works in the environment, and how to leverage script based operations in your workflow. Be advised that just running this command will place touch into a state that appears non-responsive. The UI will no longer refresh, and while touch will continue to run, you will no longer be able to interact with it through the UI. It is therefore important to consider how you want to solve this problem either by using a keyboard shortcut to re-enable draw, or to to use a callback operation.

Thanks Raganmd. I will give that a try first thing tomorrow. I appreciate you going out of your way to help.

Hi Splicebyte, Matthew is correct that turning off the realtime flag (like the Export Movie dialog does automatically) should allow you to do this as every frame is completed in its entirety before it moves to the next frame. However, you could be running into some other strange timeouts in your system as you described it as very CPU intensive. How long does each frame usually take? Usually TouchDesigner is tested against running at very fast frame rates so you might have uncovered a bug or incompatibility with your hardware when running extremely slowly. Also, graphics drivers often time out if they do not update the frame after a certain time, you might be running up against this. Is your .toe file light on media and thus easy to share? If its private then you can send it to support and we might be able to spot something obvious.

TouchDesigner is a realtime engine, so it must calculate every frame as it steps through to write to a movie. It does not cache or store the sequence, the data is calculated at each step.
Its sort of like trying to record a video game to a movie without actually playing the game, realtime engines need to play through.
But the realtime flag off should be all you need to do this as we mentioned before. If you have a frame calculation time of many-many seconds, I have a hunch it is the graphic driver timing-out.

Thanks for investigating Ben. Just to start off I have recorded with OBS what is happening so you can watch it play out. It is important to note that this same thing occurs without OBS so OBS is having little to no influence on the situation. This is showing that my hardware is not struggling. If you know what I mean. I have a Quadro K4000 that is a few years old but is definitely capable of what I am trying to do. The other specs of my system match the level of this card. Firstly the audio glitches out whenever I scrub any video which is not even connected to the audio in the network. When the audio has relation to the videos cue point it naturally glitches out even worse and then when I output it to file it gliches out during the export and finally when I look at the finished product it is glitching out as well. What I am wanting to do is slightly intensive, a bit of an ask but certainly not too much for my hardware. Really with everything said previously no matter what the intensity of the network the export results should not be affected. You surely would have to agree with me here. splicebyte.com/Touch/touchproblem.mp4

I think i’m having the exact opposite problem, i have a very simple file which takes a sound file and generates some basic visuals. i records fine when i have it on realtime and just manually play the file and hit record on the movieOut TOP, but when i do file-export movie and it takes realtime off, it hammers through it super quick and the sound and video gets really glitchy?

windows 10, 7900x 1080ti
stable release build

I"d like to be able to use the ‘export movie’ so that its nice and reproducible?

Should there be a cap on the frame rate now that computers are outrageously fast?
concreteImpermenence.toe (47 KB)