Skip to content

Conversation

psyke83
Copy link
Contributor

@psyke83 psyke83 commented Nov 7, 2022

Description

  • Revert previous change to software bitrate calculation & bufsize. I was not aware that Moonlight-QT internally scales the requested bandwidth by 75% if HEVC is selected.
  • Add back a more conservative bufsize increase. This still appears to resolve the quality degradation issue seen when using 8/16 slices, and may hopefully resolve the RPI3 decoder issues in PR33 with changed vbv-bufsize causes stuttering on rpi3 #478.

Issues Fixed or Closed

Closes #478

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update (changes to documentation)
  • Repository update (changes to repository files)

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

@psyke83 psyke83 changed the title Change bufsize Video: revert software bitrate change & use more conservative bufsize Nov 7, 2022
@psyke83 psyke83 marked this pull request as ready for review November 9, 2022 00:47
…4 slice count

If the libx264 encoder is configured to use >4 slices, the existing
bufsize (bitrate / framerate) is set too low, causing a quality
degradation and failure for the encoder to attain the target bitrate.

A previous commit set this to a larger value (bitrate / 10), but this
seemed to cause issues with the RPI3 hardware decoder; see: LizardByte#478

Ref: https://trac.ffmpeg.org/wiki/Limiting%20the%20output%20bitrate
"Specifying too small -bufsize would cause ffmpeg to degrade the output image quality, because it would have to (frequently) conform to the limitations and would not have enough of a free space to use some optimizations (for example, optimizations based on the frame repetitions and similar), because the buffer would not contain enough frames for the optimizations to be effective."
@ReenigneArcher ReenigneArcher merged commit cb406bc into LizardByte:nightly Dec 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants