screenshot images low quality

[sleepingwheel]

hey, firstly, thanks for Timecut, really great initiative.
however i struggle to produce crispy enough videos, and from the looks of it, the issue originates in screenshot part (timesnap?), not during stitching the images to video with ffmpeg.

command:
Node timecut/node_modules/timecut/cli.js "https://tungs.github.io/truchet-tiles-original/#autoplay=true&switchStyle=random" --duration=4 --output=vid.mp4 --viewport=1040,1040

system:
Macos Mojave 10.4.6.

p.s.
if it is caused by Chromium, i'm not sure how to troubleshoot or test that.
how would the specific command look like to change path to chrome from chromium?

[Asheboy]

@sleepingwheel You need to add --executable-path= followed by the path to chrome. How you find the path to Chrome on OSX, I am not sure!

[sleepingwheel]

thanks @Asheboy . managed to launch it via Chrome instead of Chromium. the result is the same fuzzy output.

Meanwhile basic screen-capture with Quicktime is much more crisp.

any other tips appreciated.

[Asheboy]

@sleepingwheel I've taken the following steps:

git clone [email protected]:tungs/timecut.git
cd timecut
yarn install
node cli.js "https://tungs.github.io/truchet-tiles-original/#autoplay=true&switchStyle=random" --duration=4 --output=vid.mp4 --viewport=1040,1040 --executable-path='/usr/bin/google-chrome'

and end up with this output https://xfer.clock.co.uk/fW1zL/vid.mp4.

Are you able to try similar and confirm that your issue still persists? Also, can you try running with --no-headless to check that the web page renders correctly there?

[sleepingwheel]

thanks once again for helping. i checked out your output video and must say although quality is a bit better i still see artifacts that prevent me from calling it good quality recording. Maybe you would agree it does look a bit fuzzy. i dont expect lossless quality though.
maybe the problem is deeper, connected to timesnap? previously i noticed that it is specifically the screenshots, not the ffmpeg conversion that is fuzzy.

Comparing timecut with default quicktime recording:

[Asheboy]

@sleepingwheel I've had a look at it in headed mode and the artifacting looks to be being rendered by Chrome, rather than being an consequence of the screen shotting. Have you got a different webpage that you can record to see if it fits your purpose?

[sleepingwheel]

I get the same with every website.
yeah i ran timecut with --no-headless, and in that mode chrome/chromium seem to be zooming in or out for every screenshot. or at least that's what i saw on my screen during recording. not sure if that the way it supposed to be.

but i guess the key here is that your output is roughly the same as mine. maybe better quality is not even available?

the same commands on different website: timecut vs quicktime:

[Asheboy]

@sleepingwheel I see what you mean. I imagine that QuickTime uses Safari and manages to get hold of something better than screenshots to render that quality.

and in that mode chrome/chromium seem to be zooming in or out for every screenshot - I have only ever seen this when using deviceScaleFactor which isn't supported by timesnap currently, so it's funny that you've experienced it here. deviceScaleFactor is actually something that may help you. Below I have two images, one with deviceScaleFactor of 1 and another with deviceScaleFactor of 2. Can you confirm if the second is of good enough quality for you?

deviceScaleFactor 1

deviceScaleFactor 2

It is important to note here that changing the deviceScaleFactor will result in large images. This image is 3840x2160, even though I've set the viewport to 1920x1080.

N.B. The deviceScaleFactor=2 image is actually double the size of

On another note, have you reviewed the screenshots which are taken by using --keep-frames? It should leave a temporary directory in the root of the project. Can you check if these are perhaps better quality? It could be degradation from FFMPEG which is causing some of your issue too.

Thanks for trying these things out for me!

[tungs]

Thanks for filing this! Just to confirm, when you're capturing with QuickTime, are you capturing a Chrome window? The zooming in and out sounds peculiar. Could you record a video (or show an image of the zoom in) of that too?

And as @Asheboy mentioned, using the --keep-frames in timecut should keep the original, lossless frames from timesnap, which should give you an idea of how much is lost in video compression.

There may be a puppeteer option to improve screenshot quality for OS X, but I didn't find it from a quick web search. @Asheboy's mention of deviceScaleFactor sounds like a promising workaround.

[sleepingwheel]

thanks both,
regarding the zooming in-out during no-headless mode, attaching a video of that with --no-headless mode:
https://vimeo.com/383965970

regarding deviceScaleFactor,
would this be the correct command then? does not seem to make a difference to me, but in your #2 screenshot it does look sharper. am i using it incorrectly?
Node timecut/node_modules/timecut/cli.js "https://youtube.com" --duration=2 --output=devicescale.mp4 --viewport=1040,1040 --deviceScaleFactor=2

and yes i can confirm it is the images in the temp folder that are fuzzy, so it does not seem to be ffmpeg fault.

[Asheboy]

@sleepingwheel deviceScaleFactor is not implemented in timesnap currently, so you're unable to test it yourself without making code changes. I can detail these if you'd like?

Regarding the zooming, do you still get this if you set your --viewport to be your full screen resolution? It would be interesting to see if this has any quality changes for you too.

[sleepingwheel]

I can detail these if you'd like?

we can try that, sure. the more details, the better please.

zooming,
yes i get the same if i dont set --viewport parameter or i set it to my full resolution.

[Asheboy]

@sleepingwheel Change this line https://github.com/tungs/timesnap/blob/master/index.js#L161 to:

return page.setViewport({ width: 1920, height: 1080, deviceScaleFactor: 2 });

and then run as normal. It will ignore your --viewport option and use 1920,1080 instead.

[tungs]

Instead of modifying the source, you can also set puppeteer/Chromium/Chrome specific arguments via the --launch-arguments option. So instead of --deviceScaleFactor=2 you could use --launch-arguments="--device-scale-factor=2", or alternatively --launch-arguments="--force-device-scale-factor=2". I'm not exactly sure what the difference is with the force prefix.

You can find a whole list of arguments here. Some may lead to better screenshot quality, though the issue may just be from how puppeteer works on OS X.

Thanks for posting the video link, it's really helpful for understanding what may be going on. It looks like the zooming is occurring under each screenshot capture, though I'm not why that's the case yet.

[tungs]

It looks like other people have had issues with puppeteer's screenshot quality (see puppeteer/puppeteer#1469). The solution offered there is to alter the device scale factor too.

[victorrseloy]

I had a similar problem and the this PR #30 fixed the problem. Do you have plans to merge it @tungs ?

[tungs]

Hi @victorrseloy, thanks for your interest and bringing this to my attention! PR #40 looks useful since it affects screenshot quality, and I'll try to get it merged in the next two weeks.

[tungs]

This enhancement should have been added in version 0.2.0. It can be invoked via something like --viewport="800,600,deviceScaleFactor=2".

Feel free to comment or file a new issue if there are still quality issues.