--disable-headless does not seem to work

[doxsch]

Bug Report 🐛

Hi everyone

I have tried to render the helloworld sample video in non-headless mode. This is to investigate a problem with the <IFrame> component. (more on this later, I will open an issue about this)
I noticed that --disable-headless does not seem to work. After sending the render command remotion render --disable-headless HelloWorld out/video.mp4 the browser window opens but closes immediately and the render process gets stuck.

Can someone verify this or is there something wrong with my installation?

Best regards

[JonnyBurger]

The render process happens in two stages: In the first one, we calculate the metadata of the composition (duration, dimensions etc.)

Then the browser tab (not the browser itself though) closes and more should be opened. It seems like something gets stuck inbetween.

Do you have a big input props payload? This could lead to this taking a while.

It seems like the disable-headless flag is not broken per se, so I would need a sample project which has this bug in order to investigate.

[doxsch]

I have only created a new project with npm init video and selected the "Hello World" template. I got the same behavior there. I therefore think that it has nothing to do with the input props.

[JonnyBurger]

Sorry this is happening to you.

However, given with this information, I cannot reproduce. Creating a new video on macOS with npm init video and then running npx remotion render --disable-headless does open the browser twice and keeps it open during the video.

Maybe you can elaborate more on your environment (OS, browser).

[doxsch]

Thank you for your efforts.

I am currently working on windows 10, this may have an impact. I have tried both the default browser (Thorium) and Chromium. For both the same behavior:

remotion render --disable-headless --log=verbose  HelloWorld out/video.mp4
Remotion root directory: D:\dev\my-video
Applied configuration from D:\dev\my-video\remotion.config.ts.
Checking if HelloWorld is the entry file
Selected D:\dev\my-video\src\index.ts as the entry point because file exists and is a common entry point and no entry point was explicitly selected
 openBrowser()  Opening browser: gl = null, executable = D:\dev\my-video\node_modules\.remotion\.thorium\win64\BIN\thorium.exe, enableMultiProcessOnLinux = false
Bundling 6%
 chrome  [23428:14248:0110/214733.863:ERROR:policy_logger.cc(154)] :components\enterprise\browser\controller\chrome_browser_cloud_management_controller.cc(163) Cloud management con
troller initialization aborted as CBCM is not enabled.

DevTools listening on ws://127.0.0.1:2896/devtools/browser/9b472317-3248-44df-be35-25c091412f03
Bundling 19%
Bundling 62%
Bundling 69%
Bundling 74%
Bundling 80%
Bundling 85%
Bundling 90%
Bundling 95%
Copying public dir 0 B
Copying public dir 0 B
Bundling done in 1072ms
Copying done in  0ms
Getting compositions
Bundled under C:\Users\doxsch\AppData\Local\Temp\remotion-webpack-bundle-W6rw3q
Created directory for temporary files C:\Users\doxsch\AppData\Local\Temp\remotion-v4-0-84-assetsgmwkutq5l8
 compositor  Starting Rust process. Max video cache size: 2596MB, max concurrency = 4

...and then the browser window closes and it gets stuck.

[JonnyBurger]

I can confirm it doesn't work on Windows. I don't know why though.

We are going through some changes #3565 and I'll see if we can tackle it in the same go.

[JonnyBurger]

In the future Chrome will completely separate the headless mode out of Chrome.

Chrome will not have the --headless flag anymore (actually it is being repurposed into --headless=new, a different version of what we are using now, but they are not recommending it for our usecase)

The current headless mode is being extracted into Chrome Headless Shell, which we will have to start using going forward. This one will not allow disabling headless mode anymore - therefore in the long-term we will not be able to support this flag anymore.

[JonnyBurger]

Keeping the issue open because this needs documentation