microsoft / playwright

Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
https://playwright.dev
Apache License 2.0
64.26k stars 3.49k forks source link

[Feature] disable video creation after context/page creation #4821

Open LanderBeeuwsaert opened 3 years ago

LanderBeeuwsaert commented 3 years ago

Let us know what functionality you'd like to see in Playwright and what is your use case. We use video creation in playwright in our CI environment to easily see what went wrong if a test fails. so during context creation, we do:

if (this.createVideo) {
  context.recordVideo = { dir: this.storageUploadPath };
}
this.context = await this.browser.newContext(context);

However, we are only interested in the video if the test actually went wrong. If the test went well, the creation of the video on page/context close only takes (quite a lot) of time away that's not useful. It would therefor be useful if we could change the setting just before page/context close to say that "nah, don't create a video anyway"

Do you think others might benefit from this as well? I would think so.

mxschmitt commented 3 years ago

Which test runner are you using? Seems for me that this makes more sense to be implemented in the user land. It wouldn't bring any performance benefit during the test, since it needs to record it anyway and if a test fails, it stops. If you are using playwright-test - playwright official test runner - you would be able to implement such a logic yourself or file an issue that it gets integrated into the project like the screenshotOnFailure functionality.

It's mostly about deleting the video files when the tests are passing if I understood it correctly. A videoOnFailure functionality in the playwright-test project sounds like a great idea.

LanderBeeuwsaert commented 3 years ago

Hi, thanks for the reply, Well in one project we're using playwright-jest but in the other we're using vanilla playwright (we want more control there to have a pool of contexts running in parallel to speed up the testing --- it gives us a x5 increase ATM).

What we've noticed is the following:

  1. during the test, ffmpeg is creating the frames, and this increases the CPU load significantly; but doesn't slow down the test execution. As you say, indeed, this can't be eliminated anyway.

  2. After the test, on context close (or page close, I'm not sure) the video file is built from the recorded frames. This takes A LOT of time, +- the same amount of time as the test itself, and I suppose a lot of CPU and disk read/writes. All this is CPU & Disk load that could be avoided by being able to cancel creation of the video just before we close the context/page. => deleting the file after creation would not work as a solution for this.

mxschmitt commented 3 years ago

Yup for 2 I agree there too. (Afaik only Chromium relies on ffmpeg in the end and the others do it somehow else). Could be added improve that behaviour.

Maybe as a spec proposal to be discussed await page.close({ saveVideos: false }) which drops the videos in the end and does not process them.

LanderBeeuwsaert commented 3 years ago

Jep, that would be the best solution.

pavelfeldman commented 3 years ago

(2) seems like a problem in itself, it does not happen on page close, it should be happening in a streaming manner.

tymfear commented 3 years ago

+1 for canceling video creation option

nmann4 commented 3 years ago

Another +1. I would also be interested in this feature. I have some long running tests and I've noticed that closing the context/page can take a significant amount of time when video recording is enabled.

gkushang commented 2 years ago

+1 on closing context without processing video-frames. We are seeing very slow executions, and I see it may improve the performance.

niyarlatotep commented 2 years ago

+1

rwoll commented 2 years ago

Folded https://github.com/microsoft/playwright/issues/14258 into here which requests being able to start, stop, and then start a video again on a page.

hyphenized commented 1 year ago

+1 for being able to record on demand, would be useful to skip recording altogether while running certain fixtures

marcusNumminen commented 1 year ago

+1 for apis that we can manually control the video recording

mikestopcontinues commented 6 months ago

I'm interested in this feature for more easily automating video generation. Not in a test context, but rather to ensure that documentation videos stay up-to-date with what the app looks like. Right now, it requires too much stitching.

shrektheking69 commented 5 months ago

@mikestopcontinues Can I ask what stitching you had to do to handle this? We are facing the same situation and could not come up with a good solution.

mikestopcontinues commented 5 months ago

@shrektheking69 I'm actually posting in support of a customer I have at BrowserCat. Since you can't guarantee the exact moment you would clip the video, I offered them the following suggestion:

  1. Record the entire session.
  2. Throw a 100% black overlay over the screen when you don't want to record.
  3. Use ffmpeg to clip every black frame from the video. (It has a blackdetect filter built in.)
  4. Voila!

Yes, this sucks, but it's the best I could figure out at the moment.

If you're willing to work with Puppeteer, it supports recording multiple videos. This is also good news for Playwright, because it means the browser already supports flexible video recording.

Sego921 commented 1 month ago

Please complete this task, without it it is impossible to correctly implement the video recording functionality.

It would be nice to implement the recording functionality using the start stop commands, rather than implementing it within the framework of creating and closing page/context.

mikestopcontinues commented 1 week ago

It seems that there's another open ticket (#28183) to enable recording multiple videos at the page level. The former ticket (#14258) was folded into this one by @rwoll. Maybe that one should be too?

Also, does this ticket has the wrong name, if the intention is to enable page-level video controls? Or are there actually two separate issues at play?