capture to disk - quality?

[inst]

Hi,
I would like to create out of my video manipulation processes in Isadora a short movie.

What ist the best quality setting for a FUll HD video capture in Isadora?

thanks for any help on this.

[Woland]

@inst said:

What ist the best quality setting for a FUll HD video capture in Isadora?

 Can't go wrong with 1920x1080

[inst]

yep. But what format qouöd you vhoose to capture on disk?

Thanks

[bonemap]

Hi,

I am going to assume your question is about compression quality of a rendered video coming out of Isadora. It is my understanding that the HAP codec, which is newer than many of the other options available from Isadora (Output>Compression Settings... ) is the one you want. There are a number of HAP options and information in this link might help you decide the most appropriate codec to select for your purpose...

Best Wishes

bonemap

[inst]

@bonemap
Hi,
yes I know the HAP format. All the video I import to Isadora are in HAP. But the other way around, if I want to export by capturing to disk my manipulated videos there seems to be no HAP option - see image below.
May be I should choos as compression style just ´none´ (´keine´ in german) there I get a .MOV that Premiere CC can also read.

[bonemap]

@inst said:

May be I should choos as compression style just ´none´ (´keine´ in german) there I get a .MOV that Premiere CC can also read.

Hi,

It makes sense that no compression 'none' is going to be better quality than a codec that applies compression. For your reference This is the list I get for exporting video... I don't have an option for 'none' ... but I wish I did! I would like an option for PNG and TIFF image sequence as well!

Best Wishes

bonemap

[mark]

@inst

Your best bet is to choose Apple Pro Res if it is available on your comptuer. (It's not built in; other apps supply it like Final Cut Pro.) You should definitely *not* choose HAP for capture to disk, nor MP4 or H264 because the amount of CPU power required to compress those formats will almost certainly impact performance of your patch. If you don't have Apple Pro Res, then use Photo JPEG. It is the most lightweight in terms of using up your CPU when capturing to disk.

In Isadora 3 coming for this  September, this capture engine will be rewritten, and you might be able to get away with H264 then. But before that, follow the advice above.

Best Wishes,
Mark

[bonemap]

@mark said:

You should definitely *not* choose HAP for capture to disk, nor MP4 or H264 because the amount of CPU power required to compress those formats will almost certainly impact performance of your patch

 Great to have that insight. And what about the 'non-realtime' rendering settings? Is there any trick to determining the Render Speed percentage in relation to fps assuming that a patch is running less than the desired realtime frame rate?

Best Wishes,

bonemap

[inst]

@mark 

Thanks too for that tip.- Unfortunately I am on Windows 10 and have no prores codec.
I saw there is a encoder https://windowsprores.com/ but I am not if this is worth buying (180$) and if it brings so much more quality to the captured files.
So I think I´ll stay with photo jpeg for now. 

[DusX]

I recently started using OBS Studio to capture from Isadora (after using it for my latest tutorial).
I found its implementation of Hardware encoding is very good. It will encoded high quality H264 on the video card in real-time with nearly zero cpu hit.
Additionally, it seems that Hardware encoding doesn't drain resources from the GPU in a way that effects Isadora's usage (this needs more testing but appears correct, in Task Manager the processes are labelled as 'Encoding' for OBS and 3D for Isadora, and GPU-z reported no real change) 
On my system with nVidia graphics, I select output/encoder = Hardware (NVENC)
Of course, running another app also means this is handled in another thread/process.
I have been able to capture at 1080p 30fps, without effecting Isadora's frame or cycles rates (there may be a frame lost at the start of recording).

This is not a solution for realtime integrated systems, but for capturing high quality stage recordings for use in other projects its pretty great.
Especially when you have the project 'just' running at your target framerate.

In the end it depends on what you are trying to accomplish.

[bonemap]

@dusx said:

it depends on what you are trying to accomplish

Thanks Ryan,

I have lately had commissions for animation productions with workflow using DragonFrame and AfterEffects. The Render format from these has been TIFF image sequences that can then be brought into Premiere as footage for the final assembly edit and then output file compression. I have optioned to use Isadora for efficiency reasons particularly generating particles for these projects. I am struggling a bit to wrangle an understanding of Isadora's non-realtime rendering output options.

OK lets assume that the Isadora patch is not running anywhere near the target frame rate for realtime application. Instead, Isadora is being used to generate source material for another non-linear composition process, as indicated above. I make the assumption that the options available to capture the stage output at a percentage of speed less than the target frame rate (this is under the Output.. Capture Stage Settings.. Non-Realtime Rendering) are there to allow a rendering process that will produce an output file at the full target frame rate without dropped frames. Is this assumption correct? If this is the case a file with the least amount of compression and options for +alpha are going to be whats needed. Would you suggest the Animation codec? does that output alpha or is there another option?

Best Wishes

bonemap

[mark]

@bonemap said:

Is this assumption correct?

 Yes. That's right. If you choose a render speed that is < 100%, every time based function in Isadora is slowed down proporionally (i.e., Wave Generators, Envelope Generators, Trigger Delay, et. al.) This gives Isadora more time to generate every frame and thus should result in full and accurate frame rates. The only caveat is that you cannot have real-time input because it is not slowed down proporionally.

Best Wishes,
Mark