4

I was wondering, is upscaling from the videoplayer worse then upscaling the video during encode?

For example, consider the original source of a video is 640 x 480. Which of the following will produce better quality on a 800 x 600 display:

  1. Encode video > play in full screen
  2. Resize video to 800 x 600 > encode > play in full screen

?

My assumption is that a lower quality resizing algoritm is chosen during video playback to save cpu. Am I right?

1

This depends on how much resources you are willing to invest into upscaling content. The default setting for libswscale in VLC seems to be bicubic, if you intend to use more sophisticated resizing filters and a particular target resolution then you should upscale the video during encode this way you also don't have to rely on the capabilities and customizing options of the player device or software.

|improve this answer|||||
1

Upscaling at playback time is done by graphics hardware, not the CPU, so your assumption turns out to be false. Good software players will feed the video through high-quality hardware scaling (e.g. mpv's opengl-hq video-out). HW upscaling might still default to bilinear, though, so it's worth thinking about this.

Upscaling before encode spreads the detail information over more pixels, making more work for the codec. However, there's no new information, and as long as you use a HQ upscaling algo, you aren't adding new detail. (stair-stepping / aliasing artifacts from low quality upscaling looks like detail that a codec has to spend bits to preserve, at the cost of the details you want.) I would guess that you'd get better perceptual visual quality for method 1 (encode,decode,fullscale) than 2 (hq-scale,encode,decode,fullscale). Both relative to source->fullscale, or to source->hq-fullscale. Given the same bitrate for both options, of course.

However, this post in a doom9 discussion about upscaling or not before encoding a dvd backup indicates that this guy got better results from upscaling before encode. (At least when targetting low-qual playback upscalers.) Anamorphic = non-square pixels, in this context. e.g. a 16:9 image stored in 720x480 (square-pixel upscaling would give 853.333:480).

I know I play back all the video I watch using high quality opengl upscaling, but the question is more about making it look good for people using the default video player in Windows and Mac. IDK what kind of video scaling quality you get out of the box. I hope it's pretty good these days, since AMD and NVidia have made their video pipeline a selling point of their graphics hardware. (e.g. HW image postprocessing / high quality stuff). I think Intel does ok too...

I'm also not sure that HQ scaling to an intermediate resolution would even help, if the final upscaler is lower quality. Does anyone have any data on that? The question is whether the quality of the output of a bilinear upscaler gets worse or not depending on how much it has to upscale.

The codec having to work harder to pull out just the information needed to recreate most of the detail could well be overshadowed by the benefit of using a good upscale to a medium rez.

If you wanted to try it out, and have access to a mix of Windows and/or Mac computers with AMD/NVidia/Intel video hardware, then you could experiment just by first comparing a HQ software upscale to fullscreen with what you get from the hw video scaler. Then try a SW upscale to mid rez. Don't bother encoding, or encode to a fast lossless format for a short clip.

Probably if you're expecting people will mostly play back your video on computers (rather than blu-ray & dvd players / other set-top boxes), then not upscaling is probably the way to go. Upscaling a bit to a medium rez is possibly helpful for some HW players, but that might only be when the source doesn't have square pixels.

Upscaling before encoding will increase the encode time. If encoding-time is limited (i.e. you'd have to use lower settings with a higher rez), then probably don't upscale. Better quality at the same bitrate from spending more CPU time per pixel on the encode might be a bigger factor.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.