Trying to make sense of all the tests we did so in case this is helpful for anyone (or it shows how grave this bug is) I’ll lay it all here:
Trying to use the latest Caspar (2.3.3) 1080i50 as a render engine to generate videos with alpha to use in Premiere, we encountered this:
ADD 1 FILE Recording.mov -codec:v prores
Using any iteration of the Prores codecs and pixel formats created a non-valid file: it speeds up (from missing frames I assume) and it doesn’t have a proper alpha channel that NLE like Premiere can use, even though Caspar is able to read the file with alpha, nothing else can.
ADD 1 FILE Recording.mov -codec:v qtrle
The qtrle codec generates a file that has a proper alpha channel but it drops so many frames (and Premiere complains about that when you try to play it) that it’s unusable. This picture is an example of the error: "Error trying to recover frame # "
If you use the ‘interlace’ tag it’s not so dramatic and if your machine is more powerful you get less errors, but there’s always many frames missing without touching the 100% CPU usage by far.
In the two examples above the bitrate (~156Mbps) cannot be changed at all through caspar+ffmpeg tags. It only gets to around half when you add “-filter:v interlace”.
In the end we will have to record the HTML templates by sending them through a NDI consumer and recording them with NDI Studio Monitor, as @markusnygard suggested here, which honestly is a big workaround…
We wait expectantly to see this bugs fixed 