xiph / xiph/rav1e

--tiles 1 --speed 1 produces lower quality nearly same filesize output than --tiles 8 --speed 3 with same quantizer

Open
#2,002 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug compression performance cursed
Dominant language
Assembly
Stars
4.2k
Forks
292
Avg merge
6d 1h
Merged PRs (30d)
2

Description

The input file was the following: http://fratti.ch/mediasamples/chansu.y4m

Sample A was encoded with --tiles 8 --speed 3 --quantizer 150: https://fratti.ch/mediasamples/chansu_slow.ivf

Sample B was encoded with --tiles 1 --speed 1 --quantizer 150: https://fratti.ch/mediasamples/chansu_slower.ivf

As one can see, sample B took longer to encode (duh), looks worse in several places that I could find, and is larger than about the same size as sample A.

My expectation is that the encoder being allowed to use slower algorithms and look at the entire frame should produce higher quality or lower filesize output at the same quantizer level.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the report using chansu.y4m and the two command lines, then compare encoded quality, filesize, and runtime for the linked IVF samples. Determine whether the slower single-tile configuration is expected to improve results; done means the behavior is explained or corrected and the comparison is covered by an appropriate regression check.

Written by the indexing model from the issue text.

Assessment

Domain
performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.